- From: Martin Chapman <martin.chapman@oracle.com>
- Date: Thu, 17 Jul 2003 10:53:02 -0700
- To: "Francis McCabe" <fgm@fla.fujitsu.com>
- Cc: "Steve Ross-Talbot" <steve@enigmatec.net>, "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>, <public-ws-chor@w3.org>
even though we don't have agree teminology yet perhaps we sould start using the term agent instead of party or participant. martin. > -----Original Message----- > From: public-ws-chor-request@w3.org > [mailto:public-ws-chor-request@w3.org]On Behalf Of Francis McCabe > Sent: Thursday, July 17, 2003 10:30 AM > To: Martin Chapman > Cc: Steve Ross-Talbot; Champion, Mike; public-ws-chor@w3.org > Subject: Re: Grounding Choreographies (the atoms) - WAS Simple > Choreography composition suggestion > > > > +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. > >> > >> > > > >
Received on Thursday, 17 July 2003 13:52:51 UTC