This weekend, I read a pretty ridiculous article. You may have heard about it, it’s titled: “How to save JEE, and it’s not EJB3.0”. JDJ must have nothing new to write about these days considering that the original post had been published 9 months ago and they’re just getting to it now. But whatever, that’s not my issue. First it’s the idea that Java EE is in trouble, which is just plain silly. To take it a step further and state that it can be “saved” by looking at the examples that AJAX set fourth, is lunacy.

AJAX has its place and there are some compelling reasons to use it, but it is still an experimental and inconsistent technology. As Brandon reminds us, with AJAX, “there is not even a ‘reference implementation’ of it”, as if that is a good thing. To further that point, nor is there a concrete definition of what AJAX is or how a browser should implement AJAX technologies. In fact, AJAX is nothing more than DHTML plus remoting. The W3C DOM specs covers much the interactive portion of AJAX, but there is nothing to cover the remoting aspects of AJAX. Most of us are also aware of how inconsistently the DOM is implemented accross browsers. With that said, you will be hard pressed to find consistency across applications which implement AJAX.

Any Backend you Want

I’ll agree that coding strictly to the JEE spec probably doesn’t suite everyone’s needs, but the JEE stack does provide a lot of flexibility. My current J2EE architecture of choice is a combination of Session Beans plus Hibernate. Not a strict J2EE design as per the standard, but I feel the choice of Hibernate is better than using Entity Beans. I did get to choose my own back end and chose my own persistence API. Additionally, Hibernate complies with J2EE standards as it can participate in a container managed transaction and be managed through JMX. As of 3.2, Hibernate can be used as a full-on JEE 5 standard, or still used as plain old Hibernate. The choice is mine.

I never felt inclined to implement my own servlet container, transaction manager, JMS implementation, persistence API, or whatever. I’m very pleased that the JEE spec defines what components of the JEE stack need to be implemented in order to be called JEE Compliant. I have choices from several vendors which follow the JEE spec or integrate nicely with the platform, as is the case with Spring. I have a certain expectation that vendors will offer specific JEE features but look for the value adds that the vendor may provide. I still can choose “any backend I want”, but still can count on a level of consistency between products. I have great confidence that I can publish a message from an application running in WebLogic to a queue that resides on a WebSphere MQ instance using JMS, and it will work as expected. If JEE were to take a page from AJAX, we’d have to write multiple “if/else” blocks to handle the different ways each messaging system implements its messaging interface. Even better, I have a great deal of confidence that I can reliably execute an RMI call from a client running a Sun JVM on Windows to a JBoss instance running on Apple’s VM on Mac OS X by doing nothing more than calling the remote method. If JEE followed AJAX, this would be a 100 steps backwards.

Any backend you want, as long as you use my front end

AJAX frameworks like DWR (which is an awesome AJAX project BTW) muddle Brandon’s point about using any back end you want. For starters, I can sit DWR on top of a pure JEE application, JEE/Hibernate hybrid, or Spring based app just fine. But each AJAX framework out there uses some form of proprietary message format to transmit to the browser. Additionally, not all AJAX frameworks use XML as the messaging format ( which begs the question why is there an “X” in AJAX?). Now suppose the stability of the AJAX framework you’re using starts to deteriorate either under heavy load, or the project has just fallen apart. Now you need to think about switching to something more stable. In the case of DWR, you will have a lot of reworking that needs to be done on the front end as well as the backend. So I sure can use any backend I want with AJAX. But when you change it, be prepared to change the frontend too.
The Need for AJAX Standards

Most of folks have “good idea” of what AJAX is but there are no specific guidelines or official AJAX patterns that have been published. To make matters worse, browsers such as Mozilla, Safari, and Opera all have subtle differences to how they implement the XmlHttpRequest object. Remember, that Mozilla’s implementation is derrived from Microsofts XmlHttpRequest ActiveX control, which is a propritary technology. The Mozilla implementation is method compatible with Microsofts, but the means to instantiate the object differes between the two browsers. To date, there is no formal agreed up spec as to how this object should work. Safari for example, still cannot execute certain HTTP methods.

So with all of this “exciting” inconsistency between browser implementations, what example should JEE learn from? In fact, I think the opposite could be true: AJAX could learn a thing or two from JEE. Publishing a spec of what the XmlHttpRequest object should and should not support would be an excellent first step. Second, a common message format would also help a lot. The folks at Adobe get this and that is why the Flash player has direct support for consuming Web Services as well as the ability to interact with RESTful web services. Having stanard means to consume WebServices directly via JavaScript in a WebBrowser would be outstanding. The ability to plug into an SOA architecture using existing WS standards would be great. Hell, even XML-RPC would be a great start.

Yes freedom is good, but anarchy is worse. AJAX, in its current form, is anarchy and chaos in the same bag. Standards are not a bad thing. But enough with this crappy article.