The SessionEJB layer presents the public interface to the application domain and, in this context, to the EJB Container, thereby providing the public interface to the application's business logic or semantic processing. It resides between the Web Container and the DomainMapper layers or, more specifically, in the architecture shown here, between the UIModel and the DomainMapper layers. Its primary function, by general "best practices" agreement, is to provide a context for transactions and for access control and/or authorization at the method level.
Generalizing Session EJBs is more interesting and more challenging conceptually than generalizing J2EE layers implemented using conventional Java classes. The conventional way to generalize a SessionEJB would be to create, for example, a SessionOOCBean, declare it to be abstract, include an abstract method to get an appropriate DomainMapper, and then define the basic CRUDS methods using DataBeans as parameters and calling the corresponding CRUDS methods in the particular mapper. The reason this can't be done is that the EJB 2.0 specification precludes SessionBeans that are either final or abstract (EJB2.0:7.10.2).
So, how can one get around this limitation? The solution shown here was developed by one of us (Brown) and implemented by the other (Smith). We will look first at the conventional EJBSession class/interface relationships and then at the relationships used for a generic OOCSession and its subclasses. Since this part of the discussion is general, the latter is referred to as SessionX, rather than SessionSet -- the example session used for illustration of the actual code.
Conventional EJBSession
Recall that EJBs are never created directly, but rather, through an EJB container. Second, whether accessed as a local or a remote object, both the container, in the form of a EJBSession's Home, and the Session Bean, are accessed through stubs, normally generated by a development tool such as WebSphere Studio. These stubs, of course, are generic objects, so they must be cast according to an interface specific to a particular EJBSession.
With these factors in mind, consider the relationship diagram shown above. The SessionXBean represents an actual Session class or object, in this case named X. It is implements the generic SessionBean interface that includes the bean's life-cycle methods -- activate, passivate, remove and setSessionContext. The methods specific to a given EJBSession are defined in the SessionX interface and implemented in the SessionBeanX class, but that class does not literally implement the SessionX interface. Rather, it is literally implemented by the generated stub, in this case _SessionX_Stub, which is the object actually provided to a client as a surrogate for the SessionBean. Thus, when one obtains this stub, through a factory object or a lookup, one casts it according to the Session interface -- SessionX in this case.
SessionOOC -- SessionX
In the discussion that follow, we'll look first at the interfaces ISessionOOC and SessuionSet interfaces, then at the design and implementations of the SessionOOC and SessionSetBean classes.
Session EJB Interfaces
The MapperOOC superclass includes the standard CRUDS methods. Those that change the data in persistent storage and, hence, could leave the database in an inconsistent state were they to fail at some intermediate stage can throw the custom exception, OOCTXException.
Session OOC
SessionOOC[Impl] serves as the superclass for more specialized OOC Session EJB Bean classes. Since the EJB2.0 specification precludes abstract methods for SessionBeans, it extends Object and implements the SessionBean interface, as do conventional SessionBeans. It implements the five CRUDS methods plus several lifecycle methods required for the SessionBean interface.
Session Set
SessionSetBean is the EJB Session object that implements the actual logic. It subclasses SessionOOCImpl, which contains the five CRUDS methods. It implements the two abstract methods of the supeclass that return an appropriate DomainMapper and return the same of the Session EJB, respectively.