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 Sunday, 20 October 2002 17:16:59 UTC