AJAX is more than DHTML

Software Developer has an interesting article on the convergence of SOA and AJAX (WOA if you're a follower of Gartner's jargon). While most of it is spot on, there's one quote from Jason Bloomberg, senior analyst with ZapThink that made my teeth itch.

"Without SOA, AJAX is just the next generation of JavaScript," says Bloomberg, "it just allows you to come up with new ways to do drag and drop."

No, actually that's not true at all and such a statement oversimplifies the functionality provided by the XMLHttpRequest object (a misnomer in itself as the object is often used to exchange data formats other than XML like JSON and HTML). Anyone who's developed seriously using AJAX knows it's a lot more than just drag and drop or the manipulation of DHTML to create sexy interfaces. AJAX at its core is based on asynchronous messaging between the client and the browser.

While developers may use DHTML and CSS tricks to display the data exchanged in an asynchronous manner between browser and server, it's not the enabler of the interface, it's merely the presentation. Without the XMLHttpRequest object, AJAX is reduced to exactly what Mr. Bloomberg postulates: a library that enables rapid development of user interfaces. But they aren't interactive without the exchange of data on an asynchronous basis, they're just really pretty to look at and fun to click around in.

An old friend who is now at Network Computing and I were discussing whether you needed SOA for Web 2.0 (AJAX) just yesterday. And when it comes down to it, you don't need SOA to enable Web 2.0, though the marriage of the two certainly makes sense and businesses will derive the most value from using both technologies together.

It could be, and likely will be, argued that any script providing the back-end "services" for AJAX are necessarily SOA by their very definition. But that's only because the definition of SOA is so nebulous that just about any application based on the granular execution of specific business functions can be labeled as such. But that doesn't imply that said scripts comprise a fully implemented SOA. In fact, most of them are just that - single scripts that execute actions based on the query parameters coming from within an AJAX-based interface. Some are separated out into one script per call, which is closer to what most would define as a SOA, but as those scripts are rarely reusable and are generally developed based on the granular functionality of an interface and not business functions, they defy being classified as true SOA services. But the AJAX-based applications based on exactly this method of development are certainly more than just "drag and drop" interfaces. They're fully functioning, interactive applications.

So no, Virginia, you don't need a SOA for AJAX to provide value or enable an RIA. The lack of a robust SOA does not reduce AJAX to just a "drag and drop" library any more than the implemention of an AJAX-based application means you've deployed a SOA.

Imbibing: Coffee