Dashboard: Developers Face Ajax Compatibility Crisis

Although the desire to jump on Web 2.0/Ajax technologies is great, vendors and developers must agree upon a level of standardization to achieve interoperability.

It's early in the adoption cycle of Web 2.0 technologies, but not too early to spot potential problems. Just as the standards for Web services (XML, WSDL, UDDI, SOAP, and so on) were supposed to promote interoperability, the standard elements behind Web 2.0, especially those for Ajax (XML, JavaScript, CSS, DOM and XMLhttpRequest), should lead to interoperable applications.

Interoperable means an application's development platform or running platform shouldn't matter, but on this score, Ajax is headed for the same problems that have plagued Web services. That's the opinion of Marina Fisher, enterprise architect for Sun Microsystems, and Laurence Moroney, director of technology evangelism for Mainsoft, co-authors (with Ray Lai and Sonu Sharma) of the new book, Java EE and .Net Interoperability (Prentice Hall PTR, 2006).

Although Web services are supposed to be platform-agnostic, achieving interoperability (say from J2EE to .Net systems) is difficult. In particular, using vendor tools that generate Web services semantics in WSDL may produce message structures that are not cross-platform compatible. Similar problems can occur with the SOAP-encoded data model, weakly typed data objects and incompatible name spaces.

Web 2.0, and Ajax in particular, face some of the same interoperability problems, and then some, say Fisher and Moroney. For one thing, Web 2.0 generally refers to applications that are client (browser)-oriented, rather than server-oriented, which complicates messaging. Many Web 2.0 applications are composites (mashups) of other apps and Web services, dependent on how the Ajax (principally JavaScript) handles integration.

In the rush to produce easier-to-use Ajax development environments, the problems that have occurred with Web services development may re-appear. Ajax toolkits may use different methodologies for calling services on the server-side, for example, making it difficult to achieve interoperability. Moroney points out that "some toolkits, such as Microsoft Atlas, let you specify a Service Reference, which automatically generates JavaScript to call the Web service, but only if that service is Atlas-based, meaning it can generate and send a JavaScript proxy to the client. Other toolkits don't even support this, so the developer who wants to consume Web services will likely have to manually code and parse the SOAP going to and from the service."

Moroney suggests a technical fix: "The tools vendors could add the facility to generate JavaScript proxies by parsing the WSDL of the Web service. In this scenario we could have a tag that, when parsed by the server, creates the JavaScript proxy class or function for calling the Web service and then 'injects' the source code for the proxy into the page as it's generated." Thus, any other JavaScript on the page would be able to talk to that Web service, whether the script is hand-coded or generated by the same server. But for this to happen, the tools vendors should ideally agree on the spec for this JavaScript library/proxy format.

Most enterprise shops work in a mixed environment, and interoperability is usually not an option. Although the desire to jump on Web 2.0/Ajax technologies is great, vendors and developers must cooperate, and a level of standardization must be agreed upon to achieve interoperability. The process that leads to this standardization will not happen by accident; and the sooner it starts, the better. --Nelson King

Editor's Choice
Joao-Pierre S. Ruth, Senior Writer