OSCON 2005: Architecting Freedom
Pages: 1, 2

The Spanning Layer

David Clark coined the phrase the spanning layer in his paper "Interoperation, Open Interfaces, and Protocol Architecture." Clark had said that there is a special form of abstraction that gives you an hourglass shape, which enables extensibility and innovation in how you apply the protocols as well as in how you overlay existing technology with the same protocols.

Gall took Clark's model and generalized it to describe an internetwork architecture and to highlight some of the key principles that make it successful. In particular, he stressed the wide-at-the-top, wide-at-the-bottom shape that you can apply to almost any architecture you see. The backbone of the architecture is interoperability. So, for example, your architecture shouldn't be tied to any platform architecture or language such as J2EE, .Net, PHP, Python, or Perl. Another key is composability, so that you can mix these different subarchitectures on the fly over the internet using intermediaries. In designing protocols, they should be as generic as possible. The wide bottom of the hourglass represents the notion of being federated, so we can overlay a wide range of existing implementations at the endpoints and at the network level to minimize the disruptiveness of moving forward.

The narrow waist of the hourglass represents the simplicity that is required. Gall explained that you get this simplicity by focusing on the three key standards: identifiers, format, and protocol. The identifier might be an address, reference, or name. Similarly, the format might refer to a document, message, or packet, and the protocol might describe the interaction, behavior, or request and reply. When you look at examples from the internet, you can see the power in simplicity. Email, for example, uses an @ address as the identifier, RFC 2822 as the format, and SMTP as the protocol. The web uses URLs as identifiers, HTML/MIME as the format, and HTTP as the protocol. IP itself uses an IP address as the identifier, an IP packet as the format, and IP protocol as the protocol.

Intermodal containerized shipping also fits this model. It uses a UPC-barcode-inspired identifier, a 20-ton packet as the format, and container port protocol as the protocol. Gall explained that containerized shipping was a revolution in logistics. It has enabled interoperation of the world's transportation networks. Note that it doesn't replace anything that existed. Its power is that it overlays the train network, the truck network, and the ship network. A steel container (a packet) can be sent around the world without needing to be opened up.

Web 2.0

Gall said that there are three essential changes to the web that make up what we are beginning to call Web 2.0. Two of them fix compromises made with Web 1.0. Tim Berners-Lee always intended for the browser to natively be read/write. The problem was that the other early implementors wanted to get their demos working quickly and so they left off the write capability. It has taken us ten years to put it back in. One of the standards important to Web 2.0 is how we write to the web.

The second feature of Web 2.0 fixes a problem with interlinking. Hypertext only supports forward links. You can click on a link and go somewhere. But much of the interesting questions have to do with backlinking. Innovations around social software and web search engines are retrofits for backlinks. We can build more interesting networks if we can understand what is linking to a particular page.

Another feature of Web 2.0 is the freedom to scale in the downward direction. We've already scaled upwards to take the web global; Gall suggested that we engage in increasing the granularity. Can we scale it down so that the web works at an interprocess or intraprocess level? IP is already used for system board level buses. "In this [Web 2.0] world," Gall summarized, "links are King, content is Queen, and code is only the Prince, but all three must be free and open."


When you architect for freedom, you are, by definition, enabling unintended consequences. There are the cool and interesting extensions that we've seen with mash-ups, RSS, and podcasting. There are also the perverse effects such as viruses, spam, adware, and phishing. Gall said the idea is not to close it all down out of fear, but to leave it open and try through community, licence, reputation, and trust to edge things back to the serendipity end of the spectrum. He ended his keynote by saying it is not enough to grant users the right to change your software; you must design your system so it is easy or even fun to change.

Daniel H. Steinberg is the editor for the new series of Mac Developer titles for the Pragmatic Programmers. He writes feature articles for Apple's ADC web site and is a regular contributor to Mac Devcenter. He has presented at Apple's Worldwide Developer Conference, MacWorld, MacHack and other Mac developer conferences.

Return to the O'Reilly Network