RE: Definition of Choreography

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