17.1 Enterprise JavaBeans Architecture

EJB components are similar to servlets/JSP pages in that remote access is built-in. You don't need to write any remote infrastructure to implement multitier architecture designs. Declaring a bean to be remote generates all of the code required to make the bean run remotely. Just as the HTTP protocol mediates remote access for web-based clients, the SOAP and/or RMI/IIOP protocols enable remote access for EJB components. Using standard remote protocols allows you to focus development on the application logic instead of protocol-handling.

But there are two significant differences between servlets/JSP pages and EJB components.

First, declarative transactions and distributed transactions are built into EJB components. As an application developer, you don't need to code transactions explicitly into your application logic. Transactions are applied to applications declaratively, not embedded into code. During application assembly, the assembler specifies the transaction attributes of each method. Assembly combines application components into larger applications and preserves transaction semantics. Distributed transactions (transactions that include multiple resource managers) are handled for your application as transparently as local transactions (those that involve only one resource manager).

Second, security is built into EJB components. You don't need to write security protocols or worry about credentials. Methods and resources are declared to require security checks; these are administration issues, not programming concerns. Similar to method-transaction associations, methods that require a specific security context are identified during application assembly.

The flexibility of transaction and security associations come at a cost. Each time a method is executed via the local or remote interface, the container checks the transaction and security requirements of the method against the current thread's transaction and security context.

EJB components come in four flavors:

Stateless session beans

Stateless session beans are the simplest enterprise beans. They have no fixed association with any particular client. They serve as message endpoints to service clients for execution of remote or local methods defined in an interface. The interface typically defines a service contract with clients. Each business method is self-contained and doesn't rely on the results of any previous method.

Stateful session beans

Stateful session beans are service endpoints created on behalf of specific clients for execution of remote or local methods defined in an interface. They implement conversational behavior with clients. Results of business methods can be stored in the bean for use by subsequent business methods.

Entity beans

Entity beans model a persistent entity, which might be a record or row in an enterprise information system (EIS) or relational database, or a collection of related records. Entity beans are identified by a primary key.

Message-driven beans

Message-driven beans serve as the endpoint for a queue or topic to a Java Message Service (JMS) or some other messaging implementation. They implement synchronous or asynchronous queued service requests.

Your applications can exploit JDO as a component for integration into EJB architecture servers in conjunction with other components. Servlets, JSP pages, session beans (both stateful and stateless), and message-driven beans can use JDO persistent classes to implement business objects, either directly as data-access objects (DAO) or through business delegates.

We start the discussion of high-level architecture by reviewing two aspects of our Media Mania application: casual browsing of the offerings in the store and business transactions, such as purchase or rental of media. The front end to both of these is the Web, but for business transactions we delegate to the EJB tier.

In Chapter 16, we discussed some techniques for accessing persistent data from JDO instances. Using a combination of servlets and JSP pages, clients can browse the offerings of the store, and the servlets/JSP pages maintain persistent information about their items while shopping. Once a collection of items has been selected for purchase or rental, we want to complete the transaction and we choose to implement the business logic using EJB components.