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