- From: Francis McCabe <fgm@fla.fujitsu.com>
- Date: Fri, 18 Jul 2003 13:44:17 -0700
- To: Assaf Arkin <arkin@intalio.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
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 UTC