- Introduction
- The Entity Bean Handle Dilemma
- The CMP Entity Bean Dilemma
- The Space vs. Time Dilemma
- The Deployment Descriptor Portability Dilemma
- The Object-Oriented vs. EJB Development Dilemma
- The Assurance Dilemma
- Overcoming the Dilemmas
- Conclusions
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The Deployment Descriptor Portability Dilemma
Just because your EJB Java code and base EJB deployment descriptor are portable between J2EE-compliant vendor implementations doesn't mean that all your deployment descriptors will be portable. A significant amount of important information gets baked into vendor-specific deployment descriptors. In particular, with EJB v1.1, you don't have to write any SQL code for your CMP entity beans, but that doesn't mean that you won't be writing any data-access code. In fact, the vendor-specific deployment descriptors for CMP entity beans contain a lot of data-access logic (sometimes vendor-specific) to support your CMP entity beans.
Although many vendors provide a tool to help you create such data-access logic, we've found that such tools can be clumsy and sometimes do not implement the most efficient—or even remotely efficient—data-access logic. Furthermore, when deploying such EJBs to another J2EE-compliant container, you'll have to either generate such deployment descriptor information again using that vendor's tool or write it yourself again (and perhaps even in another data-access language). EJB v2.0 again attempts to overcome such shortcomings by defining an entirely new data access language for CMP entity beans, referred to as EJB QL (for "EJB Query Language"). This dilemma of deployment descriptor portability was yet another argument for using BMP entity beans for EJB v1.0 and EJB v1.1–compliant servers.