Unlocking the True Power of Entity EJBs

12/19/2001

Performance this
Performance that,
I think my EJB
Is a tiny bit flat!

I've heard too much debate in the application developer community about how flawed the entity EJB model is, and that its performance isn't on par with a stateless session EJB (SLSB). I've sat, listened, and watched the debates. The conversations center around performance, the meaning of distributed component architecture, the relevance of JDO, the cumbersome nature of EJBs, and on and on. And through all of this, my concerns for the community grew, as no one was touting the real reasons entity EJBs are monstrously powerful. I told myself that they must see it -- that it should be clear -- but I still pondered, as the community seemed to be blinded to the true power of entity EJBs.

The time has come for entity EJBs to have a spokesperson that will champion their vision, potential, and true power to the world. Let's get started.

Write Once, Deploy N-Times

Yes, EJBs have transactional, security, and interoperability support at the container level. It's been repeatedly demonstrated, however, that these capabilities are more relevant at the SLSB façade layer that accesses a data layer. Indeed, most architectures that employ EJBs have the SLSB façade handle these aspects. They configure their data access layer to use entity EJBs as a pass-through for these services (i.e., if a SLSB method is configured to start a new transaction, the entity EJB method invoked by the SLSB method will be configured to accept the already-started transaction).

Although important, these EJB features distract people from appreciating the subtle and powerful nature of entity EJBs: they can be tailored for every conceivable data scenario using a "write once and deploy n-times" model.

Every system has data that is used in different ways. Data can be read-only non-transactional, read-write transactional, read-write transactionally clustered cache, read for update over multiple requests, modified through batch updates, or used in bulk data retrieval. The number of ways that data is accessed and used is limitless. The complexity of these operations increases when relationships are factored in. If you disagree, think about how difficult it would be to implement a transactionally-aware clustered cache that performed eager relationship caching for entity EJBs with relationships three levels deep.

It's foolish to think that an entity EJB deployed in its basic configuration is suited to handle data for each of these scenarios with the best possible results. The out-of-the-box configuration for Entity EJB engines, such as WebLogic, are designed to handle read-write transactional data with the best possible performance. This is done because read-write data is the easiest way to represent life cycle data: data that is created, used for a period of time, and later destroyed. It allows EJB developers to quickly test the purview of functional operations of the data. This functional robustness is often interpreted as the suggested production deployment configuration!

The real power of entity EJBs (especially robust CMP engines) is the ability for a developer to develop a single entity EJB and then deploy that component multiple times, each deployment tailored for a different data access scenario.

Yes, there are a couple of studies that demonstrate entity EJBs with CMP have lackluster performance when compared with a SLSB with JDBC. But there isn't a single study that leverages entity EJBs using the "develop-once, deploy n-times" model. A system using entity EJBs following this model will have greater overall performance, robustness, and reliability than a SLSB with multiple JDBC operations. Here is why:

A SLSB with JDBC will never be as robust in its ability to handle different data in a single server or a cluster. Container Managed Persistence (CMP) engines already support lazy loading, aggressive loading, optimized writes, field groups for CMP fields, field groups that incorporate relationships, optimistic locking policies, and transparent cache management through activation and passivation. What's the level of effort that you would have to invest to write a SLSB with JDBC to correctly implement all of these scenarios? You could painstakingly accomplish this for a single server environment, but what about trying to coordinate actions for a clustered cache? SLSB with JDBC implementations have upper limits to their capability that entity EJB CMP containers have already surpassed.

The configuration of entity EJBs allows developers to rapidly
change the way a container behaves without any code modification. This provides a level of productivity not available with other technologies.

Every test case used on entity EJBs for performance doesn't factor in the relative weights of how the data will be accessed in production. For example, Web-based systems hardly access data in a read-write transactional manner, and are primarily read-only systems. Typical test cases would use read-write transactional entity EJBs to gauge the performance for all scenarios. Yuck!