You don't have to look far to see how excited people are about the new direction EJB 3.0 is taking. In fact, the entire J2EE component suite has a mandate to simplify the development process, and we can all look forward to a time when it will be much easier to develop, test and deploy our enterprise applications. EJB 3.0 is taking ease of development extremely seriously and has adjusted its model to offer the kind of POJO (Plain Old Java Object) persistence that TopLink has been doing for a decade.

This is no coincidence as the specification lead, Linda DeMichiel, chose to look outward for advice and experience from products like TopLink. This allowed the specification to follow the trails that had already been blazed by popular and proven technologies, and that had in fact become de facto practices in the industry. The EJB specification can now proudly claim that it is transitioning back to becoming both a relevant and a useful persistence specification because it is in harmony with what the vast majority of applications are already doing.

Work on the specification is progressing rapidly, and as a strong supporter of the new EJB model Oracle is actively participating in this process. Not only are we a major technical contributor but we are also currently preparing to offer a preview release of the EJB 3.0 Container technology.

Recognizing the fact that previews are not typically going to be suitable for deploying applications into production, and that the final release of EJB 3.0 will likely be sometime next year, the question arises - I like what I see, but what can I do now? The answer is that you can be proactively preparing your application for EJB 3.0. When the final draft of the specification rolls off the presses you will want your application to be in a state where it is a simple matter to migrate to the new persistence standard. Even better, you would like your application to already be using some of the features offered by the standard. In this paper I will explain how this can be done, and give advice about which features to use so that you can not only be ready for EJB 3.0, but already be most of the way there.

The first step is to ensure that your architecture makes use of standard and accepted design patterns around persistence. This may actually require changes to your application, but is well worth the investment if you expect your application to endure the test of time. Using session facades, DAO (Data Access Object) layers or service layers are always good ideas, but in this case they are critical. Although not commonly done, if your application is already built using remote entities then you will need to rework your architecture. A remotable service layer is expected to be in place before persistence objects are accessed. If entities are being used then they should strictly be of the local variety.

Using local entities is not the end, however, since entities also provide deployers with the ability to declaratively state the transactional and security requirements for the entity. EJB 3.0 will not allow any of these attributes to be set at the entity level. Instead, the context in which entities will run will be determined by the caller, so any transactional or security context that is required should be installed or declared by its enclosing J2EE component. This separates the largely orthogonal issues of persistence from the rest of the distributed component model.

If you are already a CMP user then you may be thinking three things. First, you can't wait to get the new features and are ecstatic about ditching the extraneous interfaces, unnecessary bean code and tedious XML deployment descriptors that were some of the annoyances associated with previous entity bean development. The remote and local interfaces that had to extend EJBObject and EJBLocalObject, respectively, are no longer required and entities may now, if they choose to, simply implement a plain old Java interface (POJI).

Secondly, you are probably dreaming about how you will be able to more easily deploy your EJB's in the container, or even not deploy them at all but test them outside the container in a standalone environment. Because the entities are concrete plain old Java objects (POJO's), you will be able to create them the way that you always created Java objects, using new().

Lastly, you may be wondering how hard it will be to migrate some of your existing 2.1 style beans to use the new 3.0 style of programming. This is a concern that Oracle is taking to heart. In fact, we firmly believe that the strength of the transition strategy offered by a EJB product will be one of the main criteria that applications use when it comes time to choose their EJB 3.0 implementation. Our goal is to make this transition as easy as possible and we are planning and developing our implementation around this goal.

The bulk of the new persistence API is accessible from the EntityManager, which may be injected into a session bean or looked up in JNDI. The EntityManager represents the transactional persistence context, which maps very closely to the TopLink UnitOfWork. Any objects managed by the UnitOfWork, or EntityManager, that are found to be dirty at the end of the transaction will be written out to the data store.

An application can insulate itself from extensive changes by abstracting the code that obtains the UnitOfWork/Session artifacts. This way the actual session that gets used can be obtained in a pluggable way. Defining the session and then allowing a surrounding layer to set it from the outside would be similar to the dependency injection paradigm that has been adopted by the EJB 3.0 Container. This pattern should be followed for all resources that are used in the application. In EJB 3.0 standard resources will be declared by the application and subsequently injected into the bean at runtime.

Many of the EJB 3.0 features will be recognizable in features that have been around in TopLink for a long time. By using these features you will be able to have the functionality of EJB 3.0 even though the API's are not yet completed.

Querying is one such area where you can start using EJB 3.0 features right now. TopLink provides the ability to define and execute named queries. Configuration of queries may be done statically or dynamically to allow just-in-time querying with client-based criteria.

