RE: Composition example

I've studied Gary and Steves composition example (using the version
Steve sent out)
 
Very interesting, and somewhat surprising..
 
 
The new approach seems to make CDL more like BPEL in it's coverage. We
have an abstract choreography that defines the customer:supplier
interactions, and only those. So that defines the protocol between those
two.
 
Then we have the two specific choreographies, which are both very much
single-party oriented - what the customer does and what the supplier.
(What surprised me, but perhaps shouldn't have, is that the same
interactions occur in both. )   A single-party oriented, they are really
rather like abstract BPEL definitions - what one entity does involving
the sending and receiving of messages from one (or for the supplier 2)
partners.  In fact, the supplier could be regarded, apart from
initialising the variables in it, as fully defined - an executable
choreography.
 
The specfic : abstract relation raises some interesting points though.
Gary has deliberately made the customer behaviour a subset of what is
allowed - it never uses the suggestAlternative, and therefore doesn't
need to accept "alternative" (interesting question of how this might
align with wsdl defintiions - this thing does not support all the static
interface, although it does support everything that is possible
dynamically). Is it easy to show that the specific choreography is
compatible with the abstract ?  In this case it is simple enough to work
out by inspection - for a more complex case it might not be.
 
Of course there several other customer choreographies that would be
equally compatible:
    one that never put things on order, and always asked for
alternatives (then ordered something else perhaps)
    one that never ordered or asked for alternatives
 
And the supplier choreography is itself an "executable composition" of
the purchase abstract choreography, and the supplier:wholesaler abstract
(and unshown) choreography. 
That's a rather different kind of composition:
 
suppose we now want to compose further, such that the customer now
becomes an order taker, supporting a protocol where the incoming order
is for "N items to be delivered in not more than D days", and the
replies are semantically "delivery scheduled for d days time" ( 0 <= d
<= D) or "unavailable in time". We could change the hard-coded 7 days in
the customer choreography to a varable and set it from the incoming
message.
 
But now I've gone back variables as the "glue". But that was how the
supplier choreography was glueing the two abstract choreographies it was
driving, so presumably that's ok on this approach.
 
Actually, I'm not sure that there is really a lot of difference in
"exposing the inner workings" between the approaches. Does CDL really
have a public interface/private implementation distinction ? If I want
to compose, I need to have access to the decision points of the
composees.
 
Hmm, I think I've got confused about the question.  There would seem to
be various sorts of composition:
 
"horizontal" - an entity that has one role in choreograph A has also (in
general, interleavedly) a role in B (as the supplier here) - composition
defines how interactions and values on one side map to/trigger
interactions and values on the other
 
"abstract - executable" (I don't think this is actually a "composition"
in quite the same way) - as with the supplier and customer here, which
are both compatible with (specialisations of ?) the abstract purchase
choreography.
 
"vertical, sequential" - entities run through one choregraphy between
each other, then, depending on the state that left them in, through
another - composition defines how the states produced by the first are
inputs to the second
 
"vertical, interleaved" - entities simultaneously and interleavedly have
roles in multiple choreographies that involve them both - composition
defines how the interactions and values in one trigger interactions and
values in another. (an analogy is co-authoring a document with your boss
:-) - an example may be the interaction of an application and
transaction or security protocol)
 
 
This has ended up rather rambling, but I'm trying to sort out if this is
just a stylistic difference or a revolution.
 
 
Peter
 
------------------------------------------
Peter Furniss
Chief Scientist, Choreology Ltd
web: http://www.choreology.com <http://www.choreology.com/> 
email: peter.furniss@choreology.com
phone: +44 870 739 0066
mobile: +44 7951 536168

 
 
 

-----Original Message-----
From: Gary Brown [mailto:gary@enigmatec.net] 
Sent: 14 September 2004 17:14
To: public-ws-chor@w3.org
Subject: Composition example


Hi,
 
As an action from the previous conference call, we have submitted a
slightly modified example which hopefully explains the issues with
composition (using current CDL and the proposed behavioural approach).
 
The example contained in the attached document is different to the one
in the original proposal (which was overcomplex with channel passing),
as it simply represents a situation where an existing (hopefully
reusable) choreography needs to be composed with another choreography
that will interact with the reused choreography, in order to provide the
business logic for making a decision that will impact the reused
choreography.
 
Regards
Gary