Re: Progressive Concreteness of Choreography binding

At 12:06 AM 4/3/2003 -0800, Assaf Arkin wrote:
>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?

Are you talking a future form of WSDL which support inheritance and 
parameter overloading ?

Or are you talking about an arbitrary WSDL which has an XSL/T 
transformation attached to it.  In this case, the WSDL doesn't need to be 
non-specific to 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 10:22:49 UTC