Email web hosting - 13.1.3 The Business Interface When using a session
13.1.3 The Business Interface When using a session fa ade, you must first define the details of the interface between the web and application tiers. You might have some questions about which side should be the primary driver of this contract between the two tiers. Early in the development of the Storefront example, the IStoreFrontService interface was introduced to define the application-tier functionality required to support the presentation needs of the application. In particular, the presentation layer relies on the supporting service to authenticate users and to provide product descriptions needed to build the online catalog. Taking a user-centered view of the application, it’s easy to see how the service-layer requirements can be driven by the web tier. After all, if a certain view is to be built, the model functionality to support it has to exist. However, one of the main reasons to implement an enterprise’s business logic within EJBs is to allow those business rules and the supporting data to be used to across multiple applications. This includes providing support for clients other than those associated with web applications. This isn’t a problem, because the division of responsibility between session and entity beans helps to protect the reusability of business logic. Because session beans are treated as extensions of the clients they serve, there’s nothing wrong with defining a session fa ade that’s specific to a particular client application. As long as your entity and message-driven beans remain independent of the client, it’s reasonable to implement a session-bean interface in response to the requirements set forth by a specific client. If multiple client views of the model are required, multiple fa ades can be implemented to support them. The fa ade presented by a session bean can support either local or remote clients. Local clients of a session or entity bean can only be other EJBs deployed within the same container. These clients are tightly coupled to the beans they access, but they offer performance advantages when calls need to be made between EJBs. This is because these method calls use pass-by-reference semantics instead of being treated as remote calls between distributed components. Session beans are often local clients of entity beans, but it’s less common for them to have local clients of their own to support. Our web-tier components obviously aren’t EJBs running within the application tier, so we care only about remote clients for our purposes here. What we need to do, then, is define the remote interface for our session fa ade. Every session bean that supports remote clients must have a corresponding remote interface that extends the javax.ejb.EJBObject interface. This interface determines the business methods that are exposed by the session bean. It might seem strange, but you’ll almost never see a method explicitly declared in a remote interface. This is because of an EJB design pattern known as the business interface. Besides its remote interface, a session bean supporting remote clients must have a home interface that extends javax.ejb.EJBHome, an implementation class, and one or more XML deployment descriptors. Unlike the remote interface, which declares the bean’s business methods, the home interface defines factory-like methods for creating session-bean references. By definition, the bean’s methods are implemented by the implementation class. The deployment descriptors identify and configure a bean for use within a particular EJB container. We’ll define each piece for our example as we go along. When you think of a class and an interface with which it’s associated, you would normally expect that the class would explicitly implement that interface. This isn’t true with remote (or local) interfaces in EJB. Instead, the container creates an intermediate object (often referred to as an EJBObject) to
In case you need affordable webhost to host your website, our recommendation is ecommerce web host services.