RE: Definition of Choreography

David,

WSDL defines an abstract message as a container of multiple message parts.
That message can be used in multiple operations. The operation definition
gives it the proper semantics and also indicates the direction of the
message flow, and whether it completes synchronously or asynchronously.

I would assume that a choreography language would be designed by referencing
which operations are performed by a given role, and the order in which these
operations are performed by that role (the sequencing rules). It would
reference the definition of an operation within the port type (and service
type) definition given in WSDL. That would indicate the direction of the
messages sent/received when performing that operation.

As for pre-condition, in my opinion there are two type of conditions. Those
that relate to the internal state of the service (e.g. error occurred,
product does not exist), that are interesting to model, but not relevant to
the choreography. And those that relate to the ordering of operations
relative to each other (e.g. purchase order error may follow purchase order
submission), that are the core of the choreography.

I am, of course, referring to a narrow definition of choreography that is
essentially: the design or arrangement of messages exchanged between
mutliple services. In my opinion all other aspects of a Web service
definition, e.g. the semantics of the message, the validity of a message in
a particular situation, security and transports, etc as interesting and
important as they are, should be covered by other specifications.

arkin


-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Sunday, October 20, 2002 6:41 PM
To: Assaf Arkin; David Orchard; 'bhaugen'; www-ws-arch@w3.org
Subject: RE: Definition of Choreography


I want to address a couple of points that Assaf describes:
*	Sequence of operations vs sequence of messages
*	Handling of exceptions and compensations

SEQUENCE OF OPERATIONS VS SEQUENCE OF MESSAGES
I agree that by specifying a sequence of operations, then it implies that a
certain sequence of messages.

However, whenever you are involved in a public process, then there are two
(or more) separate sequences operations that need to match, for example the
sequence of operations at a buyer and the corresponding (almost mirror
image) sequence of operations at the seller.

The other alternative is to specify a single sequence of messages and
identify the different roles that can be involved (e.g. the Buyer and
Seller). Then, each role involved, can identify their own role, and
therefore the sequence of operations that they should follow.

If you are accept that there are benefits in standardizing these sequences
(see earlier emails), then I would suggest that standardizing on a single
sequence of messages that includes all the roles (and implicitly the
services) is simpler and more likely to be consistent.

HANDLING OF EXCEPTIONS AND COMPENSATIONS
I also think that a rigid sequence does not work, for example, you should
send an error message only if there is an error and not otherwise. I
therefore think that pre-conditions and post-conditions are a good idea, but
that the conditions should describe the pre-conditions that must exist
before a message can be sent as well as describe the post-conditions that
arise after a message has been sent.

David


-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com]
Sent: Saturday, October 19, 2002 10:17 PM
To: David Orchard; 'bhaugen'; www-ws-arch@w3.org
Subject: RE: Definition of Choreography



David,

I share your view that a choreography language that is based on explicit
ordering is easier to work with than one that is based on conditions.

I agree with another argument made that no choreography language is required
to allow two services to successfully interact with each other. However, a
choreography language goes a long way to explain how services could be
implemented such that they do successfully interact with each other.

I will not try to prove here, but in my experience any model that expresses
sequencing (as with WSCI/BPEL) can be transformed into one that is based on
conditions. However, in order to validate that a definition given in the
form of condition provides the proper sequencing, one must have a sequencing
definition at hand.

For that reason I would argue that a condition-based language is somewhat
incomplete and possibly redundant.


When formalizing the model for WSCI, one premise was that two type of
conditions exist to describe the behavior of a Web service.

One type of condition is dependent on the internal state of the service, for
example, it is meaningless for you to request account information from a
bank if you did not open an account with that particular bank.

That condition should be captured in a model that describes the semantics of
the information contained in the message. Perhaps using a semantic
definition expressed in RDF.

Another type of condition is dependent on the order of operations relative
to each other, for example, you will only receive confirmation of an order
after an order was submitted, but not if you received notification that the
order cannot be fulfilled.

That condition depicts the logical sequence of operations, and is therefore
at the core of the choreography. There are other things you would want to
say about an operation and its relevance, but that falls outside the scope
of choreography (regardless of how simple or complex the language is).


I have read here arguments about the level of details that a choreography
language should support. Whether it should just explain that message X
follows message Y, or whether it should cover exceptions and compensation.

A model that deals with exceptions and compensation is proposed in WSCI and
to a large extent in BPEL. It is based on the notion of associating
operations with some order (or flow), and allows such flows to define
sequential, parallel, conditional and repetitive order of operations. It
also allows the model to differentiate between normal, exceptional and
compensating flow.

That is why, despite some differences, you will see a lot of similarity
between WSCI and BPEL. You will also see similarty between WSCI and BPML,
although the first uses the order of operation to describe what a service
does, while the second describe how a service does it. The similarity is
there simply because all three languages attempt to support as many ordering
rules as possible.


What we are seeing in the market is that simple services are the reality
today, but with the expectation that services will grow in complexity as
more of them are being developed. I believe the growth in complexity will
parellel the work towards a single standard, and that we should keep an eye
on the future as we set the scope for the working group.


Pre- and post-conditions should not be confused with the <condition> element
and its use in the WSCI specification. The two are not directly related.

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).

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'). For that reason, while WSCI allows you
to indicate that a logic exists, it does not mandate that you indicate the
specifics of the logic - such condition are opaque.

The pre- and post- conditions that are relevant to the ordering of
operations relative to each other are expressed in the form of sequencing
rules. They associate operations to each other using constructs such as
sequences, branches, loops, contexts, exceptions, etc.

regards,
arkin



Bob,

This is a classic religious argument.  In the same way there are religious
battles over big-endian vs little-endian, strongly-typed vs weakly-typed,
interpreted vs compiled, etc., there will be battles of "condition based" vs
"explicit ordering".  While it is certainly true that condition based can
meet all the ordering requirements, there is an issue around usability.  For
example, I think coding up JSPs (explicit ordering) is about twice as easy
as XSLT (mostly condition based).  And I also have a metric that every time
you double the complexity, you lose 90% of the developers.  This is the
major reason why I'm not a big fan of condition based pipelines for xml or
web service processing models.  It's only pretty advanced developers that
use ANT and Makefiles, as yet another example.  I tend to think this is a
major reason why lisp and prolog didn't conquer the world compared to C,
C++, Java, VB.  Just debugging prolog is about 10 times as hard!  Don't get
me wrong, I think that the condition based is a great tool, but it has to be
acknowledged that there are certain types of users that we want to target
and understand their capabilities.

I have a requirement that it be as easy as reasonably possible to create
choreographies.  Which means I almost automatically prefer explicit ordering
instead of conditions.

Cheers,
Dave

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of bhaugen
> Sent: Saturday, October 19, 2002 8:54 AM
> To: www-ws-arch@w3.org
> Subject: RE: Definition of Choreography
>
>
>
> What ordering requirements cannot be met by preconditions?
>
> Alternatively, what tangled knots will you weave as
> hard-coded sequences
> get into exception paths?
>
> I remember the evolution of Critical Path and PERT networks from I-J
> explicit links to predecessor links.  Predecessors were much
> simpler and
> more flexible.  And they could express any network that could be
> expressed with direct I-J links.  And they didn't require the dummy
> nodes that I-J networks needed.
>
> While it's not exactly the same problem, I think it's the same
> conclusion with preconditions vs hard-coded sequences.
>
> Or to put it another way, Web business processes are
> conversations, not
> work flows.
>
> -Bob Haugen
>
>

Received on Tuesday, 22 October 2002 12:30:07 UTC