Foreword by Ian Robinson

Distributed application development often starts well. And just as often it ends badly. Point, add web reference, click: That’s the sound of a developer pointing a loaded client at your carefully crafted service interface. By substituting tooling for design, we somehow turned all that loose coupling into plain irresponsible promiscuity; come release time, we all have to join the lockstep jump.

In a more cautious era, we’d have just said: “No. Don’t distribute.” And in large part that advice still holds true today. A layer is not a tier. Blowing a three-layered application architecture out to distributed proportions is foolishness writ large, no matter how many open standards you implement.

But today’s applications are rarely islands. Where a business’s capabilities are scattered across organizational boundaries, so too are the systems that automate them. Some form of service orientation, both within and between companies, is necessary if we are to support the distributed nature of the modern supply chain.

The web, or rather, the technology that underpins the web, has proven enormously resourceful in this respect. Whether or not you’re aware of—or even carelessly indifferent to—the web’s prominent place in the history of distributed systems, there’s inevitably something of the web about a sound majority of the services you’ve built or used. For all its purported transport agnosticism, SOAP, in practice, has tended to ride the HTTP train. Hidden, but not forgotten, the web has shouldered the services burden for several years now.

When we look at the web services landscape today, we see that there are at least three ways to accommodate the web in the software we build. The web has succeeded not because of the overwhelming correctness of its constituency, but because of its tolerance for the many architectural styles that inhabit and sometimes overrun its borders. Some services and applications are simply behind the web. They treat the web as an unwelcome but nonetheless necessary narrow gateway through which to access objects and procedures. Adjust your gaze, and you’ll see that some services are on the web; that is, they treat HTTP not as a brute transport, but rather as the robust coordination and transfer protocol described in RFC 2616. Last, you’ll see some (very few) that are of the web. These use the web’s founding technologies—in particular, URIs and HTTP and generalized hypermedia representation formats such as HTML—to present a web of data, including data that describes how to access and manipulate more data, to consumers.

This book brings together the need for caution and defensive design when distributing systems with the several ways of using the web to enable distribution. As a compendium of sound strategies and techniques, it rivals the hard-won experience of many of my friends and colleagues at ThoughtWorks. It’s a book about getting things done on the web; it’s also a book about not backing yourself into a corner. By balancing the (necessary) complexity of shielding a service’s domain and data from that army of cocked clients with the simplicity that begets internal quality and service longevity, it may just help you avoid the midnight lockstep deployment.

Ian Robinson