Ajax and Soap, again

I'm flattered by all the attention my statements are getting on comparing Ajax with SOA web services.  Another one popped up over night: Dare Obasanjo  with the statement: "This is probably one of the most bogus posts I've ever seen written by a Microsoft employee."

So first off, a disclaimer: I'm an employee of Microsoft, but I do not speak for the company in any official capacity.  That said... my turn...

With all due respect to Mr. Obasanjo, a service that delivers data to a front end (whether it is for use by an Ajax page or a small rich-client app) is not a SOA web service.  I hate to have to point out the obvious, but alas, I must.  That is my point.  The fact that Mr. Obasanjo missed that point is led to the statement above.  I am not saying that Ajax cannot use SOAP.  I am not saying that Ajax should use WS_*.  I am not saying that lightweight services as used by front-ends are "bad" or "not really important."  I am simply saying that they have nothing to do with SOA.

His example is that, on his site, there is a web service that he uses to display movies in the Seattle area.  It returns XML that his Ajax page formats and displays.  Cudos. 

Now let's look at Service Oriented Architecture.  SOA is not really an Application-level concept.  It is an EAI-level concept.  SOA is not used to make front-ends talk to their back ends.  Web services can be used for this, but as I have pointed out before, simply using web services does not mean you are using Service Oriented Architecture.. 

Let's look at Service Oriented Architecture for a moment. Actually read the paper I reference.  You'll notice some statements that completely contradict the view that Ajax plays in the SOA space.  Excerpts below:

• Precise, published specification functionality of service interface, not implementation.
• Formal contract between endpoints places obligations on provider and consumer.
• Functionality presented at a granularity recognized by the user as a meaningful service.

From their description, it is clear that a service that is so finely-tuned as to be useful for a front end is unlikely to be useful as a SOA service.  My statement is that, in fact, it would not be useful.  This is because, in a SOA environment, the transactions that pass between systems need to be encapsulated, fully self-describing, secure, reliable, and related to the business process in which they are involved.  This is simply too much overhead for consumption by a front-end.

Therefore, Ajax interfaces, while useful from the front end standpoint, do not need to be managed from the standpoint of discoverability, transaction management, workflow, business rules, routing, or any of the other aspects of enterprise architecture that must be applied in a SOA environment.  The original post that I objected to maintained that Ajax services would need to be managed in this way and, in fact, would tax IT departments because these services will be frequently used.  That was the disagreement that Mr. Obasanjo failed to recognize.

My position remains unchanged: Ajax interfaces escape from this level of scrutiny because they are not used to connect systems to each other... they are used to connect the front-end to the back-end. 

And that isn't SOA.