Container-Managed Persistence Comparison
This section will briefly review the goals of container-managed persistence, and compare it to bean-
managed persistence. Once we have finished this high-level review, we will look at problems with the
EJB 1.1 CMP model, and how the EJB 2.0 CMP model tries to solve them.
Review of CMP Goals
One of the guiding philosophies of Enterprise JavaBeans technology is to split up the work between the
EJB component developer and the EJB container. The EJB component developer focuses on business
logic. The EJB container focuses on providing the systems-level services that every significant
application requires – such as security, transactional integrity, remote communications, and scalability.
There are at least three advantages to this division of responsibility:
-
The component developer doesn't need to worry about these system-level services, and so
they can spend more time on the business logic – which is, after all, the point of writing the
application in the first place.
-
The responsibility for developing systems-level services is in the hands of specialists, and so
they will likely run faster, operate more safely, scale better, and provide more features than
would otherwise be possible.
-
The systems-level services are based on generally accepted standards, and so the EJB software
components are portable between implementations of these services.
The idea behind container-managed persistence is that persistence should be considered one of the
systems-level services whose implementations are provided by a vendor. In theory, all three of the
preceding advantages are applicable to container-managed persistence. Consider:
The component developer can spend more time on business logic
Most organizations would rather have their programmers working on activities that contribute directly
to the bottom line, rather than on writing SQL statements and JDBC code. If you work for an online
bookstore, you should be writing software to manage inventory, track shipments, and enhance the
customer's experience. You probably shouldn't be developing an object-relational mapping framework.
It is certainly no trivial task to write, debug, and test the code that moves data from business objects and
their relationships to a relational database management system. If you use container-managed
persistence, you can concentrate on the business objects, and not their persistence.
The persistence services are developed by specialists
This means that they are likely to run faster, operate more safely, scale better, and provide more
features. The EJB 2.0 model of persistence provides sophisticated relationship-management capabilities,
a full-featured and portable query language, and a flexible object model. The EJB 2.0 specification is
written to allow optimizations such as lazy loading, dirty detection, and the efficient compilation of EJB
queries into native DBMS queries. Implementing all these features is not a trivial task, and neither is
testing, debugging, and managing them.
Your EJB components are portable between EJB containers and data stores
If you need features that are not present in one EJB container – such as the ability to map to a particular
database schema, the ability to use stored procedures, or the ability to provide a distributed read-write
object-oriented cache as a front-end to your relational database – you can simply switch to another EJB
container without rewriting your components. Particular EJB containers (or plug-ins) may provide support
for database-specific features and optimizations. You can take advantage of this when you deploy your EJB
components, without introducing database dependencies into the components themselves.
The Bean-Managed Persistence Alternative
The alternative to container-managed persistence is, of course, bean-managed persistence. The general
category of bean-managed persistence encompasses several strategies for development:
-
You might simply embed the JDBC persistence code for your database in your entities. I don't
generally recommend this approach, as it compromises portability between different database
schemas (and potentially between different databases). It can be appropriate for small projects
where you don't intend to distribute your EJB components or change your database, and
where container-managed persistence is not an option, for example because your application
server does not support the features you need.
-
You might develop a set of data-access classes to which you delegate persistence logic from
your entity beans. This preserves the portability of your entity beans, but does force you to be
responsible for designing, testing, debugging, and managing your data-access code.
-
You might use a proprietary object-relational mapping framework. This approach has many of
the same advantages as container-managed persistence. The disadvantages come because the
framework is proprietary. This is a trade-off that is sometimes appropriate; proprietary tools
are used successfully all the time. For example, one good reason to use a proprietary object-
relational mapping framework might be that your organization already has a significant
investment in it (in training and/or in code that has already been written). I think that you
should carefully consider the advantages of EJB 2.0 CMP over a proprietary framework, such
as component portability and multi-vendor support.
-
Finally, you might use an existing enterprise application, rather than a database, as your persistent
store. For example, your entity beans might save and retrieve their data from an Enterprise
Resource Management (ERP) application running on your company's mainframe. With this
strategy you will almost certainly need to use bean-managed persistence, unless you find a highly
specialized EJB container that supports your enterprise application. In fact, with the introduction of
the Connector Architecture with J2EE 1.3, even this reason is losing some impact.
It is quite likely that your new component development should use entity beans with EJB 2.0 container-
managed persistence. If you have an unusual situation, you may be compelled to use bean-managed
persistence for some or all of your application's persistence logic. Even this should be a temporary
situation. With time, EJB containers will improve their support for the EJB 2.0 persistence model, and
they will grow in sophistication and capability. As this happens, there will be fewer reasons to write
your own persistence logic or to use a proprietary framework.
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
|
