RE: Multi-Party Binding Scenario

Ricky

I agree with almost everything you say, but would like to make one comment
and disagree on another point:

SHIPPER REFERENCE
>>>Your following example describe the a specific scenario where ...
1) The SELLER can unilaterally determine the binding to the "SHIPPER" role
2) The SELLER communicate his binding decision to the BUYER within the 
exchanged messages.  Basically it pass an URL for the buyer to query 
shipment status.

There are other variation that your example hasn't described
3) The SHIPPER may send a "arrival notice" message to the BUYER.  How does 
the BUYER know this is the correctly binded SHIPPER ?<<<

The SHIPPER would need to include some reference in the message, e.g. the
Order No that the BUYER used.

ROLE BINDING USING XPATH
>>>Agree !  I think the choreography need to have a "role binding" concept
and 
an XPATH expression to extract that from the message.  Something similar to 
the correlation set in BPEL4WS.<<<

If you include a specific XPATH expression in a choreography, then the
choreography definition is no longer abstract and therefore cannot be reused
which means it does not scale. I think the binding implied by the XPATH
expression should be recorded in a Choreography Binding document that binds
an abstract Choreography Definition to the specific, services, messages,
documents, used by a specific implementation.

David
-----Original Message-----
From: Ricky Ho [mailto:riho@cisco.com]
Sent: Tuesday, March 25, 2003 11:17 AM
To: Burdett, David; public-ws-chor@w3.org
Subject: RE: Multi-Party Binding Scenario


David, thanks for your feedback.  My feedback embedded.


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

Agree !  I think the same way as you.


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

Agree !  When PartyA send the first message (with a particular type) to 
PartyB, the role binding is implicit.  Since this discussion is focus in 
role binding, I want to highlight when does the role binding happen.


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

Agree !


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

The lookup is outside the scope of this choreography (of course, you can 
define another choreography between PartyA and the UDDI service 
provider).  Here I want to highlight that at least 2 roles need to be 
binded successfully in order to start the conversation.



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

Lets separate the "communicating binding info" from the "binding" itself.

>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

Your following example describe the a specific scenario where ...
1) The SELLER can unilaterally determine the binding to the "SHIPPER" role
2) The SELLER communicate his binding decision to the BUYER within the 
exchanged messages.  Basically it pass an URL for the buyer to query 
shipment status.

There are other variation that your example hasn't described
3) The SHIPPER may send a "arrival notice" message to the BUYER.  How does 
the BUYER know this is the correctly binded 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>
>
>
>Comments ?
>
><DB>I can't think how you would put the dynamic binding information
anywhere
>but in the content of the message.

Agree !  I think the choreography need to have a "role binding" concept and 
an XPATH expression to extract that from the message.  Something similar to 
the correlation set in BPEL4WS.

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

I think putting it in the header is another possibility, but probably more 
intrusive at this moment.

Rgds, Ricky

Received on Tuesday, 25 March 2003 14:37:57 UTC