- From: Assaf Arkin <arkin@intalio.com>
- Date: Mon, 21 Oct 2002 17:23:06 -0700
- To: "Paul Prescod" <paul@prescod.net>
- Cc: <www-ws-arch@w3.org>
Assaf Arkin wrote: > Assaf Arkin wrote: > >... > > When you send me a purchase order and I have a condition that decides > whether to accept or reject it (a switch in WSCI), what I am saying in the > interface is: either one will happen. I call that 'order approved' > condition. It doesn't have a concrete meaning. You don't know what logic I > use to arrive at the condition, that is part of my implementation and can > change from time to time. But you know that I will send you either one > message, not both. That's an important aspect of the interface. WSDL/XML Schema already allows this using a "choice" element. The only thing WSCI adds is that it gives a name to the choice condition. But that name never seems to be used anywhere except perhaps as a hook into implementation ... which doesn't have to be in the public interface. [AA] It is important to understand that the name of an activity does not indicate its semantics. True, XSDL has an element called <choice>, so does WSCI, so does BPML, and a few other specifications out there. But the semantics are not the same. The semantic of <choice> in XSDL has no bearing on the semantics of <choice> in WSCI. You can use the XSDL choice to define a content model, and use WSDL to define a message with content using that content model. But you cannot use that element to indicate a branch between two different sets of operations. You can use thw WSCI <choice> for that, but you cannot use it to define content models. The WSCI choice is always used between *different* operations. If you have an operation that can return a message with either content model X or content model Y, you have a single operation. In this case you may express a branch in WSCI using a <switch>. If you have an operation that is followed by either operation X or operation Y, you have two use a WSCI choice since these are two distinct operations. A condition is not applicable to the XSDL <choice> or the WSCI <choice> - it is used in a <switch>. The condition has nothing to do with the fact that the message may or may not have a choice in its content model. It speaks about the fact that one of mutually exclusive braches are to be folowed. The condition name is useful from the perspective of the modeling tool which is used to design the choreography to distinguish between condition X, condition Y and condition Z, when you have a switch that leads to three different branches. It is nothing but a name, but a useful one at that. Plus, WSDL has a notion of "fault". [AA] And WSCI defines elements that react to faults generated by a WSDL operation, so it can express how a choreography relates to faults that can be produced by Web services. > ... > [AA] If you start with a condition-based language but allowed operations to > be used from multiple port types, you could end up defining an executable > business. An implementation. By definition any language that can > string together two operations could be abused in that way. Of course, because the stringing together of two operations is _implementation_. The customer doesn't care that you do "CheckCreditCardNumber" before "CheckClientCode" so that shouldn't be in the customer's interface. Similary, the credit card company doesn't care what protocol you are using to talk to the customer, so that shouldn't be in the interface you use to talk to them. [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. There's long been an argument between those who believe that choreography interfaces should be purely bi-lateral, and those that belive they should not. Regardless of which view point you entertain, one thing is clear. There are real users out there that want to see that information. 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. 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. arkin
Received on Monday, 21 October 2002 20:22:10 UTC