W3C home > Mailing lists > Public > www-ws-arch@w3.org > October 2002

RE: Definition of Choreography

From: David Orchard <dorchard@bea.com>
Date: Mon, 21 Oct 2002 11:15:04 -0700
To: "'Paul Prescod'" <paul@prescod.net>, "'Assaf Arkin'" <arkin@intalio.com>, <www-ws-arch@w3.org>
Message-ID: <01d101c27936$e31d0540$5f1e11ac@beasys.com>

Paul,

I think you are missing the point of the "global models" out there.  Given
messages between nodes A, B and C, sometimes A wants to know about messages
to C, and sometimes it doesn't.  We can quibble about the details of
messages from B to C that A knows about (which protocol?  Whether exact
partner or role, ie "supplier" versus NAPA auto parts store #3), but let's
not.  The point is to provide choice for a variety of applications.  And it
does work exactly "like that".  Customers and users of processes often (but
again, not always) want visibility into the nested choreographies.

Cheers,
Dave

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Paul Prescod
> Sent: Sunday, October 20, 2002 2:16 PM
> To: Assaf Arkin; www-ws-arch@w3.org
> Subject: Re: Definition of Choreography
>
>
>
> Assaf Arkin wrote:
> >...
> >
> > The <condition> element is is used in the while/until
> constructs to indicate
> > that an operation (or set of operations) will be repeated
> multiple times
> > based on some logic (a repetitive ordering). It is use in the switch
> > construct to indicate that one of multiple mutually
> exclusive paths will be
> > taken based on some logic (a conditional ordering).
>
> Do you acknowledge that this is the domain of implementation and not
> interface? If you expose your conditions in your public
> interface then
> you are presumably locked into those conditions forever. The client
> shouldn't CARE about your conditions.
>
> For example, here's what WSCI says:
>
> "In this example (taken from Section 5.4.1.2), the Travel
> Agent service
> describes how some operations must be performed in sequential order;
> first, the Travel Agent indicates an intention to cancel the
> reservation
> by sending a cancellation request to the airline. It, then, waits for
> receipt of a cancellation confirmation from the airline. Last, it
> notifies the traveler that the reservation has been cancelled."
>
> The interesting thing is that the two people interacting with this
> service DON'T care about all of that. The travel agent service must
> negotiate how to send cancellations and cancellation receipts
> with the
> airline. Sure.
>
> And the customer needs to negotiate how confirmation and cancellation
> notifications will be interchanged with the travel agent. Sure.
>
> But the airline doesn't and shouldn't care about the travel agent's
> communication protocol with the customer and the customer
> shouldn't care
> about the travel agent's communication protocol with the airline. To
> each participant, those are implementation details that
> should be hidden
> inside of the travel agent service.
>
> I can find several similar examples in the WSCI specification.
>
> Web services are supposed to be about loose binding. Exposing
> implementation information tightens the binding by allowing each
> participant to make some "assumptions" about your internal business
> logic which in the long run you may wish to change. For example:
>
> <foreach select="//proposedItinerary/leg[position()>1]">
> <action name = "ReserveSeat"
> role = "tns:travelAgent"
> operation = "tns:TAtoAirline/ReserveSeat" />
> </foreach>
>
> Now the client "knows" that the seats will be reserved in the
> order of
> the legs. If subsequent analysis proved that it is more efficient to
> start from the back, or start with legs serviced by
> particular partners
> etc. I think that is a mistake and it goes against decades of
> software
> engineering evolution.
>
> > It does not indicate what that logic is. The logic may
> require multiple
> > internal activities to be performed by the service. WSCI
> only captures that
> > some logic applies (the 'what') to a particular ordering of
> operations, but
> > not what that logic is (the 'how').
>
> When you specify the exact order that an action will be completed in,
> that sounds to me like "how". When you say exactly what kinds of
> "sub-services" a service will use to complete a task, that
> sounds to me
> like "how".
>
> When you submit a request to a government bureaucracy, do
> they usually
> tell you: "This form is going to to my desk. Then I'm going
> to forward
> it to Bob. Bob will do a database query and print out the
> results. For
> each of the items in that query, Carol will do another query
> through our
> paper catalogs. Then David will collate the results and
> return them to you."
>
> It doesn't work like that. The only time the customer would
> hear about
> the internal process sequences is if they are expected to
> interact with
> the other services directly.
>
>   Paul Prescod
>
>
Received on Monday, 21 October 2002 15:24:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:09 GMT