W3C home > Mailing lists > Public > public-ws-chor@w3.org > April 2003

Re: Progressive Concreteness of Choreography binding

From: Assaf Arkin <arkin@intalio.com>
Date: Thu, 03 Apr 2003 10:45:26 -0800
Message-ID: <3E8C8146.1070207@intalio.com>
To: Ricky Ho <riho@cisco.com>
CC: "Patil, Sanjaykumar" <sanjay.patil@iona.com>, public-ws-chor@w3.org

Ricky Ho wrote:

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

I'm talking about WSDL as it currently stands.

If you add inheritence and parameter overloading you get more reuse and 
that's a good thing. You can do more compositions by extending existing 
definitions (and implementations) instead of rewriting everything from 
scratch. But you can get a lot done with WSDL as it stands.


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


I'm talking about the WSDL abstract definitions. There is no XSL/T 
transformation attached to it.

As part of binding to a specific protocol you may want encoding rules 
and some of these rules can be expressed in XSL/T but there are other 
oprtions. As part of binding to a specific implementation you may also 
want transformation, but that's an implementation detail.

For example, the abstract message may define the message as containing:

shipTo
billTo

All buyers and sellers agree that this is the information carried in the 
message and they can all reference it in the same way.

Some implementation may have an internal structure defined as:

shipAddr
billAddr

Internally that implementation may use XSL/T (or other means) to map 
to/from the abstract message, so it can talk in one language with 
everyone else, yet retain its implementation independence. You don't 
care about what the implementation does, only about the lingua franca.

Some protocol may decide to structure things differently, for example:

addresses
  billing
  shipping

So only those services that use that protocol would convert the abstract 
message to that particular representation when they send/receive 
messages over that protocol. But if they happen to use other protocols 
they could encode the abstract message in other ways. You are still 
talking lingua france since you're talking to others in terms of the 
abstract message, even if you choose to encode it differently for 
different protocols.

So the abstraction lets you define the common language that everybody 
talks, while allowing varience of implementations and allowing multiple 
different protocols to be supported at the same time.

arkin

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


-- 
"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 13:46:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:00:14 GMT