W3C home > Mailing lists > Public > www-ws-arch@w3.org > February 2002

RE: Web Service Definition [Was "Some Thoughts ..."]

From: Champion, Mike <Mike.Champion@SoftwareAG-USA.com>
Date: Thu, 21 Feb 2002 18:22:19 -0700
Message-ID: <9A4FC925410C024792B85198DF1E97E402909D0B@usmsg03.sagus.com>
To: www-ws-arch@w3.org

> -----Original Message-----
> From: David Orchard [mailto:david.orchard@bea.com]
> Sent: Thursday, February 21, 2002 6:05 PM
> To: www-ws-arch@w3.org
> Subject: RE: Web Service Definition [Was "Some Thoughts ..."]
I'm happy with the changes, generally ...

> 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 don't disagree.  It would seem that we somehow have to address the issue
that almost all informal definitions of a web service talk about how "the
web as we know it today" requires a human reader or form-filler-outer to do
anything useful, and "web services" will allow this to be automated.  Can we
do anything with that idea without getting into philosophical black holes?
I don't like "conventional software" either ... it was a crude attempt to
say "a program that does not have the capabilities associated with an
Artificial Intelligence or require the facilities of the Semantic Web."    

> 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. 

Well, I think the REST people disagree.  Paul Prescod's recent XML.com
articles explain that point of view quite well. The SOAP message to retrieve
a stock quote is everyone's favorite (or least favorite!) example of a web
service.  If that was triggered with a URI that could be generated according
to instructions in a simple text document,  e.g
and the result came back in XML, or in some well-documented HTML format that
a program could process, wouldn't be a "web service"?  Likewise, isn't a
site that documents how you can use XML-RPC to get some specific information
back a "web service." 

SOAP and WSDL can certainly add value, e.g. if you wanted to define how to
get a series of quotes for a number of stocks during some historical period,
it would be a LOT more programmer-friendly to describe the interface in WSDL
and generate the SOAP request automatically.  But the selling point should
be that "SOAP/WSDL make it easier for non-web geeks to build and access web
services" not "if it ain't got SOAP or WSDL, it ain't a web service".  

Thinking about this a bit, I think the key differentiator for a "web
service" is the notion that it adheres to a well-specified "contract" to
deliver specific machine-processable information in response to a specific
invocation.  Obviously WSDL is one way of specifying the contract, and SOAP
is a flexible way of making the invocation and getting the result.  But if
the invocation is specified via a documented URI syntax, and the result is
informally documented XML (e.g., RSS 0.91), then it's a "web service" too.
Google is a "web service" in my book, or could be when they have some way of
returning the results in XML, or a well-documented XHTML format whose
essentials won't change every time the marketing people hear from a focus
group that it should look spiffier. 
> 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.

Hmm, I like the idea.  It would definitely be worth seeing if we could come
up with acceptable, unambiguous definitions!  I suspect that we'll have to
accept some fuzziness, "degrees of webness" and "degree of service-ness".
For example, I'd say:

html forms + undefined html result = 100 %web, 0% service
well-documented URI + well-documented html result = 100% web,  75% service
well-documented URI + informally specified SOAP result = 50% web, 90%
SOAP + WSDL  = 0% web, 100% service

I guess a hypothetical web page that accepted a URI-encoded SOAP message
rigorously defined by WSDL and returned a SOAP result that used a stylesheet
to render it in a human-friendly format could be 100% web, 100% service.
Received on Thursday, 21 February 2002 20:22:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:40:54 UTC