Enterprise JavaBeans

Packages

javax.ejb, javax.ejb. spi

Use: J2EE (J2EE1.2)

Description

In a sense, Enterprise JavaBeans are the heart and soul of the J2EE architecture. They represent the core business model, defined in terms of a collaborating set of components. EJBs are used to enforce business rules, to encapsulate business logic, and to encompass the business model within an enterprise application.

There are three fundamental categories of EJBs:

Session Beans – EJBs that directly support business logic. Session Beans can be either Stateful or Stateless. A Stateful Session Bean is associated with a specific client session, while a Stateless Session Bean represents a generic business resource, not dependent on any specific client caller.

Entity Beans – Designed to be directly associated with a DBMS or other persistent data store, providing an “objectized” form for the data

Message-driven Beans – Designed to be asynchronous receivers of message notifications from JMS technology. These beans can receive and react to messages using the JMS API as a J2EE application runs.

To create an EJB, you need to write three Java code elements:

A Home interface, used to manage the EJBs lifecycle (contains create, locate and remove methods)

A Remote interface, used to define business methods

The Enterprise Bean implementation

In addition, you write an XML document called a deployment descriptor that specifies details about how the Enterprise Bean should be managed: it contains configuration, administration, and resource management information.

EJBs, even more than the other J2EE component technologies, depend strongly on their containers. In a very real way, EJBs need their underlying container to create them, call them—really, to regulate every aspect of their life.

It's interesting to observe that the entire EJB architecture is interface-based. The only real classes that are defined for the model are the exceptions. This illustrates even more dramatically the dependence of an EJB on its container, since part of the task of the container is to generate the support code that implements the Home and Remote interfaces and ties both of them to the underlying Enterprise Bean.

Deploying an Enterprise Bean involves producing the classes which implement the Home and Remote interfaces. It involves providing code to map between method calls on the interfaces and actual method invocations on the underlying Bean. In some cases, it involves producing additional management code based on information supplied in the deployment descriptor.

It's often a big adjustment to former middleware programmers to “let go” and accept that the container takes care of the additional services required by the EJBs. It can be difficult to get used to the concept of large amounts of support code being automatically produced.

General Pattern Use

Enterprise JavaBeans have a number of patterns, but many of them are supplied by the container, implemented by the underlying framework as part of the task of producing a functional, integrated EJB.

HOPP (see page 189): Clients never interact with an Enterprise Bean directly. They always pass method calls to either the Home or Remote interface, which then trigger calls to an EJB. You could say that clients don't even talk

215

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

216

which consists of a number of tiers which can be used together, the APIs that support these patterns can be used at a number of points, or even multiple points, within a J2EE system.

Transaction (see page 265): Frequently, the connectors link a J2EE application to some other system which supports transaction management. The Java Transaction API (JTA) provides support for distributed transaction coordination—what is commonly called a two-phase commit. For technologies that support this API, they must be general transactional services. This in turn means that they must support the Commit/Rollback pattern.

Session (see page 220): J2EE also provides support for the Session pattern. The incentive for using this pattern within a J2EE model is clear: mid-term data persistence is usually important in an enterprise application. Most non-trivial business operations require some form of intermediate storage, to maintain state between operational phases or to ensure that the data will not be lost or corrupted while in flux.

In a typical enterprise application, short-term data is stored on the clients and long-term data is stored in a database or other EIS resource. Somewhere between these two extremes is data that is related to business process; that is, to work that is being done and requires several actions to complete. Mid-term persistence is what the Session pattern is all about: the storage of information that is in flux due to a client's interaction with the system. J2EE is an n-tier system, so there are a few options for where to store Session data:

On the client tier – J2EE Web clients can use cookies to store session-based information.

On the web tier – The servlet API defines an HttpSession interface to address client storage requirements.

On the EJB tier – Stateful session beans serve this purpose, as defined in the EJB specification.

217

Appendix A. Full Code Examples

System Requirements

This appendix includes full, runnable code examples for each pattern. Most of the patterns in the main part of this book included only the code that is crucial for your understanding of the pattern. This appendix includes all required class files, and a RunPattern class, which shows you how the code runs, and includes print statements specifying what occurs in the code.

The following patterns use Remote Method Invocation ( RMI ) in their code examples: Callback, HOPP, Router, Session, Successive Update, Transaction, and Worker Thread.

To run these examples, your computer must be network-enabled. Specifically, your system must be able to use TCP/IP sockets for networking and recognize " localhost " as a valid loopback IP address.

The rmiregistry is started from the RunPattern file in each of these examples. Because rmiregistry is a server process, these examples will appear to block when they are finished. You must manually terminate the Java process to exit the rmiregistry.

218