RE: Some proposed definitions of "web service" based on the call toda y

The definition we come up with for Web services presumably will serve
two purposes:

1 - Because of the source, if it is at all reasonable it is likely to be
widely viewed and quoted as the authoritative statement of what a Web
service is.  At least, this would be nice.

2 - I think it defines the ENTIRE scope of the WG normative output.  We
were chartered to say something about Web services, not "other things".
I suppose we could recognize the existence of "other related things",
but I don't see how we could say anything normative about them, at least
directly.

Now, if I am reading this right it seems that the WG, or some portion of
it, has somehow gotten the idea of defining Web services in a way which
is specific not only to a spec, WSDL, but a version of it which does not
currently exist.  This would mean:

1 - There are no current implementations of Web services.  You cannot
assert compliance to a spec that is not yet defined.

2 - The architecture has nothing directly to say about all those "other
things" that are out there right now, including all implementations that
think they are Web services, ebXML, HTTP GET's without XML definitions
of the interfaces, services defined via RDF and so on.  I think that if
we wish to say something about these things that they have to be in
scope.  If someone working with "other things" wants to get some insight
from this architecture then that's their responsibility.

3 - When WSDL 1.2 is replaced by something else the architecture will
cease to apply.  Again, these will be "other things", and owners of
"other things" can try to figure out for themselves if there is an
application or, I suppose, the WG can be recalled.  The scope is limited
in time as well as limited currently to an empty set of implementations.

I personally would like to be able to say something about ebXML, HTTP
GET's, semantic description of interfaces and so on, even if it is at a
high level and subsequently the architecture focusses on a more
restricted domain.  I would like them to be in scope, and to be in scope
they have to be Web services.  Not only that, but I would like this
architecture to have a chance of providing guidance into some next
generation of Web services.  To do so, Web services that use specs other
than the current ones must be in scope.  They must be Web services.
Finally, this WG is enough for me.  I do not want to be recalled when a
version number, or spec name, changes -- and I would not want to wish
that on anyone else either.

I would like to think that we can do a lot better than this.  I think
that we have ALREADY done a LOT better than this and somehow have
diverged from a developing definition that was really looking extremely
useful.

-----Original Message-----
From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com] 
Sent: Thursday, April 17, 2003 4:36 PM
To: www-ws-arch@w3.org
Subject: Some proposed definitions of "web service" based on the call
toda y



Whew, that was fun :-(  Although it got better when we stumbled on the
"instant straw poll in IRC" idea; we should do that more often.  I'd say
that in general, anyone who has the "floor" in the speaker queue may
propose one of those by typing the question into IRC; those not on IRC
can ask to have their vote recorded by someone who is.

Let me throw out some proposals that reflect the various opinions I
heard today; without my co-chair hat on, I could live with either of
them:

========================================================================
===
The term "web service" is used in a wide variety of ways by different
people, and we will not presume that the definition used here is
consistent with all of them.  Nevertheless, for the purposes of this
document, we will use the term to mean the following: 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 MUST be [capable of being ?] formally defined in WSDL 1.2.  A
software agent interacts with an  Web service in the manner prescribed
by the formal definition, using the XML Infoset and processing model
defined by SOAP 1.2.

[Chris said some things about SOAP being general enough to describe any
reasonable "web service" interaction that I didn't capture very well ...
maybe he can refresh my memory.]

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

The term "web service" is used in a wide variety of ways by different
people, but there is a rough consensus along the following lines: 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 that is consistent with the
description, using standard protocols. 

That definition of "web service" is not sufficiently precise or rigorous
for architectural purposes, however.  We will use a more restrictive
term to describe the scope of the architecture described here:
"Extensible XML Web
Services", abbreviated XWS.   the purposes of this document, we will use
the
term to mean the following: An XWS is an interface to an executable
software agent that is designed to be used by another software agent.
An XWS is identified by a URI, and MUST be capable of being formally
defined in WSDL 1.2.  A software agent interacts with an  Web service in
the manner prescribed by the formal definition, using the XML Infoset
and processing model defined by SOAP 1.2."

["XWS" is essentially a placeholder for some term ... I don't care what
it is, but it must specifically describe the "MUST" constraints
specified by the WSA.]

========================================================================
==
Of course, improved definitions are solicited.

Received on Friday, 18 April 2003 09:10:57 UTC