"What persistence solution should I use today?",a customer asked me when I was pitching about EJB 3.0. I suggested them to use TopLink but they do not want to tie their applications to a proprietary framework. They have CMP as their corporate standard and they are pretty happy with CMP. But they are very concerned with the radical changes being made by EJB 3.0 and want to be assured that they can migrate their EJB 2.x applications to EJB 3.0. They seemed to be relieved when I revealed that we are planning on providing a migration path from TopLink POJO customers to EJB 3.0 persistence API. It is worth mentioning that EJB 3.0 compliant J2EE containers will still support EJB 2.1 and all EJB 2.x applications will not require any modification.
This question may be coming to many of your minds with the persistence API is being merged in JSR 220. So the persistence API defined by JSR-220 EG is a year from now. EJB 3.0 is best bet for future. This is heartening to know that many JDO vendors have joined JSR-220 Expert Group. All persistence framework vendors (including some JDO vendors) have started to pitch how they are well positioned to migrate applications to persistence API defined by EJB 3.0. But JSR-220 is about a year from now and what persistence solution should I use today.
I can unequivocally state that first step to migrate to EJB 3.0 persistence is to use POJOs in conjunction with a persistence framework available in the market. Mike Keith has written a nice article Preparing for EJB 3.0 Today. You may notice that quite a few persistence frameworks have mushroomed in the past few years and here are some attributes you should look for when you select your persistence solution today that can help you migrate to EJB 3.0 persistence.
Comprehensive experience in O-R mapping. The persistence framework has many years of experience with Object-Relational persistence and is being used by many customers.
Data Source. The persistence framework must support different types of data sources (major relational databases and EIS using JCA) used in your organization
Mapping Tools. Must provide a Graphical-mapping tool to make your life easier for mapping your objects to tables. Mapping tools really are useful for large projects and mange the dependencies between class mappings. As mappings, relationships, and table structures change if you use individual mapping files (XML) it will be up the developer to find and correctly modify all affected files. Typically this involves trial and failure in the runtime environment. Having a mapping tool allows you to address this and scale to large projects and more developers sharing the mapping responsibilities.
Database Support. Takes great benefits of your database such as stored procedure and triggers, support advanced data types for your database and respect database locking and play well with database security.
Query Support. Should provide the ability to write your query either in Java, OO query such as EJB QL, Query By Example, and SQL or allow stored procedure to be used for query.
Locking. The framework must have solid support for locking whenever multiple applications share the same dataset.
Caching. The persistence framework should have efficient and flexible support for caching of data thus reducing the load on database.
Cache Coordination in a cluster. It must support caching across different nodes in a cluster.
Migration to EJB 3.0. You should invest in a persistence framework that you will believe will exist for next couple of years and has the ability to provide migration utility from their existing persistence e.g. EJB 2.0, proprietary POJO persistence to EJB 3.0 persistence.
You have to remember that managing persistence related issues is one of the most underestimated challenges in enterprise Java today – in terms of complexity, effort and maintenance and you have to make the right decision today so that you do not forfeit your investment in future.
