RE: Change of participants

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

WHEN DOES ROLE BINDING OCCUR ?

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"


HOW DOES ROLE BINDING DECISION BEING COMMUNICATED ?

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.


WHAT DOES THIS BUY US ?

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
> > >
> > >
> > >
> >

Received on Wednesday, 23 April 2003 21:34:03 UTC