March 2002

EJB 2.0: 20 things you've never seen

Tyler was giving this presentation, which attracted a very compact crowd (people were sitting in the aisles). He proceeded in dispelling all the myths that have plagued EJB because of the deficiencies in the 1.1 specification and then emphasized how much of an improvement EJB 2.0 was, even over solutions like Stateless Session Beans + JDBC.

The crowd was riveted. I was checking regularly around me, and they were busily scribbling notes and following every word Tyler was saying. The funny anecdotes that he dispensed here and there definitely contributed to make people relate to the problems he was addressing. There were a lot of questions after the presentation and he was still being harassed on his way back to the booth :-)

I have no doubt that all the attendees to this session will go back to their company and try to buy everyone around them into EJB 2.0.

JDO with Entity and Session Beans

Craig Russell, the JDO spec lead (although, not exactly any more) gave this presentation. Before I dig into it, some background about the JDO story.

The JDO effort started in a typical Sun way: a skunk work by a little group which, after a little while, received enough visibility within Sun to become a full project. By the time Sun realized its mistake, it was too late: JDO was competing against EJB and the customers became more confused than ever. Sun never explained in a convincing manner what their position was, except maybe by being clear on the fact that as of today, there was no plan to include JDO in J2EE.

Time went by, and when it became obvious that JDO was nowhere near replacing EJB, Russell changed his angle, in a purely "if you can't beat them, join them" fashion. The message he has been pushing these past months was "JDO can be an alternative to persist Entity beans". Hence this talk, and my great interest in it.

Craig opened by enumerating all the ways that Java objects can be persisted: File I/O, Serialization (I'm unclear on the difference between these two), JDBC, CMP and JDO. The way he sees JDO plugging itself in EJB's is by the use of BMP.

While it is indeed the only approach that makes sense, it makes me very puzzled. As CMP is finally getting the recognition it deserves with EJB 2.0 and when we are finally about to see J2EE users embrace it in full, Sun makes the same mistake again by pushing a technology that will do nothing else than confusing its customers more, and for a result that is far from being overwhelmingly better. But let's leave the controversy for now and focus on the technical side.

Then again, the presentation fell very short. First of all, advocating BMP to push a persistence mechanism is a huge step backward to me, and I don't think I need to explain why it is a bad idea to suggest to customers that they should implement their own transaction marks, handling rollbacks, etc... But most of all, when showing different pieces of code illustrating the different approach (CMP vs BMP/JDO), the difference wasn't very striking to me.

Basically, with CMP, you look up the JNDI name of the home, perform a findByPrimaryKey() and then act on the result. With JDO, you look up the JDO persistence manager, retrieve the object by its key and then do something with it. Admittedly, the implied deployment descriptors are overlooked, but this is more a matter of having good tools (e.g. WebLogic Builder ;-)) rather than a deficiency in the technology.

There are two interesting things to say about JDO, though, but the funny thing is that Craig is pushing the one that seems the least useful to me:

• JDO supports inheritance of objects (this is what Craig emphasizes)
  
  
• JDO's query language is Java (this part is hardly mentioned)
  
  
• After doing SQL and EJB QL for a while, I would certainly feel relieved to write my queries in Java.

The biggest disappointment came when the session ended when I expected that we were finally getting to the interesting part. I can't really understand why Craig thinks that EJB users will be thrilled to use BMP and JDO, but maybe I'm just missing something.

JDO is here?

There has been a lot of news on the JDO front. First, the executive commitee voted 14-0 for the spec on Monday (Apache and Caldera didn't vote). This seems to have injected life into the effort, and people are taking it seriously. I talked to PrismTech (makers of a highly performant JDO engine,OpenFusion [http://www.prismtechnologies.com]) who have noticed a lot of interest in their product at this years JavaOne. POET announced their new JDO engine FastObjects (/news/thread.tss?thread_id=12659), and the vendors have gotten together with a new website for all things JDO: JDOCentral.com.

An inside source mentioned that JDO will probably be included in J2EE at some point (sooner rather than later), and that there is a lot of infighting on how JDO and Entity Beans fit together. This has been the case all along, but now JDO seems to be gaining more and more internal support within Sun.

Craig Russell had a JDO session today, showing where it can fit in the enterprise. The large showing backs up the fact that developers are interested.

Java Sessions: Using JCache, JMS, and XML to Build Scalable Web Apps

Chris Berry, Senior Principal Engineer at E-Trade, started this talk with a simple proposal: He offered the possibility of creating a system that provides significant performance improvements over traditional architectures. How would this be done? Using a distributed caching architecture of course. This would yield better performance results because the system is now effectively 'closer to the client'. Other benefits include high scalability and increased fault tolerance.

Chris then asked the audience what the most computationally expensive tier was. This time, the obvious answer was the data services, or database tier. Distributed caching takes the load off the database tier which greatly increases performance. Since most applications are 'read-heavy', reading the same set of pages frequently, a distributed cache allows for great performance increases by pushing data out to where it's needed at memory-speeds. Hence, the customer does not have to wait for responses since latency, by virtue of caching, has been significanty reduced at the web tier.

At this point, a witty young Englishman, James Strachan, Senior Scientist SpiritSoft Ltd., continued into the more technical aspects of the presentation. He described the various requirements needed for a distributed cache, and gave some indepth exposure to the JCache API.

A distributed cache is a hierarchical tree of caches extending across the enterprise. The basic software components required for a distributed cache architecture are the JMS API, which is the messaging component, JCache, which is the cache provider or component, and application client code. JMS is the data transport component and XML is the data format. XML, the 'lingua franca' and the 'bedrock of the Web' and Web Services, works well with JMS because it allows for the passing of state as opposed to having to pass objects. JMS also works well with JCache because both are independent and highly reusable. In this architecture, a distributed cache can exist at the web tier and the database tier. Distributed caches in the middle tier optimize network communication, topic subscription, and database transaction density.

The distributed caching standard is both powerful, and fairly simple to get into. Real world benchmarks were talked about with E*Trade being the customer. We need to keep up with this API, and hope that it stabilizes in the near future.

J2EE Model-Driven Development

A great part of JavaOne is the architecture talks. Today, one of the more interesting talks was given by Jay Walters from netNumina on Model-Driven Develpoment of Web Services.

The basic idea behind the talk was Model-Driven Development using automated tools: turning a UML model of a system into an auto-generated implementation.

This process of going from a UML business model to an implementation is separated into several stages. The starting point is a Platform Independent Model (PIM) of a system. Through several iterations of an automated tool, a Platform Specific Model is reached. The platform specific models become progressively more detailed, containing more implementation-specific details like design patterns for various platforms (J2EE, .Net) and more domain-specific models (standard financial object models and functionality, for example).

To make things a little bit less abstract, this is similar to what YACC does (turning a grammar specification into an implementation of a compiler), except that in this case, the scale and complexity are much bigger.

PRINTER FRIENDLY VERSION