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

Dear Colleagues,

I am a bit behind with mail, so someone may have already made this
point, but I would like to suggest that we need (at least) two terms not
just one (agent).  Some other groups have used 'party' and 'role' where
a party is a single administrative domain (at least - I am sure has
other characteristics as well) and can play several roles
(simultaneously, overlapped or sequentially or any combination).  There
can by 'internal' communication between the roles a party plays but all
communications between the roles that different parties play is via
external communications (messages / interactions of direct interest to
the Choreography).

Thus if we do not use these two terms I think we need two which are
their 'moral equivalent'.

Best Regards     Tony
A M Fletcher
 
Cohesions  (TM)
 
Business transaction management software for application coordination
www.choreology.com
 
Choreology Ltd., From 4 August: 68 Lombard Street, London EC3N 9LJ
UK
Tel: +44 (0) 8707 390076   Fax: +44 (0) 8707 390077  Mobile: +44 (0)
7801 948219
tony.fletcher@choreology.com     (Home: amfletcher@iee.org)


-----Original Message-----
From: public-ws-chor-request@w3.org
[mailto:public-ws-chor-request@w3.org] On Behalf Of Assaf Arkin
Sent: 17 July 2003 19:32
To: Francis McCabe
Cc: Martin Chapman; Steve Ross-Talbot; Champion, Mike;
public-ws-chor@w3.org
Subject: Re: Grounding Choreographies (the atoms) - WAS Simple
Choreography composition suggestion



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 Wednesday, 23 July 2003 05:45:24 UTC