RE: Progressive Concreteness of Choreography binding

Inline.

At 02:04 PM 4/2/2003 -0800, Patil, Sanjaykumar wrote:

>This is good. With the example, we can now make the abstract discussion 
>more concrete :-)
>
>Questions:
>a> Do we need message definitions in the choreography? Wouldn't message 
>properties be sufficient?

At the abstract choreography level, No for 1st question and Yes for the 2nd

>b> Is our model to define the choreography with POHandlingProcess at the 
>center of the universe? Based on whether we define it as a collaboration 
>or as individual role's process, the language will change.
>    For example, if we were to follow a collaboration model, the first 
> statement in the Process construct will be something like 'Partner 
> "seller" to receive "PO" from partner "purchaser"' instead of 'receive 
> "PO" from partner "purchaser"'

You are absolutely correct.  So I use the term "Orchestration" rather than 
"Choreography" in my pseudo code.  Lets separate out the debate of 
"Orchestration" vs "Choreography".

>c> What is the purpose of "Message binding" in the Implementation Binding? 
>Perhaps this is related to question a> above. Wouldn't Message Property 
>binding be sufficient?

Message properties doesn't define all elements of the message.  It only 
define a subset of information that the orchestration use for evaluating 
conditions.  For example, the PO message may need to contain an element 
"poNumber", but you don't have a message property "PO.poNumber" because you 
don't use that for evaluating condition.  So at the implementation binding 
level, you need to bind both the message as well as message properties.

>d> Assuming that there is an individual Implementation Binding for each 
>role involved in the shared collaboration, the Partner binding can be to 
>identify the choreography interface of each partner. The choreography 
>interface of "mySelf" may not be needed as it becomes part of the other 
>roles' implementation binding.

You are right !  My example is based on the WSCI/BPEL model which the 
process itself play a specific central role.  If we take a more symmetric 
representation, then we'll end up something you describe here.  My example 
tries to illustrate the abstractness of the process, but not the 1st person 
view vs the neutral view.

Ricky

Received on Wednesday, 2 April 2003 20:28:28 UTC