Pork Barrel Protocols

Everyone generally agrees that the goal of web services is to apply the traditional Web programming model, which is simple and interoperable, to problems other than delivering thin-client user-interfaces. For instance, you might want a traditional Visual Basic "thick-client" application to access data from a Solaris server. You could solve your problem with CORBA or maybe with Java RMI, but using HTTP would be easier, because it's a model everyone understands, and cheaper, because HTTP plumbing is already supported pretty much everywhere. All you need is a way to format the data you are sending back and forth, and XML fills the bill nicely. So you retool your Visual Basic client to send XML-based HTTP requests to the Solaris server, which handles them with a Java servlet. The servlet retrieves the data, turns it into XML, and returns the results. The Visual Basic application parses the returned XML, renders the data and lets the user manipulate it as they see fit.

This example illustrates the basic idea of a web service, but a more concrete definition is desirable. We define a "web service" as an endpoint for communication that

1. Uses standard high-level Internet communication protocols like HTTP or SMTP
2. Transfers data using XML messages
3. Describes its message types using a portable type system which is both language and platform neutral
4. Provides a way to access metadata describing the messages it accepts

Bearing in mind the goals of simplicity and interoperability -- the things that made the Web successful -- let's consider these requirements in order.

First, web services rely on standard Internet protocols like HTTP and SMTP because nearly every platform supports them and because the entire Internet infrastructure -- the proxy servers, routers, gateways and firewalls that make up the physical network -- is designed and configured to transport and accept these protocols.

Second, web services use XML-based messages because XML has industry-wide support and processing tools are inexpensive and ubiquitous. The SOAP specification defines a very widely endorsed format for these messages, and at least one alternative exists, XML-RPC.

Third, web services describe their message formats in terms of a language and platform neutral type system. This helps facilitate the definition of precise wire-level contracts between web services and their clients, which makes building robust interoperable distributed systems easier. XML schema (XSD) is an obvious choice for a type system, but there are some conflicts between XSD and portions of the SOAP specification that need to be resolved.

Fourth, web services provide some way to access metadata describing the messages they accept in terms of the type system mandated by the previous requirement. This allows consumers to write client code to access services. If the metadata is software-consumable, and it need not be, some type-safe client-side proxy code for invoking a web service may also be generated.

Note that our definition does not address the dynamic discovery of new web services, security, transaction models, or integration with object or workflow-based programming models. These topics have become very popular recently and vendors are racing to explain how their products will address them. However, we ignore these topics intentionally.

The way we see it, the web service idea is like an emergency relief bill passing through Congress or Parliament. After a natural disaster strikes, the government typically passes a bill authorizing measures to help the damaged community recover. The last ten years of fighting about operating systems, programming languages, distributed object technologies, and application server platforms have been, metaphorically, of course, like a natural disaster. Collectively, the developers of multi-vendor, multi-platform distributed systems certainly constitute a kind of conceptually damaged community in need of assistance. The web service idea, as we define it above, is a relief bill intended to help.

Relief bills are almost always voted into law: who is going to stand in the way of funding to rebuild homes, businesses, or distributed applications? Unfortunately, because they are almost always ratified, relief bills are an attractive target for lobbyists and special interest groups who want to alter clauses, adjust phrases, tack on riders and add amendments, some of which may have very little to do with the original legislation. This is happening to web services as we speak. What began as an attempt to leverage the simplicity and interoperability of the Web programming model to solve some basic problems in distributed systems has evolved into an attempt to reinvent our entire distributed computing infrastructure.

The result so far is a jumble of acronyms identifying a heap of proposals for proprietary, often competing, "standards" and protocols. For instance, Microsoft and IBM have both defined their own XML dialects for describing how to coordinate complex interactions between multiple web services, XLANG and Web Service Flow Language (WSFL), respectively. In principle, we are not against anyone attempting to solve complex distributed computing problems. If the proponents of these various efforts make progress and produce tools and technologies that make building distributed systems easier, more power to them. But if, in pursuing these goals, we sacrifice the simplicity and interoperability of the Web programming model -- the very thing web services attempt to leverage -- we'll end up spending a lot of time and money, only to end up where we started. We'll have proprietary solutions that cannot interoperate. Needless to say, we must avoid that.

Our very minimal, working definition of the term "web service" is an attempt to promote simplicity and interoperability, but it doesn't really go far enough. For example, we are not comfortable claiming that compliance with both the SOAP specification for message formatting and the W3C XML Schema specification for message typing is mandatory when there are some inconsistencies between them (i.e., SOAP section 5.) Going forward, the web service community will have to come to consensus on how to resolve this and many other issues so that the promise of interoperability at the messaging level -- the real benefit of web services -- can be widely realized.