RE: Change of participants

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:

1) Different addresses for the same entity in the same role.

2) Transparent, dynamic redirection of messages for a role.

3) Redirection that requires some explicit acceptance or 
acknowledgement (probably because there are accountability
implications).
> 
> 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 00:26:50 UTC