Understanding the EJB Session Bean Facade Architecture

This architecture is an extension of the three-tier pattern, with the addition of EJB session beans wrapping the access to the application tier. The EJB session beans provide public API access to application operations, enabling you to separate the presentation tier from the application tier. The architecture also lets you use the EJB session beans within a J2EE container.This type of architecture generally includes JTA integration, and serialization of data to the client.

Figure 2-5 Three-Tier Architecture Using Session Beans and Java Objects

Description of "Figure 2-5 Three-Tier Architecture Using Session Beans and Java Objects"

A common extension to the three-tier architecture is to combine session beans and persistent Java objects managed by TopLink. The resulting application includes session beans and Java objects on a TopLink three-tier architecture (see Figure 2-5).

The three-tier architecture creates a server session and shares it between the session beans in the application. When a session bean needs to access a TopLink session, the bean obtains a client session from the shared server session. This architecture has the following key features:

• Session beans delimit transactions.

  Developers must configure TopLink to work with a JTA system and its associated connection pool.

• Accessing the persistent objects on the client side causes them to be serialized.

  Ensure that when the objects re-emerge on the server-side, they properly merge into the cache to maintain identity.

Example Implementation

An example of the EJB session bean facade architecture implementation is a Model-View-Controller Model 2 architectural design pattern that runs in a J2EE container with servlets and JSP and uses the session bean, enabled by TopLink, to access data without EJB.

Advantages and Disadvantages

The EJB session bean facade architecture is a popular and effective compromise between the performance of persistent Java objects, and the benefits of EJB for standardized client development and server scalability. It offers several advantages:

• Less overhead than an EJB entity bean application

  TopLink shares access to the project, descriptor, and login information across the beans in the application.

• Future compatibility with other servers

  This design isolates login and EJB server-specific information from the beans, which lets you migrate the application from one application server to another without major recoding or rebuilding.

• Shared read cache

  This design offers increased efficiency by providing a shared cache for reading objects.

The key disadvantage of this model is the need to transport the persistent model to the client. If the model involves complex object graphs in conjunction with indirection, this can present many challenges with inheritance, indirection, and relationships.

For more information about managing inheritance, indirection and relationships, see Part X, "Mappings".

Understanding Session Beans

Session beans model a process, operation, or service and as such, are not persistent entities. However, session beans can use persistence mechanisms to perform the services they model.

Under the session bean model, a client application invokes methods on a session bean that, in turn, performs operations on Java objects enabled by TopLink. Session beans execute all operations related to TopLink on behalf of the client.

The EJB specification describes session beans as either stateless or stateful.

Stateful beans maintain a conversational state with a client; that is, they retain information between method calls issued by a particular client. This enables the client to use multiple method calls to manipulate persistent objects.

Stateless beans do not retain data between method calls. When the client interacts with stateless session beans, it must complete any object manipulations within a single method-call.

Technical Challenges

Your application can use both stateful and stateless session beans with a TopLink client session or database session. When you use session beans with a TopLink session, the type of bean used affects how it interacts with the session.

• Stateless Session Beans and the TopLink Session

  Stateless beans store no information between method calls from the client. As a result, re-establish the connection of the bean to the session for each client method call. Each method call through TopLink obtains a client-session, makes the appropriate calls, and releases the reference to the client-session.

• Stateful Session Beans and the TopLink Session

  Your EJB Server configuration includes settings that affect the way it manages beans–settings designed to increase performance, limit memory footprint, or set a maximum number of beans. When you use stateful beans, the server may deactivate a stateful session bean enabled by TopLink out of the JVM memory space between calls to satisfy one of these settings. The server then reactivates the bean when required, and brings it back into memory.

  This behavior is important, because a TopLink session instance does not survive passivation. To maintain the session between method calls, release the session during the passivation process and re-obtain it when you reactivate the bean.

• External JDBC Pools

  By default, TopLink manages its own connection pools. For the session bean architecture, you must configure TopLink to use connection pooling offered by the host application server. This feature is useful for shared connection pools and is required for JTA/JTS integration (see "Configuring External Connection Pooling").

• JTA/JTS Integration

  JTA and JTS are standard Java components that enable sessions to participate in distributed transactions. You must configure TopLink to use JTA/JTS to use session beans in the architecture (see "Integrating the Unit of Work With an External Transaction Service").

• Cache Coordination

  If you choose to use multiple servers to scale your application, you may require TopLink cache coordination (see "Understanding Cache Coordination").

Unit of Work Merge

You can use a unit of work to enable your client application to modify objects on the database. The unit of work merge functions employ mappings to copy the values from the serialized object into the unit of work, and to calculate changes.For more information, see "Merging Changes in Working Copy Clones".