While it is interesting that a wide variety of consulting and product companies have tried to brand themselves as “the” experts on Service Orientation, there are a few examples of good sites that, although sharing corporate sponsorship, managed to describe SOA principles in a way that is fairly neutral. The important thing to remember, even when using these sites, is that the opinions expressed in them are not standard, even if well described.
Therefore, when a recent exchange between myself and Dion Hinchcliffe got rolling, Mr. Hinchcliffe pointed to a nice site at serviceorientation.org and stated that interoperability is not one of the SOA principles, and therefore my argument could be dismissed. The two problems with this argument are, of course, (a) that the principles on the site do not represent consensus, and that (b) interoperability is specifically required by one of the principles on the site (service contract).
The core disagreement is on this point: does an enterprise that is implementing a SOA environment need to be concerned about the use of Ajax tools? Mr. Hinchcliffe asserts that Ajax tools will use services, and therefore will drive the implementation of an SOA environment. My assertion is that Ajax tools will use fine-grained application interfaces, not re-usable services, and therefore will not have any effect, positive or negative, on the implementation of a SOA environment.
The reason for this is simple: Ajax is too light-weight to play in the SOA world. Ajax controls cannot meet or enforce a contract. Ajax controls cannot use discovery protocols. They must be tightly coupled with their services due to many considerations, including browser-enforced data security, in addition to the lack of discovery capabilities. Ajax cannot compose a composable service request. All Ajax requests will be simple, by nature.
The requirements for an Ajax interface are speed of execution, small size of response, and very specific interaction behavior. Loose coupling is not a requirement for Ajax services. I would state that loose coupling is nearly an impossibility for Ajax interfaces.
The requirements for a web service are reliability, compliance to contract, loose coupling (in the sense of coding to contract and service discoverability) and services provided at the level of composability. This last one is the most important point. A composable service is one that can be understood by the business to be composed of atomic units of functionality. The problem with the notion of an Ajax site consuming an enterprise web service is that the atomic units are TOO BIG to be useful at the front end. Therefore, in order to create a composable service, the smallest unit of composition is not appropriate for the use of the Ajax site.
In conclusion: it is completely safe to assume that Ajax sites will not consume enterprise web services.
One thought on “Why Ajax can be safely ignored for a SOA adoption program”
Are you implying [from the last major paragraph] that there will have to be a layer of abstraction between the AJAX UI layer and the Webservice.
The layer of abstraction is something similar to a proxy or facade? and the proxy/facade will handle the complexities of the interaction with the web service.
UI <-> Proxy <-> Webservice.
If so, I still think that AJAX style interaction can’t be ignored by web service creaters/consumers. Someone still needs to make the proxy.
Do you have any examples of an Enterpise Web service that wouldn’t be able to be consumed via an AJAX style interface.
I have done some proxy stuff for my AJAX application calling Yahoo’s API’s. see http://www.kinlan.co.uk/AjaxExperiments/AjaxTag and also http://www.kinlan.co.uk/2005/08/proxy-script-to-yahoo-api-term.html