Preface

It is hard to believe that we are nearing the 20th anniversary of the fabled “Gang of Four”Design Patterns book. Enthusiasm for the “Pattern” book style has waxed and waned in the interim. While the style has been done and overdone, it is still a comfortable approach to distilling bite-sized nuggets of design discussion. Every entry is given a name, a motivation, examples, and a discussion about potential positive and negative outcomes. The structure of the narrative reminds us that choices have consequences and designs have intended uses. It encourages us to be thoughtful and cautious in the techniques we employ to solve real-world problems. It also gives us a high-bandwidth way to describe a significant design element of a system by name.

Soon after discovering the elegance of patterns, many developers fall into the “Everything is a Pattern” Anti-Pattern. They misinterpret patterns as components and consider them building blocks. They believe that patterns give them a pass on actually thinking about the systems they are building. They seek frameworks that implement the patterns for them, avoiding even more work.

That is not the goal of this book. The resource abstraction is about shielding clients from unnecessary details. Resource-oriented patterns are not about shielding developers from thinking about what they are building. They represent Uniform Interfaces, but not necessarily Universal Interfaces. Their applicability may vary widely-depending upon the context of your requirements.

It is also hard to believe that we have just recently passed the 20th anniversary of the World Wide Web. What would have at one time seemed inconceivable to nearly everyone has become commonplace to most.

I am convinced that we are not done learning from the deliberate and cautious choices made at the beginning of this journey. The migration from static documents to dynamic applications certainly involved new technologies (e.g., AJAX, JavaScript libraries, Cascading Stylesheets, etc.), but it was enabled by the underlying pieces of logically named Uniform Resource Locators (URLs), the Hypertext Transfer Protocol (HTTP) and Hypertext Markup Language (HTML). Even as we consider modernizing protocols such as SPDY and HTTP 2.0, we are doing so with the goal of keeping the infrastructure consistent.

It is to the immense credit of Tim Berners-Lee, and to those who helped him to design and build The Web, that this fundamental communication pattern was maintained. When you want a document on the Web, you simply ask for it by name. Finding the name is a separate issue that we will revisit later, but the notions of disambiguation and resolvability are wrapped up in the design of Uniform Resource Locators.1 The name of the thing is not only its identifier in a global context, it is also the handle by which you request it. Name. Point. Request.

The scope of what we can address, of course, includes documents. But we refer to resource locators, not simply document locators, because we have more varied types of information to address. These can also include data, services and concepts. Not all resources are directly addressable, but we have a common scheme for addressing all of the different things we care about.

Another trick the Web pioneers pulled in their design was to give people the ability to choose the names for the things they published. You did not need to seek the permission of a central authority to name something and share it. It is remarkable (and largely unexpected) that giving people this ability did not devolve into chaos. Entire industries had previously emerged to manage the centralized control of identifiers such as International Standard Book Numbers (ISBNs), International Standard Audiovisual Numbers (ISANs), and Digital Object Identifiers (DOIs). The benefit these organizations promised was guaranteed uniqueness. But on the Web, anyone can give a name to a document in a domain they control without permission and not have to worry about conflicts.

The combined decisions of allowing people to name their own resources, publish their content at will, and letting those names be used in the resolution process were crucial to the success of the Web. Sharing documents became as easy as sharing the name of the document. This ultimately changed our whole notion of how to share information in a networked environment. We began to talk more about information resources and their identity and less about document formats and storage. This level of indirection opened up paths to dynamic content generation, technology migration strategies, context-specific responses to individual clients, and more. The Web of Documents has become the Web of Data.

These technologies combined seamlessly to bring us a platform usable by scientists, knowledge workers, grandparents, and children. It was not an accident that this happened. Tim Berners-Lee, Roy Fielding, Dan Connolly, Dave Raggett, and others from the Internet Engineering Task Force (IETF) and World Wide Web Consortium (W3C) toiled to create a platform unencumbered by patents and displaying the architectural properties of loose-coupling, scalability, flexibility, and extensibility.

