Java Reference
In-Depth Information
directly to the Home or Remote implementers, but to the stubs that then communicate with matching server-side
implementers. This demonstrates the application of the HOPP pattern, and it is used for all EJB communication.
Factory Method
(see page 21): EJBs use the Home interface as the first point of contact for an EJB resource.
Clients, whether servlets, JSPs or other EJBs, call a create or locate method on the Home in order to obtain a
reference to the Remote stub, which can then be used to call business methods. The fact that the create method
triggers the creation of Enterprise Bean resources suggests that a Builder pattern is present for EJBs. Technically,
the pattern goes a bit beyond the simple Factory Method, since it generally involves creating a support framework
for the Enterprise Bean as well. For instance, calling create on a Stateful Session Bean triggers creation of both
the Bean itself and the Bean's remote implementer.
Proxy
(see page 197): Conceptually, you could say that Enterprise JavaBeans provides Proxy-like pattern
behavior, because method calls to both the Home and Remote interfaces are ultimately translated to calls on the
underlying Enterprise Bean. Of course, there is processing which occurs and a change in the method name being
called, so the structure does not represent a classic Proxy implementation.
Session
(see page 220): EJBs support the Session pattern through the Stateful Session Bean. It's important to
recognize that this pattern only applies to Session Beans that are explicitly designed to be Stateful. The Stateless
Session Bean does not maintain the concept of consistent caller identity, so even if it does persist data over time,
the data cannot be associated with a specific client.
Connector Pattern Use: Factory Method
J2EE offers a great many APIs to bridge between different enterprise technologies. This is only natural, since the
express purpose of the J2EE architecture has more or less always been to allow integration with as many
enterprise systems as possible. The basic model for connector technologies is tried and proven—it represents the
refinement of a model that was pioneered in JDK1.1 with JDBC.
For connector technologies, the API defines a programming abstraction, a layer of code between the Java
application and some underlying implementation. The implementation may be the system or service itself, but
more frequently it tends to be a translator, an adaptor module between the API and the actual end resource.
By defining a code model in this way, it's possible to make a fairly generic API, something that can be used for
generic capability programming, then applied to any one of a number of implementations within a family of
technologies.
The J2EE APIs that represent connector technologies are shown in the following list
Java Messaging Service (JMS) - Connector API to asynchronous messaging services. Examples include
JMQueue and JMX.
JavaMail - Connector to e-mail technologies such as POP3.
Connector Architecture - A generic connector API, supporting a variety of Enterprise Information System (EIS)
resources, such as nonrelational databases and ERP systems.
Two other J2EE connector technologies already discussed in this section are:
Java Database Connectivity API (JDBC)
Java Naming and Directory Interface (JNDI)
Regardless of the specific technology being used, certain design patterns tend to naturally occur because of the
general architecture and distributed model behind the connector model. Since most of the connector technologies
rely on JNDI to supply initial connection capabilities to callers on any of the tiers, the connectors typically
provide a connection factory, which implements the Factory Method design pattern. Conceptually, most of the
connectors also provide adaptor capabilities, at least at an architectural level
Architectural Pattern Use
A few patterns within J2EE are more accurately associated with the architecture as a whole than with any single
technology. Because J2EE operates as a federated enterprise model, many of these patterns can be leveraged at a
number of points, or even multiple points, within a J2EE system. Since J2EE is a flexible architectural model
