implement the (Web site traffic) remote interface. This object intercepts calls
implement the remote interface. This object intercepts calls made by clients of the bean, then delegates them to the implementation class after performing any operations (such as security or transaction management) that might be required. Instead of the Java compiler verifying that the bean class implements each of the business methods declared by the remote interface, that responsibility falls to the deployment tools provided by the container. Even a bean class that compiles without any errors will fail at deployment if there’s a mismatch between it and its remote interface. If you declared a session bean to implement its remote interface, you’d be guaranteed that the compiler would catch any problems with its business-method declarations. The problem is that you’d also have to provide dummy implementations of the non-business methods declared by javax.ejb.EJBObject. These methods would never be called (they’re called only on the intermediate object created by the container), but they would have to be there to satisfy the compiler. Instead of taking this approach, most EJB developers create a second interface, known as the business interface, that declares the business methods that need to be exposed. Declaring the remote interface to extend this interface and the bean class to implement it exposes the required methods, so the compiler can verify that the bean implements them. This pattern provides a convenient starting point for defining our client access mechanism. The use of a business interface also prevents programmers from accidentally passing or returning a this reference to an instance of a bean class that has been declared to implement its remote interface. This topic is beyond the scope of this book, but the short explanation is that the EJB container can manage bean instances properly only when they’re referred to using only their remote (or local) interfaces. A bean reference can’t be returned in place of its remote interface if the bean class implements only its business interface. Returning to the IStorefrontService interface that eventually must be satisfied by our implementation, recall that it contains methods related to both user authentication and the product catalog. Even when using a session fa ade, you would likely separate these responsibilities into separate session beans. This would reduce the complexity of the session beans involved and simplify their maintenance. However, given that EJB design isn’t our focus here, our first simplification will be to assume that our fa ade will consist of a single Storefront session bean. You probably wouldn’t do this in a real application, but once you know how to interface with a single session bean, applying the same technique to multiple session beans is straightforward. A suitable business interface for the Storefront session bean is shown in Example 13-1. Example 13-1. The business interface for the Storefront session bean package com.oreilly.struts.storefront.service; import java.rmi.RemoteException; import java.util.List; import com.oreilly.struts.storefront.catalog.view.ItemDetailView; import com.oreilly.struts.storefront.customer.view.UserView; import com.oreilly.struts.storefront.framework.exceptions.*; /** * The business interface for the Storefront session bean */ public interface IStorefront {
We recommend cheap and reliable webhost to host and run your web applications: Coldfusion Web Hosting services.