Radical computing thoughts: Data impedance & automatous computing
Sat, 27 Oct 2001 13:45:58 -0700
> (1) Most of the text in "real" computer programs, accounting
> for a disproportionate number of bugs, and a hugely
> disproportionate expense in maintenance and understandability,
> is the code that does nothing except move data between internal
> variables and external representations.
In my experience, I've noticed much more time-spent-on and bugs-found-in
failure-handling code than in anything else. This isn't a particular
"component", as it's pervasive, but it's code whose importance and
complexity is consistently underestimated.
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.
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)? I haven't seen anything even that distinguishes between fatal
errors (service no longer exists); retry errors (resource is busy);
correctable errors (invalid parameter); or warnings (your service-payment
balance is low). (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 (!), but there is likely some core set that would have meaning to
many types of applications.)
Or is this just another one of the litany of problems limiting true
interoperability and/or discoverability?