Simplicity and Complexity

According to Bob Balahan (3C-InterOp), web services are not there (yet). He argues that the interoperability promised by web services is currently frustrated by the behaviour of the leading vendors. Here is my attempt to summarize the argument (which starts in his blog and continues through several replies to my comments.)

1. Web service standards are incomplete, open to multiple interpretations and implementations. (This is a form of leaky abstraction.)
   
2. As soon as you want to do something complex, you are faced with inconsistencies ("subtle differences") between different vendors. (And not just different vendors. With large and complex software coming from large and complex vendor organizations, and with consolidation occurring (and likely to continue) among the platform vendors, it would be amazing if there weren't sometimes subtle differences even within a single platform from one vendor.)
3. Obviously there is an incentive for developers who care about interoperability to identify and avoid the areas of inconsistency wherever possible. Where there is a threshold of complexity above which the differences between (or even within) platforms start to bite, developers should strive to remain below this threshold (thus getting interoperability despite the differences in interpretation and implementation above the threshold). Bob calls these "lowest-common-denominator features", known to work reliably everywhere.
4. Karen Hobert adds that the standards themselves are subject to change . She doesn't say this, but this is perhaps especially true in the areas where these inconsistencies have been identified. So complexity doesn't just affect interoperability but also maintainability.
5. However, remaining below the complexity threshold would be hard enough for developers who hand-coded everything. But when you use the code generation tools, you are taken above the complexity threshold by default. Bob and Karen have a nice example of this, where WSAD generated complex objects into the XML.

Bob sees all this as vendor lock-in. They could agree, he says, but so far they haven't. Who creates this complexity? Who benefits from complexity? The vendors.

---

There is certainly a tendency for complexity to escalate, and the vendors don't do enough to contain complexity, or to protect their customers from the consequences of complexity. But the benefits of this complexity to the vendors is unclear.

And I think we must give the industry some credit for what it has achieved to date. The situation used to be a whole lot worse than it is today. There may be specific areas where the standards let you down - but that's better than having no interoperability at all. And the point of a good architecture is that it should allow you to contain and manage the complexity and uncertainty.

---

See also Lost In Translation: Top Ten Tips for Web Services Interoperability
See my note on Code Generation