New York University

Computer Science Department

Courant Institute of Mathematical Sciences

 

Enterprise JavaBeans Patterns

 

Course Title: Application Servers                                           Course Number: g22.3033-011

Instructor: Jean-Claude Franchitti                                            Session: 6

 

 

The first few pages of this document work to define the terms used throughout the rest of the document, where four different Enterprise JavaBean (EJB) architectural patterns are discussed in detail to determine the strengths and weaknesses of each.

Definition of Terms and Concepts

EJB architecture is centered on an application server that hosts multiple Enterprise JavaBeans. Each EJB represents either a data or business component in the application. Data components are called Entity beans, while business components are called Session beans.

Entity Beans

Entity beans represent meaningful sets of data: usually all or part of a table or view in a database. An order entry application, for instance, might have Order and Customer entity beans. In this case, a single instance of a Customer Entity bean would represent a single row in the Customer database table, or a single customer.

Entity beans generally don’t have any functionality beyond creating, updating, and deleting their data. They manage the persistence of information associated with a given block in an application’s entity relationship diagram.

The application server maintains Entity beans in a cache to optimize performance in creating, distributing, and destroying instances of Entity beans. In doing this, however, the performance characteristics of the database may be masked by a less efficient application server.

Container-managed vs. Bean-managed

Entity beans may be container-managed or bean-managed. Container-management indicates that the application server handles all persistence and transaction management of the data associated with an Entity bean. This means developers don’t have to write any code to access the database, which can result in significantly reduced development time. Application servers place various restrictions on the kind and complexity of data that container-managed Entity beans can manage. Some application servers don’t support container managed Entity beans at all, although it is a requirement of the EJB 1.1 specification.

For bean-managed Entity beans, developers must write all of the code that retrieves, updates and creates the data associated with the bean. Developers must also handle transaction management of the bean to a certain extent. Bean-managed Entity beans are most appropriate when the chosen application server doesn’t support container-managed entity beans, or the data managed by the bean is non-standard and is not supported by the application server. As with container-management, some application servers don’t support bean-managed entity beans.

Session Beans

Session beans handle the business logic of an EJB application. They can use whatever Entity beans are available to perform more complex actions such as calculations, enforcement of business rules, and updates to multiple data locations. Session beans often use multiple Entity beans to bring application data together in meaningful ways. For these reasons, Session beans represent the majority of effort in developing an EJB application. Several different methods of combining Session and Entity beans are discussed throughout the remainder of this document.

Java Database Connectivity (JDBC)

Application servers use Java Database Connectivity (JDBC) to read from and write to relational databases. The placement and use of JDBC can have significant performance ramifications, as it is the point of contact between the database and the application server.

When using container-managed Entity beans, direct access to the database through JDBC must be managed carefully to avoid changing data cached in the application server.

The Client

The ‘client’ as used in this document, refers to the code that uses the Enterprise Beans. This may be a servlet running within the application server or another application server in a cluster, an applet running within a user’s web browser, a Java application running in batch mode on a server, or a Java application running on a user’s desktop. How the beans will be used must be carefully considered when choosing which pattern best fits the application architecture.

The Four Patterns

Each of the four patterns change one or two of the following properties:

q       Container-managed vs. bean-managed Entity beans.

q       Use of Session beans

q       Use of Entity beans

Changing these properties leads to a solution leaning more or less towards the following development goals:

q       Time to market

q       Performance

q       Flexibility

 

The following table summarizes the four patterns:

 

Pattern

Entity Mgt.

Uses Entity Beans

Uses Session Beans

1.    Container-managed Entity Beans with Session Beans

Container

Yes

Yes

2.    Bean-managed Entity Beans with Session Beans

Bean

Yes

Yes

3.    Entity Beans Only

Container

Yes

No*

4.    Session Beans Only

N/A

No

Yes

*  Session beans are used in this example for complex database interactions, but they do not serve as a front-end for Entity beans. Instead, they access the database directly as an Entity bean would.

1. Container-managed Entity Beans with Session Beans

 

Entity Management

Uses Entity Beans

Uses Session Beans

Container

Yes

Yes

 

In the above and following diagrams, white shapes indicate components to be written, while gray shapes indicate components already written or to be generated.

This pattern consists of Entity beans for each set, or table, of meaningful data, fronted by Session beans that encapsulate the business rules and logic. The application server manages all persistence within the Entity beans, and Session beans act as a buffer between the client and the Entity beans.

