Modeling Session Bean Relationships
A session bean can have relationships with other components and classes, for example, JavaBeans, other session beans, servlets, and so on. Modeling of such relationships is discussed in this section.
Session Beans and Plain Java Classes
A session bean is just a pattern application to a set of Java classes, and there is nothing inherently unique about the individual elements that collectively make up a session bean. As such, the relationships between a session bean element and other Java classes are quite ordinary. For instance, an EJB implementation class could utilize a number of Java classes to fulfill its needs. In such cases, a session bean would invoke methods on a Java class just as another Java class would.
Figure 12-15 shows an example of modeling a session bean and other Java classes.
Figure 12-15. Session bean and Java classes
Session Beans and JavaBeans
Session beans and JavaBeans can be used together in various fashions. For ex ample, a JavaBean may be used as a way of exchanging information between session beans and other JavaBeans in an enterprise application.
An interesting pattern[5] is to use a JavaBean as an accessor to a session bean. This has the advantage of providing a very simple interface to the client yet hides the full power of the EJB architecture behind the simple JavaBean.
[5] Outlined in Using JavaBeans as Accessors to Enterprise JavaBeans by Andre Tost, October, 1999, published by IBM Developerworks.
Session Beans and Servlets
Servlets are often used as intermediaries between session beans and the user interface. For example, a servlet gets invoked to handle the incoming HTTP request. The servlet in turn calls upon a session bean to perform some specific tasks.
In such a situation, it is the servlet that invokes the session bean. As such, the servlet may also be responsible for locating the session bean on behalf of the client and instantiating the bean to handle incoming requests.
On a class diagram, such relationships are shown as dependencies or unidirectional associations from a servlet to a session bean. If the servlet doesn't need to be associated with the same session bean over time (e.g., a stateless session bean instance that is different each time), a dependency is appropriate for modeling the relationship. Otherwise, a unidirectional association would better serve the modeling.
An example is shown in Figure 12-16. Optionally, a servlet to session bean association may be stereotyped as <<instantiates>> to clearly identify that the servlet uses the session Home interface to create the session bean.
Figure 12-16. Servlet and session bean relationships
Some J2EE practitioners have argued[6] that servlets, rather than processing the request and response, should primarily focus on identifying and instantiating the appropriate session beans suitable for the task at hand, and then simply forward the request and response objects onward for the session bean to process. The argument is that it makes sense to use servlets when you are dealing with a Web browser, but as the clients become diverse, it makes sense to make the presentation logic client-agnostic and independent.
[6] See, for example, “Presentation Logic and EJBs: Using session beans to help bridge the Java-HTML gap” by Michael Lacy, Java Developers Journal, May, 2000.
Session Bean and JavaServer Pages (JSP)
A JSP relationship with a session bean is essentially similar to that of a servlet and a session bean. An example is shown in Figure 12-17.
Figure 12-17. JSP and session bean relationship
However, even though a JSP gets compiled into a servlet, it is generally preferred to use a JSP for presentation aspects and not embed detailed logic within the JSP as you would in a servlet. One approach is to use a JSP to call upon a servlet, which is then responsible for interacting with the session and/or entity beans.
Session-to-Session Relationships
A session bean may need to interact with other session beans to fulfill its responsibilities. For instance, you may use a stateful session bean to manage the subcontractor order placement session, and the stateful session bean may need to interact with a stateless session bean to obtain authorization for accepting the order.
As another example, consider a possible implementation of a shopping session. The user shopping session may be managed by a session bean, which has a one-to-one relationship with a cart bean.
Such relationships are modeled as association or dependencies between session beans. If a session bean needs to retain information about the other bean for an extended period of time, that is, in between business methods, the appropriate method is to use an association. Otherwise, a dependency is sufficient.
Using bean-to-bean relationships of this sort is sometimes referred to as session bean chaining. Session bean chaining involving a single stateful session bean and multiple stateless session beans is reasonable; however, caution is warranted if you are chaining several stateful session beans together. Due to the stateful nature of the session beans, it may take significant effort to set up the chain, so recovering from failure in the chain can be very time-consuming.
Figure 12-18 shows an example of a session bean-to-session bean relationship.
Figure 12-18. Session bean-to-session bean relationship
Session Bean Inheritance
The current version of the EJB specification does not specify a mechanism for EJB component inheritance. That is, subclassing of an entire EJB at once, such that you benefit from the interfaces as well as the implementation class. Some server vendors may support such EJB inheritance, but use caution if portability is a consideration.
The current recommendation is to subclass the Home and Remote interfaces and the implementation class separately, and then use them as the basis for creating new session beans.