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.