Caveats for Web-friendly service description

Greetings,

First off, I have to say that I'm very encouraged to see this interest
in Web-friendly service description, and in particular, the involvement
of so many Web services proponents.  We've come a long way these past
few years!

I've been known to say in the past, that a service description language
is counter to Web architecture, so I want to expand on that claim a
little, since I don't mean to be interpreted as saying that there isn't
any value in the work being discussed here.

What I mean by that claim is that I believe that doing this work in a
manner consistent with REST and Web architecture means avoiding some
common practices.  I'll use an example to illustrate...

Both WDL and WADL (and perhaps others, I just happened to notice these
two did it) declare the list of possible response codes that a service
returns, ala;

WDL: <wdl:output code="400 403 503" ref="yahoosrch:Error"/>

WADL: <wadl:fault name="searchError" status="400 403 503"/>

I don't think that's a very good idea, because if those descriptions are
used to generate client code, then that code will be inconsistent with
the HTTP spec since it says;

  "applications MUST understand the class of any status code, as
   indicated by the first digit, and treat any unrecognized response as
   being equivalent to the x00 status code of that class"
    -- http://www.zvon.org/tmRFC/RFC2616/Output/chapter6.html#sub1

(Alternately, if those status codes aren't used to generate code, then
what are they used for?  That's why I believe they should go.)

The general point here, is, I believe, not that we have to be careful
with violating any specs (though of course that's still important), but
instead that we avoid, for the cases where code will be generated,
describing things which may change in the foreseeable future.  The
reason is simply that we should be aiming for loose coupling, and having
a change in a service (e.g. new response code) require a change in a
client works directly against that.

Another example of this is the use, in most of the description specs
I've seen, of XML schema.  For the same reason as above, I generally
think it's a bad idea to describe the data produced using a schema
since schemas generally (DaveO's excellent extensibility advice
notwithstanding) change foreseeably over time, and I don't want a change
in the schema produced by a service breaking clients if I can help it.
Instead, I'm more a fan of simply using a media type as a name for an
open-ended sequence of backwards-compatible schemas (think "text/html"
vs. HTML 2.0, 3.2, 4.01, etc..), as well as, of course, associating an
extensible processing model to that media type to accomodate as many
unanticipated extensions as possible over time.

So what does such advice mean to a description language?  IMO, it means
that we should be designing a forms language, not what is typically
known to be a "service description language".  A forms language is
processed entirely at runtime, and declares state transitions, possibly
parameterized, of an application.  RDF Forms is a forms language.  WRDL
is another.  WSDL 2.0 has some form features, but is predominantly for
service description.

It would be good to see some other views of what it is exactly that
we're trying to accomplish here, i.e. what aspects of a service should
a standard description language describe or not describe?

Cheers,

Mark.
-- 
Mark Baker.  Ottawa, Ontario, CANADA.          http://www.markbaker.ca
Coactus; Web-inspired integration strategies   http://www.coactus.com

Received on Wednesday, 1 June 2005 02:23:16 UTC