RE: Multi-Party Binding Scenario

Ricky

See comments inline below.

David

-----Original Message-----
From: Ricky Ho [mailto:riho@cisco.com]
Sent: Monday, March 24, 2003 6:12 PM
To: public-ws-chor@w3.org
Subject: Multi-Party Binding Scenario



Some thoughts about role binding in multi-party choreography.

In addition to message exchange sequence, does the choreography also 
specify the sequence how roles will be binded and where rebind can happen ?
============================================================================
=================================
YES.  This increase the complexity of multi-party scenario.  Because the 
message exchange sequence now has a coupling with the role (re)binding 
sequence.

When does the choreography get instantiated ?
===================================
In the choreography should define at least one role that can start the 
"conversation" (ie: a "choreography instance").
<DB>Using just a role to identify who can start a conversation is perhaps
too vague. I think the better way is to identify the action (i.e. the
sending of a specific message type) that identifies the start. As messages
always flow between roles, the role is implicit.</DB>

1) PartyA (who wants to play RoleA) propose a conversation by sending a 
message to PartyB (who PartyA want her to play RoleB).  The message 
contains at least two role bindings (PartyA/RoleA, and PartyB/RoleB)
<DB>I think specifying party and role isn't enough as the same two roles can
be involved in multiple different choreographies. If you assume that the
parties involved MUST know about the choreography BEFORE they can take part
then identifying the Choreography and the particular action (or message)
within the choreography should be enough.</DB>

2) After receive this message, PartyB can agree or disagree to bind to 
RoleB of the conversation.  If she disagree, then the conversation 
terminates there.
<DB>Isn't this just "business as usual" as anyone who receives can reject it
for any reason. This could be technical (e.g. message malformed) or business
(e.g. I don't want to get into a choreography with you)</DB>

3) If PartyB agrees to play RoleB, then the conversation starts 
successfully.  In other words, when a choreography starts successfully, 
there will be at least 2 roles being binded.
<DB>Alternatively, Party A could look up information about Party B, in a
directory somewhere and know that they take part in conversations without
any prior agreement. Looking up information in a directory is going to be
needed anyway as Party A needs to know what choreographies Party B supports
if they are to stand any chance of a successful interaction. Am I missing
something about what's special about this type of binding?</DB>


When does the bindings of other roles happen ?
===================================
The choreography defines who (RoleA or RoleB) can propose bindings of these 
other roles.  Basically the message exchange sequence between RoleA and 
RoleB defines when these other bindings can happen.
The binding to other parties has an extra step.  For example, it is 
possible that PartyA propose binding of RoleC by PartyC and even 
communicate this knowledge with PartyB before it has actually contact
PartyC.
At some later point, PartyA or PartyB will actually send a message to 
PartyC which at that time, will confirm the binding of PartyC.  On the 
other hand, PartyA or PartyB can send an ont-of-band message to 
PartyC.  PartyC will then send a message to PartyA or B and confirm the 
binding.
<DB> How would PartyA communicate this binding information. Wouldn't it be
just be data in the message?
I think I would call this dynamic message addressing rather than binding.
"Binding" suggests some type of permanent connection whereas this
description is totally dynamic. For example is this the type of choreography
you are thinking of where:
1. A Buyer sends an order to a Seller
2. The Seller uses a URL in the order to send the Order Response to the
Buyer
3. The Buyer uses a URL in the Order Response to do shipment status query
with the Shipper

Message flows below ...

ORDER MESSAGE FROM BUYER TO SELLER
The message below is sent to "www.jones.com/ecom/salesmanagement/" which the
buyer discovered from an on-line directory:
<Order OrderNo="AB9876">
  <Buyer Name="Smith", 
    eCommerceURL="www.smith.com/ecom/ordermanagement/"... />
  <Seller Name="Jones", 
    eCommerceURL="www.jones.com/ecom/salesmanagement/" ... />
  <LineItem ProductCode="1234" Qty="100" />
  <LineItem ProductCode="5678" Qty="50" />
  ...
</Order>


ORDER RESPONSE FROM SELLER TO BUYER
The message below is sent to "www.smith.com/ecom/ordermanagement/" using
information in the Buyer element of the Order message:
<OrderResponse OrderNo="AB9876">
  <Buyer Name="Smith", 
    eCommerceURL="www.smith.com/ecom/ordermanagement/"... />
  <Seller Name="Jones", 
    eCommerceURL="www.jones.com/ecom/salesmanagement/" ... />
  <Shipper Name="White", 
    eCommerceURL="www.White.com/ecom/shipmanagement/" ... />
  <LineItem ProductCode="1234" Status="Ok" />
  <LineItem ProductCode="5678" Status="OutOfStock" />
  ...
</OrderResponse>

SHIPMENT STATUS REQUEST FROM SELLER TO SHIPPER
The message below is sent to "www.white.com/ecom/ordermanagement/" using
information in the Shipper element of the Order Response message:
<ShipmentStatusRequest OrderNo="AB9876">
  <Buyer Name="Smith", 
    eCommerceURL="www.smith.com/ecom/ordermanagement/"... />
  <Seller Name="Jones", 
    eCommerceURL="www.jones.com/ecom/salesmanagement/" ... />
/ShipmentStatusRequest >

etc ...

</DB>


Does all parties always know bindings of all roles ?
=====================================
Not necessary.  PartyA decide to bind RoleC with PartyC, but she doesn't 
need to notify PartyB.  Even if she does, she may communicate with PartyB 
at a later point in time but not immediate.

Does all roles rebindable ?
====================
Again up to the choreography to define.  I guess the 2 initial roles are 
likely to be not rebindable.


Comments ?

<DB>I can't think how you would put the dynamic binding information anywhere
but in the content of the message. If you put it in the header, then you
would need to associate semantic meaning with it, for example that a
particular URL was the URL of the shipper to be used for shipment status
requests.</DB>

Best regards,
Ricky

Received on Tuesday, 25 March 2003 11:38:27 UTC