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

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

From: Francis McCabe <fgm@fla.fujitsu.com>
Date: Tue, 22 Jul 2003 12:45:37 -0700
Cc: public-ws-chor@w3.org
To: "Cummins, Fred A" <fred.cummins@eds.com>
Message-Id: <114B0320-BC7D-11D7-8086-000393A3327C@fla.fujitsu.com>

Fred:
   I may have a slightly funny view of the concept of role; but I 
understand the term in a strictly relative sense: a role is *always* in 
relation to some context.

   From a programming language perspective, roles seem analogous to the 
distinction between parameters of a function and arguments to a 
function call. When a function is called, parameters (roles) are bound 
to actual values (agents). However, within the body of a function, 
parameters are (nearly) always indistinguishable from actual values -- 
or rather an identifier in a function body is treated equivalently 
whether it is a parameter or a local variable.

  In the context of choreographies I see something similar: in a 
`concrete' choreography, there will be identifiers of the agents in the 
choreography. When a concrete choreography is *abstracted* some of 
those names are re-interpreted as parameters and hence as roles. A 
choreography is then *applied* by instantiating some of the roles with 
`real' names; of course, those real names may themselves be role-names 
rather than agent names ... its turtles all the way down.


Frank


On Tuesday, July 22, 2003, at 11:03  AM, Cummins, Fred A wrote:

>
> Frank,
>
> Catching up from Friday:
>
> I agree with your definition of agent.  It should be
> distinguished from "role."  An agent may have many
> roles.  When an agent participates in a choreography,
> it may have one or more roles.  An agent may be
> a buyer and also a shipment receiver (choreography
> with a transport carrier).
>
> So choreography defines the interactions between roles
> of agents.  In general, I would not expect the
> choreography to be concerned with the agents, only the
> roles.
>
> Fred
>
>
>> From: Francis McCabe [mailto:fgm@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 Tuesday, 22 July 2003 15:45:44 GMT

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