A
EJB Architectures Summary

Enterprise JavaBeans present a way to build components as well as a means to make these components exist in a transactional, secure, and distributed environment. However, a single bean represents only one component - and consequently only one part of a complete application. EJB provides developers with flexibility in determining how these components should be made to work together. There are a number of ways in which Enterprise JavaBeans can be made to work together to form a complete enterprise application. TopLink can be integrated into each variety of EJB application architecture to provide both the technology that enables these architectures and the features that add value to them.

This chapter gives an overview of some of the basic design patterns available when using TopLink and TopLink CMP. It is not meant to be prescriptive and neither is it complete. It briefly suggests some of the more useful EJB designs and their suitability to specific applications. Architects and developers may find these sections useful at the early stages of application design. As more experience is acquired the appropriateness of particular patterns will become more obvious, and architectural decisions will be more intuitively reached.

Note: Although discussed in the context of EJB 2.0, the architectures presented in this chapter are still valid in an EJB 1.1 environment. Any time entity beans are mentioned in terms of their local interface, these can be replaced with beans using their remote interface. The only downside to this strategy is the extra overhead involved with remotes.

Introduction to EJB architectures

The basic ways in which EJBs can be assembled, or the basic "EJB architectures", can be described in terms of which kinds of beans or J2EE components are used, how client applications access them, and how the underlying "domain objects" are represented. The EJB architectures can be fundamentally divided into three categories: an Entity bean architecture, a Session bean architecture, and a Session and Entity "tiered" approach. Each basic architecture also has variations and refinements and can be decorated with a variety of J2EE components.

