- From: Frank McCabe <frankmccabe@mac.com>
- Date: Thu, 17 Jul 2003 19:23:18 -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
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 Thursday, 17 July 2003 22:23:25 UTC