|By Andrei Iltchenko||
|January 22, 2007 01:00 PM EST||
One of the things that kept me and my team busy over the past couple of years was starting to support J2EE 1.4 in OptimalJ - a goal that we accomplished with the release of OptimalJ 4.2. Now that this job is complete, it's interesting to look back and ponder the experience and learn from it.
As OptimalJ is a vendor-neutral modeling tool that generates J2EE applications, we tend to avoid application server-specific features that are not mandated by J2EE. Typically our first take is to implement our code-generation modules by the letter of the spec and then ensure we fill in the necessary bits for a particular vendor by generating additional vendor-specific deployment descriptors. This task, quite feasible at first sight, proved rather intricate with J2EE 1.4. Why? One reason is incomplete implementations of certain parts of the spec. However, there were more causes as you'll see later. But first let's recap the history of J2EE 1.4.
The spec was released in November 2003. The first J2EE product certified by Sun was JBoss 4.0.0 released in July 2004. IBM's WebSphere 6.0 went out in October 2004, while BEA's WebLogic offering hit the market in July 2005. All these products passed Sun's J2EE 1.4 CTS. For an idea of what the J2EE CTS embodies, take a look at this interview: www.theserverside.com/tt/articles/article.tss?l=SunInterview. Here's a relevant quote from http://java.sun.com/javaee/overview/faq/j2ee.jsp (my emboldening):
J2EE technology is a set of standards that many vendors can implement. The vendors are free to compete on implementations but not on standards or APIs. Sun supplies a comprehensive J2EE Compatibility Test Suite (CTS) to J2EE licensees. The J2EE CTS helps ensure compatibility among the application vendors, which helps ensure portability for the applications and components written for the J2EE platform. The J2EE platform brings Write Once, Run Anywhere (WORA) to the server.
Our first surprise was with the new MDB (message-driven bean) contract. One vendor's product simply couldn't cope with the new activation configuration concept. This is really the core functionality of EJB 2.1 and JCA 1.5. In EJB 2.1, MDBs are decoupled from JMS and their component contract is changed to be extremely generic and extensible. They can receive messages from virtually any inbound resource adapter, not necessarily a JMS adapter. If you want to learn more about the interaction between resource adapters and MDBs in J2EE 1.4, take a look at this article: www.theserverside.com/tt/articles/article.tss?l=J2EE1_4. It is amazing how the product could pass Sun's J2EE 1.4 CTS without implementing this support.
The next wrinkle was with the timer service - a long-asked-for missing piece of J2EE that enables enterprise components to have a reliable and transactional timer. An enterprise component can request that a callback method be invoked on it after a given passage of time (possibly repeatedly). The component can query for pending callbacks, cancel some of them, add new ones, etc.
An important consideration here is to note that in EJB 2.1 all instances of the same stateless session bean (SLSB) and the same MDB are considered equal, i.e., if the container has created and pooled n instances of SLSB BeanA and one such bean instance has scheduled a time notification, the container can pick any of the n instances in the pool to service the request. While the timer notification is pending, any of the n BeanA instances that the container invokes can query for pending timer notifications and see that the notification is pending. That instance can cancel it, so that the timer event will be annulled and not invoked on any of the n instances.
Great was my surprise when I saw that one vendor implemented the timer service without regard for the above fact. The vendor's product sometimes allowed one instance of BeanA to observe the pending timer notification as cancelled and then suddenly again as pending - all in the same transaction!
A friend of mine, who works at another company, had a similar experience with his vendor (also certified by Sun as J2EE 1.4 compliant). He was deploying his application in a cluster and used the timer service with SLSBs. The phenomenon he witnessed was this: he had a pool of n BeanA instances deployed to multiple nodes in the cluster. When any of the n BeanA instances scheduled a timer notification, only the BeanA instances running on the same node as the bean instance that scheduled the notification could see and service it. BeanA instances running on different nodes would neither see the pending notification nor be able to examine or cancel it, which essentially breaks the EJB requirement that all instances of the same SLSB have the same object identity.
With such surprises from certified J2EE 1.4 servers, how can you write a portable J2EE component that uses the timer service and enjoy the "Write Once, Run Anywhere" experience?
All this was small time compared to the issues we ran into when dealing with the highlight of J2EE 1.4 - support for Web services. The details of a compliant J2EE 1.4 Web services implementation are spelled out by three constituent specs that J2EE 1.4 includes by reference: Web Services For J2EE, Version 1.1 (aka JSR-109/JSR-921), JAX-RPC, Version 1.1, and WS-I Basic Profile, Version 1.0. The last specification is crucial in ensuring interoperability of Web service components developed with J2EE.
One cardinal requirement of a compliant Web services stack is that it can handle literal serializations/deserializations of Java Data Models into/from XML. The need to support literal serialization of data calls for an XML Schema-aware Web service. If a vendor's Web service stack is not XML Schema aware, you will very likely have issues with the interoperability of the Web services you deploy to the vendor's product.
When we started testing our code generation modules on one vendor's product, we were in for a big surprise. The application server had a non-XML Schema-aware Web services stack, which effectively meant no proper support for WS-I Basic Profile. Why wasn't such a major omission caught by J2EE 1.4 CTS?
That wasn't all. Two products we tried couldn't handle overloaded methods in service endpoint interfaces (SEIs) of J2EE components. For an idea of what the SEI is, refer to my earlier article "Moving to SOA in J2EE 1.4" (http://java.sys-con.com/read/180362.htm).
Another major obstacle was with document-literal bindings. One of the three vendor products we support required that additional Java code artifacts called "wrapper beans" be generated and registered in a JAX-RPC type mapping DD for every operation of a SEI that is exposed as a Web service component with a document-literal binding, while two other products wouldn't work when such extra code artifacts were generated and registered. Yet more unfortunate was the fact that the product requiring the extra code artifacts left it up to the component developer to provide these rather than generate them automatically during deployment. Being quite unhappy with such a state of affairs, I decided to contact the "Web Services for Java EE" specification lead with a view to ensuring that the issue be resolved to the benefit of Java EE developers and the "Write Once, Run Anywhere" goal. One reply I got back from the spec lead was this:
We had clarified to you before on this issue that there is not much we can do for the JAX-RPC case with JSR-109 v1.1 or v1.2. There are J2EE 1.4 compliant application server vendors who have passed the CTS (Compatibility Test Suite) and changes proposed by you would mean that they would now need to fix their implementations to conform to this new requirement. This will not be received well by vendors who have all ready spent their resources getting J2EE 1.4 certification. While I do appreciate your intentions of improving developer experience, this may be a bit too disruptive for the application server vendors/licensees.
We have made improvements in the deployment/packaging process with the latest release of JSR-109 v1.2 (part of Java EE 5.0) for JAX-WS endpoints. Unfortunately we found more inconsistencies with document-literal bindings. One J2EE 1.4 certified vendor couldn't deal with Web service components featuring methods without a return type when a component's binding was document-literal.
Another problematic area was the JavaBean-based nature of SOAP serialization rules (http://java.sys-con.com/read/180362.htm). When a J2EE Web service component receives or returns a value mapped to a JavaBean, the container is supposed to serialize it to/deserialize it from XML by using the java.beans.Introspector class to examine its properties. Two out of three products we tried didn't do that in the initial version of their products.
It's true that it is all but inevitable that a complex product has bugs, still most of the issues I presented above are of a bigger scale than simple bugs and should have been flagged with the J2EE 1.4 CTS.
Where Does Modeling Come In?
With the differences in implementing the same J2EE 1.4 features I described, you should probably start questioning how feasible it would be to maintain a J2EE 1.4 application that needs to run on more than one application server and not be rigged toward a given vendor. Based on the experience we have gone through, I've come to the conclusion that doing that might be quite a pain and will definitely not scale as the size of your application's code base increases. This, in my opinion, is a valid example in which model-driven architecture and development delivers the fruits so long as you have chosen a mature and reputable MDA product that supports J2EE.
You are welcome to discuss the topic on my blog: http://blogs.compuware.com/cs/blogs/andrei_iltchenko/default.aspx.