My experience with patterns is that the behavior and implementation of patterns is a mystery even after considerable thought and paper diagramming. Of course, if you are a student, your experience is probably to go ahead and implement the pattern as part of an exercise for class. My intent in this book is to give you the generic perspective that is useful in a pattern yet also hand you an implementation of the pattern that runs within the context of a larger application.
To fulfill this intent, I
Once I have laid out the
At the time of publication, I did not have a complete application; rather, I focused on the pattern samples for Web Services. Over time, my
Several chapters discuss the patterns that the Web Service platform embodies. These chapters do not intend to introduce a specific Web Service platform implementation, but they should be enough to give you a good understanding of the underlying motivations and organization of most platforms. When I discuss a specific Web Service platform, I use the Apache Axis platform that plugs into the Apache Tomcat engine.
Finally, my target audience should have practical experience with software patterns. Although this is not a mandatory prerequisite, it is helpful to understand the level of abstraction at which I approach each pattern.
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,
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
Figure 1: Pattern relationships
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.
Throughout my career I have been interested in messages and events. Although Web Services have asynchronous calls and although the service
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.