And yet, it still requires a surprising amount of motivation to get people to think about adopting these technologies within firewalls as well. We forget that Tim’s original proposal was written in the context of solving the information sharing needs of a single (albeit complex) organization, the European Organization for Nuclear Research (CERN).

In his storied proposal,2 he said:

“If a CERN experiment were a static once-only development, all the information could be written in a big book.” Berners-Lee [1989]

Clearly, this was not the case. In trying to do fundamental science, new participants, new strategies, new results, and new experiments needed to be constantly accepted by the system. Given that CERN brought researchers from around the world and interacted with other academic, commercial, and governmental institutions, no social or organizational policies could force standardization among all the participants. A technological solution that embraced change was proposed. After the proposal got no traction for quite some time, Tim was eventually given permission to work on it on the side. The rest is history.

Most of the world embraced the vision whole-heartedly because it allowed them to participate regardless of the technology choices they had made. Different operating systems and platforms were melded into an interoperable environment where anyone could contribute. Broken links were tolerated and localized to specific interactions. The decentralized approach of logically-connected resources allowed demand to spike unpredictably.

All of this is to say that the approach looked at the world of information integration differently. Change was expected. Breakage was expected. Consensus was not required. Central authority could be embraced or not.

In the years since, we have seen a spate of activity around the development of resource-oriented architectures. Most have gotten it wrong because they bring with them the baggage of code-focused world views of excessive coupling. The ones who succeeded did so by aligning themselves with the vision of The Web.

It may be premature to catalog resource-oriented patterns, but these are solutions I have seen in the wild. The goal is to help others make deliberate and cautious choices in their own resource-oriented systems so that they, too may align themselves with an architectural world view that has been so successful.

In Chapter 1, we introduce four patterns that act as primary sources. These represent how we choose to organize our information in ways that embrace change. In Chapter 2, we move to the secondary structures of resources being applied to other resources. In the process, we consider how we can transform and manipulate content available to our creativity but outside of our control. Finally, in Chapter 3, we end with four patterns that connect the resource view of the world to the realities of modern business systems.

It is difficult to describe a dynamic and flexible ecosystem solely in the linear narrative of prose, so I have developed running examples of each of the patterns in two modern, resource-oriented environments. As the world’s only fully resource-oriented software environment, NetKernel (http://netkernel.org) is an obvious choice to explore these ideas. Additionally, the Restlet (http://restlet.org) environment elevates Web abstractions in a more conventional Java-based framework.

You will find these examples and instructions for getting them up and running here: https://github.com/bsletten/roa-book-examples. You are encouraged to experiment with the sample implementations to deepen your insight into how they can help you make deliberate choices in building your own resource-oriented architectures.

Don’t forget: Thinking is still required.

I would like to thank the series editors Jim Hendler and Ying Ding for their encouragement and stewardship throughout the process of writing this book. I would also like to thank Mike Morgan of Morgan & Claypool for his patience and the opportunity to contribute to the growing body of work in this series.

The ideas in this book would never have germinated without the inspiration provided by Peter Rodgers and Tony Butterfield of 1060 Research Ltd. (http://www.1060research.com)

I would not have gotten the practice of talking about these patterns without the opportunity afforded me by Jay Zimmerman and the NoFluffJustStuff (http://nofluffjuststuff.com) conference series. Being given the chance to have a conversation with committed developers 20-30 times per year is a gift. The friendship, support, and inspiration of my fellow “FluffTalkers” past and present is a part of that gift.

Finally, nothing is worth anything without the love and support of my wife, Kristin, and Loki, the God of Mischief. I am frequently too busy working on my things and travel too much, but I derive no greater joy than returning to spend time with the two of you.

 

Brian Sletten

Bosatsu Consulting, Inc.

April 2013

1http://tools.ietf.org/html/rfc3986

2Deemed “vague but exciting” by his supervisor. http://info.cern.ch/Proposal.html

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
54.144.233.198