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

> -----Original Message-----
> From: Srinivas Pandrangi [mailto:srinivas@ipedo.com]
> Sent: Thursday, February 28, 2002 7:53 PM
> To: Vinoski, Stephen
> Cc: www-ws-arch@w3.org
> Subject: RE: Web Service Definition [Was "Some Thoughts ..."]
> 

> Let me repeat that my only concern is if this definition is 
> "too" broad....
> It should contribute towards better
> understanding the beast. It will be a disservice if we leave folks
> wondering if an ftp server is a web service, an smtp server is a web
> service etc. While conceptually they are services, they might not help
> anyone understand web services any better. 

OK, let's address this point.  The definition we're calling "Steve's" 
basically says that a web service is
1 - identified by a URI
2 - is invoked via a standard protocol
3 - suitable for being "called" by an application

What "non-web services" fit this definition?  Can we modify it a bit to
exclude them?

FTP has been mentioned -- I think we'd agree an FTP server is not a "web
service" even though it has a URI, is invoked by a standard protocol, and
can be called by an application.  I'd say it's not a web service because the
content of the result is not interpreted by most applications, or "processed
in a meaningful way."

Likewise, a random web page is not a web service even though it has a URI
and is invoked by HTTP, for the same reason.  A web browser does not process
the content returned by an HTTP server in a meaningful way. [Yeah, I need
help on what "meaninful" means ...this is vague, but gets to the essence of
what a web service is]

How about a DCOM or CORBA object?  Its result is generally processed in a
"meaningful" way (i.e., it's not just a bunch of bits, but some data
structure that usually represents something "understood" by the calling
program).  On the other hand, DCOM/CORBA objects are not identified by Web
URIs or invoked by Web standard protocols.  I think we *do* have to be
somewhat more restrictive about what "standard" means here, and that we are
talking about *internet* standards.  (I guess that could mean "layered on
IP" ... but that would exclude WAP, sigh ... I don't know how to define
"internet either, I guess).

How about the mythical sluice gate that can be controlled via commands from
a WAP phone, and the "result" is more or less water flowing.  I guess I
think that *is* a web service, because it's one application calling another
(let's say the gate controller is identified by a URI) over an "internet"
protocol  (WAP is more or less "the internet" IMHO).  

How about something like the UPS package tracking tool?  It has a URI, an
internet standard protocol (an HTTP POST of an HTML form), and I guess one
could write an application that grokked the result and did something useful
with it.  I'm a bit uncertain whether this is a "web service" because
there's not a clear enough "contract" (or "schema", or "definition") for
easy application to application calling and processing, but it's close, and
could easily become a web service.

How about Google?  A query has a URI, it's sent via HTTP, and if Google
documented the result XML/HTML/XHTML format, I guess it's sortof a web
service ...  I don't know ...

Anyway, I think we'd make more progress toward either coming up with an
acceptable definition of "web service" OR defining the requirements for a
"web service architecture" if we think through some of these corner cases.

Received on Thursday, 28 February 2002 20:48:19 UTC