- From: Francis McCabe <fgm@fla.fujitsu.com>
- Date: Tue, 22 Jul 2003 12:45:37 -0700
- To: "Cummins, Fred A" <fred.cummins@eds.com>
- Cc: public-ws-chor@w3.org
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 UTC