This pattern most closely follows the EJB specification, and would be considered by Sun the default recommended EJB method of development.

Pros

q       Because there is no direct interaction between the client and Entity beans, a minimal number of beans must be instantiated remotely. For example, rather than the client remotely instantiating Order, Customer, and Product Entity beans to place an order, a single OrderPlacement Session bean can be instantiated remotely. On the server, the Session bean will manage the use of the various Entity beans required to complete the task. This can be a significant performance benefit.

q       Decreased time-to-market because no code must be written to access or update the database.

q       Entity interactions with the database are handled at deployment, so changes to the database are unlikely to require code modification.

q       Session and Entity beans can be reused in other applications within the organization.

q       Clean separation of data, business logic, and presentation layers. This allows parts of the application to change without affecting the other parts. It also allows additional companion layers (such as a second user interface) to be applied.

q       Transactions are handled, through Session bean methods, by the container. No hand coding of transactions is required.

Cons

q       Data storage providers limited to those supported by the chosen application server (generally anything with a JDBC driver).

q       More complex architecture than other patterns.

q       Entity beans may cause application server caching mechanism to bottleneck a more efficient database mechanism.

q       Container management may not support all data storage mechanisms.

q       Use of Entity beans must be considered carefully, as over-use can lead to significant loss of throughput.

Performance Characteristics

If Entity beans are used carefully, this pattern performs second only to the Session Only pattern discussed in this document. The 4x400 MHz IBM Netfinity NT server used in tests could handle a maximum of 400 users under this pattern, while 300-350 users provided the best throughput/performance ratio.

See Entity Bean Notes at the end of this document for important findings on the appropriate way to use them in an application.

2. Bean-managed Entity Beans with Session Beans

 

Entity Management

Uses Entity Beans

Uses Session Beans

Bean

Yes

Yes

 

This pattern is identical to the first pattern except that the Entity beans are bean-managed instead of container managed. This change allows alternative persistence mechanisms that may not be supported by the application server to be used.

Because of the similarities between pattern 1 and 2, the following Pros and Cons indicate only the differences between this pattern and pattern 1.

Pros

q       Alternative persistence mechanisms may be used.

q       Possibly more efficient data access methods could be employed.

q       Tighter control over transaction boundaries.

Cons

q       Considerable added time and complexity for development and testing.

q       Possible performance hit (see performance characteristics).

Performance Characteristics

This pattern performed 15% slower than the Container Managed pattern. While it is possible that significant time and testing could yield a more efficient mechanism than Container Management, this avenue is not generally recommended as a method to increase performance due to added time to market, minimal possible performance benefits, and the real possibility of performance loss. The design tested did less actual work with the database than was seen with Container Management by eliminating some unnecessary reads and updates, yet it still performed 15% slower.

See Entity Bean Notes at the end of this document for important findings on the appropriate way to use them in an application.

3. Entity Beans Only

 

Entity Management

Uses Entity Beans

Uses Session Beans

Container

Yes

No

 

 

This pattern allows the client to talk directly to the Entity beans, and uses Session beans only for complex database queries that would involve several Entity beans. The Session beans that are used don't go through Entity beans, but speak to the database directly through JDBC. This pattern may save some development time, but is generally not recommended for design and performance reasons. This pattern might even be viewed as how not to design an EJB application.

Eliminating Session beans as buffers between the client and the Entity beans merges the business logic layer with the presentation layer, creating a less flexible system. The presentation layer is generally the most frequently changed, and business logic will be exposed to defects and require testing every time the presentation is modified.

This system will also prove slower due to the increased network activity generated by the frequent access of Entity beans by the client. For example, instead of calling a PlaceOrder method on a Session bean, the client may have to instantiate and modify several Entity beans to place an order.

Further, since Entity use is not wrapped in a Session bean method, transactions must be managed manually by the client.

Pros

q       Possible faster time-to-market due to elimination of complexity and formality.

q       Container-managed Entity beans provide a layer of abstraction between application and data model, lowering the likelihood that data model changes will require code changes.

Cons

q       Slower than patterns with Session beans only on the client due to increased network traffic.

q       Results in less flexible system due to elimination of business logic layer.

q       Requires client to manually manage transactions.

Performance Characteristics

