Monthly Archives: September 2004

More on WS-* Complexity

Poking around the Web today I noticed a few more posts on the subject of Web services complexity. A pretty good summary is available here.
Like Mike Champion, I am a veteran of many, many REST vs SOAP debates at the Web Services Architecture WG (check the public email archives and you will see all every argument ever made ;-). The trouble with many of the arguments, as Geoff Arnold points out so eloquently here is that the REST folks (and ok, maybe my friend Mark Baker is on the extreme here, but I’m not sure they aren’t all zealots) seem to believe that everything else is wrong.
As I tried to point out in my previous blog entry on this topic, I pretty much agree with Mike that it’s a case of finding the right tool for the right job. But as I also pointed out, said last year that 20% of their developers use SOAP. This is exactly the kind of information you won’t hear from the REST folks since they don’t like to acknowledge the possibility that other valid solutions exist.
One funny thing about this kind of noise starting again (or maybe it just never went away, maybe it was me that wasn’t paying attention for a while), is that a new study is just out saying that the Web services market is exploding. The projection is $950M in 2004 and $6.2B by 2008.
Granted, the article doesn’t say much about the basis for the study, but it does characterize the market as being appropriate for “unified corporate portals” and helping solve the enterprise integration problem. Those of us who work in the enterprise software field know that the enterprise integration problem remains among the CIO’s top concerns (it is often cited as the top). Web services, and SOAs based upon them, have tremendous potential for addressing this problem, and therefore are of tremendous significance, at least for the world’s IT systems.
Simon St. Laurent’s blog provides a good perspective on the whole “XML vs SOAP” debate, albeit acknowledging he has no interest in enterprise software issues. I would point out though that CORBA has succeeded in exactly the place where Web services are trying to get – as an enterprise integration technology, and an enabler of SOA. Most of the world’s largest SOAs today are implemented using CORBA. So CORBA is not a bad comparison.
Among other things, though, Simon points out a blog by Nelson Minor on the topic of doc-literal Web services. Most of the time, the REST folks who raised all the fuss at the W3C preferred to contrast REST to the rpc-oriented Web services style.
Some of us have been saying for years now that Web services aren’t very good RPC technologies. In a recent blog entry I mentioned that using doc literal is probably the best way to use Web services. In his blog, another former WSA veteran, Chris Ferris, said that he agreed.
Typically the REST folks don’t like to hear things like this from Web services advocates, either, since it also tends to undermine their arguments. They also don’t like to consider a mixed world in which the REST approach may have its place for simple interactions and Web services may be needed for more complex transactions.
Personally, I like the idea of using XML over HTTP for everything, but I don’t think it’s practical. Too many other transports are already in use — you can’t just rip everything out and replace it all with XML/HTTP equivalents. (Although from a certain perspective, it appears this is what’s happening with the WS-* specs, it isn’t. The WS-* specs are defining features that primarily map to existing execution environments rather than replace them.)
I also agree that the whole WS-* thing is getting out of hand. My interpretation of the new WS-Transfer and WS-Enumeration specs is that they are intended to provide XML/Web services equivalents for the .NET (previously Windows DNA) concepts of ADO record sets (ok, so we now also have JDO for the Java world). And maybe this is necessary because IBM et. al are taking Web services off toward the Grid with the Web Services Resource Framework set of specs, and not everyone is interested in the Grid (or it’s too much of an IBM thing). But the problem with the WS-* specs isn’t a technological problem, despite some REST folks wishing it were. It is a vendor politics issue, and it simply needs independent leadership.
Referring again to CORBA, one of the reasons for its success as enterprise computing infrastructure (and granted this is an historical success, but nonetheless one any standards-based technology can aspire to – and of course it’s also worth pointing out the J2EE dependency upon CORBA) was that it had an architecture, (pretty) clearly defined and administered by OMG. The WS-* community badly needs an independent body (like OMG was for CORBA vendors) to determine whether specs like the WSRF or Transfer/Enumeration are relevant and appropriate to include.
With all due respect to Don, Chris, and Felipe, who have written a very good document on Web Services Architecture, the responsibility for defining the Web Services Architecture is not a single vendor’s. I realize that I spent almost two years in a failed attempt to help get W3C become that place and write that spec. I also realize that many of the REST advocates felt that it was an appropriate failure.
By the way, does anyone know of a recent REST market study? That might help clarify the debate somewhat.

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 (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 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?

Description First

Recent blog entries from Don Box and Aaron Skonnard ask the question about contract-first development for Web services.
This is not a new concept, of course. CORBA was designed around the concept of an interface language separated from its implementation. Before that, DCE included an interface language, as did COM. And even before all of that, ACMS from Digital included an interface language, as did the Structured Transaction Definition Language specification based upon it.
In Web services this idea has been somewhat controversial, since SOAP was defined before WSDL, and is often used without WSDL in practice. Also, we have the REST crowd who argues that XML over HTTP is sufficient for everything.
The big deal in all of this is transport independence. But what does that really mean? Allowing SOAP messages to flow over multiple transports? Or the ability to send the same SOAP message over multiple different transports?
I think we also have to be careful about this. It’s easy to think about the contract as simply the next evolution of ACMS, DCE, DCOM, and CORBA. But it isn’t. It’s important to consider the purpose of the contract. For Web services, the purpose is to share data over the network. Therefore the Schema is more correctly viewed as the contract, not the WSDL, although the WSDL can be (and usually is) built up from the Schema.
Meaning it’s not the signature of the program or object that’s important for the contract. It’s the definition of the data to be transported. The big idea about WSDL that makes it different from the previous interface languages is that it clearly separates the data definition from the transport definition. The same message can be sent over different transports – the same service can be available over multiple transports.
Anyone wanting to try this out can download Artix for free.
ps Can someone tell me why BizTalk doesn’t support WSDL?