Web services is a glamorous term for a very old and established idea. The core Web services technologies, SOAP and WSDL, allow developers to define new protocols. A protocol is nothing more than a way for computer programs to talk to each other over computer networks. As long as there have been networks there have been protocols. What makes Web services unique is that they're the first mainstream technologies, supported by all major vendors, intended to make the creation of new protocols so easy that ordinary business developers can do it.

Developers who, for instance, build a SOAP wrapper around their payroll systems may not think that they're building their own protocol, but in fact they are. Web service developers must decide how to group their logical objects into services. They must create some technique to correlate messages sent to the service with particular objects. They must choose which messages may be sent to which objects. For each message they must choose whether or not it should be sent in a manner that expects a reply. They must choose an XML representation for the message. These are the decisions that would usually be made by a so-called "application protocol" like SMTP (Simple Mail Transfer Protocol), FTP (File Transfer Protocol), or HTTP (HyperText Transfer Protocol).

I claim that there are two problems with this picture. First, making new protocols is still not easy enough for ordinary developers to do. Today's tools only make it seem easy by removing or hiding many options necessary to actually make these new protocols succeed. Second, making many new protocols isn't necessarily a good idea. Let's drill into each of these assertions in depth.

Visual Studio.NET is probably the most popular, widespread Web services creation toolkit. It seems to make Web service construction ridiculously easy. A developer takes an existing class, clicks a few buttons, and has a Web service. The developer doesn't need to learn anything about either XML or network programming.

The problem is that this technique obviates any advantages that Web services were to provide over DCOM and CORBA. In particular, Web services were supposed to more cleanly separate a service's interface from its implementation. This aspect of Web services, termed loose binding, requires a thorough understanding of XML. Loose binding allows your implementations to evolve while your public interface is static. In order to make Web services easy, the tool vendors ripped out its central benefit.

As if that isn't bad enough, the Web services specifications themselves had already ripped out one of the core values of the Web. The Web is first and foremost an environment in which any object (traditionally, but not necessarily, a Web page) can reference any other object. It was the first global information system through which any organization's data objects could reference and thereby incorporate data objects from any other organization. The Web performed this amazing feat by moving all information into a single namespace addressable through URLs (known to the intelligentsia as URIs). XML technologies have always built on this feature: XPointer, XLink, XInclude, and even XSLT are all organized around the concept of URLs. SOAP-based Web services are never in practice organized around URLs. Some use GUIDs. Some use numeric identifiers. Some use RPC parameters. There's no standardization as there is on the Web.

Even if we ignore this large problem, it's debatable whether scalable, robust, fault-tolerant Web service construction can be made as easy as clicking buttons on a dialog box. Networked applications must intrinsically deal with many issues that don't affect local programs: latency, race conditions, topology changes, network outages, obsolete client and server software, denial of service attacks, and so forth. The dialog boxes don't offer any strategies to deal with these problems. When today's Web services are deployed in the real world, I expect we'll find that ignoring these issues will have serious consequences for the reliability of our services.

Let's move on to the second problem. Does it make sense to encourage people to create all of these new protocols? Metcalfe's Law states that the value of a network grows by the square of the size of the network. So a network that is twice as large will be four times as valuable because there are four times as many things that can be done due to the larger number of interconnections. A network a hundred times as large is ten thousand times more valuable.

Consider how this applies to protocols. According to Metcalfe's Law, the open, public, SMTP-based e-mail system is thousands of times more valuable than even the most sophisticated proprietary e-mail system at even the largest company. This explains why today almost every corporate executive has e-mail whereas 10 years ago they would have left that unimportant chore to a secretary...if they bothered with it at all. It was the ability of anybody to talk to anybody that made e-mail so powerful. The same can be said for the Web and its popular HTTP protocol.

