Middleware Matters

Bill de hÓra makes some good points, as do Tim Bray and others: the web services specs are somewhat out of hand.

I think one reason we have so many web services specs is that we have a terminology problem, specifically with the term "web service." If you're really talking about services that are programmatically accessed over the WWW without human intervention using standard Internet protocols, then everything written about REST and HTTP and XML and messages definitely applies. I was a charter member of the now-defunct W3C Web Services Architecture Working Group (WSAWG), and the first thing we set out to do was to define what a "web service" is. Something close to the definition above was in fact one of the first candidates. After two or three months of arguing, we finally settled on something along those lines, only to have the whole question reopened several months later. Not being able to exactly define a "web service" was what doomed the WSAWG to ineffectiveness and eventual extinction. I mean, how can you define an architecture for something unless you know what it is? Different WSAWG members had very different ideas of what a "web service" was, and those different ideas often conflicted with each other, preventing any real progress.

Like it or not, however, the term "web service" is often used to apply to things that don't fall precisely under the definition above. Most of the people I encounter in my circles, for example, use "web services" to describe intra-enterprise business services that can be accessed over a variety of protocols. These services are not and will never be offered over the WWW. They're not necessarily RESTish. They don't need to scale to web scale, and never will. Some are stateful, some are not. They might in fact be steaming piles of poorly designed and poorly written code, and in fact are often built on what many purists might consider to be obsolete technologies. Regardless, what's most important about them is that they work, and so these businesses want to make them even more valuable by making them much more accessible within their businesses. They're happy to describe these services in WSDL, since that helps them abstract the services, but they don't want to have to redesign them or rewrite them or change their protocols or adopt new unproven approaches just so they can ensure that the services conform to some purist's view of what's a "real web service."

The end result of this terminology issue? Lots of people argue endlessly about web services, and they write myriad specs for web services features, but they're often neither arguing about nor writing about the same thing. Not even close.

So what do you call these services? The term "service" is too generic. "Business service" and "computing service" are no better. For better or worse, "web service" is currently the best term to use for them, especially given that (at least in my circles) they all have WSDL definitions, and WSDL includes the word "web." Perhaps WSDL should just be called SDL. I take issue with the purists who say that a "web service" is defined as a SOAP-based service, nothing more, nothing less. It's like saying that a Domino's pizza shop shall only take verbal orders over the phone, and if it accepts orders via a website or by fax or from a person who physically walks into a shop and verbally speaks their order to an employee, then it's not a Domino's pizza shop. Obviously such a restrictive definition is pointless, because what customers ultimately want is the service that Dominos provides, regardless of how they request it. Similarly, what ultimately matters with a "web service" is the "service" part, not the "web" part.

So, I'm afraid that we're stuck with the numerous web services specs, at least for awhile, because "web services" has become such an umbrella term. Some of those specs will prove to be useful in practice, others won't. Like many others, I also take issue with many of those specs, but in the end, the market will naturally cull the herd.