Yesterday I was reminded just how much work the OpenDocument group has to get before it becomes a usable standard. I say “usable” because as of now, I cannot use it. At least on my PowerBook anyway. Normally, I write my posts in a either OpenOffice or MS Word. I don’t have office on my PC so I use OpenOffice. Since Mac OS X is my primary platform, I own an MS Office 2004 license. I started yesterdays post while on my PC and I later attempted to finish it on my PowerBook. I saved it as an OTD, and then I was quickly reminded that it cannot be opened on a Mac OS X system.

It’s interesting that my home state is pushing for a standard that really on supported by one major Office Suite. There is this page which lists the appications that work with OpenDocument. But with the exception of AbiWord (which still leaves A LOT to be desired) nothing in that list runs on a Mac. Ignoring Windows for a moment, Mac OS X represents the next largest installed base for desktop systems. Mac OS X is still much bigger than Linux on the desktop. And please don’t tell me that OpenOffice will run fine under X11 or that NeoOffice is “will work.” Yes, they do work, but they are both unfished or do not integrate with the OS. Take a quick glance over at opendocumentfellowship.org, and it doesn’t look like much progress is being made on making applications that support OpenDocument. And lastly, the ODF Add-In for MS Word will only work on the Windows version of Word.

The other major word processor on Mac OS X is Apple’s own Pages which supports the current MS Word format. Seeing how Apple is on the ECMA Technical Committee for the standardization of the Office Open XML Format and not on the OpenDocument comittee, I can only imagine that the next release of Pages will support the Office Open XML format. Additionally, Office 2007 for Mac OS X will support the Office Open XML Formats as well. But still, not a peep from the OpenDocument community on how they intend for Mac uses to be able to work with this new “standard” format.

So come 2007, Mac users won’t be able open documents from the great state of Massachusetts, even though it is an ISO standard. It’s ironic that a standard is shutting out an entire platform! Wasn’t Microsoft accused of this 6 or 7 years ago? I’m all for standards, but when only a very small group supports a defined standard, is it really standard? Remember that Mac users are a whiney, pissy bunch who make themselves heard when we’re being neglected. With the current state of OpenDocument on the Mac, I’m hedging my bets that Microsoft will be successful at making Office Open XML the defacto document standard. That is of course if Adobe, which is an OpenDocument member, doesn’t swoop in the next few moths with a cross-platform Office Suite which intgrates with Acrobat and their graphics tools. Such a product on Mac OS X might be far more compelling than what Office 2007 might provide.

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.

My mother is a breast cancer survivor and I have another family member who is currently fighting the disease. So in support of the National Breast Cancer Awareness month, Damn Handy will be Pink for the month of October!