What DO we agree on? (was RE: The stack diagram (was RE: Discuss ion topic for tomorrow's call)

> -----Original Message-----
> From: David Orchard [mailto:dorchard@bea.com]
> Sent: Wednesday, April 16, 2003 1:27 AM
> To: 'Mario Jeckle'; www-ws-arch@w3.org
> Cc: 'George Blanck'; Savas.Parastatidis@newcastle.ac.uk;
> Eric.Newcomer@iona.com
> Subject: RE: The stack diagram (was RE: Discussion topic for 
> tomorrow's
> call
> 
 
[not speaking with co-chair hat on!!!!]

> We do not have agreement on what is REQUIRED for something to be 
> a Web service.
> What are the constraints?  All we have so far is that it's 
> gotta have a URI. If it's not SOAP, not WSDL, not even XML, then there
really 
> isn't much else there there.  Great, a URI.  But what next?  Our
architecture 
> won't provide anything that is of use to developers, as the URI isn't 
> nearly sufficient to do something with. 

Dave raises the awfully good point that these definitions have to actually
provide use to someone if this effort is to be worthwhile.  On the other
hand, I think there's more agreement than meets the eye, at least more than
just "it's gotta have a URI."

I'll guess that there is rough agreement on the following constraints on
what WE mean by "Web service": [The stuff in brackets is commentary /
clarification, not proposed text for a definition.]  Please YELL if you
can't live with any of these points, and please suggest wording improvements
to clarify them.

1. A Web service is designed and deployed to provide information to or
perform some action on behalf of some software agent. [As opposed to a human
agent; it's got to be invokeable / understandable by conventional software
without necessarily involving AI or Semantic Web techniques.  Also, I've
been thinking that something like "designed and deployed" is needed to
distinguish a "Web service" from "screen scraping information meant for
humans"]

2. A Web service is a resource and has identity, thus can be uniquely
identified by a URI. [This is the minimal sense in which a service is a
"Web" service, IHMO. ]

3. A Web service MUST have its interface defined in a sufficiently explicit
and rigorous manner such that it can be invoked by a software agent without
human intervention.  [I'm not happy with the wording here, but I want to
accept the basic "IBM" position that some sort of "web services description
language" is necessary for something to be a Web service, but don't want to
restrict that language to WSDL .... it could be a BNF description of a legal
URL + the DTD/schema of the returned data, or some RDF-based
language/ontology, or perhaps even a SOAP message template.  I think we need
to work the hardest to find a consensus in this area.]

4. Software agents communicate with Web services using a standard protocol
that directly or indirectly uses URIs to identify the commuicating parties.
[ I'm not happy with this wording, but most definitions of "Web service" say
something about standard protocols ... but there are also clear use cases
where proprietary protocols are involved. I *think* this definition would
cover all uses of HTTP/FTP as well as SOAP on top of proprietary protocols
or -- the SOAP layer understands the URI, and the protocol binding maps that
into whatever the underlying protocol understands].

5. The Web Services Architecture constrains itself to those Web services
description languages and invocation protocols that employ XML.  [I would
like us to somehow say that *we* are focusing only on "XML Web services" but
don't wish to make the point that if it ain't got XML, it ain't a Web
service. Perhaps in deference to the RESTifarians and Roger's example of a
software agent retrieving a JPEG image identified by a URI, we could tweak
this to "protocols that employ URIs and XML".]

========================================================================

For reference, here are a couple of existing definitions

Classic: "A Web service is a software system identified by a URI, whose
public interfaces and bindings are defined and described using XML. Its
definition can be discovered by other software systems. These systems may
then interact with the Web service in a manner prescribed by its definition,
using XML based messages conveyed by internet protocols."

This fits the constraints mentioned here ... but doesn't mention my
constraint #1 that a Web service is designed to be used by a software agent,
and I think it's a bit fuzzy on the "formal description language"
constraint.
 
Eric's: "A Web service is an XML interface to an executable software agent
that is accessible using Web technologies.  A Web service has a description,
identified and published using a URI.  The agent has a network address, also
identified and published using a URI.  A Web service description defines the
set of one or more XML messages that can be sent to and/or received from a
Web service.   A Web service description may be discovered using a registry,
directory, or other mechanism that associates human readable keywords with
descriptions."

This seems a bit more stringent than my proposed constraints ... it doesn't
mention that a Web service can simply retrieve information as well as
invoking an executable software agent, and seems to require XML a bit more
explicitly than some might be comfortable with.

======================================================================

I'll make a concrete proposal, taking bits from both definitions and making
sure to cover all the constraints identified above:

"A Web service is a standardized interface to an information system or
executable software agent that is designed and deployed to be used by a
software agent without human intervention.  A Web service is identified by a
URI, and has a formal definition in a language that employs URI and XML. Its
definition can be discovered by other software systems. Software agents
interact with a Web service in the manner prescribed by the formal
definition, using XML based messages conveyed by standard protocols that
directly or indirectly use URIs to deliver messages between the agents."

Thoughts?

Received on Wednesday, 16 April 2003 09:19:41 UTC