Not surprisingly, this pattern performed abysmally in tests, bringing standard throughput on the server from 400 down to 100 users. Even at 100 users, however, it performed 5 times slower than the Container Managed pattern did at 100 users.

4. Session Beans Only

 

Entity Management

Uses Entity Beans

Uses Session Beans

N/A

No

Yes

 

 

This pattern removes the Entity beans, merging the data and business logic layers of the application. In other words, this pattern brings data model specific JDBC and SQL code into the Session beans.

While JDBC provides a sufficient abstraction of the physical database used, Entity beans provide an interface or layer of abstraction between the data model and the business logic. This allows table and field names, even relationships, to change in the data model without required code changes in the application. This pattern removes the Entity beans and therefore loses this benefit.

Performance is the primary benefit of this pattern. Entity beans, while architecturally sound, cost a significant performance hit. Entity beans bring the caching logic out of the database and into the application server. Application servers have yet to match the efficiency of proven database-caching algorithms. Even if the application server is not allowed to cache data from the database, however, this pattern still provides a performance benefit through the removal of a layer of code between the application and database.

As with pattern 3, removing a layer may provide faster time-to-market by reducing the complexity and amount of code that must be written. This is only the case, however, if bean-managed Entity beans were removed. In this pattern, all the data access and update code must be written manually, instead of generated by the application server, as is the case with container-managed Entity beans. For applications with relatively simple database interaction, however, the time to hand-code database interaction could be comparable to the time spent developing and testing Entity beans.

The timesavings between bean-managed Entity bean and no Entity bean patterns is insignificant when compared to the timesavings between container-managed Entity bean and either bean-managed or no Entity bean patterns.

Pros

q       Improved performance due to removal of Entity bean overhead and replacement of application server caching mechanism with faster database caching mechanism.

q       Faster time-to-market when compared to bean-managed Entity beans.

q       Less complexity in development and testing when compared to bean-managed Entity beans.

q       Removes Entity beans’ excessive reads/updates to database that can cause deadlocks.

Cons

q       Less flexible due to inclusion of data model specific code in business logic layer.

q       Possible slower time-to-market when compared to patterns using container-managed Entity beans.

Performance Characteristics

Among the four patterns, this was the clear leader in performance tests. Throughput jumped to 450 users, with 400 producing the best performance/throughput ratio. At 400 users, this pattern was 5 times faster than the Container Managed pattern, the second fastest.

Performance Charts

 

Entity Bean Notes

Entity beans are employed by more than one of the patterns discussed in this document. The following summarizes findings about the use of Entity Beans that apply to any pattern using Entity beans.

SQL Statements vs. Finder Methods

The way Entity beans are used in EJB applications can have significant affects throughput and performance. When retrieving multiple records for display purposes, straight SQL should be used to retrieve result sets. When Entity bean finder methods were used for this kind of data retrieval, the average transaction took more than 5 times longer, while 90th percentile transaction times were almost 20 times longer. While finder methods that return more than a few beans may be adequate for rapid prototyping, the gain in performance is well worth the added development complexity of hand-coded SQL statements against the database. The following performance chart illustrates this point.

Competitive Updates and Deadlocks

Because of the way Entity beans call a SELECT upon instantiation and an UPDATE when data is changed, competitively updating multiple beans within a transaction can cause frequent deadlocks. Therefore Entity beans are not recommended for data that will be updated by multiple users simultaneously.

Summary of Findings

Each of these patterns represents important design, performance, and time-to-market trade-offs.

If design and flexibility are top priorities, pattern 1 provides the highest level of separation between the data, business logic, and presentation layers. This allows the implementation of any of these layers to change without affecting the unchanged layers. Since it uses container-managed Entity beans, it also provides an added layer of abstraction between the application data layer and the data model implemented in the database.

Pattern 4 proves to be the best choice when performance and throughput are the top priorities. By eliminating data access inefficiencies introduced by the application server, pattern 4 gains significant performance improvements over the other patterns discussed. Considering the relative immaturity of EJB application servers compared to time-tested relational databases, this finding is not surprising.

Patterns 1 and 3 provide the fastest time-to-market. Only the time to design and build the Session beans is eliminated with pattern 3. All of the business logic must be written, whether it lives in Session beans or within client code. Considering the prohibitive performance cost of pattern 3, pattern 1 is the better choice due to its superior design and close runner-up placement as fastest time-to-market.