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

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

From: Francis McCabe <fgm@fla.fujitsu.com>
Date: Fri, 18 Jul 2003 13:44:17 -0700
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
To: Assaf Arkin <arkin@intalio.com>
Message-Id: <999D2F10-B960-11D7-8CCE-000393A3327C@fla.fujitsu.com>

This is simple.

An agent is the computational resource (yuk) that may be considered to  
represent a legal entity and which offers and/or requests services; in  
particular Web services.

The service itself is manifested by the messages between the agents;  
those messages are the basic raw materials for choreographies, not the  
agents. Controlling the agents amounts (IMO) to orchestration;  
observing the messages amounts to choreography.

Frank



On Friday, July 18, 2003, at 11:51  AM, Assaf Arkin wrote:

>
> 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 16:58:49 GMT

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