ACM News Service

“W3C Workshop on Constraints and Capabilities to Explore Next Web Services Layer”
XMLMania.com (10/12/04)

World Wide Web Consortium (W3C) members are working on a Web services constraints and capabilities framework that will allow organizations to communicate the terms of their service. Requirements for using HTTP or the ability to support GZIP compression, for example, need to be communicated in a standard manner using the Web Services Description Language (WSDL 2.0) specification, SOAP, or HTTP. W3C director Tim Berners-Lee said more standards were needed to support automated Web services. Participants at a two-day W3C workshop on Web services constraints and capabilities were required to write a position paper stating how they would preferably communicate constraints and capabilities in regards to reliable messaging protocol requirements, encryption using WS-Security or other security mechanisms, and an attached P3P privacy policy. Besides discussing how best to implement such constraints and capabilities requests and what vocabularies to use, the workshop participants also discussed their framework’s impact on and relation to other W3C protocols and Web technologies. Upcoming W3C recommendations include WSDL 2.0, which is currently in the “last call” stage and will be extended by the constraints and capabilities framework. SOAP 1.2 is also nearing completion, having advanced to candidate recommendation status in August 2004.

Mark Nottingham wrote:

From the standpoint of interface semantics, the difference here is really just one between saying “POST machineMgmtFormat” and “MANAGEMACHINE.” In the uniform approach, the service-specific semantics are pushed down into the type (media type) and content (entity body) of the data. In the specific approach, they’re surfaced in the interface itself.

This isn’t a big difference… While there isn’t much technical difference between these approaches, there’s a big gap in how people can use them. In HTTP, creating new methods is expensive, while creating new URIs is very, very cheap. OTOH, Web services makes creating new methods cheap, while making the creation of new URIs expensive. This is not because either approach is technically limited; it’s due to the design of both the specifications — like WSDL — and the toolkits that people use.

Bill de hÓra adds:

While HTTP does allow for addition, practically speaking, the verb set is fixed. It has taken years for WebDAV additions to HTTP* to penetrate more than a fraction of the Web. Other efforts, such as HTTPR, an extension for reliable messaging, have gone nowhere. Even within the mandated verb set of HTTP itself, we find the availibility of verbs varies widely (notably PUT and DELETE) with entire eco-systems (such as mobile device clients) having only a subset. One can argue that the active verb set of HTTP comprises a subset of 3 verbs – HEAD, GET, POST – anything else is dead tongue.

The problem with HTTP POST, and what makes it special, is that it is a semantic catchall. What makes POST a uniform speech act is ironically the absence of interesting semantics and lack of specificity. Although it has specifications that are helpful to people when dealing with caches and state management, there’s no controlled means of defining what one is actually saying with it, without some further and prior agreement between client and server. The reality is that POST has been overloaded and abused to get systems talking even where such systems would have done better with an alternate verb – and the result is that in many systems the POST speech act is close to meaningless. WS-Transfer aims to throw some light into this void by providing a means to add consistent meaning to operations that would often be drilled through POST. In particular this may prove valuable for use with web services toolkits which are often designed to hide the networking aspect of communications from the developer.

…

Systems are being built, week in, week out, than cross the Web/Middleware boundary without being informed by both approaches and where they are approriate. This implies projects with excess risks and costs, wasted effort, re-learning of best practices or what is already in the state of the art. This is all the more important now that systems that incorporate web and middleware aspects are increasingly the norm (the size of the industry sector affected is significant).

At CommerceNet Labs we have a team of people who jump back and forth between the Web and middleware worlds regularly, and none of us find ourselves enthusiastic about WS-Transfer. I’m trying to figure out why that is. Perhaps it’s Mark Nottingham’s Web services has no architecture observation.

Perhaps it’s the potential for verb proliferation getting out of hand. Perhaps it’s just general WS-* malaise. Or perhaps it’s the feeling that this protocol feels more complicated than HTTP for most applications that come to mind. Services shouldn’t have to be complicated, right?

