W3C home > Mailing lists > Public > public-ws-chor@w3.org > March 2005

RE: toRole and fromRole names and type references and similar.

From: Martin Chapman <martin.chapman@oracle.com>
Date: Mon, 21 Mar 2005 16:54:08 -0000
To: "'Tony Fletcher'" <tony_fletcher@btopenworld.com>, "'Gary Brown'" <gary@enigmatec.net>, <public-ws-chor@w3.org>
Message-ID: <002001c52e36$9d4c6b70$0901a8c0@ie.oracle.com>
Tony,
 
Roles manifest themselves in the current spec as channels. Rather than
talk about a single role instance of a role type we talk about access
points to the role. Hence the role doesn't have to be explicit, and is
really only a deployment time concept.
 
For example suppose we have the RoleType BuyerType. Rather than talk
about a Buyer such as Tesco, Sainsbury etc, we talk about channels to
buyer: tescochan1, sainsburychan2 for example. This is because each role
may need multiple access points for different participants, so the role
becomes superfluous at this level of specification.
 
Martin.
 
 
 

-----Original Message-----
From: public-ws-chor-request@w3.org
[mailto:public-ws-chor-request@w3.org] On Behalf Of Tony Fletcher
Sent: 21 March 2005 15:38
To: 'Gary Brown'; 'Tony Fletcher'; public-ws-chor@w3.org
Subject: RE: toRole and fromRole names and type references and similar.


To Gary and others,
Comments below
 

Best Regards     Tony
A M Fletcher
 
Cohesions  (TM)
 
Business transaction management software for application coordination
www.choreology.com <http://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: Gary Brown [mailto:gary@enigmatec.net] 
Sent: 21 March 2005 13:01
To: Tony Fletcher; public-ws-chor@w3.org
Subject: Re: toRole and fromRole names and type references and similar.


Hi Tony,
 
I still need a concrete example, as I don't see what is missing from the
current CDL spec. What you are suggesting seems to be adding more
content to a choreography definition without adding more value - I'm
sorry but at the moment I don't understand the problem you are trying to
solve.
 
If you are objecting to the fact that we have role types, but no
instances, then possibly the problem is that we have "role types". Maybe
we should just have "roles" - i.e. a participant plays a set of roles,
and a relationship provides an association between two roles. Likewise,
a relationship instead of a relationshipType.
 
Yes that is exactly it.  RoleTypes (and the other *Types) are useful in
that they give you one place to put the defintion material, but
roleTypes do not interact, in my understanding, roles do.  So to use the
same sort of example that I used with Steve the other day:
participantType = DistributorType1
This particular type of participant has three roleTypes called
TalkToSupplier, TalkToBuyer and ReportToCustoms.  The ReportToCustoms
roleTYpe is a standardised one common to many different paricipantType
definitions. The roleTypes define the allowed behaviours.
 
A participant of this participantType might be ACMEdistribution and it
would 'comply' with its participantType definition by having roles
ACMETalkToSupplier, ACMETalkToBuyer and ACMEReportToCustoms (for
imnstance - I am not suggesting one has to stick to this way of naming
things!).  It is these roles that would be shown as interactiong with
other roles in a chregraphy desvcription.  That same chreography
description might have a second participant of the same participantType
called ABCdistribution and it would have roles ABCTalkToSupplier,
ABCTalkToBuyer and ABCReportToCustoms
 
[Perhaps I should not complicate things further at this stage which is
why I am putting this bit in square brackets - it means I will quite
understand if people say we should ignore.  In addtion I think we should
allow a participantType definition to say that some of its roleTypes are
optioanl for a participant that complies with this participantType to
support.  So in the above example the participantType DistributorType1
could include an optional roleType TalktoOtherDistributor which may not
be used in some chreographies but in othres would allow ABCdistribution
to request parts from ACMEdistribution so that it could make up an order
- for instance.]
 
Hope it is clear now what I am driving at.
 
Regards
Gary

----- Original Message ----- 
From: Tony Fletcher <mailto:tony_fletcher@btopenworld.com>  
To: 'Gary Brown' <mailto:gary@enigmatec.net>  ; public-ws-chor@w3.org 
Sent: Monday, March 21, 2005 12:46 PM
Subject: RE: toRole and fromRole names and type references and similar.

Dear Gary,
 
Thank you for your response.  The intent was not role instances but
rather instances of roleTypes - which is a role!
 
That is the point I am making.  At present we set up the
participantType, roleType and ChannelType definitions, but then each
time we use a role we have to give it a name and say what type it is.
If you look towards the bottom of my mail you will see I have suggested
adding a roleAssignments element where one could say what roles the
choreography used give them names and say what type they were and then
we could just use the role name and omit the type reference elsewhere.

<roleAssignments name="ncname" ">

   <roleAssignment role name="ncname" roleType="qname" />+

</roleAssignments>

 
Maybe even better would be to have an element where one assigned a name
to a participant and said what type it was and gave names to each role
in that participant - we define participantTypes at present but never
seem to use participants (of a given type).
 
So we would then have:


<participantType name="ncname">

   <roleType typeRef="qname" />+

</participantType>

and something like


<participant name="ncname" typeRef="qname">

   <role name="ncname" typeRef="qname" />+

</participantType>

where the typeRef of the participant needs to match an 'ncname' of a
participantType and the typeRef (s) of the role(s) need to match the
corresponding 'ncname'(s) of a roleType contained in that
participantType.
 
