- From: Mark Baker <distobj@acm.org>
- Date: Mon, 25 Feb 2002 10:49:43 -0500 (EST)
- To: RogerCutler@chevrontexaco.com ("Cutler, Roger (RogerCutler)")
- Cc: steve.vinoski@iona.com, Mike.Champion@softwareag-usa.com, www-ws-arch@w3.org
Roger, > I like the way that this definition is going, too, but I think that as it > stands it is too broad because I think it will include orchestrations and > the sense of the group seemed to be that orchestrations are a higher level > construction than web services. In order to fix this I suggest that we > define a web service as having the following participants, all identified by > URI's: > > 1) A single "requestor". > > 2) A single "responder". > > 3) Zero or more "recipients". > > A web service is initiated by a communication from the requestor to the > responder and the responder sends any number of communications to the > recipients. All these commmunications are via web protocols. I think you're too narrow now. 8-O SOAP 1.2 explicitly supports an extensible array of message exchange patterns[1]. Defining a web service in these terms would unnecessarily restrict our scope, IMO. For example, consider a voting service where I can ask a set of people to vote for or against something. In this case, there are multiple responders. I'm not sure how what Steve or I suggested relates to orchestrations. I see orchestrations (as I understand the term) to be Composites[2], that is, that they are themselves Web services. [1] http://www.w3.org/TR/soap12-part2/#soaptmep [2] http://c2.com/cgi/wiki?CompositePattern MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@planetfred.com http://www.markbaker.ca http://www.planetfred.com
Received on Monday, 25 February 2002 12:40:04 UTC