- From: Burdett, David <david.burdett@commerceone.com>
- Date: Fri, 18 Jul 2003 12:54:37 -0700
- To: "'Assaf Arkin'" <arkin@intalio.com>, Frank McCabe <frankmccabe@mac.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
Assaf My take is that strictly speaking, a choreography is "A definition of the sequence and conditions in which a set of interactions occur between two roles". Where *interactions* include both individual (e.g. HTTP) messages as well as higher level concepts such as a single "reliably delivered message" which actually requires several HTTP message to implement, or at a even higher level, concepts such as a "Request for Quote". Also roles can include, at a low level, general concepts such as a "sender" and "receiver" which could be appropriate when defining the choreography associated with a RM protocol, or such business level concepts such as "buyer" and "seller" when defining a business level protocol/choreography. In both cases roles defined in the choreography are abstract and need to be mapped to the physical instances which will often, but needn't be - as Martin mentioned, web services. If we say that Choreographies *always* have to be *between* web services then it precludes the choreography being used by something that is not a web service, which I don't think we want to do. My $0.02c. David -----Original Message----- From: Assaf Arkin [mailto:arkin@intalio.com] Sent: Friday, July 18, 2003 11:52 AM To: Frank 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 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 15:56:01 UTC