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: Thu, 17 Jul 2003 11:32:14 -0700
Message-ID: <3F16EBAE.8030202@intalio.com>
To: Francis McCabe <fgm@fla.fujitsu.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

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 Thursday, 17 July 2003 16:33:02 GMT

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