OpenAjax Alliance Plants its Stake in the Sand

By Tony Baer

With the formal launch of its website today, the OpenAjax Alliance is formalizing its near-term goals, announcing the beginnings of its organizational structure, and releasing its mission statement.

The group was formed last May to make some order out of a technology where there are, by some counts, roughly 200-odd tools that still march to their own drummers.

Specifically, the 50-plus member organization will convene early next month and elect its first steering committee, which will consist of seven members. And members will be asked to sign a formal agreement that core technologies submitted must be royalty-free and publicly available based on the Apache 2 license.

Beyond that, the organization plans to operate on the basis of moral rather than formal authority. It's as if the Java Community Process (JCP) were re-imagined in an age of open source, and where nobody wants any single vendor to be more equal than most. In other words, the group is trying to hang onto the idealism against which it was formed.

So at this point, nobody's planning any reference implementations. "We're going to be much more lightweight than the JCP," said acting director John Ferraiolo, who recently joined IBM from Adobe. He said that OpenAjax would try more informal approaches. "We've chosen that direction because it's a high priority for us to encourage innovation."

As to what the organization plans to do, the initiative is called "The OpenAjax Hub." That's the standard JavaScript functionality that addresses interoperability issues that occur when multiple Ajax libraries are used within the same web page.

Until now, that's been an academic issue because the technologies were largely confined to a single web page, and because each of the technology building blocks were standard. For instance, JavaScript is an ECMA-based standard designed to run atop W3C standard HTML web pages, leveraging yet another W3C standard, XMLHttpRequest (the piece that lets a JavaScript-based web page selectively update itself, rather than require a complete page refresh).

So, if you designed your own web page with the same tools and same libraries, you never had to worry if the page would render.

The problem emerged with mashups, where you combined different pieces of JavaScript-rendered objects. Suddenly, you were dealing with different tools, each with its own unique libraries, having to coexist on the same web page.

What's kept the problem manageable until now has been that a few places on the web, such as Google Maps, enforced their own de facto standards. But as mashups get more widespread, something more formal will be needed to fill the vacuum.

For now, OpenAjax is proposing that the hub act as an intermediary to allow toolkits to reuse and mingle libraries from different toolkits. And it would include a standard control for invoking Ajax libraries at run time, a PubSub event manager, a markup scanner for ensuring that the right calls are invoked, and an anti-collision feature to ensure that different Ajax libraries are not trying to control the same objects.

What's missing is a conflict resolution feature to deal with events where those conflicts actually occur. That reflects the fact that the 4-month old group is still defining its mission, and has not yet even decided whether, after electing a board, whether it would still have an executive director.

About Datamonitor