Yes, this is an interesting use case. AJAX produces some very cool interfaces like google maps mash ups and what not.
Although every computer science problem can be solved by adding a layer of abstraction it's not a license to make more layers when you only need a few. I'm gonna go with JP on this one. An intermediary will add some latency and might not be your best bet for a UI problem like AJAX. For some other types of problems, (like contract and policy enforcement) it's incredibly useful. Then again, it depends on how you define and implement "intermediary"... --- In [email protected], "JP Morgenthal" <[EMAIL PROTECTED]> wrote: > Or, it's just a Web application that consumes the service as the model on > behalf of the view and Ajax updates that view from the model. That's the > way I'm designing my stuff anyway. So, in effect, there is no mediation. > As we learned from our ebXML days, the only real mediation is when the > action is passed from one server to the next through redirection. Then, we > will require real intermediates that can maintain the state across many > asynch calls. > > Attend the Leaders in Integration Seminar > October 11 & 12, 2005 > Ritz-Carlton, Tyson's Corner, Virginia > http://www.avorcor.com/events > > -----Original Message----- > From: [email protected] > [mailto:[EMAIL PROTECTED] On Behalf Of Gervas > Douglas > Sent: Monday, August 29, 2005 5:45 PM > To: [email protected] > Subject: [service-orientated-architecture] Wainewright on Mediation, Synapse > et al. > > <<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 ------------------------ Yahoo! Groups Sponsor --------------------~--> Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life. http://us.click.yahoo.com/A77XvD/vlQLAA/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/
