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

> -----Original Message-----
> From: Walden Mathews [mailto:waldenm@optonline.net]
> Sent: Wednesday, April 16, 2003 9:54 AM
> To: Champion, Mike; www-ws-arch@w3.org
> Subject: Re: To be a Web service, or not to be a Web service ...
> 

> I like these examples, but I wish you'd re-work them to make sure
> you're describing the service and not the client.  What the 
> client does
> may be indicative of the service, but a direct description of the
> service would be clearer.

Good point ... that post was a "brain dump before bed", which I should
probably try harder to resist the temptation to do. 

But here's an attempt to rework them:

1) The "service" is an ordinary HTML Web page whose structure appears to
follow a predictable pattern but the underlying code/stylesheets are not
publicly available; a client agent "screen scrapes" the HTML to extract
information into a data structure for further processing.

2) The "service" is some executable software acessed by a CGI script that
processes the information defined by an HTML FORM; the client agent
generates the GET or POST that would be submitted by a browser after a human
fills out the form.

3) The "service" is a RESTful hypermedia application (e.g. an online travel
agency) designed to be used by either human agents or software agents and
the returned data is XHTML; the client agent was programmed after
consultation with the "service" developers to simulate the sequence of GETs
and POSTS -- checking the HTTP return codes and parsing the result data to
find the appropriate URI to go to the next state.

4) Same as 3) but there is no human-usability requirement and 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) The "service" is some executable software accessed by a SOAP interface
whose only description is the Java code that actually implements it; the
client agent is hand-coded after a telephone conversation with the developer
of the "service."

So, which of these are "Web services" according to our constraints /
definition?

I say that 1) and 2) are not Web services because they were written without
regard for being used by software agents; the fact that programmers can
emulate the behavior of the human agent is a tribute to their skill, not to
the "service-ness" of the server-side code.  

3) and definitely 4) *are* Web services because they are intended for
software agent consumption, the service is identified by a URI, the
interface is sufficiently well defined so that software can use it [this
might be a bit fuzzy in 3), I admit ...], the communication is via a
standard, URI-aware protocol, and XML is used to communicate between the
service and the client agent [XHTML is still XML!].  

5) as I said in a previous post is a bit dicey ... it "smells" like a Web
service to me but may not meet the "formal description" constraint ... but
on the other hand, the Java code *is* a formal description, and if a client
agent developer can directly or indirectly refer to the formal description,
then maybe that meets the constraint.

The only one I feel strongly about is 4) -- A rigorously defined RESTful
hypermedia application using URIs and XML data exchanges is a "Web service"
as far as I am concerned, even if SOAP and WSDL are not involved.  [Go
ahead, impeach me as co-chair for this heresy ... but obviously I'm speaking
with my "member" hat on here!]

Received on Wednesday, 16 April 2003 10:36:11 UTC