- From: Gary Brown <gary@enigmatec.net>
- Date: Fri, 18 Mar 2005 08:57:00 -0000
- To: "Tony Fletcher" <tony_fletcher@btopenworld.com>, <public-ws-chor@w3.org>
- Message-ID: <006601c52b98$766ebf80$0200a8c0@LATTITUDEGary>
MessageRegarding the example, it appears what you have done is promote the inner choreography to the top level, as removed another inner choreo and placed its interaction in the main choreo. Looks fine to me. The problem we face is how relevant is the global model? In my example I represented a sequence, but if there is no connection between the two sub choreographies, what is to stop them being performed the other way around, or concurrently, and therefore not conforming to the global model. On the other hand, it is possible that the 'participants', although not connected within the CDL model, so actually have some hidden connection that always enforces the sequence, but it is not observable. Which is the correct view? Regards Gary ----- Original Message ----- From: Tony Fletcher To: 'Gary Brown' ; public-ws-chor@w3.org Sent: Thursday, March 17, 2005 7:40 PM Subject: RE: Relationship issue example Dear Gary, My current short answer is: I think we should leave as is, and yes I think it is fine to have a single choreography description document describe what are actually two, or more, totally disconnected choreographies - I think we should allow that design freedom - even if it does seem a bit strange. The slightly longer answer is: From the point of view of a single endpoint there are degrees to which they are involved in what is happening (message wise) in the choreography from being involved with everything to not being involved at all in some part. Consider a choreography with just two participants each of which have just one role and these two roles 'talk' to each other. In this case both roles are involved in each and every interaction in the choreography. But if you think about it this is really a particular case and not the general case. With three participants and four roles say A<-->B<-->C then Participant B is involved in all the interactions, but A has no involvement with the B<-->C interactions and thus the B<-->C interactions are just the same as D<-->E interactions as far as A is concerned (it has no involvement and no visibility of either set of interactions. In general it is only the choreography designer that can 'see' (or whatever word you would like to use - a bit philosophical this!) the complete choreography, or a monitor that has access to all the interactions (/channels). It seems to me this is as true for the A<-->B<-->C<-->D case as for the A<-->B C<-->D case. Finally a question for you. I have done a quick hack on the choreography example that you sent (so I may not have got all the details of the syntax correct, but hopefully you will understand what I intend). Is it still legal CDL? (If it is I intend to make a further modification and comeback with another somewhat philosophical question - and if it is not legal I would appreciate knowing why. Best Regards Tony A M Fletcher Cohesions (TM) Business transaction management software for application coordination www.choreology.com Choreology Ltd., 68 Lombard Street, London EC3V 9LJ UK Tel: +44 (0) 1473 729537 Mobile: +44 (0) 7801 948219 tony.fletcher@choreology.com (Home: amfletcher@iee.org) -----Original Message----- From: public-ws-chor-request@w3.org [mailto:public-ws-chor-request@w3.org] On Behalf Of Gary Brown Sent: 16 March 2005 10:53 To: public-ws-chor@w3.org Subject: Relationship issue example Hi This is an example where a choreography has been defined with 4 participant types. However the choreography consists of two sub-choreographies that have no connection between them. Therefore, even though the two sub-choreographies are performed in sequence, there are no common participants between each of the sub-choreographies, and therefore no sequential ordering in terms of a global model. One way to solve this problem would be to suggest/enforce that both of the sub-choreographies need a common participantType. However, this may require that the common participant type is the one that 'initiates' the second sub-choreography, as it would be the only one that knows when the first sub-choreography has completed. If there is no linkage between the different sub-choreographies (i.e. common participants), then we would need to ask whether this is a valid choreography - as in reality it is describing two completely independent choreographies within the one CDL document. Example has been attached and pasted below (although not formatted). Regards Gary <?xml version="1.0" encoding="UTF-8"?> <package name="relationship" author="GB" version="1.0" targetNamespace="mynamespace" xmlns="http://www.w3.org/2004/12/ws-chor/cdl"><description type="description">Example to show issue with relationships in different choreographies</description><informationType name="string" type="xs:string"/><token name="string" informationType="string"/><roleType name="roletype1"><behavior name="behavior1"/></roleType><roleType name="roletype2"><behavior name="behavior2"/></roleType><roleType name="roletype3"><behavior name="behavior3"/></roleType><roleType name="roletype4"><behavior name="behavior4"/></roleType><relationshipType name="rel1"><role type="roletype1"/><role type="roletype2"/></relationshipType><relationshipType name="rel2"><role type="roletype3"/><role type="roletype4"/></relationshipType><participantType name="part1"><role type="roletype1"/></participantType><participantType name="part2"><role type="roletype2"/></participantType><participantType name="part3"><role type="roletype3"/></participantType><participantType name="part4"><role type="roletype4"/></participantType><channelType name="channelType1"><role type="roletype2"/><reference><token name="string"/></reference></channelType><channelType name="channelType2"><role type="roletype4"/><reference><token name="string"/></reference></channelType><choreography name="mainchoreo" root="true"><relationship type="rel1"/><relationship type="rel2"/><choreography name="subchoreo1"><relationship type="rel1"/><variableDefinitions><variable name="chan1" channelType="channelType1"/></variableDefinitions><interaction name="first interaction" operation="firstOp" channelVariable="chan1"><participate relationshipType="rel1" fromRole="roletype1" toRole="roletype2"/><exchange name="first request" informationType="string" action="request"><send/><receive/></exchange></interaction></choreography><choreography name="subchoreo2"><relationship type="rel2"/><variableDefinitions><variable name="chan2" channelType="channelType2"/></variableDefinitions><interaction name="second interaction" operation="secondOp" channelVariable="chan2"><participate relationshipType="rel2" fromRole="roletype3" toRole="roletype4"/><exchange name="first request" informationType="string" action="request"><send/><receive/></exchange></interaction></choreography><sequence><perform choreographyName="subchoreo1"><description type="description">Perform subchoreo1</description></perform><perform choreographyName="subchoreo2"><description type="description">Perform subchoreo2</description></perform></sequence></choreography></package>
Received on Friday, 18 March 2005 08:57:24 UTC