Re: Multi-Party Binding Scenario

I would agree on this point.

"Burdett, David" wrote:

> 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 22:37:23 UTC