- From: Steve Ross-Talbot <steve@enigmatec.net>
- Date: Fri, 18 Jul 2003 09:24:36 +0100
- To: "Cummins, Fred A" <fred.cummins@eds.com>
- Cc: Martin Chapman <martin.chapman@oracle.com>, "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>, public-ws-chor@w3.org
Which is why I took the approach I did in trying to describe the grounding. Certainly the abstract language that we design could be used to describe MEP's. It could and should be capable of describing choreography in any context. We have to ground somewhere sensible given what we have been chartered to do. It is possible that MEP's are the right level. Equally it is possible that they are too low and that we need to think in terms of business messages and not protocol messages. Hence my scoping or grounding out at what I was calling a web service. Using the term "agent" or better still "process" (at least for my money) would allow us to work at the right level of abstraction. Then it's a case of trying a process (or agent if you prefer) to the correct term in the web service stack. Cheers Steve T On Thursday, July 17, 2003, at 06:58 pm, Cummins, Fred A wrote: > Martin, > > While I agree that it should be possible to define a MEP with > the choreography langauge, I would not like a reliable messaging > choreography to be merged with a purchasing choreography. > I want the purchasing choreography to be expressed with the > reliable messaging protocol implied, i.e., abstracted out. > > The MEP will have implications to the design of the business > choreography. Consequently, it may be necessary to incorporate > a reference so that the assumptions are clear, but I don't > see a single choreography incorporating both levels of > abstraction in any more complex way. > > Fred > >> -----Original Message----- >> From: Martin Chapman [mailto:martin.chapman@oracle.com] >> Sent: Thursday, July 17, 2003 12:17 PM >> To: Steve Ross-Talbot; Champion, Mike >> Cc: public-ws-chor@w3.org >> Subject: RE: Grounding Choreographies (the atoms) - WAS Simple >> Choreography composition suggestion >> >> >> >> 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. >>> >>> >> > 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.
Received on Friday, 18 July 2003 04:24:43 UTC