W3C home > Mailing lists > Public > www-ws-arch@w3.org > April 2003

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

From: Walden Mathews <waldenm@optonline.net>
Date: Wed, 16 Apr 2003 17:36:47 -0400
To: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>, www-ws-arch@w3.org
Message-id: <000401c30460$494a8d60$1702a8c0@WorkGroup>

Mike,

I would resist the temptation to define a service as an interface,
because I think the default understanding is that services *have*
interfaces, not that they *are* interfaces.  A small change on the
surface...

I would also like to see the "designed to be used by another
software agent" language firmed up, because regular HTML web
pages fit that description, and I know that's not what you had
in mind.

On the question about "formal vs machine processable", does
"formal" imply "any regular grammar"?  Would "machine processable"
include natural language?  Is there a way to get more precise?

I think you might have to work harder to get an entry level
definition of Web services that includes REST-based applications.
For one thing, the web server per se doesn't match as the service
provider in that model.  For another, there's language about
formal definition of the service; there's no such constraint in
REST.

Sorry that I'm not proposing alternate text; I'm not up to it
in these cases.

Walden

----- Original Message -----
From: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>
To: <www-ws-arch@w3.org>
Sent: Wednesday, April 16, 2003 4:15 PM
Subject: 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 17:37:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:17 GMT