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.
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…
>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
[…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
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.
>local clients makes for some really
>challenging test scenarios — whenever a
>new version of your supported web browsers