EJB 3.0 queries will be obtained from the EntityManager, and will be executable on it. It will be possible to create a native SQL query for the rare cases when you need to go directly to SQL, and get objects back from the query. TopLink has custom queries that do exactly that, and they perform the mapping of the result set data to objects.

Query languages are often the source of migration headaches because it is very difficult to translate automatically without writing a substantive or exhaustive translation parser tool. EJB QL is a reasonable and sufficient abstraction of a relational query language and will benefit from the several new features that are being added to it. Existing EJB QL will apply and still more EJB QL constructs and functions will enhance the query language further. Even though the query API's may not be released yet, it would make sense to write queries using EJB QL since the query language is not going to change substantially, except in an additive way. TopLink supports using EJB QL with POJOs, thus helping an application to get to a state where it is able to port its queries over to another database, another framework, or another persistence API.

True and natural inheritance, as Java objects were built to support and participate in, was never specified in EJB 2.1. In practice, inheritance was only possible if the vendors did not throw up obstructions, but was still quite difficult to define and manage. This will not be the case in EJB 3.0. With concrete Java objects being able to inherit from each other, and not be required to define methods that handcuffed the extent of the inheritance, you will be able to create entity inheritance hierarchies arbitrarily deep and wide.

This same flexibility is currently achievable from both within the TopLink Mapping Workbench or JDeveloper, GUI tools for mapping Java objects, as well as in the Java-based API for mapping objects. Your domain model can be produced now to adhere to the inheritance strategy that suits your application without having to wait for the specification to be released.

The optimistic locking model that TopLink strongly supports is now going to be adopted into the EJB 3.0 model. This is a very good thing for applications, not only because it will offer huge increases in performance in the face of normal 90/10 read/write access ratios, but because it leads to the kinds of scalable architectures that modern systems require. This is a key locking paradigm that is already used by thousands of applications in the industry to achieve the scalability that web applications demand.

The flexibility of the TopLink options for locking values, and how they are determined, computed and stored, supercedes those included in the EJB 3.0 specification. The basics are clear, however, and portability is easily achieved by making use of the straightforward approach of a database column and object version field for each optimistically locked object.

This type of locking provides the added benefit of being able to use the objects in disconnected modes. Modifying data and relationship while offline can be easily supported simply by merging the data back into a transaction and verifying through the optimistic lock value that the object that was modified was not a stale copy. This aligns perfectly with what TopLink users are already doing when they merge their objects back into a unit of work.

The EJB model of life cycle callbacks is being adapted in two useful ways. The first is that the callbacks are more relevant to the O/R mapping runtime execution model and fine-grained events such as insertion in the database will enable actions to be taken to perform things such as auditing and other book-keeping. Secondly, non-bean event listeners can register to handle the event callbacks. This means that when you use the TopLink event listeners that you are already using the model that EJB 3.0 entities have now embraced.

Perhaps the most obvious and visible support that has been provided by TopLink over the years is the ability to map object data and their relationships to relational tables. This has been a critical problem that has plagued applications that want to write object-oriented Java programs but store their data in relational databases.

The decision to add standardized metadata and semantics for object-relational mappings into EJB 3.0 is a giant step towards allowing applications the flexibility to take their application and run it on different databases and even use different persistence frameworks to do so. The first pass at the O-R mapping standard will include the most popular mappings that people now use to map their domain models, such as basic data conversion, one-to-one and many-to-many relationships, and so forth. Subsequent drafts will add more of the "deluxe" mappings that TopLink already offers, so as the specification matures it will approach even closer to TopLink as a portable solution for applications even if they have exceptional requirements.

Over the past 10 years TopLink has been incorporating the requirements of its large customer base and evolving with the way that applications persist their objects. Now that EJB 3.0 is modernizing its approach to persistence to align itself with what the majority of applications are doing, TopLink customers that have been doing POJO-based persistence for years can feel both justified and confident that standards are following their lead. Because the TopLink model is being held up as an example of how people are happy with a persistence framework, the features can be used as a step towards reaching the EJB 3.0 standard. In other words, applications that want to start now to implement EJB 3.0 can use a stable and proven product to do so, even though the specification may still be in its infancy.

TopLink is fully committed to EJB 3.0, and helping our customers move to get there. Not only will we offer migration assistance to existing TopLink customers but we are making plans to help applications that are based on other technologies as well. Stay tuned for more articles, seminars and talks about how you can benefit from adopting EJB 3.0 persistence in your applications.

Mike Keith is an architect for Oracle's TopLink product and represents Oracle on the EJB 3.0 expert group.