While recently delivering a week-long workshop at a client location, I was required to spend a fair amount of time waiting in the reception area every day. The client was a very large company in the finance industry, and in order to enter their offices, I had to first request a visitor`s pass from the security guard and then wait until someone from the office came down to the lobby to escort me back up.

Upon entering the building for the first time, I noticed that the front door was stuck. It took me two or three tries to force it open. The security guard later told me that a delivery person had accidentally struck the door with some sort of cart, warping the frame and damaging the handle. They weren`t expecting replacement parts to be installed for another two weeks and were not allowed to keep the door open.

While waiting for my escort that day, I noticed numerous people (mostly office staff) trying to access the building via the jammed door, each going through the same experience I did. People tried different approaches, some more effective than others. At one point there was an actual line-up impatiently waiting for the person at the front to figure it out. Just about everyone who eventually entered complained about the door to the guard.

On the next day of the workshop I was again waiting in the lobby watching the same story unfold. I saw familiar faces struggling with the door again; getting it ajar seemed more a matter of luck than technique, so it was difficult to remember how one opened it the day before. On this day, the security guard ran toward the door to help people open it whenever he could. However, over time, he found himself rushing back and forth a lot, dealing with the door and tending to people at the reception desk who needed to register and request passes.

The third day came around, and I was surprised to encounter the guard standing outside by the entrance. I could see through the glass walls that someone else was taking care of reception duties. As I approached the door, the guard greeted me, and I assumed he was going to open it to let me in. Instead, he asked me not to enter and proceeded to give me a short lesson on how to open the door with two swift moves. The lesson consisted of a brief explanation and a short demonstration. I thanked him and moved to go inside, but he stopped me, shut the door, and then said "Ok, now you do it." And so I did.

Introduction

While waiting in the lobby that morning, I watched him give that same lesson to just about everyone who needed to enter. Sometimes the guard had a whole class as a group of office employees who arrived at the same time were taught together.

As I walked toward the building on the fourth day, I noticed the guard was no longer at the door. Recalling "the moves" I`d learned the day before, I proceeded to open it with relative ease. As I entered the lobby, I could see that the same guard was alone again to manage the reception area. Then, while waiting for my escort as usual, I witnessed droves of people entering the building with little to no problems.

It was even more impressive the following day during my last morning. People were coming and going without breaking a stride. It was as if the door had actually been fixed. At the end of that last day of training, I said good-bye to the guard and complimented him on how he dealt with the door issue. "You`re a true problem solver," I said. "Yes, I know," he responded with a grin, "I`m the smart one."

On the taxi ride back to the airport, I thought some more about the damaged door and the solution the guard came up with. I did some rough math, taking into account how long it took the average person to get past the jammed door during the first two days and how many people I saw streaming into the building every morning. I estimated that over the last two days (after each employee was given a lesson by the guard) about 35,000 seconds were saved, translating into around 9.7 hours.

I never did find out when that door was eventually fixed, but assuming it took another week as expected, that time savings could easily be doubled or tripled. That`s potentially 20?30 extra working hours the company received, thanks to one person`s ingenuity.

This experience reminded me of why I felt strongly about putting together this catalog of design patterns. That guard spent the second day trying a variety of ways to deal with a problem until he found a proven method that was effective, easy to learn, and repeatable by anyone. On the third day he transferred that knowledge to all who needed it, and on the remaining days they put that knowledge to good use. In the end, the cumulative benefit was significant because all of the employees who saved time were able to spend that time solving new problems for the benefit of the company.

While problem solving is a fundamental skill we all possess, not everyone should have to solve the same problems. This is the basic rationale behind design patterns. There are jammed doors along the path to completing just about any IT project, perhaps even more so with SOA initiatives simply because their scope tends to be larger and more ambitious. I hope you`ll find this book an effective resource for "learning the moves" to counter problems you might have to face in pursuit of realizing your own service-oriented solutions.

1.1 Objectives of this Book

A design pattern is simply a proven design solution for a common design problem that is formally documented in a consistent manner. This book was written with one primary goal in mind: to provide a master pattern catalog and pattern language for SOA and service-orientation. This sole objective has driven this collection of design patterns through numerous rounds of reviews, revisions, and community participation.

1.2 Who this Book is For

This book is intended for IT practitioners who:

want to learn proven design solutions and practices for building SOA

implementations

want to prepare themselves for common challenges associated with the definition

and design of services and service-oriented solutions

want to learn about SOA and service-orientation by studying detailed aspects of fundamental design

want to learn about the different types of service-oriented architectures and under

stand exactly how they are distinct from other architectural models

want to gain a deep insight into the complexion of modern-day service-oriented

solution design

This book can essentially be considered a reference text for use by anyone involved with the construction of service-oriented solutions.

1.3 What this Book Does Not Cover

The following sections highlight specific subject areas not addressed in this book.

Topics Covered by Other Books

This title is dedicated to documenting design patterns only. Because most of the patterns in this catalog were specifically created in support of service-orientation, there are many cross-references to design principles whenever they are related or relevant to a particular pattern. These design principles are covered separately in SOA Principles of Service Design, a companion guide for this book.

1.3 What this Book Does Not Cover

Furthermore, this book does not contain a tutorial about Web services or service-oriented computing. There are several publications that have already covered these areas in detail. Suggestions are provided in the upcoming Recommended Reading section.

Web Service and REST Service Design Patterns

The Web services technology platform has historically influenced the evolution of service-oriented computing, affecting the complexion and feature-set of typical service-oriented architecture implementations. As a result, numerous design patterns in this book make reference to the use of Web services, and the majority of examples provided show services being implemented as Web services.

Furthermore, a series of REST-inspired design patterns were also developed for this pattern catalog but were not considered ready for inclusion in this first edition of the printed SOA Design Patterns book. These patterns have been published in the Candidate section of the SOAPatterns.org Web site where they will be subjected to on-going reviews, along with other candidate patterns.

It is important to note that the purpose of this book is to provide a catalog of design patterns that help solve problems specific to the realization of SOA and service-orientation. As has been established in previous series titles, Web services and REST services provide implementation options for building services as part of service-oriented solutions.

SOA Standardization Efforts

There are several efforts underway by different standards and research organizations to produce abstract definitions, architectural models, and vocabularies for SOA. These projects are in various stages of maturity, and several overlap in scope.

The mandate of this book series is to provide the IT community with current, real-world insight into the most important aspects of service-oriented computing, SOA, and service-orientation. A great deal of research goes into each and every title to follow through on this commitment. This research includes the detailed review of existing and upcoming technologies and platforms, relevant technology products and technology standards, architectural standards and specifications, as well as interviews conducted with key members of leading organizations in the SOA community.

As of the writing of this book there has been no indication that any of the deliverables produced by the aforementioned independent efforts will be adopted as industry-wide SOA standards. In order to maintain an accurate, real-world perspective, these models and vocabularies can therefore not be covered or referenced in this book.

However, given the unpredictable nature of the IT industry, there is always a possibility that one or more of these deliverables will attain industry standard status at some point in