RE: Participants and roles

Dear Colleagues,

To clarify, having now read Steve's mail, in the mailed proposal I have just
sent I would see the definition of role types as being independent of that
of a participant type.  Thus several participant type definitions could
reference a single role type definition, if that is what the choreography
demands.

To use Steve's example I am intending to allow:

Participant Types:
		BankParticipantType			(TraderRoleType)
		BrokerParticipantType			(TraderRoleType)
		CounterpartyParticipantType 		(TraderRoleType)

But I can have:


Participants:
	BankParticipant of BankParticipantType
(BankTraderRole of TraderRoleType)
	BrokerParticipant	of BrokerParticipantType
(BrokerTraderRole of TraderRoleType)
	CounterpartyParticipant of CounterpartyParticipantType
(CounterpartyTraderRole of TraderRoleType)


Another way of achieving the same thing that my proposal would allow is:
Participant Types:
		TradingParticipantType			(TraderRoleType)
		

But I can have:


Participants:
	BankParticipant of TradingParticipantType
(BankTraderRole of TraderRoleType)
	BrokerParticipant	of TradingParticipantType
(BrokerTraderRole of TraderRoleType)
	CounterpartyParticipant of TradingParticipantType
(CounterpartyTraderRole of TraderRoleType)

Note: this ignores other aspects such as variable type definition which may
be different for each participant and this may force the choreography
specifier down Steve's original route of having three different participant
type definitions.


Best Regards     Tony
A M Fletcher
 Tel: +44 (0)1473 729537   Mobile: +44 (0) 7801 948219
 tony_fletcher@btopenworld.com         (also amfletcher@iee.org)
 


-----Original Message-----
From: public-ws-chor-request@w3.org [mailto:public-ws-chor-request@w3.org]
On Behalf Of Steve Ross-Talbot
Sent: 01 August 2006 16:45
To: WS-Choreography List
Cc: matthew.d.rawlings@jpmchase.com; Kohei Honda; Marco Carbone; Robin
Milner; Nobuko Yoshida
Subject: Participants and roles



In the current WS-CDL schema a role type may only belong to one  
participant type. This means that the natural way of describing  
behavior is not readily supported in WS-CDL today. For example I  
might have a bank as a participant type that wishes to behave in the  
role of a trader. I might also have a broker that wishes to behave in  
the role or trader and a counterparty that wishes to do the same thing.

To do this today I need to add to the role name something unique to  
the participant in order to model the different role types across the  
participant types.
That is I cannot have the following:

	Participant Types:
		BankParticipant			(TraderRole)
		BrokerParticipant			(TraderRole)
		CounterpartyParticipant 	(TraderRole)

But I can have:


	Participant Types:
		BankParticipant			(BankTraderRole)
		BrokerParticipant			(BrokerTraderRole)
		CounterpartyParticipant 	(CounterpartyTraderRole)

While it is possible to model things as WS-CDL stands it does lead to  
a significant explosion in description because RoleTypes cannot be  
shared. The only reason for RoleTypes to be unique today is because  
all variables and conditions are projected through the RoleTypeName  
back to the ParticipantTypeName.

In effect the nature of a ParticipantTypeName is more akin to an  
instance. It is half way between an instance and a binding to an  
instance and this is what has caused the problem to surface.

What we need to be able to do is enable RoleTypeNames to be shared.  
This would require changes to the spec but would significantly add to  
the usability of WS-CDL in practice. The sort of changes that would  
be required would be to add the ParticipantTypeName to the CDL  
functions that take RoleTypeName and to do the same for variable  
declarations and any other conditionals. There may also be a need to  
change how we bind when doing a perform as this also takes  
RoleTypeNames.  I have not done a full sweep of the spec as yet.

This may have an effect on the type system so we would need to pass  
this by our invited experts to ensure that we understand what effect  
it has if any.

Cheers

Steve T

Received on Tuesday, 1 August 2006 19:04:23 UTC