But SOAP isn't like SMTP or HTTP. If General Motors exposes a SOAP interface with one set of messages and Ford exposes a different SOAP interface with other messages, a supplier trying to integrate with both of them is only marginally better off than if one company had exposed a CORBA interface and one a COM interface. Mapping between their different method semantics is the tricky part. In any modern programming language the difference between calling a COM versus a CORBA method is trivial in comparison.

Corporations that use Web services technologies to invent new protocols are going to get very poor economies of scale and essentially no Metcalfe-value multiplier. Inventing new protocols should therefore be a last resort.

A small group of Web service developers has recently begun to promote a radically different strategy. We argue that protocols are essentially means of moving information around a network and coordinating processes based on that information. In this sense they're not unlike file systems and databases. Where file systems and databases are generic holders of heterogeneous data, protocols could be generic movers of such data.

We could stop making protocols optimized for particular types of data and particular problem domains and instead focus on protocols that can work with any kind of data in almost any application domain. Just as we don't have special file systems for image files, or special databases for customer addresses, we don't need different protocols when moving images instead of customer addresses. No matter what the content type, we could transfer representations of it between machines. This model is therefore called "REpresentational State Transfer," or REST.

File systems have a relatively simple, generic model: "read file", "write file", "delete file", "extend file". Databases do too: "SELECT", "INSERT", "UPDATE", "DELETE". In the protocol world the protocol that is most generic and has the best testing is HTTP. Its "GET", "PUT", "POST", and "DELETE" methods are quite analogous to the SQL and file system methods.

Consider how much HTTP infrastructure and knowledge is already out there. The software industry has spent the past five years selling people tools for working with HTTP. It's stable and has excellent reliability and scalability features, such as load balancing, failover, and transparent caching. The vendors, of course, want to convince you that you now need new tools because of the rise of Web services. But those tools will need years to catch up, and in fact may never catch up because, arguably, the SOAP Web services model itself makes tool development much more difficult.

Every resource exposed through HTTP (as opposed to SOAP) has a URI. That means that every resource can refer to every other resource. You can see how Metcalfe's Law applies. In a Web of REST Web services the notion of application just drops away and is replaced by the much finer-grained idea of "resource." There are no concrete boundaries between applications - there is just a "Web" of linked resources.

HTTP's very generic methods can work on any kind of data. In most cases this will be some XML vocabulary. This is also where incompatibility will inevitably creep back into the system. Going back to our analogies, storing Word documents on a common file system does not automatically make them compatible with WordPerfect, and using SQL does not automatically make a program designed for one database schema work with another. Similarly, programs expecting different XML vocabularies will not magically work together.

But just as there are filters for office file formats and views for relational databases, there are tools and techniques for mapping between XML vocabularies. XSLT is the most pervasive and famous, but we should also pay attention to the so-called Semantic Web technologies: the Resource Description Framework (RDF) and the Darpa Agent Markup Language (DAML). Another technique for managing XML interoperability issues is the standardization and sharing of schemas through registries, repositories, and standards bodies.

Even in the SOAP model, we'll need to fight incompatibility through transformations and XML vocabulary registries. REST just helps to take protocol interoperability issues out of the equation so we can focus on these pressing XML issues.

The existing Web protocol, HTTP, already makes the transfer and addressing of networked data as natural, standardized, and well understood as the storing of data in file systems and databases. It provides a more solid foundation for the future of Web services.

To learn more about how to build Web services with XML and HTTP, please see:

REST discussion wiki: http://internet.conveyor.com/RESTwiki

Published Jul. 31, 2002— Reads 8,577 — Feedback 1
Copyright © 2002 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.

About Paul Prescod
Paul Prescod, coauthor with Charles F. Goldfarb of the XML Handbook, worked with the W3C to develop the XML family of standards. A proponent of open source technologies, Paul is known for his implementation of systems using XML and the open source Python programming language. He also has experience in C, C++, and Java. Before founding Constant Revolution, Paul worked for ActiveState, the leading vendor of tools for open source programming languages.