- From: Cutler, Roger (RogerCutler) <RogerCutler@chevrontexaco.com>
- Date: Sat, 23 Feb 2002 10:31:31 -0800
- To: "'Edwin Khodabakchian'" <edwink@collaxa.com>, "Cutler, Roger (RogerCutler)" <RogerCutler@chevrontexaco.com>, "'David Orchard'" <david.orchard@bea.com>, www-ws-arch@w3.org
Well, are you SURE that number 8 is "a" web service, not an orchestration of two web services? It seems to me that if you allow 8 as a web service you are sliding down the slippery slope of including all orchestrations or choreographies -- and as I understood it that is not considered desirable. I have another (hopefully) clarifying set of questions: Is IRC a web service? Is Yahoo Messenger? If not, why not? Could they be made web services by incremental changes in how they work or what they do? If these, or some derivatives, are indeed web services do the definitions of web services we are considering need to be expanded or generalized to include them? I do not have suggested answers to these questions -- I honestly don't know and I'd like to find out. Opinions: 1 - I would like to see web services defined pretty broadly so, for example, one can build useful orchestrations out of web services components. If web service is defined so narrowly that all you can make is RPC's I think that people will curse us. 2 - If web services are defined pretty broadly I think it might be useful to define subclasses like "simple web service". 3 - I strongly favor functional definition of web service within a broad technical framework. That is, I like saying that web services have to use URI's and XML, I don't like saying they have to use WSDL and/or UDDI. 4 - I think that if we have a definition of web services that works we should be able to make a list of things that are and are not web services and in the latter case identify specifically what part of the definition is violated. I think that we should, in fact, make such a list and that if we do it well people will bless us. -----Original Message----- From: Edwin Khodabakchian [mailto:edwink@collaxa.com] Sent: Friday, February 22, 2002 3:54 PM To: 'Cutler, Roger (RogerCutler)'; 'David Orchard'; www-ws-arch@w3.org Subject: RE: Web Service Definition [Was "Some Thoughts ..."] Roger, 1 - 8 are indeed web services. You might want to separate the public interface of the web service (contrat that B exposes to A) and the private implementation of the web service (how B implements A's service request). Through that angle, the exchange between A and B is a conversation: A sends initial request document to B B can send back N notifications back to A B can throw an exception back to A B send result of request back to A This conversation can be seen as a long lived request and described through WSDL. Please not that the conversation is atomic and not re-entrant. Once the notion of conversation is defined, all the use cases described can be decomposed into sets of conversations. The way B composes multiple private conversations in order to fullfil A's request is called orchestration (aka. Private business process) and can be modeled using WSFL for example. In my opinion, one of the key aspects of web services should allow to make conversation interoperability simple, non-ambigous and easy-to-manage. It is also very important to separate the public face of the conversation and the private implementation....All standards that have tried to model private implementation over the last 20 years have failed or become niche! Edwin -----Original Message----- From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org] On Behalf Of Cutler, Roger (RogerCutler) Sent: Friday, February 22, 2002 8:11 AM To: 'David Orchard'; www-ws-arch@w3.org Subject: RE: Web Service Definition [Was "Some Thoughts ..."] I'm a little concerned here about the "a" in "a markup result". I think it should say something like that it produces one or more responses directed to one or more recipients. I think that it might be useful to say that all participants in the transaction (requestor, responder and all recipients of responses) are identified by URI's and that all information flows are addressed via these URI's. Could you please tell me whether the following are web services? (Unless otherwise stated information flows are via XML addressed via URI's and all participants are identified by URI's). All scenarios start with "A sends a request to B". Then ... 1 - B sends a single response back to A. 2 - B sends an immediate response back to A, then another response two weeks later. 3 - B sends a request to C, receives a response from C and on the basis of that information sends a response to A. 4 - B does something but does not send a response to anyone. 5 - B sends responses to A and D. 6 - B sends multiple reponses to D and nothing back to A. 7 - B makes a telephone call to C and on the basis of that information sends a response to A. 8 - B sends a request to C, C sends a response back to A. 9 - B telephones C, C sends a response to A. My answer, and I really hope that we will agree on this, is that 1-7 are web services, 8 is an orchestration composed of two web services and 9 is a work flow outside the scope of web services. If we are agreed on this, it seems to me that it might be useful to call #1 a "simple web service", since a lot of the time I think that's what people are thinking of and there might be some designs, architectures or techniques that will only apply to that case. I would be very unhappy, however, if cases 2-7 were excluded without some really good reason. -----Original Message----- From: David Orchard [mailto:david.orchard@bea.com] Sent: Thursday, February 21, 2002 5:05 PM To: www-ws-arch@w3.org Subject: RE: Web Service Definition [Was "Some Thoughts ..."] Now you're cooking! However, I think that the coupling to the web should a little explicit. How about: "A web component is a component accessed over HTTP or other messaging protocol, identified by a URI, and producing a markup result" "A web service is a web component that: is invoked using an XML message such as a SOAP message, via a well-defined message exchange pattern; and is defined by a description of the data required to invoke the service, such as a WSDL document; " So we refine the web component into a web service by mentioning SOAP and WSDL. I took some of your web service text and refactored it into the web component definition I'm not too keen on the addition of "usefully processed by conventional software without human intervention." because I can't figure out how to define "conventional software" nor "usefully" processed". I got rid of the term "unambiguous". This does beg the question of how to differentiate web services from xhtml, xslt, SVG - certainly HTTP is a well-defined MEP ;-) It seems to me that if you don't use SOAP AND you don't use WSDL, you probably don't have a web service. One criteria that I tend to like is that a Web service must have at least one of SOAP or WSDL. If somebody creates a non-soap XML document and ships it over HTTP to a URI that doesn't have a WSDL, that's just a web document/component. Question: Is anything describable by WSDL, like an XHTML page described by WSDL, a web service? I tend to think not, but it does fit in the WSDL definition. An xhtml document could go from a web page to a web service by simply being described in WSDL if this is the case - note the runtime messages didn't change at all. I thought about trying to differentiate soap/xml-rpc etc. from xhtml/xslt/svg, by saying that soap/xml-rpc are frameworks that "verticals" define. W3C defines xhtml/xslt/svg, whereas the contents of soap messages are defined outside the W3C. That is there is a separate namespace name that is required for the message to be meaningful. But this fails with the SOAP because a complete message could use just SOAP encodings. So the closest I could get on the "vocabulary" axis is that the XML exchanged is defined by SOAP or defined by a non-w3c xml vocabulary. This would exclude xhtml, svg, xslt and allow xml-rpc, ebXML, others. A bit tortuous, and I'm sure there are some xml vocabularies that people wouldn't think are web services. Maybe we should come up with a spreadsheet listing different xml vocabs/definitions and see if people think they are in scope of web services or not, like: xhtml, nowsdl: web xhtml, wsdl: web or web service? soap: web service myvocab, smtp, nowsdl: web or web service? myvocab, http, nowsdl: web or web service? myvocab, wsdl: web service. Then we do the karnaugh map for our web service definition. Cheers, Dave > -----Original Message----- > From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On > Behalf Of Champion, Mike > Sent: Thursday, February 21, 2002 2:09 PM > To: www-ws-arch@w3.org > Subject: RE: Web Service Definition [Was "Some Thoughts ..."] > > > > Starting with the strawman proposal, and then applying some comments > that came up in email and the teleconference. > > > "A web service is is a software application or component > that can be > > accessed over the Internet using a > vendor/platform/language-neutral data > > interchange format to invoke the service and supply the response, > > using a rigorously defined message exchange pattern, and > producing a > > result that is sufficiently well-defined to be processed by > a software > > application." > > Comments (sorry, I'm in brain dump mode and won't cross-reference the > archives): > > First, how do we distinguish Web services from "the web" itself? A > sufficiently generic definition would imply that an arbirtrary web > page is a "web service" that supplies an HTML document. That is too > broad to be useful, IMHO. I just noticed that Microsoft has a "Global > XML Web Services Architecture" that they refer to. > http://msdn.microsoft.com/library/default.asp?url=/library/en- > us/dngxa/html/ > gloxmlws500.asp > I'm not sure that this is meant as a definition, but this > says "XML Web > services are built on XML, ... (SOAP),... (WSDL), and ...(UDDI) > specifications." We should probably discuss each point > individually. I'm > willing to say that we are talking about *XML* web services > in which the > service is identified by some combination of URIs and XML, > and the result is > an XML instance. On the other hand, I'm reluctant to say > that "web services > *require* SOAP, WSDL, or UDDI, although each obviously is an > *example* of > role that might be critical to our definition. > > Is SOAP critical to the definition of a Web Service? There are two > very distinct positions on this question, as far as I know. One is > the SOAP-RPC approach, which says that a URI identifies a fairly > generic "endpoint" (sortof like a function library) and the contents > of the SOAP envelope identify the specific function to be invoked and > the parameters to be passed. The other is the REST approach, which > says that the web service is a > "resource" as understood in the Web Architecture and the URI should > completely identify the service, the function, and the > parameters. SOAP > might be useful in a REST-ful web service (especially since > it is defined on > the InfoSet and not XML syntax, so could be encoded in URI > syntax ... and > could obviously be used to package up the result, but it is > not critical to > the *identification* of a REST web service. Do we want to > take sides in > this? I hope not ... we'll lose the W3C Director if we insist > on one, and > half the vendors if we insist on the other! <grin> So, I'd > say that a web > service is "unambiguously identified using Web technologies, > including a URI > and optionally an XML description such as a SOAP message". > > Next, WSDL is integral to IBM's definition, and an official W3C WG > now, so some imply we should explicitly reference it. This is a > show-stopper politically, in my humble opinion. The scripting people, > most notably Dave Winer [a co-author of the original SOAP spec] are > adamant that an informal > document describing how to access a web service is > sufficient. I'd amend > the strawman to say that a web service must have a "clear > description of the > data required to invoke the service, such as a WSDL document." > > Someone mentioned that a machine-processable result (as opposed to a > human or an artificial intelligence) is integral to the definition. > The strawman says "producing a result that is sufficiently > well-defined to be processed > by a software application." How about saying that a web > service must, by > definition, "produce a result that can be processed by conventional > software without human intervention." > > We talked about "orchestration" on the call. I got distracted for a > couple of minutes, but it appeared that we think this is not integral > to the definition of a web service, although potentially a topic that > the architecture should cover. > > So, here's the "son of strawman" definition (stickman?): > > "A web service is is a software application or component that: > > Is accessed over the Web (broadly defined) using HTTP or another > standard messaging protocol; > > Is identified and invoked using using Web technologies, including a > URI and optionally an XML description such as a SOAP messagem, via a > well-defined message exchange pattern; > > Is defined by an unambiguous description of the data required to > invoke the service, such as a WSDL document; > > and Produces an XML result that can be usefully processed by > conventional software without human intervention." > > > > > > >
Received on Saturday, 23 February 2002 13:31:44 UTC