The EJB specification does not dictate how enterprise entities are used, but it is clear from the evolution of the specification that certain architectures were assumed to be dominant. Some of the recommended architectures are explained in the J2EE Blueprints (see http://java.sun.com/blueprints). These documents should be reviewed for more information about J2EE and EJB architectures.

Remote Entities

If entities alone are used then they must have remote interfaces that expose all of the client servicing methods. In the absence of Session beans, the client may only access entity state through its remote interface, and may not traverse relationships, except as encapsulated by remote method calls. Only remote references and data may be returned by these calls. Finders may only return remote references as well.

Figure A-1 Remote entities architecture

Text description of the illustration rementar.gif

Clients gain from this approach in that the distribution of the entities is transparent. Clients reference the entities as if they were local, and do not need to worry about location. Entities can exist at different locations without the client even being aware of it.

The converse of transparent distribution is that if clients are not aware of the distributed nature of the entities then they may not be aware of the cost of invoking them. If the entities are "fine-grained" objects then each fine-grained method invocation on them will end up being a remote call. The accumulation of these remote method invocations could sum up to a potentially serious network or communication latency cost.

If Container transactions are used for each entity operation a separate transaction will end up being initiated for each method invocation. This could introduce excessive and unnecessary transaction management overhead if client-demarcated UserTransactions are not used.

Since Entity beans are intended to be "components" there are more restrictions placed on them than on regular Java objects (e.g. thread-spawning is disallowed). This may impose limits on how they can be used to model certain domain concepts. The limitations should be well understood and compared against the model to ensure that they are not discovered too late in the design phase.

In general, however, this architecture is less desirable than other architecture types. The relationship limitations imposed by the EJB specification are often an impediment to using this approach.

Advantages

• Increased distribution

• Potential for greater location transparency

Disadvantages

• Not suitable for fine-grained entities

• Communication overhead for each method call

• Transactional costs of each method call

• Client accesses many EJB interfaces (no single client interface or point of server entry)

• Much of the business logic must reside on the client

Remote Session beans

It is common practice to apply a Session bean layer in front of lightweight objects. This may take the form of the session façade pattern described below, with lightweight entities or other types of persistent objects being managed.

Figure A-2 Remote session beans architecture

Text description of the illustration remsessb.gif

Since Session beans do not themselves represent durable objects, often a session façade pattern will be used to converse directly with persistent Java objects, without the use of entities. Persistent data can be modeled using regular TopLink-enabled persistent Java objects that are managed by the Session beans and mapped using TopLink tools. Since few domain objects actually "live" on the client, client applications rarely need to access the domain objects directly, but if regular objects are used then they may be sent to the client if necessary since no such restriction exists for them. The Session beans are used to carry out most of the application logic. Stateful beans are used for those operations for which client-identity is important, while stateless Session beans can be used for "single-shot" operations. All of the EJB benefits of security, transactions and distribution are available through the Session beans.

The exclusive use of Session beans does not allow for overly complex client behavior - all client behavior is limited to services provided by the Session beans. Simple client behavior is a general characteristic of all thin client architectures.

Simplicity and fast client access are clear benefits of this approach. In addition, there is great flexibility in how the domain objects are designed, and how these objects are mapped to the underlying relational database tables.

Advantages

• Location transparency on session interface

• Fine-grained persistent object operations can be "batched" or combined into a single session bean call to reduce communication overhead

• High performance storage/retrieval of persistent objects

• EJB features available through single point of session bean entry to reduce Container overhead

• Can relate persistent objects

• Can pass persistent objects to the client side if necessary

Disadvantages

• Fine-grained client calls may require explosion of session interface calls

• Persistent Java objects not included in EJB specification

Session Façade - Combining Session and Entity beans

The majority of systems have relationships between application entities. This being the expected scenario, it is well observed and explained by J2EE designers. More common, however, is to incorporate the domain logic into the session bean itself. This migrates the business logic from the client to the server which provides a number of well-known benefits including ease of maintenance, convenient upgradability, and increased access to server features.

Regardless of whether the session bean simply forwards operations to entities or actually includes the application logic as a façade that fronts the local entities it is a modular approach to remotely accessing server-side objects. It is also likely to be easier to maintain as the J2EE specification moves forward, since session beans tend to experience change to a lesser degree than other components, such as entities. The decision to use a stateful or stateless session bean will likely depend on the amount of business logic incorporated into the session bean.

Figure A-3 Session façade architecture

Text description of the illustration sessfacd.gif

Advantages

• Location transparency on session interface

• Fine-grained entity operations can be "batched" or combined into a single session bean call to reduce communication and transaction overhead

• Inter-entity method calls are pass-by-reference

• Can maintain entity relationships

• All components described by EJB specification

• Flexibility to create new (local) transactions on specific method calls when required ·

Disadvantages

• Fine-grained client calls may require explosion of session interface calls

• Some Container overhead still incurred on each local entity call

Dependent Java Objects

Because of TopLink's ability to persist regular Java objects without the need for EJB container support these objects offer the most flexibility. They do not incur the entity costs of container management but can be persisted independent of the entity. This means that changes are detected at commit-time, but if nothing changes during the course of an entity update then the object will not be written back, and likewise only the object may be written out if the reverse is true. The dependency upon the entity is still intact, however, as any removal of the entity will automatically propagate to cause the dependent Java object to be removed from persistent storage. Like serializable value objects, they can be transported back and forth between the client and server, allowing for client interactions that refer to the owning bean, but operate on the dependent data. These objects are not supported in the EJB specification, but do offer the benefits of managed, mapped persistence.

Figure A-4 Using dependent Java objects in a system

Text description of the illustration depjavob.gif

Conclusion

EJB provides developers with a great deal of infrastructure that makes building enterprise applications easier. This allows developers to build better applications by allowing them to focus on the business logic of their application rather than on distribution, security, and transactions. Even with everything that EJB provides, developing with EJB requires intelligent architectural choices to be made. Although EJB provides much, it also allows for flexibility so that developers can use it to meet their needs.

Regardless of the EJB architecture used, TopLink will support it by providing the right level of control and transparence appropriate to the architecture. The TopLink persistence framework also adds the value required to customize applications to run at their best, and will play an essential role in enabling customers to successfully develop and deploy their enterprise applications.