Radical computing thoughts: Data impedance & automatous computing
Sat, 27 Oct 2001 20:46:07 -0400 (EDT)
> Which makes me wonder why there's not more attention paid to this in the
> standards that are being developed for web services. For example, I expected
> that the service-description language (WSDL) might have some facility for
> this, yet I didn't see anything.
My guess is that the Web Services camp is implicitly buying the
worse-is-better* argument, where the called program makes little
attempt to return the operation to its state before failure, instead
simply sending an error code (which code usually dereferences to "foo
failed", as Russell noted) and leaving it to the calling program to
deal with it.
more at http://www.dreamsongs.com/WorseIsBetter.html]
Whether this is The Right Answer or not is obviously the subject of,
well, gee, I guess we can't really call it a Holy War anymore, so say
its a Heated Discussion.
> Is every error returned by a web service to be considered fatal? Is
> every error semantic-free, and therefore handled only by the
> end-user (by reading some text)?
Its funny, I thought I'd think of a place where this has been
discussed in the literature, but maybe it's so obvious that it has
slipped treatment, but despite all the advantages of environments with
low coordination costs, one of the disadvantages is low coordination.
What you describe here is the standard Unix-y method of handling
errors, and with only the inclusion of a few standard error codes, it
describes the Web version as well. (I wonder if there are any articles
treating the design decisions not to include a Web-y version of
> (Let alone a standard for errors such as out-of-memory; timeout; bad
> value in argument; item not found; etc. This would have to be
> extendable (!), ...
This is usually where Mark Baker, the Erol Flynn of Representational
State Transfer, swings in on a rope, sabre flashing, to smite
pro-extensibility arguments with a crushing blow, but since he's busy
working on his URN costume, I'll step in.
Extensibility is part of the problem here, not the solution. By
allowing every remote program to define its own error codes, you
reduce (Mark would say eviscerate) the possibility of real
caller-doesn't-care-about-the-callee and callee-doesn't-care-
If, in some best of all world's internet, there was a well-defined
list of error codes that was both clear and easy to implement, like
http return codes on steroids, the next best thing would probably be
no error codes, because at least there there would be no expecation
that the other party would handle things, and less would fall through
Worst of all is a world where you think that by defining things
carefully, the world will adopt your definitions. This way madness
(and much that is wrong with the BigCo version of Web Services) lies.
> Or is this just another one of the litany of problems limiting true
> interoperability and/or discoverability?
Yes, but not a trivial one.