Ajit Sagar

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.