Nailing down the definition of "Web services" and the scope of WS A for the document

The chairs, editors, and team contacts have spent a couple hours today
discussing how to incorporate the good ideas that have come up while we
splashed around in the "what is a Web service" trout pond ... without
getting bogged down in the mud.  Here is my understanding of the consensus,
for discussion by the larger group.  The over-riding intention is to push
the WSA document ahead as efficiently as possible.

First, it probably makes sense to distinguish the generic term "Web service"
from the definition of the scope of the WSA.  To pick up a point that Assaf
made: "How would you define the first few services put in place before there

was reason to exchange WSDL definitions?"  We want to be able to say that a
relatively broad set of things can be considered "Web services" but that the
WSA is going to focus on a more restrictive set.

Here's a proposed defintion of the more general term:
"A Web service is an interface to an executable software agent that is
designed to be used by another software agent.  A Web service is identified
by a URI, and has a definition in a language sufficient to describe the
interface to developers of client agents. A software agent interacts with a
Web service in the manner prescribed by the formal definition, using
standard protocols."

A couple of clarifications:  first, this doesn't exclude RESTful,
information-exchange services; the "executable software agent" could be an
HTTP server.  Second, note the phrase "designed to be used by another
software agent."  We don't want to accept "screen-scraping" as even a
generic Web service technology; ANYTHING is a Web service under such a
defintion.

I (we?) think that this generic definition includes most of what reasonable
people would consider to be Web services without being uselessly broad.  On
the other hand, it's still probably too broad to be the scope of the WSA
effort -- it doesn't require SOAP, WSDL, or even XML. Let's define a more
restrictive subset, which we'll call "XML Web services" [or perhaps
"WSA-compliant Web services, although the word "compliant" stocks a trout
pond or two], upon which the WSA will focus:

"An XML Web service is an interface to an executable software agent that is
designed to be used by another software agent.  An XML Web service is
identified by a URI, and [CAN | MUST] have a formal definition in a language
that employs URI and XML. WSDL 1.2 is the "reference" specification for an
XML-based description language, but others are possible.  A software agent
interacts with an  Web service in the manner prescribed by the formal
definition, using XML based messages conveyed by standard protocols. SOAP
1.2 is the "reference" specification for an XML-based web service protocol,
and the higher layers of the WSA model will assume that it or an equivalent
protocol  are employed."  

One clarification: I stuck in the references to SOAP and WSDL after the
discussions with the other editors, and would be glad to remove them ... but
I do think we need to make some reference to the centrality of SOAP and WSDL
in the WSA. 

There is one issue that the editors did not come to consensus on, and for
which we need input from the entire WG:  Is it sufficient to say that the
interface to an "XML Web service" CAN be described (or "is capable of being
described") using a formal description language, or is it better to say that
it MUST be described in a machine-processable description language?  

So, is this at least a good starting point for a consensus on how to define
"Web service" and "XML/WSA-compliant Web service" in the WSA document?  Who
on the WG can't live with it?  Who outside the WG wishes to strenuously
object? And what should the scope of the WSA require ...interfaces that CAN
be described in a machine-processable language or interfaces that MUST be
described in a machine-processable description language?  What other
wordsmithing would anyone propose?

Received on Wednesday, 16 April 2003 16:15:54 UTC