RE: Composition example

Gary,
 
As I said before, there seem to be distinctly different kinds of
"composition". Taking the basic (usually/always? bipolar) abstract
choreography as the starting point:
 
    a) we can compose by aligning roles, where the composition defines
that the entity performing role A in choreography one is also performing
role X in choreography two.
 
    b) we can expand the abstract choreography by filling in more
details within one (or possible more) of its roles
 
In my earlier message, I made a distinction between three different
temporal variants of a), but I think those distinctions are really
secondary.
 
But I don't really think b) is composition at all, on its own. You may
need to combine some of b) with a), to define how the composition links
the separate choreographies - which inevitably means defining some of
the "internal" behaviour of the entity that plays multiple roles. This
can be done with variables, or could involve a sort of internal
choreography defintion with another set of messages - both would really
just be different way of expressing the same linking semantics.
 
But your customer, seemed to be me to be just an elaboration of the
abstract choreography. In fact, I had (mis?) understood that a
choreography was always supposedly confined to the "behavioural
contract" - this may often involve more data-oriented and variable
detail than just the message sequence (though I suspect if one spends
enough effort messing with the type system you can make it pure
messages), but is still just the externally observable.  In which case,
there would be no interface/implementation division, because all of a
choreography is public. But since a choreography covers dynamic
behaviour, even a bipolar one is more than "interface" in the IDL or
WSDL sense.
 
Is a concrete choreography a concept known to CDL ? (This is a general
question, and apologies to the group if it shows I haven't been paying
enough attention to the list)
 
Peter
 
 
 

"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."
 
GB: The intention was only to show the abstract choreography just to
illustrate the "touch points". This abstract choreography is not
intended to become part of the notation. The main point is that the
common interactions between the Customer and Supplier choreographies are
compatible, and therefore would enable their respective choreographies
to be composed. I believe this it would be relevatively straightforward
to automate this compatibility checking for complex examples.
 
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.
 
GB: In the context that you used the variable, I don't see this as being
"glue" - it is simply using information from a message to elaborate the
conditional expression that decides whether it should place an order or
not. The problem I see with using variables as "glue", is where they are
effectively globally defined and made available to multiple
choreographies, where there is no semantics/contract as to the role or
usage of that variable between those choreographies - which means that
it is not a suitable mechanism for loosely coupled choreographies (i.e.
for reusable choreographies) - it would only be useful in tightly
coupled choreographies where the implementation details of each
choreography were known.
 
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.
 
GB: If we want third-party choreographies to be reused (composed) then
we do need a "public interface/private implementation distinction" -
decision points should not be visible, only the externally observable
behaviour that may result from those decision points. This is why the
only relevant aspect of this type of composition is effectively the
abstract choreography (i.e. the behavioural contract) - as long as it
does not change, the implementation details of the concrete choreography
being composed are irrelevant.
 
 
GB: With this type of composition approach, it would be possible to
check for compatibility between composed choreographies, and also to
ensure that a choreography "implements" an abstract choreography - as
you have stated in your "abstract-executable" version. I believe this
makes it a "global model" equivalent approach to standard Pi process
composition.
 
Regards
Gary