RE: Plan B: fundamental contraints and scope

Here is a first pass at putting together the constraints and
examples servics. It tries to avoid the "what is a WS" discussion
and just lay out definitions and conformance statements.

Do these constraints make sense? I know I am not happy with
a few of them.

Is the analysis useful?

If so, I think we should concentrate on getting these details
understand and agreed upon. Then we can take up the "what is"
discussion again.


DaveH

-----Original Message-----
From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com]
Sent: Friday, April 18, 2003 4: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?