I can see a few problems with this approach, firstly mixing page flow and orchestration is a little dangerous in my experience it tends to lead to very bulky frontends that become very hard to maintain and also very inflexible as the orchestration and process elements become directly represented by the pages.
The second is that from a security perspective most AJAX approaches bar the invocation of multiple servers which means they could only orchestrate things from a single domain name. Personally I stick by the old Unix philosophy of "do one thing well", front-ends should aim to be the best interface for the user, no more and no less. Steve On 21/05/07, JP Morgenthal <[EMAIL PROTECTED]> wrote:
Michael, Regarding your Business UI point, that's an excellent way to express what I was trying to say. And, yes, that is exactly what I have found. JP __________________________________ JP Morgenthal President & CEO Avorcor, Inc. 46440 Benedict Drive Suite 103 Sterling, VA 20164 (703) 444-1130 x 4: Office (703) 554-5301 : Cell [EMAIL PROTECTED] __________________________________ *SOA success is just a click away...* On May 18, 2007, at 4:12 PM, Michael Poulin wrote: I have question and a statement. Q: What does mean "the browser, by means of Ajax, becomes the orchestrator of services"? Ajax does not orchestrate anything but update the dispalyed elements (including data), neither in client nor in service streming pattern... S: I have obviously found that the Business Interface and User Experience model have different logic than the Business Service and we cannot simly say that it is just a Business Service with (or w/o) a UI. So, this leads to the recognition of the Business Interface service- a sort of lightweight Business Services oriented to the business human user (user experience requirements). Did anybody find anything similar to this? - Michael *Ashish Deshpande <[EMAIL PROTECTED]> wrote: But, you wouldn't do these transactional (or orchestration) tasks from the RIA (the browser), would you? Are you suggesting that the browser becomes not just the interface for some app that orchestrates the services (which is itself a service), but that the browser, by means of Ajax, becomes the orchestrator of services? If that's the case, it would worry me. If not, then I don't understand the comment – I would expect the transactional update to itself be a service and the RIA is simply an interface to this service, which then does boil down to a CRUD operation on a document (the input message for this orchestrator service). Thx, -Ashish --- In [email protected]<service-orientated-architecture%40yahoogroups.com>, JP Morgenthal <[EMAIL PROTECTED]> wrote: > > From my experience, manipulating a CRUD layer from a RIA is simple. > The more difficult aspect, especially in a mashup, is perform ing > transactional tasks across this CRUD layer. For example, if you need > to update two systems simultaneously, then, today, the model falls > apart unless you own the entire infrastructure and can generate the > transaction inside the CRUD layer. > __________________________________ > JP Morgenthal > President & CEO > Avorcor, Inc. > 46440 Benedict Drive > Suite 103 > Sterling, VA 20164 > (703) 444-1130 x 4: Office > (703) 554-5301 : Cell > [EMAIL PROTECTED] > __________________________________ > SOA success is just a click away... > > On May 14, 2007, at 7:09 AM, Ashish Deshpande wrote: > > > --- In service-orientated-<service-orientated-architecture%40yahoogroups.com> [EMAIL PROTECTED], Michael > > Poulin <m3poulin@> > > wrote: > > > > > > In the Presentation layer, user experience is not bound any more > > to the fragmented web > > pages and page flows running exceptionally in synchronous mode; in > > the Business layer, > > there is no need for special components but only services; in > > between layers, there is no > > need any more or traditional Web application' facades, adapters, > > etc.) but just data > > transformation and service subscription utilities. Data > > transformation is bi-directional: > > from/to the Business Interfaces/User interface format to/from > > business services' > > interfaces format. That is, Web apps shrink into data > > transformation facilities. > > > > Exactly – most real web applications boil down to CRUD operations > > on documents. And > > web services tend to expose these operations on documents or > > combinations thereof (a > > business process or service). What's missing is an easy way to > > interact with these > > documents using Rich Internet Applications (RIAs). That's where > > Ajax comes in – it puts a > > "face" on SOA and makes it possible to create complex, visual, > > browser-based applications > > by mashing up web services on your network. Just imagine > > replicating the mashup > > phenomenon within your company – even just within the IT department. > > [snip] ------------------------------ Looking for a deal? Find great prices on flights and hotels<http://us.rd.yahoo.com/evt=47094/*http://farechase.yahoo.com/;_ylc=X3oDMTFicDJoNDllBF9TAzk3NDA3NTg5BHBvcwMxMwRzZWMDZ3JvdXBzBHNsawNlbWFpbC1uY20->with Yahoo! FareChase.
