- 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>
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 UTC