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

OK, now I understand what 3 is, and in fact much better what they all
are.  I agree with you that 1 and 2 are not WS's, for the reasons sited
and that the rest are Web services.  I particularly think that 5 is a
Web service for similar reasons as my image-returning Web service.  I
have already responded that I don't like your formal description
requirement because it seems not to be consistent with several of David
Booth's very excellent scenarios that are early bound.

-----Original Message-----
From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com] 
Sent: Wednesday, April 16, 2003 9:24 AM
To: www-ws-arch@w3.org
Subject: 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 13:27:16 UTC