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.
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 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.
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 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.
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’ 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.
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.
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.
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.
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.
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.
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.
q Alternative persistence
mechanisms may be used.
q Possibly more efficient data
access methods could be employed.
q Tighter control over
transaction boundaries.
q Considerable added time and
complexity for development and testing.
q Possible performance hit
(see 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.