OpenAjax Alliance had its 2nd face to face meeting on Oct 5th and 6th at Sun Microsystem’s office in Santa Clara, CA after the AjaxWorld Conference. While paying close attention to confidentiality concerns, I feel comfortable sharing some of my thoughts and reactions. In particular, I am sharing some of my thoughts on the key challenges facing Ajax adoption and what OpenAjax should try to address in the near term. I love to hear feedback from the community (please comment here) – after all, OpenAjax Alliance should be working on issues that the community cares about, right?

The goals of this second meeting were to communicate what we have achieved so far, address some of the questions that emerged over the last few months (such as intellectual property policy), establish a steering committee that would make decisions on every aspect of the organization on behalf of all members and talk about some operational aspects of the organization, share with each other as well as some customer representatives the experience and challenges we see about Ajax, and discuss what are the key issues/initiatives that we should go after going forward. In my opinion, this is a very successful meeting and we have achieved all of these goals.

OpenAjax Alliance Accomplishments so far
OpenAjax Alliance has made significant achievements over a short period of time in my opinion: growing membership to over 50 industry leaders, launching website, publishing a technical white paper ( on the cover page of the inaugural AjaxWorld Magazine, the OpenAjax Hub (, etc.

Election of OpenAjax Steering Committee

With each member company having one vote, OpenAjax Alliance elected its inaugural 7-member Steering Committee: Dojo Foundation (SitePen), Eclipse Foundation, IBM, Nexaweb, Tibco, Zend and Zimbra. The individuals that represent these member companies on the Steering Committee are: Alex Ruseel (Dojo/SitePen), Mike Milinkovich, David Boloker(IBM), Coach Wei (Nexaweb), Kevin Hakman (Tibco), Mike Pinette (Zend) and Scott Dietzen (Zimbra).

In my opinion, this is a well balanced committee that would give OpenAjax Alliance the right leadership and guideline to make it successful. The committee includes representation from big commercial vendors (IBM), median size commercial vendors (Tibco) and smaller commercial vendors (Nexaweb, Zimbra, Zend), consulting/service companies (SitePen) and open source organizations (Eclipse and Dojo) – with each of the entities being a recognized leader in their respective areas. The people serving on the committee all have strong background and track record related to open standards, enterprise software, Ajax and web 2.0. For example, David Boloker is CTO of IBM Emerging Technology, Scott Dietzen was CTO of BEA Systems before Zimbra – together with Sun, they played key roles in launching the Java Community Processes and delivering the success of Java community today. Kevin Hakman and I have both been developing products to enable Ajax and Web 2.0 for the enterprise starting from 2000. My experience of working through over 5000 enterprise deployments of Nexaweb can be valuable to the cause of the alliance. Alex Russell is the leader of Dojo Foundation and one of the widely recognized experts in Ajax. Mike Milinkovich is executive director of Eclipse Foundation – his experience and insight of how to work with many different companies are invaluable to the alliance. Zend is a growing company that has established a strong reputation in the open source community.

Key Ajax Adoption Barrier: Confusion

Quite a few companies spoke of what they heard from customers related to Ajax adoption and their wish list for OpenAjax Alliance. In particular, I enjoyed talks from John Crupi (CTO of JackBe), Andre Charland(Nitobi), Anil Sharman (VertexLogic) etc. Greg Murray from Sun Microsystem showed jMaki and Chris Schalk from Oracle showed ADF Faces …-very impressive.

I think the biggest adoption hurdle for Ajax has nothing to do with technology. The biggest adoption hurdle is the massive confusion going on right now. Ajax is not the solution to all problems. There are different levels of adoption of Ajax (borrowing terms from Ray Valdes from Gartner: snippet, widget, toolkit/client-side framework and client/server integrated framework). Different Ajax solutions are for different levels of adoption, etc. – I personally strongly recommend a web 2.0 reference architecture to customers because they need something like this to understand the landscape and pick the right solutions.

Technical Issues that OpenAjax Alliance Should Address in The Near Term

There are different categories of developers (architects, application developers, business analysts, designers, content creators, etc. See my blog on  developer community) – how should we address their conerns about Ajax? In which order?

I think the first step is to address the needs for architects – give them the capability to use Ajax from different vendors or packages. Among the 180+ Ajax toolkits, “Interoperability” is very low today. Even for architects, it is very hard to pick and choose different components from different packages. "Interoperability" seems to be the No.1 issue to address.

To address interoperability, I think OpenAjax Alliance should try to address the following five issues first (collectively loosely referred to as “OpenAjax Hub”):

  1. Toolkit “loading and unloading”(the capability to load and unload more than one Ajax toolkits into one page): For example, right now a lot of toolkits overload the “onload” function, which will certainly cause collision with another toolkit;
  2. Name collision (the capability to deal with variable and function name collision). For example, quite a few Ajax toolkits today use “$” as a function name. When they are all loaded onto the same page, what happens?
  3. Event Hub (The capability to have interaction between different Ajax toolkits). The key requirement here is to enable some kind of “event” propagation so that an event generated from toolkit A can be processed by toolkit B. An example is that the user drags an item from Toolkit A and drops it on Toolkit B – how should this two toolkits communicate the information related to this event? The proper solution is to provide a common event hub that each Ajax toolkit can publish and subscribe events. Initially, we do not have to define the details of different event objects, which can be defined in the future.
  4. Markup scanning (the capability for an Ajax toolkit to scan an HTML document to pick up the interested markup segments for processing): many Ajax toolkits allow the usage of markup to define components within an HTML page but they all have their own mechanism of scanning the document. If more than one toolkit is loaded, the HTML document maybe scanned multiple times with the danger of causing significant inefficiency and collision. Providing a common mechanism to scan an HTML document would solve this problem.
  5. Network Hub (server connectivity management): most browsers allow only limited number of connections to the server (for example, Internet Explorer allows only two). If each Ajax toolkit uses its own mechanism to handle server connectivity, it is highly likely collision will happen if more than one Ajax toolkits are loaded on the same page. A proper solution is to provide a common mechanism that centrally manages server connectivity and serves all registered toolkits.;

What do you think of these issues? Are we on the right path if we solve the above five issues first? Your comments are very welcome.

Key Additional Technical Issues for Ajax Adoption

There are obviously quite a few additional important technical issues that we would like to address – but for a variety of reason, I don’t feel they are within the reach for OpenAjax Alliance in the very near term; however, I’d like to hear your feedback.
  1. Performance: Some browsers, in particular, Internet Explorer, do not good a good job at processing Ajax code. Can we figure out a way to influence these browser vendors to fix some of these issues?
  2. Ajax toolkit footprint. A lot of Ajax toolkits are actually fairly big, some times over one megabytes. The need to download megabytes of JavaScript is not helpful for user adoption. Combining multiple toolkits will only make this issue worse. How can this issue be addressed?
  3. Security: There are lot of fuzz about Ajax being not “secure”, 95% of which is FUD. How can we educate the market and customers that Ajax itself does not necessarily impose new security issues? Further, if there are real security concerns, what are they? How can we collectively address them?
  4. Offline and Mobile Ajax: Mobile computing is important from an OpenAjax Alliance point of view, but is Mobile Ajax realistic now? What should we do with Mobile Ajax? (BTW, Alex Russell has an excellent blog on this subject) Talking about mobile Ajax, shouldn’t we address offline Ajax first? Shouldn’t we try to make sure Ajax work well on desktop first?
  5. Development and Maintenance Difficulties with Ajax: What should we do to make Ajax accessible to typical application developers, beyond these highly skilled architects?

    Writing distributed application has always been hard. Ajax, given its high dependency on browsers, browser versions and operating systems, the mix of many different technologies (CSS, DHTML, JavaScript, DOM API, etc), the difficulty of maintaining large amount of JavaScript code and the lack of development tools, has been a luxury of the gifted few so far. While companies like Google and Yahoo can afford to hire the best engineers to build amazing applications using Ajax and have truly opened the eyes of the mass, typical enterprises do not have the capability to do so.

    I personally believe if Ajax does not extend to the reach of typical application developers, it will remain a luxury for the gifted few and will never achieve wide enterprise adoption. The mission of OpenAjax Alliance is to advance enterprise adoption of Ajax while preserving the open value of the web. If we, as an industry, do not address the development and maintenance challenges of Ajax, we will fail in our mission.

    On the other side, I don’t necessarily think OpenAjax Alliance is the only channel to solve the Ajax development and maintenance challenge. There are already some really good efforts going on now in the industry. The efforts include both tooling and runtime offerings:

    • The ATF Project at Eclipse Foundation is going to be a solid IDE for writing Ajax applications. I was very impressed by the talk given by Robert Goodman from IBM on Eclipse ATF at AjaxWorld Conference.
    • Apache XAP targets at solving the same problem from a programming model and runtime perspective (by using declarative Ajax to minimize the coding effort required by developers);
    • Speaking of my company, Nexaweb, we have been working with Eclipse ATF developers in building a visual IDE for Ajax. I think it will be very cool and will bring Ajax to the reach of normal application developers.  There are probably a few other vendors trying the similar effort as well – though I don’t know any at the moment.

Here is my wish list to my blog readers: I’d really love to hear from you about what you think. Do the near term objectives for OpenAjax Alliance (OpenAjax Hub) make sense? How can we make sure different Ajax toolkit providers conform to OpenAjax Hub so that we have interoperability? Further, with regard to the additional list of issues (performance, mobile, offline, security, development and maintenance difficulties), how should we approach these issues? In which priority? What do you recommend OpenAjax Alliance do? What do you recommend individual vendors (like Nexaweb) do? What do you recommend we, as an industry, together do? Please leave your comments either at my blog (at  or feel free to email me at cwei at nexaweb dot com. I love to hear from you and I definitely value your input!