Patterns and Idioms
You now know all the important theory behind writing Session beans, but it's always helpful to have one or two real-world insights into how to write them in practice. Patterns (or more fully, “design patterns”) are documented pearls of wisdom. Idioms are much the same thing, although they tend to be more lower-level and code-oriented.
On Day 18, many of the design patterns discussed piecemeal throughout the book will be brought together to see how they apply to all aspects to the J2EE environment. Some of those given here will be presented more fully. But for now, there are patterns and idioms specific to writing session EJBs. Reading this section might save you some time.
Business Interface
One of the peculiarities of the EJB architecture is that there is no direct link between the defined remote interface and the bean that provides the implementation. For example, the remote interface Advertise is not implemented by AdvertiseBean. However, no link is needed because the EJB specification declares that it is the vendor's deployment tools that are responsible for ensuring that every method defined in the remote interface has a corresponding method in the bean, and that the required methods for the home interfaces also exist.
However, this means that any mismatches between the interface and the bean's implementation will be picked up not during compilation, but during deployment. From a practical point of view, this can make debugging the problem harder. After all, you are probably accomplished at reading compile errors and figuring out what the cause of the problem is. But you won't (at least initially) be familiar with the errors that the vendor's deployment tool throws up when it announces that your bean does not comply with the EJB specification.
One idiom that solves this is to create an additional interface that defines just the business methods. This interface is sometimes called the business interface. Then, the bean implements the business interface, while the remote interface for the bean extends that business interface.
This hasn't been done in the case study, so as not to complicate and confuse. However, it would be simple enough to introduce a business interface. Figure 5.16 shows a UML class diagram that illustrates this for the Advertise bean.
Figure 5.16. Defining a business interface means that the bean can implement that interface.
With this idiom, if there is a mismatch between the interface and the bean, it will be picked up during compile time.
There is just one subtlety of which you must be aware. When applying this technique to the remote interface of a bean, the methods in the business interface must all throw java.rmi.RemoteException. This is because the vendor-generated EJBObject for the remote interface must follow the rules of remote objects, so that every one of its public methods throws the RemoteException. This applies also to the inherited methods of the business interface. The AdvertiseBus interface is shown in Listing 5.6.
Listing 5.6. AdvertiseBus Interface
RemoteException;
7: String getName() throws RemoteException;
8: String getEmail() throws RemoteException;
9: String[] getAddress() throws RemoteException;
10: String[] getJobs() throws RemoteException;
11: void createJob (String ref) throws RemoteException, DuplicateException,
Adapter
As you write your EJBs, you will quickly find yourself writing reams of “boilerplate” code. For example, the setSessionContext() method almost always just saves the session context to an instance variable. The ejbActivate() and ejbPassivate() methods often do nothing at all.
If you have written any GUI applications using AWT or Swing, you almost certainly will have used the various Adapter classes in the java.awt.event package. For example, the java.awt.event.WindowAdapter class provides empty implementations of the seven methods in the java.awt.event.WindowListener interface.
Adapter classes can also provide common default functionality. For example, the AbstractList class acts as an adapter to the List interface in the java.util package, providing the majority of the implementation required. Although the List interface defines 25 methods in total, the AbstractList class implements all but two of them.
Creating an adapter for your Session beans can save you time in the long run. You can provide default implementations for many of the lifecycle methods, and can also provide additional methods. For example, you might decide to provide a log() method that will forward any log messages to some remote URL or to a logging database.
Coarse-Grained
Remote Session beans should offer coarse-grained services. In other words, the services offered by a remote Session bean should do large(-ish) chunks of work. The overhead of the network to use these beans then becomes much less significant.
There are a number of approaches for arranging this. One approach is to create value object classes. These are serializable objects that encapsulate enough information for the Session bean to provide some service. The client populates these value objects and then sends them across the wire as part of the remote method call. The Session bean then interrogates its copy of the value object to accomplish its work. You will learn about the value object pattern and some related patterns more fully on Day 18.
The value object idea as described is to encapsulate enough data in an object such that the Session bean can do a reasonable chunk of work, but the responsibility for figuring out what that chunk of work is still resides with the Session bean. A natural extension to this concept is to place that responsibility into the value object itself. In effect, the value object represents the action or command to be invoked. Indeed, the name of this design pattern is the Command design pattern.