Best Regards     Tony
A M Fletcher
Home: 35, Wimborne Avenue, IPSWICH  IP3  8QW
Tel: +44 (0) 1473 729537   Mobile: +44 (0) 7801 948219
 amfletcher@iee.org       (also tony_fletcher@btopenworld.com)
 

-----Original Message-----
From: Gary Brown [mailto:gary@enigmatec.net] 
Sent: 21 March 2005 08:57
To: Tony Fletcher; public-ws-chor@w3.org
Subject: Re: toRole and fromRole names and type references and similar.


Hi Tony,
 
I am not sure why we need the name and type reference, can you give a
concrete example? As we don't have the concept of role instances, I
would assume that a single attribute (whether called name or type ref)
would be sufficient.
 
Regards
Gary

----- Original Message ----- 
From: Tony Fletcher <mailto:tony_fletcher@btopenworld.com>  
To: public-ws-chor@w3.org 
Sent: Saturday, March 19, 2005 11:04 PM
Subject: toRole and fromRole names and type references and similar.

Dear Colleagues,
 
In trying to sort out roletypes from roles for issues 1018 and 1018
I wonder if we should not change the interaction syntax defined in
2.5.2.3 from


                                                     Interaction Syntax


The syntax of the <emph>interaction</emph> construct is:



<interaction  name="ncname"

              channelVariable="qname"

              operation="ncname"

              align="true"|"false"?

              initiate="true"|"false"? >

 

   <participate  relationshipType="qname"

                 fromRole="qname" toRole="qname" />

 

   <exchange  name="ncname"

              informationType="qname"?|channelType="qname"?

              action="request"|"respond" >

     <send      variable="XPath-expression"? 

                recordReference="list of ncname"?   

                causeException="true"|"false"? />

     <receive   variable="XPath-expression"? 

                recordReference="list of ncname"? 

                causeException="true"|"false"? />

   </exchange>*

 

   <timeout  time-to-complete="XPath-expression"

             fromRoleRecordReference="list of ncname"?

             toRoleRecordReference="list of ncname"? />?

 

   <record  name="ncname"

            when="before"|"after"|"timeout"

            causeException="true"|"false"? >

     <source  variable="XPath-expression"? |
expression="Xpath-expression"? />

     <target  variable="XPath-expression" />

   </record>*

</interaction>

to


                                                     Interaction Syntax


The syntax of the <emph>interaction</emph> construct is:



<interaction  name="ncname"

              channelVariable="qname"

              operation="ncname"

              align="true"|"false"?

              initiate="true"|"false"? >

 

   <participate  relationshipType="qname"

                 fromRole="ncnameqname" fromRoleType="qname"

                 toRole="ncnameqname" toRoleType="qname"

   />

 

   <exchange  name="ncname"

              informationType="qname"?|channelType="qname"?

              action="request"|"respond" >

     <send      variable="XPath-expression"? 

                recordReference="list of ncname"?   

                causeException="true"|"false"? />

     <receive   variable="XPath-expression"? 

                recordReference="list of ncname"? 

                causeException="true"|"false"? />

   </exchange>*

 

   <timeout  time-to-complete="XPath-expression"

             fromRoleRecordReference="list of ncname"?

             toRoleRecordReference="list of ncname"? />?

 

   <record  name="ncname"

            when="before"|"after"|"timeout"

            causeException="true"|"false"? >

     <source  variable="XPath-expression"? |
expression="Xpath-expression"? />

     <target  variable="XPath-expression" />

   </record>*

</interaction>

 
That is that we should give the roles names as well as showing what type
the correspond to.
 
Similarly for perform.  Should we not change


<perform  choreographyName="qname" 

          choreographyInstanceId="XPath-expression"? >

   <bind  name="ncname">

     <this variable="XPath-expression" role="qname"/>

     <free variable="XPath-expression" role="qname"/>

   </bind>*

   Choreography-Notation?

</perform>

to


<perform  choreographyName="qname" 

          choreographyInstanceId="XPath-expression"? >

   <bind  name="ncname">

     <this variable="XPath-expression" role="ncname"
roleTypeRef="qname"/>

     <free variable="XPath-expression" role="ncname"
roleTypeRef="qname"/>

   </bind>*

   Choreography-Notation?

</perform>

 
I propose to change the syntax of assign from
 

<assign  roleType="qname">

   <copy  name="ncname" causeException="true"|"false"? >

      <source
variable="XPath-expression"?|expression="Xpath-expression"? />

      <target  variable="XPath-expression" />

   </copy>+

</assign>

to
 

<assign  role="ncname" roleType="qname">

   <copy  name="ncname" causeException="true"|"false"? >

      <source
variable="XPath-expression"?|expression="Xpath-expression"? />

      <target  variable="XPath-expression" />

   </copy>+

</assign>

 
I propose to change the syntax for noAction from 

 

<noAction roleType="qname? />

 

to 

 

<noAction role="ncname"? roleType="qname"? />

 

 
 
although having one place in a choreography where we say what roles are
involved and what the type of each role is would probably be better then
doing it in several places like this and having to check consistency.
Perhaps something like


<roleAssignments name="ncname" ">

   <roleAssignment role name="ncname" roleType="qname" />+

</roleAssignments>

 
then noAction would become

<noAction role="ncname"? />

 
and similar elsewhere.
 
 
 
 


Best Regards     Tony
A M Fletcher
 
Cohesions  (TM)
 
Business transaction management software for application coordination
www.choreology.com <http://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)

 
Received on Monday, 21 March 2005 17:00:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:07 UTC