Re: Progressive Concreteness of Choreography binding

Patil, Sanjaykumar wrote:

>Ricky, I agree with all of your points.
>
>I also see how your design is more modular, but I guess I need to understand a bit more the practical motivations behind/benefits of this design.
>
>Personally I was assuming the reason behind an abstract process in your example was to support the choreography between multiple participants. I guess a choreography between multiple participants can be defined by laying out the sequence, the direction of message exchanges and the few properties that drive the exchange of messages, etc (that is without depending much on the service descriptions), and hence I thought the abstraction in your example justifiable.
>  
>
Can't that be achieved by defining the choreography in terms of WSDL 
operations which are not specific to one particular service?

arkin

>However if the above was not precisely your motivation, then may I ask :-
>a> Do you have other scenarios in mind that would justify the additional layer as necessary and not an unnecessary complexity.
>b> Whether the separation of choreography from orchestration would require a similar kind of abstraction? Answering this one should probably be my own exercise as it was my own doubt, but perhaps you have some comments!
>
>Sanjay Patil
>Distinguished Engineer
>sanjay.patil@iona.com
>-------------------------------------------------------
>IONA Technologies
>2350 Mission College Blvd. Suite 650
>Santa Clara, CA 95054
>Tel: (408) 350 9619
>Fax: (408) 350 9501
>-------------------------------------------------------
>Making Software Work Together TM
>
>
>-----Original Message-----
>From: Ricky Ho [mailto:riho@cisco.com]
>Sent: Wednesday, April 02, 2003 5:28 PM
>To: Patil, Sanjaykumar; public-ws-chor@w3.org
>Subject: 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
>
>  
>


-- 
"Those who can, do; those who can't, make screenshots"

----------------------------------------------------------------------
Assaf Arkin                                          arkin@intalio.com
Intalio Inc.                                           www.intalio.com
The Business Process Management Company                 (650) 577 4700


This message is intended only for the use of the Addressee and
may contain information that is PRIVILEGED and CONFIDENTIAL.
If you are not the intended recipient, dissemination of this
communication is prohibited. If you have received this communication
in error, please erase all copies of the message and its attachments
and notify us immediately.

Received on Thursday, 3 April 2003 03:07:53 UTC