Pattern books take a variety of directions to portray patterns to the reader. Some books use rigid templates, and others lean more toward readable prose. Purists usually like the prior, and book readers, like me, like the latter. To be honest, I think pattern books should serve both types of readers. I have taken the approach to organize the book as a readable, prose -based, stand-alone piece of work.
A brief introduction to the topic of Web Service Patterns leads off the book. Next, I present the high-level requirements, business drivers, and architecture of the case study. After the case study, the chapters discuss various software patterns and how each one fulfills the system structures embodied in the high-level architecture. I introduce a single pattern per chapter (with the exception of two chapters that introduce variants and a necessary dependent pattern) along with how the pattern fulfills the needs of the case study. In addition to how the pattern specifically addresses the case study, each pattern documents the more general problem and solution that the pattern addresses. Figure 1 illustrates the relationships between the patterns.
The patterns come in five categories:
Learning It is important to understand the Web Service environment, where it originated from, and the mechanisms that help it fulfill its purposes of implementation and location transparency. The "learning" patterns fulfill this need.
Adapting These patterns help refine your knowledge of a Web Service environment. These patterns change your way of thinking from object orientation to a flatter, more component-like approach for building representations of data and processes. The "adapting" patterns are used throughout the remainder of the book as base patterns.
Determining changes Throughout my career I have been interested in messages and events. Although Web Services have asynchronous calls and although the service implementations could be based on a message-oriented architecture, I still find the traditional event patterns (the Observer and Publish/Subscribe patterns) interesting in the environment. They add a mechanism that programmer's expect from today's services.
Refining These patterns are necessary enhancements to disprove that Web Services are monolithic in nature. Web Services are simply an access mechanism to behavior implemented in a language. These patterns help you understand the Web Service environment better and help you mold the environment to your own needs.
Creating flexibility Finally, you can create more flexible Web Services that better suit your needs with a few additional patterns. The patterns in this category could easily be shuffled throughout different points in the book, but I chose to put them at the end because they are simply internal mechanisms and contracts to Web Services that help create a more optimized and flexible environment. In essence, they are extensions of the other patterns, not base patterns.
Some of the later patterns in the book could easily be rearranged. For example, the Service Factory pattern could follow the Business Process pattern. The Physical Tiers pattern could follow the Service-Oriented Architecture pattern. I chose to structure the book in a way that would help you best learn the Web Service environment. In this spirit, I waited as long as I could before I ratcheted up the complexity with patterns such as the Physical Tiers pattern and Service Factory pattern.
Finally, I present a variety of architectural, design, and implementation patterns (idioms) in the book. Several times, you will have to switch hats from architecture to design, but I hope to create a logical flow as to how you would go about understanding a complete application.