W3C home > Mailing lists > Public > public-ws-chor@w3.org > September 2004

Re: Composition example

From: Gary Brown <gary@enigmatec.net>
Date: Mon, 20 Sep 2004 10:27:04 +0100
Message-ID: <009701c49ef4$01d8a2c0$4b00a8c0@LATTITUDEGary>
To: "Furniss, Peter" <Peter.Furniss@choreology.com>, <public-ws-chor@w3.org>
MessageHi 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.

Received on Monday, 20 September 2004 09:27:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:27 UTC