- From: Assaf Arkin <arkin@intalio.com>
- Date: Tue, 22 Oct 2002 10:03:48 -0700
- To: "Paul Prescod" <paul@prescod.net>, <www-ws-arch@w3.org>
Paul, I'm very flattered that you name a principle after me. This should go down in history ;-) However, I would like to suggest an alternative priniciple, call it the 'value chain' principle, along the following lines: Given a choreography between SERVICES 1 through N (where N >= 2) Given a contract expressed in a choreography language called CONTRACT Given CONTRACT expresses a constraint/condition/sequence called CONSTRAINT Given any two services I and J, such that I in N, J in N and I is not J CONSTRAINT is part of the public interface between SERVICE I and SERVICE J if it is possible to observe whether the constraint has been upheld or violated in the packets on the wire between I or J and any other service in the CHOREOGRAPHY This should be reworded accurately so it is recusive. That is, if J talks to K and K talks to M, and I can prove that J upheld of violated the constraint by talking to M, we can show that interaction encompassing I, J, K and M. There may be other messages exchanged between I, J, K and M that do not prove any constraint for I and are not shown. For the specific example given in WSCI, the traveller can determine if the travel agent has upheld or violated the constraint by interacting directly with the airline. The travel agent agrees to expose its interaction with the airline, because the traveller can prove whether the constraint has been upheld or violate by interacting with the airline through a message exchange that is defined as part of that choreography. The travel agent exchanges other messages with the airline, however, these do not reflect directly on the interaction between the traveller and the airline, hence are not shown in the choreography. Even more specifically to this principle and example, the traveller knows at what point it can strive to prove if the constraint has been upheld or violated, because it knows the logical sequence of events that occur between all three parties. There is no point in asking the airline for a copy of the airline ticket before the travel agent has ordered it from the airline. But it is possible to prove that the travel agent is a fraud by asking the airline to furnish a copy of the ticket after the travel agent has supposedly ordered it, as marked by the event of the travel agent returning a copy of the ticket to the traveller. One important addition to the 'value chain' principle is: - A value chain is defined collaboratively by multiple participants in the choreography, and the choreography occurs as the result of the collaborative execution of services performed by all the participants. This makes it very clear that the question her is not 'what would the travel agent expose?'. On its own, the travel agent is not a value chain. It would only expose an interface covering it and its customer. This is allowed and perfectly acceptable. What we see in this example is a representative of travellers, representative of travel agents, and representative of airlines (a value chain), all sitting together and coming up with a choreography that defined how their services will all work together. A value chain (and choreography) can consist of two participants, but it can also consist of more than two participants. The value chain does not define how each service is executed, only how it is performed within the larger choreography. I make a conscious distinction between the term execute (the 'implementation') and the term perform (the 'interface'). My company is indeed in the space of business processes, so we get to speak to business users on a daily basis and capture their requirements. Two requirements we have are: * Capture the way in which any one participant implements its process such that it can be executed repeatedly to completion. This is where we need a computational complete execution language. * Capture the way in which any two or more participants collaborate together through the exchange of messages over, such that each participant can understand its constraints to participate in the collaboration, and all participants understand the result of the collaboration. This is where we need a constraint language that allows multiple implementations to exist (an interface) and allows multiple interfaces to be shown in a single composition (choreography). Stephen White did an excellent job of capturing the differences in a previous e-mail. Don't hate me because businesses want to view choreographies that involve interaction between multiple partners that all talk to each other. Help me support their case. arkin Assaf Arkin wrote: >... > > [AA] Rule #1 of the interface: what the customer does not care should not be > in the interface. WSCI does not force you to include that information in the > interface. Let's call this rule Assaf's Principle. It is similar to Occam's principle in that it lets us strip away that which is inessential. Now let's turn it into something measurable and concrete: Given a SERVICE and a CUSTOMER. Given a contract expressed in a choreography language called CONTRACT. Given CONTRACT expresses a constraint/condition/thing called CONSTRAINT. CONSTRAINT is part of the public interface between CUSTOMER and SERVICE if and only if it is possible to observe whether constraint has been upheld or violated in the packets on the wire between CUSTOMER and SERVICE. I claim that that's the long form of Assaf's principle. So the fact that the travel agent confirms seats on the airline one leg at a time is demonstrably not part of the customer interface because the customer _cannot observe_ whether they do this or not in any data on the wire. Now this is just the start, but it is an easy, clear starting point. The harder question is to determine what _should be_ in the interface and what needs to be declared at design time versus discovered at runtime. But it would be positive forward progress if we could agree that if there is _no way_ for a client to know whether a constraint has been followed or not, then that constraint is NOT relevant to that client and should therefore not be exposed to them (Rule #1). >... > Think value chain processes. Choreographies involving multiple participants, > where the relation between the activities performed by all the participants > are explicitly modeled. Check out your favorite book about supply chain > management for some examples. A supply chain is an _implementation_ of a process. > No, internal operations are not shown. When a particular participant talks > to their SAP or Oracle, that is not exposed in the choreography. But the > model of the value chain often depicts how participant A sends a message to > B, and B sends a message to C before coming back with a reply to A. Some > business user think that information is important. I prefer to fulfill the > requirement of my customers. >... Your company is a business process management company. Of course your customers come to you for implementations of business proceses. The same goes for BEA et. al. That doesn't mean that there is no difference between interface and implementation. It means that it is your job to help your customers distinguish between them. Paul Prescod
Received on Tuesday, 22 October 2002 13:03:01 UTC