Dion Hinchcliffe wrote a blog entry entitled State of Ajax: Progress, Challenges, and Implications for SOAs which did a good job of pointing out the [somewhat obvious yet not so obvious] link between web services and AJAX. For those who don't have time to wade through his entire post, the key bit is
Lightweight SOAP and REST services are in and WS-* services may be on the rocks. Since Ajax applications can and will frequently call backend XML web services as the user interacts with the front-end, having lightweight, easy-to-consume, high performance/availability SOAP and REST web services will only become more important. Of course, the implication is that since Ajax applications live in a fairly austere JavaScript sandbox, this means heavy-duty WS-*-style SOAP stacks probably won't play well with the lightweight XML/JSON service interactions that Ajax prefers. This doesn't mean WS-* is broken for Ajax, but at this time there are no Ajax frameworks yet that support more than basic SOAP service interaction.
There's some stuff I agree with here but a lot I don't. Personally I think even lightweight SOAP services are out in the AJAX world. As it stands, lots of AJAX developers are trying to eschew the overhead of XML for the simplicity of JSON let alone the overhead and complexity of SOAP. The fact is that most AJAX applications talk to lightweight REST services with either XML or JSON being the wire format.
This is yet another example of the dichotomy between providing services for the Web and building services for using within an enterprise's intranet.
Surprisingly, it seems some people fail to acknowledge this dichotomy. One of these people is Nick Malik who in his recent post On Atlas/Ajax and SOA stated
I ran across a blog entry that attempts to link Atlas/Ajax to SOA. What absolute nonsense!
...
So what's wrong with having a browser consume enterprise web services? The point of providing SOA services is to be able to combine them and use them in a manner that is consistent and abstracted from the source application(s). SOA operates at the integration level... between apps. To assume that services should be tied together at the browser assumes that well formed architecturally significant web services are so fine-grained that they would be useful for driving a user interface. That is nonsense.
For an Atlas/Ajax user interface to use the data made available by a good SOA, the U/I will need to have a series of fine-grained services that access cached or stored data that may be generated from, or will be fed to, an SOA. This is perfectly appropriate and expected. However, you cannot pretend that this layer doesn't exist... it is the application itself!
In a nutshell, the distinction is in the kinds of services provided. An SOA provides coarse-grained services that are self-describing and fully encapsulated. In this environment, the WS-* standards are absolutely essential. On the other hand, the kinds of data services that a web application would need in an Atlas/Ajax environment would be optimized to provide displayable information for specific user interactions. These uses are totally different.
This is probably one of the most bogus posts I've ever seen written by a Microsoft employee. As Nick points out, the point of providing services is to be able to combine them and use them in a manner that is consistent and abstracted from the source application.
For example, my Seattle Movie Finder web page is powered by a RESTful web service which gives it information about movies currently playing in the Seattle area. The URL http://www.25hoursaday.com/MovieFinder/MovieFinder.aspx?showall=1, gives me an XML list of all the movies currently playing in my neighborhood. The web page is an AJAX application that consumes this service. This information could also be consumed by a smart client on a desktop or another service which augments the data (e.g. merges in the movie critic ratings to the various movies before sending to an end user). Claiming that because this service doesn't use the various WS-* technologies and is being accessed from a web browser somehow makes it illegitimate is just plain ridiculous.
Furthermore, it is quite likely that the various services that are used to gather this information aren't RESTful. However what works within the intranet isn't necessarily what works on the Web.
An interesting challenge I've faced at work is convincing some of the developers on my team that just because we use SOAP for the services we use internally, this doesn't mean we may not use alternate appproaches for Web facing services. This issue first came up when we decided to go with the MetaWeblog API as the blog editing API for MSN Spaces and I'm sure it will keep coming up.
When you have a hammer, everything looks like a nail. SOAP/WS-* are not the answer to every problem and just because they can't be used in a particular problem space doesn't mean that problem space any less valid than others. The sooner people understand the dichotomy that is intranet vs. internet service development, the better.