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

I am a little nervous about Number 3, but maybe it's a matter of
interpretation.  You will recall that some of David Booth's scenarios
have the description of the WS interface being transferred via
"semantics", which can include things like telephone calls,
collaborative development, email and so on.  I think it is important
that the interface be well defined and stable, but I do not think that
it is necessary for it actually to have an XML description that can be
late bound.  I am willing to yell awfully hard to preserve early bound
scenarios, since they are very common in business applications.

Actually, I doubt that this was your intention, but I want to be careful
about this.

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