EJB 2.0 is testimony to the fact that the J2EE model has come a long way.
You can do a lot of things with 2.0 that were tedious and error-prone in EJB
1.1. The Container Managed Persistence (CMP) relationship management alone
makes it worthwhile. Just define all database access through method calls on
entity beans, configure the deployment descriptors to recognize the method
calls, set the autogeneration of RDBMS tables to "true," start the server,
and you're ready to rumble. No more mucking around with databases. Once your
DBA has set up your relational database, you never have to look at it again.
As far as your application is concerned, you deal in objects, whole objects,
and nothing but objects. Right?
Wrong! While the EJB 2.0 architecture definitely alleviates the pain of
dealing with databases directly, it cannot completely eliminate it. Note
that I'm not making light of database maintenance. On the contrary, the main
point of this editorial is that the moment you use more than what the EJB
model offers, you need to make sure your project has a person who can
synchronize and coordinate between the object and relational worlds. When
you get around to building an application with complex relationships between
entities, there are several factors you need to consider from a programming
perspective. Relationships between entity beans are handled quite cleanly by
CMP, as are cascading deletes at least simple cascades.
However, unless you create foolproof code that perfectly manages data
integrity on the first shot, which you may in a small-to-medium application,
you're bound to get dirty data in your database because of logical errors.
By dirty data I mean data that doesn't necessarily conform to the entity
relationships the way you had intended. Then comes the data cleansing stage,
which can cascade into multiple problems at several levels. This is because
the data cleansing at the RDBMS level may be out of sync with the cleansing
required by the object model.
The alternative is to identify the appropriate constraints in the
database that restrict the entry of inconsistent data from the object model.
If you were programming in JDBC directly, chances are the constraints would
have been a part of your design from the get-go. However, the abstraction
provided by the EJB model lets developers unfamiliar with the intricacies of
databases program complex applications. A developer can more or less exist
in his or her OO world without worrying about low-level SQL queries and
mundane database tasks. However, when things go sour, it's very hard even
for a seasoned DBA to come in and fix things.
The correct approach for a successful project is to make sure you have
at least one person on your team who can deal with these issues at the same
time your EJB developers are designing their object components. In some
cases the RDBMS constraints may conflict with the object model, and
compromises may have to be made at either end. However, the end result will
be that you will have a more robust and maintainable application. A fringe
benefit is that you'll learn about how entity beans work behind the scenes
and how to use them judiciously. Luckily, in our last project we were able
to recruit a very knowledgeable developer who was familiar with both the
object and relational worlds. Although my team started out designing from
the object perspective, and all of us had some experience in RDBMS
applications, his contribution made the difference between succeeding and
failing in a large-scale J2EE project.
Ajit Sagar is the J2EE editor of JDJ and the founding editor of XML-Journal.
He is the director of engineering at Controlling Factor,
a leading B2B software solutions firm based in Dallas, and is well versed in
Java, Web, and XML technologies.