On 21/05/07, Michael Poulin <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[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 service-orientated-architecture@ yahoogroups.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-architecture@ yahoogroups.com, 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 with
Yahoo! FareChase.
> >
> >
> >
> >
> >
>
>
>
>
>
> ________________________________
Get your own web address.
> Have a HUGE year through Yahoo! Small Business.
>
>
>
>
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/service-orientated-architecture/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
<*> 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/
