While surfing the web, I happened to find a blog entry by Dion Hinchcliffe, containing some interesting observations on the conflict between Ajax and SOA, related to my recent discussion with Dag König. The most interesting part is the enumeration at the end of the post, under the heading "SOA Implications".
Ha, Dion’s blog is the first one I’ve seen that looks like a OneNote notebook! That’s cool. Well, reasonably cool, at least.
Conceptual Integrity 
I’m skeptical about AJAX driving web services from SOAP to REST (sounds hygienic, though, if we could only get a TOOTHBRUSH in somewhere before going to bed!). I’d expect the WS for an AJAX application to be tightly bound to that particular solution, with minimal reusability in new solutions. AFAIK, AJAX has no component model for the client side, which combined with extreme statefulness should result in extremely close coupling.
REST in AJAX therefore becomes an internal implementation detail of the overall web application. The security model is limited by the authentication information the browser can provide (but please, no more basic authentication: I can’t take it!). The web application back end may need to do a lot of translation and adaptation to take advantage of reusable enterprise level web services. All in all, not a ringing endorsement for AJAX as a SOA force from where I’m sitting…
But the blog entry is good in pointing out the dependency issue: relying on JavaScript, DHTML and DOM in local clients makes for some really challenging test scenarios — whenever a new version of your supported web browsers are released. Ah, for those golden 90’s!
>I’m skeptical about AJAX driving web
>services from SOAP to REST
Actually, that wasn’t my idea, rather that the SOA would lose Microsoft’s focus.
>(sounds hygienic, though, if we could only
>get a TOOTHBRUSH in somewhere before going
>to bed!).
[…desperately brainstorming in order to make that an acronym for something…]
That’s of course “The Object Oriented Transactional Hypertext Batch Reading Unified Scripting Host”.
>I’d expect the WS for an AJAX application
>to be tightly bound to that particular
>solution, with minimal reusability in new
>solutions.
That should be the case for the backend architecture, I agree. But for the external API, I think we’ll see something different.
>AFAIK, AJAX has no component
>model for the client side, which combined
>with extreme statefulness should result in
>extremely close coupling.
Agreed.
>relying on JavaScript, DHTML and DOM in
>local clients makes for some really
>challenging test scenarios — whenever a
>new version of your supported web browsers
>are released.
I’m sure JavaScript will be replaced as the client technology, sooner or later. Probably all this will end with “Smart Clients” anyway (see of course http://blog.drakengren.com/conceptual_integrity/2005/10/ajax_and_smart_.html ).