John Reynolds's Blog

March 2004 Archives

BPELJ - Good idea or bad dream?

IBM and BEA have just released a joint white paper on BPELJ, a combination of BPEL and the Java programming language:

BPELJ: BPEL for Java technology

I'm a fan of BPEL (Business Process Definition Language), and I really like the process definition features in WebLogic Workshop 8.1, but I'm not so sure about BPELJ. Apparently, IBM and BEA feel that BPEL is not sufficient by itself, so they are encouraging authors to embed Java "snippets" into their XML. This gives me flashbacks to JSP in the pre-Tag library days, and I can only shudder at the thought that somebody will propose the addition of tag libraries to BPEL.

My concerns are probably moot, since it is pretty clear that BPEL and BPELJ are intended to be read and edited by application development tools rather then by mere mortals. No doubt the next version of WebLogic Workshop is already outputting these files.

Update: See my later thoughts on BPEJ.

Aspects of Persistence - What should CMP and JDO share?

My response Make JDO the "P" in CMP to Bruce Tate's article For JDO, the Time Is Now generated some interesting responses of its own.

There is a lot of passion in the Java community sorrounding Entity Beans, and I sense that we could direct that passion towards the development of a much improved and more comprehensive specification.

There are many aspects to persistence, and I believe that the community of Java programmers will be best served by solutions that allow us to pick and choose the aspects that are most suitable for our projects.

Some projects are stand-alone, and are not dependent on legacy Relational Databases. In the past, proponents for these applications rose up and banned the inclusion of an Object/Relational mapping standard in the JDO specification because they did not want their persistence options limited.

I think that this reaction was a mistake, and I suggest that we approach this issue from a different perspective. Reliance on a preexisting RDBMS is an undeniable aspect of some programs. If that aspect applies to your program, then you should enable the O/R mapping aspects of the specification. If your project doesn't need to interact with an RDBMS, then select whatever aspects of Persistence that you need.

What are the aspects of Persistence that are currently available?

• Maintenance of State between program invocations is the simplest aspect of persistence. This could be implemented in many ways, from simple serialization to much more robust solutions, but basically your only concern is that the state of an object is not lost.
• Container Managed Persistence is a control simplification aspect for many programs. When does the state need to be stored? When does it need to be restored? WIth a standard interface for your objects you can leave these and other details to the "container".
• Transactional Support is another aspect that is important to many. It may be important that a sequence of steps complete successfully or all changes are rolled back.
• Caching is another aspect, primarilly concerned with performance.
• Clustered (Distributed) Caching is an important aspect for applications that are distributed across multiple nodes. To some applications this is very important, to others it is moot.
• Object Relational Mapping, which I've previoulsy mentioned, is also a key aspect of many programs. There are many ways of implementing this feature, but surely a standard for specifying the mapping would be beneficial to all.
• XML mapping or Object mapping of one form or another can also be a key aspect of persistence. Once again, there would be no need to reinvent the wheel each time an application is written if standard solutions could be applied.

Make JDO the "P" in CMP

Bruce Tate's article "For JDO, the Time Is Now" brings up many good points, but it misses a key concern of mine: Solutions that already incorporate Entity Beans would be painfully expensive to rearchitect as JDO solutions.

The J2EE specification for Entity Bean CMP should dictate the interface for using JDO as a persistence mechanism. This would allow developers to reliably introduce JDO below the Entity Bean level without impacting the overlying layers of their applications.

I am involved with a project that uses Toplink as the CMP mechanism for Entity Beans and have experienced the pain of incorporating a non-standard persistence mechanism. Bruce is not completely candid when he states that TopLink can be used as a snap-in replacement for EJB CMP; it's more like a hack-in or pound-in replacement.

The interface between the EJB container and an underlying persistence mechanism is not a part of the J2EE standard, so Oracle (formerly WebGain) has to craft unique versions every time the container (in our case WebLogic) changes. At times we have been unable to apply WLS Service Packs because they would break Toplink. This is a real maintenance and upgrade hassle.

A standard mechanism for using JDO as the "P" in CMP would avoid versioning problems between EJB containers and JDO implementations, and it would also enable the ability to truly snap-in competing JDO implementations (competition is a good thing).

On another note, Bruce lobbies for the recognition of SQL in the JDO standard, and I heartily agree. EJBQL and JDOQL just aren't up to snuff, and from my perspective they just aren't worth bothering with. SQL is not as "Java friendly" as the new query languages, but it is much more comprehensive and widely understood. It seems like a distraction to pursue EJBQL, JDOQL and JDBC rather then focusing on tools to help developers write good SQL.

All in all, I am delighted at the possibility of a JDO resurgence, but I hope that it expands to embrace fixing EJB CMP rather then just replacing it.

Update 1: The problems that we have experienced due to the tight coupling between Weblogic Server and Toplink CMP have crossed the pain threshold to the point where we have commited to fixing the problem.

After careful analysis, we have determined that EJB CMP 2.0 can not meet our needs (primarilly due to the limitations of EJBQL) and the best option for us is to eliminate Entity Beans and use Toplink for Java directly from our session beans. This looks like a rather straightforward conversion for us. I'll keep you posted. Update 2 (July 2004): The EJB 3.0 spec's radical overhaul of CMP has so confused us that we've slammed on the brakes. We're going to maintain our current code for the next few months and wait for the dust to settle.

This work is licensed under a Creative Commons License.