Phil Windley writes:

Dave Sifry gives some details about the Technorati outage this past weekend. Seems an electrical fire in the data center their co-lo at was the culprit. Running a 24/7 Web application reliably isn’t easy and it isn’t cheap. It took us several years of problems and study to hit on a solution at iMALL. We finally did figure it out and that was a real lightening of my load. One of the answers is product engineers, an engineer on the operations side whose job it is to make the product (not just the server) work. Properly incented, a product engineer will drive all of the emergency and contingency planning, along with ensuring that engineering delivers a system that can be reliably operated.

This just serves as a reminder that it’s still hard (and costly) to run a web service reliably.

Via Mike Dierken we found this wonderful tidbit from Adam Bosworth stating

I have a posted comment about just using XML over HTTP. Yes. I’m trying, right now to figure out if there is any real justification for the WS-* standards and even SOAP in the face of the complexity when XML over HTTP works so well. Reliable messaging would be such a justification, but it isn’t there. Eventing might be such a justification, but it isn’t there either and both specs are tied up in others in a sort of spec spaghetti. So, I’m kind of a skeptic of the value apart from the toolkits. They do deliver some value, (get a WSDL, instant code to talk to service), but what I’m really thinking about is whether there can’t be a much simpler kindler way to do this.

Amen. Stick a fork in WS-*, because as Simon says, Web Services are receding:

Web Services are on their way to a CORBA-like market: sort of interoperable, vendor-ridden, and critically important to a small number of people. If that’s the case, then maybe the rest of us can return to vanilla XML HTTP, sometimes known as REST.

Ah, how we all pine for a simpler time, before WS-* made everything feel so much more complicated than Web applications should feel… since I don’t have anything more constructive to say, we’ll pile on with some beautiful words from Sean McGrath:

The whole WS standards thing has more moving parts than a 747. Much of it recently invented, untested and unproven in the real world.

Given that there are no exceptions to Gall’s Law:

A complex system that works is invariably found to have evolved from a simple system that worked.

I believe WS-YouMustBeJoking is doomed to collapse under its own weight. Good riddance to it.

Why has this situation come about? Because smart people had neural spasms? No. Because smart people realise that this stuff is *real* important and commercial agendas are at work all over the map.

The most important document to read if you want to understand the WS-IfThisIsProgressImAMonkeysUncle cacophony is How to wage and win a standards war by Carl Shapiro and Hal Varian.

That felt so satisfying to read, I’m going out back for a cigarette… ;)

For more wonderful backlash, see also Tim Bray’s The Loyal WS-Opposition:

No matter how hard I try, I still think the WS-* stack is bloated, opaque, and insanely complex. I think it’s going to be hard to understand, hard to implement, hard to interoperate, and hard to secure.

I look at Google and Amazon and EBay and Salesforce and see them doing tens of millions of transactions a day involving pumping XML back and forth over HTTP, and I can’t help noticing that they don’t seem to need much WS-apparatus.

I’m deeply suspicious of “standards” built by committees in advance of industry experience, and I’m deeply suspicious of Microsoft and IBM, and I’m deeply suspicious of multiple layers of abstraction that try to get between me and the messages full of angle-bracketed text that I push around to get work done.

This led to WS-PageCount, with a followup and a reference to WS-Halloween.

For more backlash, see also Mike Gunderloy’s WS-JustSayNo. (which quoth, “One of the powerful concepts in Extreme Programming is YAGNI, which stands for You Aren’t Gonna Need It. The idea is simple: implement things when you need them, not when you think you might need them in the future. As far as I’m concerned, this applies to most Web services experiments today.”)

For a more even-tempered approach, see Phil Wainewright’s WS-LooseCoupling.

And for those optimistic folks who still believe in the Web Services stack and/or want to know how all the pieces fit together and lead to Nirvana, see Microsoft’s just-released An Introduction to the Web Services Architecture.