Web Services and the Eight Fallacies

by Mark Baker

A point that doesn't get emphasized enough in the REST/SOAP debates, is the nature of distributed computing on the Internet and how it is inherrently different than elsewhere, such as behind a firewall on a LAN, or within the confines of a single machine.

In Peter Deutsch's infamous seven (updated to eight by Gosling) fallacies of distributed computing, number six - there is one administrator - is the principle difference between Internet and LAN based distributed computing, and unfortunately, next to no Web services recognize this. They believe that what worked for the Intranet, will work for the Internet.

Having one administrator is roughly what you have behind a firewall, so it isn't technically a fallacy of all distributed computing, "just" distributed computing on the Internet. What it means is that there exists an out-of-band channel with which evolutionary aspects of the software can be managed. So tasks such as deploying new versions of interfaces can be coordinated with a phone call or an email, and the common understanding that you're working for the same organization so you have an obligation to work together (and if you don't feel that way, you should expect to receive a visit from your boss).

On the Internet, not only do parties not share a common administative domain, they don't, a priori, share any trust relationship whatsoever. So the only communication you can expect with a publisher of a service is through the interface to the service itself. This is a radically different design center than previous distributed architectures such as the OMA have used.

The principle implication of this to Web services, is that on the Internet, practically all forms of distributed computing are coordination problems, requiring that a coordination language be defined that can be used to implement the types of tasks that the parties involved want/need to have implemented. Some of these languages are very specific in scope, whereas others are very general.

In my view, HTTP defines the single most general coordination language ever developed (GET/POST), and while not suitable for absolutely all tasks (like a telnet replacement, for example), it is sufficient for very many, including everything that I've seen Web services used for.


2002-11-02 08:05:05
Coordination and Interface Versioning
The alternate way to look at this is that it is a problem of interface versioning.

One of the usual way of handling the coordination of client and server during interface changes is to tightly synchronize version upgrades of both sides at the same time, but of course this is only possible where there truly is a "single administrator" to coordinate the change, which as is pointed out may be the normal situation for an application deployed "behind the firewall" but is certainly not the case on the Internet.

However, the other well proven way of handling this is coordination of upgrades is to simply maintain both the old and new versions of the interface until all parties have upgraded, or possibly forever.
This is the principle of "immutable interfaces".

None of this applies to Web Services technology on its own of course, and is really just a general problem for *all* distributed computing technology.
Even HTTP suffers/ed from this exact same problem, as indicated by the need for RFC-2145 "Use and Interpretation of HTTP Version Numbers" (http://www.ietf.org/rfc/rfc2145.txt)

The fact that most of the publicly visible "toy" examples of Web Services on xmethods don't tackle this problem does not mean that this isn't a topic being considered seriously and being successfully dealt with by enterprise software architects in major vendors and corporations using Web Services technology and XML Schema versioning.

Distributed computing is just plain hard to do right some times!

- Jorgen Thelin
Chief Architect, CapeConnect
Cape Clear Software Inc.

2002-11-04 10:26:59
Coordination and Interface Versioning
For sure, using immutable interfaces ala COM is one way to approach this. But interface versioning and deployment is just one example of the general coordination problem.

I'm sure there are some "in the know" who are trying to tackle this (and other) problems of distributed computing, but the fact that Web services requires every developer to be a distributed computing guru is a problem I don't believe will ever be overcome.

IMO, what's needed is an general application framework that already addresses many of the known hard problems, making it easier for the average developer to produce applications which will work well over the Internet. And I think we've already got one; the Web.