To be a Web service, or not to be a Web service ...

OK, which of these are or are not Web services?  All are assumed to involve
one software agend accessing another.... and I won't waste time with obvious
cases where SOAP and WSDL are involved.

1) Generating a URI by some hard coded or ad hoc means, then doing an HTTP
GET of an HTML page, then screen-scraping it (based on hard coded or ad hoc
definition of the content) to populate a data structure.

2) Emulating a human's action filling out an HTML FORM by generating an HTTP
GET or POST request.

3) A RESTful hypermedia-like interaction where a URI is generated, data PUT
or GET from that URI, the HTTP error code is checked, and the results parsed
to find the appropriate URI for the next round of interaction via some
heuristic.

4) Same as 3) but the syntax of the returned data is XML that conforms to an
agreed upon schema and the rules for interpreting the results and moving to
the next state are well-defined in an XML-based format.

5) A hand-coded SOAP interaction between client and server software based on
an informal understanding of the interface  to some service.

6) An application generated from a WSDL description of a non-SOAP
interaction via HTTP.  (Assuming that WSDL supports such a thing)

7) A "semantic web" application in which agents interact via HTTP (without
SOAP) based on a formal description of what is to be done that doesn't
involve WSDL, but does involve RDF/OWL. 

I'd be interested in people's thoughts, and if it would be useful I think we
could organize a straw poll.  FWIW, I think they are all "web services"
except 1) and 2). 

Anyone wishing to refine / clarify / expand this to make it more useful for
voting against is welcome to do so.

Received on Wednesday, 16 April 2003 09:32:50 UTC