The Open Ajax Alliance has been in existence since late 2005/early 2006. In that time I am not sure what they’ve done other than publish the OpenAjax Hub.

The charter is “The OpenAjax Alliance is an organization of vendors, open-source initiatives and Web developers dedicated to the successful adoption of open and interoperable Ajax-based Web technologies. The alliance’s prime objective is to accelerate customer success with Ajax by improving the customer’s ability to mix and match solutions from Ajax technology providers and helping to drive the future of the Ajax ecosystem.”

I can see how back in 2005 the view might have been “hey, there’s a lot of buzz about Ajax, why not form an alliance so we can make things go smooth”. Truth is I don’t think any of these vendors were too concerned with interoperability, at that time they all wanted to one-up each other and get their latest/greatest ajax platform out the door.

As history now shows, there haven’t been a whole heck of a lot of interoperability problems (not due to the openAjax alliance). Since the underlying data of Ajax is XML or JSON, it’s fairly hard to make things not interoperable. Let’s define interoperability in this context;

1. if you combine two or more javascript libraries (in fact the OpenAjax alliance goes even more specific and says “Ajax” libraries) will they each function.
2. Can two or more libraries exchange data.
3. Can two or more libraries trigger or subscribe to the same events.

I’ve probably missed a few things but those are the basics. Unless the library goes completely overboard it’s likely to be fairly safe.

That said, are the so many issues in the field that it warrants formation of an alliance across companies? Hardly.

One reason that interoperability of Ajax frameworks has not been an issue is that folks typically don’t use more than one. The ones they DO mix and match are typically very lightweight and tend not to step on one another’s toes. E.g. Prototype.JS and JQuery* can quite happily co-exist.

So why bother with this Alliance? I don’t know.

These groups make me nervous. They’re typically “name dropped” in meetings when you’re actually trying to get something done. “We can use OpenHub, it’s industry standard”. This is like a grenade going off. The magic combination of “Open”, “Industry” and “Standard” is like the Queen of Diamonds to the Manchurian Candidate. The room perks up and folks align their points of view with the speaker.

OpenAjax Hub amounts to less than 200 lines of JS code, including comments. I challenge anyone to find the download link on OpenAjax.org. Did we need an alliance in existence for 4 years to nail that?

Alliances such as OpenAjax are an example of design by committee that that by their very nature stymie innovation. Think about it, you’ve got 1 or 2 representatives in the alliance from 8 or 9 companies that are otherwise competing with one another. They meet once a week for an hour long con-call. Every new feature or requirement is proposed, reviewed, submitted for feedback over a very long period before being implemented. Hardly agile development.

So what’s my point? I think the ideas put forth by OpenAjax are valid, noble ideas. Interoperability between Ajax frameworks, great idea. But how many times has this issue come up in the real world? If it IS truly a problem I’d argue we don’t need an alliance to fix it. If anything I think the alliance makes it happen slower. With all that said, if I DID face the problem of using two different Ajax frameworks on the same page, I’d probably look to the OpenAjax Hub to fix it. Hey, no one ever got fired for hiring IBM.

So beware of “alliances” (unless you’re on CBS Survivor**).

* JQuery supports OpenAjax Hub through an extension.
** Be doubly wary of alliances.

Ask a question in a meeting on any of these and you’ll give off an air of being really tech-savvy. Unfortunately the question and answer will be pointless. People ask anyway:

1. BPEL compliance (Business Process Execution Language): "Is your engine BPEL compliant?" Doesn’t mean anything. You’ll never switch orchestration engines. Even if you do and your orchestrations are BPEL compliant you will still have re-work to do to get them up and running.
2. "Pure Java": Doesn’t mean anything. When was the last time you switched application server? From say BEA to WebSphere??? Never happens. I don’t understand it but for whatever reason folks feel more comfortable if their code is "portable" even if they never port it. 
3. "Lightweight container": Everything’s a lightweight container. I have yet to meet a heavyweight container but if I do I’ll shake it’s hand.
4. "Do you support WSRP?": Web Services for Remote Portlets: Useless feature that should never be used. Sort of like a toilet with a passenger-side airbag.
5. "Your business folks could edit this process": No they couldn’t or if they could it’s typically not a good idea to let them.

I’m sure there are others, what other useless but sought after features can you think of?

Judging by the responses at TheServerSide.net [LINK] it would seem the answer is unfortunately no.

If you look at the spec though it’s pretty blatantly obvious to me that the real answer is it was never alive!!!

WSRP stands for Web Service for Remote Portlets. It lets you share a portlet hosted in a portal with other portals based on configuration alone.

The host (WSRP producer) instantiates the portlet and then serializes it into XML, including HTML and wraps the whole thing in SOAP. It also does things like URL re-writing to avoid collisions with the consumer. It even does things like re-writing the javascript.

It’s a super lazy approach and the problems are numerous:

a) The size of the data packet over the wire: Includes Presentation and Data combined.
b) Have to layer security on top of it. Can flow security contexts over in some cases but generally you’ll want to do WS-Security over SOAP. Now you’re really bloated.
c) Context: The portlet think’s it’s running on it’s host portal, can’t interact with other portlets on the screen as it doesn’t know where it’s being hosted.
d) Things like Ajax or javascript-ish controls are going to be tough to debug.
e) Performance: All that stuff on the wire.
f) Additional processing for stuff like Request.Redirect to strip out HTTP headers.

The list goes on and on and yet this spec is on V2.0 now!!! I don’t understand it but there you have it. With things like JSON/REST/SOAP and the ease by which you can create a UI nowadays you’d think folks’d wise up, take the hit and build a native portlet to consume a data web service. You’re life will be so much easier in the long run and you’ll get better mileage from the data web service than you will from WSRP web services.
<shakingHead rollingeyes="true" />