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.comReceived on Monday, 25 February 2002 12:40:04 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:24:54 GMT