<<The deeply ingrained point-to-point mindset of mainstream computer systems design is hampering recognition of some of the most basic concepts required for successful deployment of service-oriented architecture. It always seems more appealing to think in terms of dedicated, high-performance direct connections, but pause for a moment to consider the limitations on scalability and flexibility this kind of architecture brings with it.
Here's a topical example. A few days ago, Dion Hinchcliffe wrote a great summary of the State of Ajax: Progress, Challenges, and Implications for SOAs. Ajax is the use of Javascript and XML to fetch data from a back-end source and present it in a web page without having to do a page refresh. It's important because, as Dion writes: "Practitioners of Ajax get high-intensity user interaction (end-user productivity), asynchronicity (efficient background processing), web browser access to web services (web service access, reuse, and interoperability, as well as SOA integration), platform neutrality (browser and operating system agnosticity), and the Ajax feature set can be delivered as a framework you don't have to create yourself (developer productivity)." But Dion forgets about mediation, writing that "heavy-duty WS-*-style SOAP stacks probably won't play well with the lightweight XML/JSON service interactions that Ajax prefers." This is a misguided assumption for two separate reasons: As Nick Malik pointed out in a somewhat ill-tempered post, a lot of Ajax implementations are going to be RPC-style requests that are effectively part of an application rather than something that operates at the services layer. In cases where Ajax acts as a client service consuming an enterprise web service, the way to preserve WS-* integrity will be to do so through the means of a mediation layer that transforms between the two services implementations. Citing Ajax may be an extreme example, but it demonstrates the value of mediation in connecting diverse services. You can never assume in an enterprise services infastructure that every participant will be using a full WS-* stack (and even if they are that they will all be using the same one!). The surge of interest in Ajax is yet another illustration of the unpredictable variables that enterprise SOA has to cope with. You can either attempt to lock down your enterprise architecture with iron-fisted governance that in all probability is going to negate every benefit you ever hoped to gain from rolling out SOA in the first place. Or you can mediate. As Blue Titan's Frank Martinez explained to me last week, this means adopting a new programming model in place of client-server or client-service that is client-intermediary-service. Actually, that should probably be clients-intermediaries-services all in the plural, because it's only by having a distributed web (or mesh, or fabric) of intermediaries that you get the kind of redundancy and scalability that's required to operate an enterprise infrastructure of multiple autonomous service consumers and providers.>> You can find this at: http://www.looselycoupled.com/blog/lc00aa00112.html Gervas ------------------------ Yahoo! Groups Sponsor --------------------~--> Fair play? Video games influencing politics. Click and talk back! http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/NhFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
