jRelational Framework

enterprise java beans

The jRelational Framework is an implementation of the Sun Data Access Object pattern.

The jRelationalFramework has been used very successfully with more than one EJB project we have done here at is.com. This framework was born out of the performance limitations of Container Managed Persistence (CMP) Entity beans. Because the EJB specification in 1999 was still relatively new there were few best-practices that had been defined. This page was written to help you learn from our mistakes, so that you can create a scalable system the first time around. We think that the jRelationaFramework is well suited for use in a scalable EJB architecture:

First Attempt

Our first attempt at an Enterprise Bean architecture had 3 bean layers. The first layer was made up of stateless session beans that were the interface to the client. The second layer also consisted of session beans, but they mapped the CMP entity beans to value objects. The lowest layer was the Entity bean layer with each bean class mapped to one table. The picture below illustrates this architecture.

Not until we had gotten a ways into development did we realize why this would not scale:

The middle layer bought us nothing other than allowing us to separate the data mapping logic into a separate class. This could have been done much more efficiently (both from a runtime perspective and a development perspective) with non-EJB helper objects.
CMP Entity Beans where each bean class is mapped to one table does not scale well. We encountered many problems with beans being locked during simple reads which forced us to abandon Entity Beans altogether. Granted, some of these locking issues may be resolved in future releases, but according to Peter Herzum, using one bean class per table will never scale well for large systems or large development teams.
Having so many beans meant that we had a lot of extra source and deployment files which slowed down our compile times dramatically.

A Much More Scalable EJB Architecture

According to the latest Sun Enterprise Blueprints, which are best practice principles for J2EE and EJB, an entity bean is better suited to represent a coarse-grained business object that provides more complex behavior than only get and set methods. In other words, we should shy away from entity beans that map to one table only and have no business logic. This concept can apply to either entity beans or session beans. Our final architectures have chosen to use session beans.

Also according to Sun's Blueprints, only the business objects that need to be accessed directly by the client need to be enterprise beans: use helper objects. Our use of the middle "domain" EJB layer and use of entity beans as simple data holders violated this principle.

Our solution was to create a data access helper superclass (which eventually became the AbstractDomain class of the JRF framework) that replaces both the "domain" layer and the entity layer. The "service" layer then consists primarily of pass-through methods to the domain helper classes. This allows the "service" beans to do what they do best: managing transactions and security.

One of the biggest benefits to switching to this architecture was that we reduced the number of source code files by at least 40% while gaining much faster response times without losing any functionality.

See the Sun Value List Handler Pattern for a good explanation of how to use Data Access Objects (jRF) to page cached result sets on the server.