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

Re: Grounding Choreographies (the atoms) - WAS Simple Choreography composition suggestion

From: Assaf Arkin <arkin@intalio.com>
Date: Fri, 18 Jul 2003 11:51:46 -0700
Message-ID: <3F1841C2.2090407@intalio.com>
To: Frank McCabe <frankmccabe@mac.com>
CC: Martin Chapman <martin.chapman@oracle.com>, Steve Ross-Talbot <steve@enigmatec.net>, "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>, public-ws-chor@w3.org

Then how should we use the term agent as suggested by the WSA?

Also, how do we deal with the trivial case of a choreography that 
involves only one message (got to start somewhere). There's a Web 
service requester (agent 1) sending a message to Web service provider 
(agent 2). The later is a Web service, but the former is not. What are 
we choreographing in this case?

arkin

Frank McCabe wrote:

>
> No, that would be orchestration! ;-)
>
> Frank
>
> On Thursday, July 17, 2003, at 11:32  AM, Assaf Arkin wrote:
>
>>
>> So a Web Service Choreography does not choreograph Web services, it 
>> choreographs agents?
>>
>> arkin
>>
>> Francis McCabe wrote:
>>
>>>
>>> +1.
>>>
>>> Following the form of the WSA, we have agents that provide and 
>>> request Web services. This is based on the intuition that a service 
>>> is fundamentally about the potential for action, and that actors 
>>> (computational and otherwise) are the entities that do the acting.
>>>
>>> Frank
>>>
>>> On Thursday, July 17, 2003, at 09:16  AM, Martin Chapman wrote:
>>>
>>>>
>>>> I think there is a fundamental terminology issue here that needs to be
>>>> cleared up.
>>>> An entity (avoiding any overloaded word) that sends a message to a web
>>>> service (and may expect a response depending on the wsdl) doesn not 
>>>> iteslf
>>>> have to be a web service. This is the most fundamental building block.
>>>> Furthermore this interaction supports an MEP (in soap teminology) and
>>>> pattern (in wsd teminology).
>>>> Perosnllay if we can not describe these meps in a choreography 
>>>> language we
>>>> have failed, and hence I do not think that mep choreogaprhy is any 
>>>> different
>>>> from web service choreography.
>>>>
>>>> Martin.
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: public-ws-chor-request@w3.org
>>>>> [mailto:public-ws-chor-request@w3.org]On Behalf Of Steve Ross-Talbot
>>>>> Sent: Thursday, July 17, 2003 2:14 AM
>>>>> To: Champion, Mike
>>>>> Cc: public-ws-chor@w3.org
>>>>> Subject: Grounding Choreographies (the atoms) - WAS Simple 
>>>>> Choreography
>>>>> composition suggestion
>>>>>
>>>>>
>>>>>
>>>>>    At the considerable risk of adding further confusion to the
>>>>> discussion I would like to attempt to clarify what I said on the call
>>>>> with respect to the grounding of a choroegraphy.
>>>>>
>>>>>
>>>>>    Here is how I see it:
>>>>>
>>>>>    A "web service" choreography, as distinct from any other
>>>>> choreography, is grounded to a minimum of two web services instances.
>>>>> This may mean that the web services are the same web services but
>>>>> different instance or it may mean that they are distinct 
>>>>> (personally I
>>>>> have a hard time seeing what they would be anything other than the
>>>>> latter) such that I can observe a communication between them.
>>>>>
>>>>>    A communication is a minimum of a single message sent from one web
>>>>> service to another web service.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>    It may be the case that in receiving or indeed sending a 
>>>>> message the
>>>>> sending web service and/or the receiving web service can be 
>>>>> externally
>>>>> observed to change their behaviour.
>>>>>
>>>>>    A "web service" choreography, as distinct from any other
>>>>> choreography, is based on externally observable behaviour where this
>>>>> behaviour is defined in terms of communications between web services
>>>>> and externally observed behavioral changes of a web service.
>>>>>
>>>>>    For the avoidance of doubt, a Message Exchange Pattern (MEP) or 
>>>>> any
>>>>> mechanism that describes communication between two parties can be 
>>>>> said
>>>>> to be a choreography. But it cannot be said to be a "web service"
>>>>> choreography.
>>>>>
>>>>>
>>>>> Cheers
>>>>>
>>>>> Steve T
>>>>>
>>>>>
>>>>> On Wednesday, July 16, 2003, at 02:57  pm, Champion, Mike wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Fletcher, Tony [mailto:Tony.Fletcher@choreology.com]
>>>>>>> Sent: Wednesday, July 16, 2003 9:12 AM
>>>>>>> To: public-ws-chor@w3.org
>>>>>>> Subject: FW: Simple Choreography composition suggestion
>>>>>>>
>>>>>>
>>>>>>>
>>>>>>> The point I disagree with is the notion that something is not a
>>>>>>> Choreography if somewhere, at some level it involves 
>>>>>>> 'orchestration'
>>>>>>> within a single system.  If we accept this notion /
>>>>>>> restriction it means
>>>>>>> that you can only have Choreographies involving exactly two parties
>>>>>>> where each party only plays a single role - we will not be
>>>>>>> able to have
>>>>>>> Choreographies with more than two parties / roles at all.
>>>>>>
>>>>>>
>>>>>>
>>>>>> That wasn't my intent, FWIW.  All sorts of compositions and
>>>>>> decompositions
>>>>>> can occur within a "choreography," but IMHO only those that 
>>>>>> involve the
>>>>>> globally visible shared state are in scope for the choreography
>>>>>> description
>>>>>> language we are developing.  The discussion yesterday got me
>>>>>> re-thinking all
>>>>>> sorts of things ... if the fundamental unit of a "choreography" is a
>>>>>> Web
>>>>>> service invocation / MEP, then all sorts of implementation 
>>>>>> details of
>>>>>> the
>>>>>> service that involved "orchestrated" interactions behind the 
>>>>>> scenes are
>>>>>> abstracted away, but if the fundamental unit is a message, then all
>>>>>> those
>>>>>> messages behind the scenes have to be accounted for somehow.  I'm as
>>>>>> confused as anyone at this point.
>>>>>>
>>>>>> By all means let's make sure that we don't box ourselves into a 
>>>>>> corner
>>>>>> based
>>>>>> on some preliminary guesses about what terms mean!
>>>>>>
>>>>>>
>>>>>> This email is confidential and may be protected by legal 
>>>>>> privilege. If
>>>>>> you are not the intended recipient,  please do not copy or disclose
>>>>>> its content but  delete the email and contact the sender 
>>>>>> immediately.
>>>>>> Whilst we run antivirus software on all internet emails we are not
>>>>>> liable for any loss or damage. The recipient is advised to run their
>>>>>> own antivirus software.
>>>>>>
>>>>>
>>>>> This email is confidential and may be protected by legal
>>>>> privilege. If you are not the intended recipient,  please do not
>>>>> copy or disclose its content but  delete the email and contact
>>>>> the sender immediately. Whilst we run antivirus software on all
>>>>> internet emails we are not liable for any loss or damage. The
>>>>> recipient is advised to run their own antivirus software.
>>>>>
>>>>>
>>>>
>>
>>
>> -- 
>> "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 Friday, 18 July 2003 15:24:01 GMT

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