W3C home > Mailing lists > Public > public-ws-chor@w3.org > April 2003

Re: Change of participants

From: Assaf Arkin <arkin@intalio.com>
Date: Wed, 23 Apr 2003 19:04:36 -0700
Message-ID: <3EA74634.3020200@intalio.com>
To: Ricky Ho <riho@cisco.com>
CC: "Cummins, Fred A" <fred.cummins@eds.com>, public-ws-chor@w3.org



Ricky Ho wrote:

> I completely agree that "role", "entity", "address" should be distinct 
> concepts.
> 1) Different addresses for the same entity in the same role.
> ===========================================
> This is about binding between "entity" and "address".  I agree with 
> Assaf we can assume an out-of-band communication exist and leave this 
> out of scope of choreography.
> 2) Transparent, dynamic redirection of messages for a role.
> ===========================================
> This is about binding between "role" and "entity".  But because it is 
> so "transparent", this change of role is invisible to other 
> participants (of other roles).  So I like to consider this delegation 
> as purely a "private implementation" of that particular participant.  
> Because this is private implementation, maybe it should also be out of 
> scope of choreography (at least for the current moment).
> 3) Redirection that requires some explicit acceptance or 
> acknowledgement (probably because there are accountability implications).
> ===============================================================================================
> This is also about binding between "role" and "entity", but this is 
> non-transparent to other participants.  I think we should leave up to 
> the choreography itself (which is industry specific) to determine how 
> to agree upon role rebinding (I don't want to force that every 
> participant changes has to get every other participants agree) as well 
> as communicate them.
> So far, our choreography model only talk about "roles" and message 
> exchange between them, it assumes the "entity to role" binding happen 
> magically.  I like to see our choreography model be extended to 
> capture "entity to role" binding.  In other words, the choreography 
> model (that we're defining) should treat the "role/entity binding 
> data" specially from other "application specific data".  Maybe we 
> should even type the message to be "role-rebinding" message.  Here are 
> some examples of when does role-binding occurs and how to communicate 
> role binding information
> a) Implicit
> ========
> When I send an purchase order message to Amazon, then entity "Ricky" 
> is IMPLICITLY binded to the role "buyer" and entity "Amazon" is 
> IMPLICITLY binded to the role "seller".  In this case, the purchase 
> order is a "role-binding message".
> b) Protocol Exchange
> ================
> When Amazon send a "shipment request message" to Fedex, the role 
> "shipper" is not binded yet.  Only after Fedex send back a "shipment 
> confirmation message" will the binding be considered completed.  In 
> this case, both the "shipment request messaging" and "shipment 
> confirmation message" are "provisional role-binding message"
> a) Explicit passing role-binding decision
> =============================
> Amazon send me an "order confirmation message" which also tells me 
> that the shipper will be Fedex.
> b) Implicit by message correlation
> =========================
> This time Amazon doesn't tell me anything.  I receive a "shipment 
> notification message" from Fedex, from there it refers to my Purchase 
> order number.  So I know Amazon has chosen Fedex to ship.
> So what is the value of extending our choreography model to capture 
> this rather than leave it up to the person who design the flow ?  A 
> big one that I can see is to validate the correctness of the 
> choreography flow further.  Along the line that we want to use 
> bi-simulation to validate that a private implementation is compliant 
> to the role defined in the choreography, we want to make sure that 
> there is NO ambiguity of what role that an entity is playing when he 
> receive a message.
> Best regards,
> Ricky
> At 11:26 PM 4/22/2003 -0500, Cummins, Fred A wrote:
>> Assaf wrote:
>> >
>> > I think that a service needs the concept of an address. The
>> > address can
>> > contain multiple points of contacts.
>> [fac] An "address" implies location, I prefer to use "entity" as
>> implying a point of accountability/responsibility, as in "legal
>> entity."
>> A "service" is something an entity is willing to provide or perform.
>> An entity might perform a variety of services.  It might provide
>> alternative services through the same interface, although we might
>> then just consider it a composite service (a service consisting of
>> services).  Maybe a service reduces to a role an entity is willing
>> to perform.  In which case, maybe all we need to talk about is
>> roles.
>> > For example, the service could say:
>> > use this URI between 5 to 9 and the other URI the rest of the
>> > time. Or
>> > use this URI if you can sign/encrypt messages and another URI
>> > if you opt
>> > to use SSL. So it should be able to represent an address that is more
>> > than just one URI, maybe by providing a WSDL service definition or
>> > something akin to WS-Addressing.
>> [fac]
>> >
>> > Perhaps a change of address could be addressed out-of-band
>> > using a more
>> > generic protocol that is not specific to the choreography, so all
>> > choreographies could leverage that capability without having to
>> > complicate all of them. Whether a buyer can allow the seller
>> > to change
>> > its point of contact midway through a choreography would
>> > depend on the
>> > use of this protocol, keeping the choreography simple.
>> [fac] This sounds good to me.
>> >
>> > But there's still needs to be some ability for a participant to be
>> > replaced at the discretion of all remaining participants, as per the
>> > choreography definition (i.e. the fact must be communicated to all
>> > affected parties). And also for the participant to be able to
>> > delegate
>> > responsibilities to other participants. For example, as a
>> > seller I may
>> > not be able to fulfill the order but I may delegate that to
>> > some other
>> > seller (by special agreement with that seller). Since that
>> > should occur
>> > at specific states and should not cover the buyer, it should be
>> > expressed in the choreography.
>> [fac] I think the issue becomes how transparent can the redirection
>> be.  This depends on the nature of the transaction.  If the buyer
>> is given the opportunity to accept or reject the delegation by the
>> seller, then this will show up in the choreography.  If, on the
>> other hand, delegation is just accepted, then it just becomes a
>> footnote in a message, and is not relevant to the choreography.
>> As a practical matter, if I submit an order to A, I don't expect
>> to receive an invoice from B unless there is some notice of
>> transfer of responsibility.  But if I receive an invoice from A
>> sent from a different address, or directing payment be sent to
>> a different address, that's probably okay, as long as I can
>> authenticate the sender as A.  This issue is the legality of
>> the delegation, not the addresses involved.
>> >
>> > So these are three different use cases, and I think only the last two
>> > are something we should be addressing at some point.
>> [fac]I think there are still three issues/cases to consider:
>> >
>> > arkin
>> >
>> > Cummins, Fred A wrote:
>> >
>> > >Assaf, Ricky,
>> > >
>> > >There is another dimension to changing participants assigned to
>> > >roles.  The question is when can the entity behind the URI
>> > change. For
>> > >example, it is possible that a participant wants to receive initial
>> > >requests at one URI and redirect subsequent actions to different
>> > >URIs, potentially depending on the nature of the request or
>> > >the availability of resources.  The entity could be the same
>> > >but the requests are directed to different processes or business
>> > >units within the entity, or simply to different servers.
>> > >
>> > >>From a business standpoint, the participant sending the messages
>> > >wants to know who he is dealing with.  Is it acceptable to have his
>> > >messages redirected to a different entity?  I think this gets us into
>> > >questions about the content and security of the messages, and beyond
>> > >the scope of the choreography.
>> > >
>> > >A participant should be able to delegate to an "agent" to continue
>> > >the exchange.  The delegation will require more than a simple "change
>> > >of address."  The agent must be able to speak for the principal,
>> > >and have appropriate credentials.
>> > >
>> > >So, I think dynamic changes to a participant (i.e., URI) assigned to
>> > >a role should be considered something quite acceptable at the
>> > >discretion of the participant.  It should make no difference in the
>> > >choreography because the role remains the same. The message structure
>> > >and content must provide for communication of such changes
>> > along with the
>> > >appropriate credentials to be associated with the new URI.
>> > >
>> > >Fred Cummins
>> > >
>> > >
>> > >
>> >

"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 Wednesday, 23 April 2003 22:06:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:01 UTC