Yes, Web component situates on the server. What I see in our Web sites, the "access mechanisms for business logic" has its own business logic, not only user experience logic. This is what I am trying to identify as Business Interface Services...
- Michael Steve Jones <[EMAIL PROTECTED]> wrote: On 21/05/07, Michael Poulin wrote: > > > > > > > Steve, here are a few considerations: > > 1) "mixing page flow and orchestration" - with Ajax expect significant page > flow reduction; for a function in a page (the function might be reusable > itself) I assume a Web component that orchestrates Interface Services. So, > the Web components decouples orchestration from the page information flow. I > have found that in my financial pages many functions repeat in different > business contexts, e.g. the same functions in almost all fund products. That > is, I can engage the same Transformation Service in the Presentation tier. > Not clear on what this means, but if you are saying that the HTML file (AJAX) just does the page creation and the server side does the orchestration then I agree. > 2) as of single domain, once again, my "subscription" Web component can play > a role of a point of indirection. That is, unmmanageable (due to the browser) > Ajax risk of cross-domain security gets delegated to the manageable Web > component. > So Web Component here is meaning server side? In this case I agree. > 3) without "Interface Business Services", I see a gap between the best user > interface and the best Business Service(s). Would you agree? > I called them "Virtual Services" in my book, they provide no direct business logic themselves but provide the access mechanisms for business logic that resides elsewhere. > - Michael > > > Steve Jones wrote: > > > 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 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 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 service-orientated-architecture@ yahoogroups.com, JP Morgenthal > > 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-architecture@ yahoogroups.com, Michael > > > > Poulin > > > > 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 with Yahoo! FareChase. > > > > > > > > > > > > > > > > ________________________________ Get your own web address. > Have a HUGE year through Yahoo! Small Business. > > > > Yahoo! Groups Links --------------------------------- 8:00? 8:25? 8:40? Find a flick in no time with theYahoo! Search movie showtime shortcut.
