RE: Plan B: What are the fundamental contraints on the services in-sc ope for WSA?

I like this approach.  I think it's useful.  Let me remind you, for the
purposes of this thread, of your earlier posting giving some interesting
examples of things that might or might not be WS's:

http://lists.w3.org/Archives/Public/www-ws-arch/2003Apr/0118.html



-----Original Message-----
From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com] 
Sent: Friday, April 18, 2003 5:03 PM
To: www-ws-arch@w3.org
Subject: Plan B: What are the fundamental contraints on the services
in-sc ope for WSA?



The chairs/team/editors had (naively?) hoped that we might be able to
get consensus on a definition of "Web services" (at least as the term is
used in the WSA document) this week.  That clearly hasn't happened, but
we had a "Plan B" that I'll propose to see if that gets us anyhere.

The idea is to pose a related, but different question: what are the
*characteristics* of the services that are in-scope for the WSA?   One
way
to go about this would be to pose a number of architectural scenarios
and ask for a sense of the WG as to whether each is in scope for WSA.
For example, consider this one [loosely adapted from an example that
Roger has
used]:

A website offers an image-processing service: consumers of the service
can POST an image in a variety of formats, specify (via HTTP parameters)
the operations to be be performed (choices would include resize, rotate,
contrast enhance, convert to another format, etc.) and the response
would be the processed image (or the URI of the image, gimme a break,
I'm just making this up!).  

OK, this is clearly a "service offered over the Web" ... we could
probably argue for days about whether it is a "Web service"  since there
is no XML, WSDL, or SOAP involved. The more useful question is "should
the W3C WS Architecture document, version 1.0, explicitly consider this
to be
in-scope?: Yes or No?"  We could look at a few such examples of corner
cases; in other words, we would start with examples, classify them as in
or out of scope, and then infer the rules or constraints implied by the
classifications.

Another way to go about it would be to start with the constraints
themselves.  For example, here's a strawman set of constraints on what
is
in-scope:

A service that is in-scope for the WSA: 

1.  ...  is designed and deployed to provide information to or perform
some action  at the request of a software agent without human
intervention

2.  ...  is a resource and has identity, thus can be uniquely identified
by a URI  

3 ... communicates with "client" agents via a standard protocol that
directly or indirectly uses the URI to direct messages to the service   

4. ... has a formal interface description that is [or can be on demand]
encoded in XML and has at least the descriptive power of WSDL

5. ... communicates using an extensible XML protocol with at least the
capabilities of SOAP 

The chairs' suggestion is for people to propose one or more constraints
like this with a paragraph or so of description for each ... and to
debate whether each is necessary for a service to be in-scope.

If we agreed on something like the list above, we could then just assume
that any in-scope service had a formal description and used XML ... thus
we could talk about properties and relationships and additional
constraints that flow from those features.  For example, when talking
about "visibility", we could say flatly and authoritatively about the
ability of intermediaries to use XML standards such as XPath to "look
inside" a message for routing, cacheing, filtering, etc. purposeds.  Or,
we could say flatly that a choreography feature extends the description
language to describe long-running, stateful interactions.

If on the other hand we can't agree to such constraints, then we'll have
to be much more vague and conditional .... "If on one hand the
invocation message does use XML, then intermediaries can use XPath to
look into it ... if on the other hand it uses HTTP, then intermediaries
can examine the HTTP headers ... if on the other hand it uses SOAP over
some proprietary transport protocol, the intermediaries can examine the
SOAP envelope ...." 

So, the more constraints we can agree to, the simpler and more rigorous
the WSA ... but of course the smaller the domain it applies to .... but
we can at least make this clear!  Can we kick off a discussion of one or
both of these approaches to coming up with language for the WSA document
that specifically describes what kinds of services it is intended to
cover?

Received on Monday, 21 April 2003 10:53:38 UTC