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

Burdett, David wrote:

>     [David Burdett] Not sure. For example if you design four different
>     choreographies that are alternative ways of doing the same thing
>     (e.g. placing an order), wouldn't the role stay the same?
>
I need to see something more concrete here to understand what it means 
to stay the same role. What would make a role the same across two 
choreographies?

arkin

>     At most the relationship between choreographies will be akin to a
>     type library that gets used in multiple progams.
>     [David Burdett] Agreed. 
>      
>     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
>


-- 
"Those who can, do; those who can't, make screenshots"

----------------------------------------------------------------------
Assaf Arkin                                          arkin@intalio.com
Intalio Inc.                                           www.intalio.com
The Business Process Management Company                 (650) 577 4700


This message is intended only for the use of the Addressee and
may contain information that is PRIVILEGED and CONFIDENTIAL.
If you are not the intended recipient, dissemination of this
communication is prohibited. If you have received this communication
in error, please erase all copies of the message and its attachments
and notify us immediately.

Received on Monday, 9 June 2003 17:49:50 UTC