Web Services -- A Bridge Too Far?

dge While the basic concept of "Web Services" is straightforward enough the underlying complexities can be rather overwhelming. Just mastering the acronyms and understanding all of the protocols involved, as listed here at the CBDI Forum, can be a major job in iteslf.

Except for the most simplistic of services, there's the need for a rash ofother capabilities: reliability/robustness, availability, consistency, recoverability, bulletproof security, and more.

Consequenly a raft of definitions and standards for Web Services has arisen, and more continue to arise. Unfortunately, some of them have been "competing standards" (depending largely on whatever parties were promoting their differing points of view).

At what point are the standards and definitions for Web Services "good enough"?

Over at the webservices.org site Robert Houben has been writing about his philosophy "best characterized by the following mantra: Make the common task easy, but always enable the complex task."

Take a look at Robert's articles, about whan standards go wrong, why we need more simplicity, an dhis conclusion from applying the Pareto Principle (the 80/20 rule) to come up with a sufficient set of requirements most companies will need in Web Services integration products:

• Making the Common Thing Easy – Part I


• Making the Common Thing Easy – Part II

It's all too hard, a KISS would be nice!

This weblog, doubtless one of tens of thousands of new blogs launched today (25th April 2006 -- ANZAC Day here in Australia), is devoted specifically to things that are "good enough" for effective use in their current form or incarnation.

It will mainly be concerned with software, but may from time to time divert to other things where so-called "feature bloat" and overcomplexity cause otherwise good things to be too hard to understand and use efficiently.

Sometimes I'll link to other weblogs or web sites, at other times I'll inflict my own comments and observations upon you.

- - - - - - - -
To kick off, here's a link to Adam Bosworth's excellent blog post where he talks about the "eternal tension between that part of humanity which celebrates our diversity, imperfectability, and faults, as part of the rich tapestry of the human condition and that part which seeks to perfect itself, to control, to build complex codes and rules for conduct which if zealously adhered to, guarantee an orderly process." And he goes on:

"It is an ironic truth that those who seek to create systems which most assume the perfectibility of humans end up building the systems which are most soul destroying and most rigid, systems that rot from within until like great creaking rotten oak trees they collapse on top of themselves leaving a sour smell and decay. We saw it happen in 1989 with the astonishing fall of the USSR. Conversely, those systems which best take into account the complex, frail, brilliance of human nature and build in flexibility, checks and balances, and tolerance tend to survive beyond all hopes.

So it goes with software. That software which is flexible, simple, sloppy, tolerant, and altogether forgiving of human foibles and weaknesses turns out to be actually the most steel cored, able to survive and grow while that software which is demanding, abstract, rich but systematized, turns out to collapse in on itself in a slow and grim implosion."

Adam follows this with quite a few examples, and I strongly encourage to read the entire article.