Dave Johnson

There has recently been a maelstrom brewing over SOAJaX with some people claiming their is no correlation whatsoever between the two [1], some comparing the software industry to the fashion industry [2], some making nice graphics outlining important implications for SOA designers [3,4] the old �it�s all semantics� argument [5] and some being completely inane [6].

As many before have noted, SOA and AJaX are both just ridiculous acronyms describing architectural paradigms that encompass entire families of web technologies - but let�s try to look beyond that So let�s try to answer the question of what exactly SOA and AJaX have to do with life the universe and everything.

To start with, the �it�s all semantics� argument is correct. If you look around you can find a different definition of SOA depending on the time of day [8]. So, as Dion Hinchcliffe discusses [7], I think a good place to start is looking at what exactly SOA and AJaX are.

To get the definition of SOA I went straight to the horses mouth - OASIS. Since some smart people realized that SOA was completely ambiguous and didn�t mean anything in the real world, a technical committee created specifically to define a SOA reference model (they call this the SOA-RM TC). Hopefully, the result of all the hard work being done by the SOA-RM TC should be some guidelines to help in defining what components are required to actually call something a SOA. The work is not completely done but a recent SOA-RM Technical Committee overview presentation [9] by Duane �cosmic genius� Nickull (I hope that some of the absurd smarts rub off on this Canadian technologist) of Adobe. From this presentation there are at least five things that are required for something to be considered a SOA: a service that can be called through a prescribed interface, a service description declaring all relevant aspects of the service for would be consumers, discoverability, abstract data and behavioural models, and finally a policy which imposes constraints on consumers of the service. Of course loose-coupling is also a SOA hallmark.

Ok. I did not see any mention of Flickr, CSS, XML or the �yellow fade� technique there. Things are looking grim.

Now let�s consider what a RM for AJaX might look like. I am thinking that the important things for AJaX must be some degree of Asynchronicity, JavaScript and XML? Let�s knock of the last two first. Since SOA is quite technology agnostic it cannot really have anything specifically to do with JavaScript or (although most implementations use) XML. However, we may be able to weave a connection around the thin thread that is the capital �A� in AJaX - of course the second �a� is part of the word JavaScript and so should not be capitalized but that is another kettle of fish as they say. Asynchronous. Both SOA and AJaX (for the sake of argument) use either a synchronous or an asynchronous based communication pattern. So in the strictest sense AJaX can be a nice way to consume SOA services and provide a usable interface to them. That being said, if today�s SOAs are defined using the likes of WS-* then AJaX will never rise to God-like status it is striving for because you don�t want the WS-* stack written in JavaScript. So AJaX can consume services based on a SOA if AJaX developers want to play in the same league, but today I doubt it. This is where the commonalities start and end - but hey it�s better than nothing.

Strictly speaking AJaX is simply an important layer above a SOA like any other web application framework today; they are, for the most part, separate and discrete entities. Their paths may cross at some point in an optical fibre in the middle of the Atlantic Ocean but that is as close as they come. Before AJaX rose to super-stardom developers would simply utilize SOA from their Ruby on Rails or .NET or JAVA application running on the server and then convert the returned data to HTML and serve that up to the client. Now that AJaX has landed people have the opportunity to bypass that server layer and go straight to the source - if they want to deal with SOAP, WS-* etc they can do that. In general this is not the case. Since developers are lazy by design (at least the good ones) and AJaX developers (the laziest of the bunch) have shunned XML and, in an effort to reduce the amount of JavaScript coding to be done, have come up with their own data formats (JSON, JavaScript on the rocks or JSOR, amongst other more obscure or proprietary ones). These formats were spawned outside of the standards world in the wild west that is Web 2.0. Sure you can have a system that follows the tenets of SOA and uses JSON as the data format of choice if you are building a Web 2.0 consumer facing photo sharing website but this might not be so helpful when trying to integrate supply chains.

Although SOA has not quite hit the fashion industry status that AJaX has, SOA is the bricks and mortar that our software systems of the near future will be built upon while AJaX is but the decoration nailed to the walls. It just so happens that in Web 2.0 the walls are generally quite thin and AJaX appears to, and does, blend into a bit of an ad hoc, loosely defined, SOA.

So what implications do SOA and AJaX have for each other? Dion mentioned in one of his articles [3] that AJaX would likely push SOA away from WS-* way of doing things but I contend that AJaX will not have as much influence on SOA as he suggests because:
1) the SOA crowd is more established than the Web 2.0 cowboys thus it will take more than a few rogues to completely turn the tables
2) in web browsers today there is no support for discovery and policy binding, which are necessary for SOA particularly in the enterprise
3) people have been developing web applications that consume services for many years - to think that because of the re-introduction of asynchronous requests from the browser developers will suddenly find that they need to access enterprise Web Services directly from the browser seems unfounded (and a security risk to boot)

If nothing else, AJaX is creating a new generation of developers that will at least think about rich clients and how they interact with SOAs - this is good. Also, the visual side of AJaX helps to put a pretty face to the SOA name (guilt by association) - this is also good.

To finish off on a positive note, I think the biggest implication that AJaX has for SOA is that AJaX (and Web 2.0 in general) represents a vast improvement of client applications in terms of usability, which opens up new, uncharted territory for data manipulation and visualization on the client. This new territory will likely increase the amount and variance of data that web application developers will want; thus, developers will increasingly be faced with situations in which the only logical choice will be to access data through a SOA and to buy into the SOA way of doing things. If SOA gets buy in from the vocal and loveable AJaX crowd it could be a real shot in the arm for SOA as well as the implications that SOA has in store for the future. We are already seeing this trend with our AJaX based components on various platforms, which apparently are �ready for prime-time, white collar, Fortune 1000 usage� [3] as can be seen by our customers such as Time Warner, BMW, Bank of America, Goldman Sachs, and Siemens to name a few.

The question is will AJaX stagnate as purely an extension of current web development techniques or will it mature into it�s own �light� SOA for client side development or even better will browser vendors decide to build WS-* into the browsers of the future so that AJaX can play ball with the big boys?

[1] On Atlas/AJaX and SOA - Nick Malik
[2] SOA, AJAX and REST: The Software Industry Devolves into the Fashion Industry - Dare Obasanjo
[3] State of Ajax: Progress, Challenges, and Implications for SOAs - Dion Hinchcliffe
[4] Ajax: User Interface Pattern or SOA Dissemination Engine? - Dion Hinchcliffe
[5] AJAX, SOA, and FWCAR - Mohair Sam
[6] New Specification for SOA using AJAX = JAXASS - Titus
[7] Beating a Dead Horse: What�s a SOA Again? All About Service-Orientation� - Dion Hinchcliffe
[8] Revisiting the definitive SOA definition - SearchWebServices.com
[9] An Introduction to the OASIS Reference Model for Service Oriented Architecture (SOA) - Duane Nickull

Del.icio.us

This entry was posted on Friday, September 2nd, 2005 at 11:16 am and is filed under AJAX, Semantic Web, Service Oriented Architecture, Web2.0. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.