Web Services Complexity

I’ve been meaning to write an entry about WS-Addressing and its submission to W3C. But because WS-Addressing is used by a bunch of other specs (WS-ReliableMessaging, WS-BPEL, WS-Notification, WS-Eventing, WS-AtomicTransactions, and WS-Coordination, to name a few), and addressing is a general requirement for many other specifications, it kind of brings up the whole issue of: Are there too many WS-* specs?
A good write-up on WS-Addressing can be found on Robin Cover’s pages, which includes several references to the list of WS-* specifications that require addressing and several explanations of addressing’s importance.
Simply put, if the addressing information isn’t contained in the message, it has to be contained in the transport. That’s the way things tend to work in existing distributed computing environments, but because Web services are designed to be transport-neutral, the addressing has to go inside the envelope.
A search today of Google news for Web services turned up some very interesting articles. I also think they are very closely related to the question raised by the addressing dependencies, although the topics are different.
First is Mike Gunderloy’s WS-JustSayNo in ADT Mag, which references Tim Bray’s blog about how “bloated, opaque, and insanely complex” the Web services stack is getting. Mike generally agrees, and advises developers to worry only about the specs of immediate need. It’s just too much to track all the WS-* specs now.
It is really hard. I’ve just had to plow through the stack for the new book I’m writing with Greg Lomow, Understanding SOA with Web Services. Almost half the book is tutorials on new WS-* specs important to SOA.
The second article is by my old pal and VB guru Jeff Webb. I really should send him an email and see how he’s doing. Anyway, it’s actually an entry in his new blog at O’Reilly about using REST instead of SOAP. (If I email Jeff maybe I’ll mention that REST and SOAP aren’t directly comparable, since one’s an architecture and the other’s a spec, but I think we all know what he means.)
At the end of the blog entry, Jeff wonders why Microsoft doesn’t show REST examples for VB developers. Using the REST based alternative services from Amazon.com (in other words, plain XML over HTTP, without the SOAP envelope) he shows how easy it is to develop and modify VB code to use the Amazon.com services. Much easier to deal with than all the generated proxy code you get when you use SOAP…
Although this interview with Jeff Barr of Amazon was done about a year ago, it includes discussion about the REST vs SOAP debate. Jeff basically said that he thinks Web developers prefer the REST style since it’s simplere, they’re used to working with browsers, and they can work more comfortably with the plain XML. On the other hand, he feels that SOAP appeals more to program developers used to working with compiled languages since the SOAP format provides more structure and formal data typing. At the time of the interview, about 80% of their traffic was REST.
Maybe Jeff Webb’s article shows that even program developers prefer the “plain XML” approach for its simplicity. Maybe even basic SOAP is too complex. Maybe all the WS-* specifications are making SOAP way too complex to deal with. How do we really know where to draw the line between a necessary spec and something that tips the complexity balance the wrong way?
With a bit of focus on the most important features for an SOA, however, it was not hard to identify a reasonable subset of the WS-* specs to worry about. I boiled it down to: security, reliability, transactions, metadata (including policy), and orchestration. Greg and I define a “Web services platform” for SOA that is primarily based on WS-* specifications. The SOA context provides at least one way to rule specs in or out, but then you are into enterprise architectures, integration projects, multi-channel access, automated business process management, etc.
Maybe it’s just a case of using the simple format to do simple things and a complex format to do complex things?

Advertisements

3 responses to “Web Services Complexity

  1. Simple and Complex

    Very nice post from Eric: Maybe it’s just a case of using the simple format to do simple things and a complex format to do complex things? Exactly. This is what I ment by my ‘do you neet it?’ question in this post….

  2. Simple and Complex

    Very nice post from Eric: Maybe it’s just a case of using the simple format to do simple things and a complex format to do complex things? Exactly. This is what I ment by my ‘do you need it?’ question in this post….

  3. WS Complexity

    The WS Stack has a variable geometry constantly taking on a different shape, with different architectural properties.