Re: Change of participants

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.
>  
>
Technically speaking in order to use a service I need its address. I may 
be interesting in knowning what the business entity is because I elect 
to use different business entities at different times (e.g. my 
suppliers). I may be interested in knowing the business entity but use a 
variety of services offerred by the same entity (e.g. a service 
provider). Or I may build a solution that uses a variety of services 
that are all offered by the same business entitity (e.g. system 
integration). In all cases, I need to technically be aware of the 
address in order to use these services. So I see addresses as a basic 
requirement that does not change regardless of which scenario I end up 
using.

If I did not receive payment from a customer I know which legal entity 
is reponsible. I can go to court and sue them. But I can't expect a 
payment unless I sent them an invoice, and I can't send them an invoice 
unless I know their billing address. So before I decide to process an 
order from some legal entity I would like to make sure I know their 
shipping address AND their billing addresses.

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

+1

>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.
>
Let's assume that legally speaking all the parties that use the 
choreography agree to the possibility of delegation. What it means is 
that they all agree to write such a choreography and use that 
choreography. If they don't, they would either not propose it, or prefer 
to use other choreographies. I don't want to speak for all business use 
cases. If some use cases need delegation let them write appropriate 
choreographies, and if other use cases don't need delegation let them 
not use this feature.

If they did elect to use a choreography that allows delegation, and the 
choreography indicates where, when and how delegation occurs, then they 
also need some framework to make it work. The legal agreement to do that 
is all good, but if you have no way of exchanging messages, you can't 
technically do that. So assume that the legal agreement has resulted in 
the use of a choreography that includes delegating, the choreography 
must be able to leverage some mechanisms for handling the delegate address.

>  
>
>>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).
>
+1

In my opinion #1 should be the subject of some addressing mechanism. 
It's generic enough to stand in its own right and something we could 
leverage by using WS specifications in the proper way. #3 is also 
interesting but like many other things you can do that are not dependent 
on the specifics of the choreography (resending and acking messages, 
coordinating transactions, creating security contexts, etc).

In #3 you delimit the states in which the delegation could happen and 
also describe its effect. In some cases it may be a normal part of the 
flow (e.g. see shipper for exact delivery date), in other cases it may 
conditionally lead to another state (whether accepted or rejected), and 
in other cases it's not even an option - the choreography has no step 
where you can delegate. In my opinion this should be written down as 
part of the choreography.

arkin

Received on Wednesday, 23 April 2003 22:14:45 UTC