RE: Relationship cardinalities (was ... RE: Requirements: Decisio n Po ints Requirement Proposals

RE: Relationship cardinalities (was ... RE: Requirements: Decision Po ints
Requirement ProposalsDavid,

In my view it is a party (participant, instance etc) that takes part in a
choreography. They do so by taking on one (or more ) of
the defined roles.  There is no formal relationship between roles in
different choreographies, otherwise they would be part of (the same)
choreography definition.
At most the relationship between choreographies will be akin to a type
library that gets used in multiple progams.

Martin.


  -----Original Message-----
  From: public-ws-chor-request@w3.org
[mailto:public-ws-chor-request@w3.org]On Behalf Of Burdett, David
  Sent: Monday, June 09, 2003 1:35 PM
  To: 'Assaf Arkin'; Burdett, David
  Cc: 'Jean-Jacques Dubray'; 'Yaron Y. Goland'; 'WS Chor Public'
  Subject: RE: Relationship cardinalities (was ... RE: Requirements: Decisio
n Po ints Requirement Proposals


  Assaf

  I always tend to think that one role can take part in multiple
choreographies, for example a buyer could take part in:
  1. Several different choreographies each of which resulted in the
placement of an order
  2. A separate order status choreography that could work with any of the
different choreographies.

  I also recognize that the same choreography and roles could be invented
multiple times. For example, the shoe industry could invent a choreography
for placing orders that was identical to one developed by the wine industry
but they give the choroegraphies different identifiers (URIs) for
choreography itself and each of its roles.

  This is really a broader standardization issue that will only be solved
when there is choreography instance standardization. For example the UBL
initiative is developing standard representations and semantics for order
documents using XML schema. We really need standard order placement
choreographies to be developed using WS-Chor ... but we need WS-Chor first.

  David



  -----Original Message-----
  From: Assaf Arkin [mailto:arkin@intalio.com]
  Sent: Monday, June 09, 2003 12:18 PM
  To: Burdett, David
  Cc: 'Jean-Jacques Dubray'; 'Yaron Y. Goland'; 'WS Chor Public'
  Subject: Re: Relationship cardinalities (was ... RE: Requirements:
  Decision Po ints Requirement Proposals



  For brevity sake, two comments and +1 on everything else.

  Burdett, David wrote:

  >CHOREOGRAPHY RELATED
  >1. A role may take part in one or more choreographies
  >For example a buyer there are several different ways of placing orders
that
  >involve different sequences of messages. However the basic role stays the
  >same.
  >
  >
  That depends on how you define a role. You can define a role as being a
  component of the choreography in which case a role participants in one
  choreography. That does not restrict an entity from being multiple roles
  in multiple choreographies. You can define roles that participate in any
  number of choreographies, but I'm not sure what it buys you, and if
  you're having problems reaching agreements you probably would have a
  problem agreeing to use the same role in multiple choreographies.
  (Again, won't restrict the same entity ...)

  I accept that as a party intending to buy products I would assume the
  role 'buyer' in one choreography, 'procurer' in another, and 'sucker' in
  a third one. On the other hand, I may be expected to operate in the same
  way in all three choreographies, i.e. implement the same interface, but
  that brings us back to the role=interface equality, mobile process model
  and all other undesirable solutions.

  >4. A choreography specifies the sequence, conditions and dependencies of
  >sending one or more messages
  >This is really the core of what choreographies are all about. The only
  >question I would have is whether this is compatible with the ideas of
  >pi-calculus, and if it isn't does it matter?
  >
  >
  Yes it does. And if it doesn't then pi-calculus wouldn't be relevent to
  our work.



  arkin