This chapter is from the book
This chapter is from the book
This chapter is from the book
5.2 Historical Influences
Because service-orientation has deep roots in past distributed computing design platforms, many of the SOA design patterns have origins and influences that can be traced back to established design concepts, approaches, and previously published design pattern catalogs.
As illustrated in Figure 5.1, object-orientation, EAI, enterprise application architecture, and software architecture in general represent areas for which well-recognized design pattern catalogs exist, each of which has influenced design patterns in this book. Starting with the original pattern language created by Christopher Alexander, let’s briefly discuss these influences separately.
)
Alexander’s Pattern Language
It’s been well documented how the notion of the design pattern owes its existence to the work of Christopher Alexander. Just about every design pattern publication pays tribute to Alexander’s pattern language as a fundamental influence and source of inspiration.
Alexander pioneered the concept of patterns in relation to building architecture and related areas, such as city and community structure. He documented a collection of patterns and organized them into a pre-defined series he called a “sequence.” The result was an architectural pattern language that inspired the IT community to create their own patterns for the design of automated systems.
Alexander’s work is more than just a historical footnote for design patterns; it provides insight into how patterns in general should and should not be structured and organized.
For example, some lessons learned from Alexander’s work include:
-
Pattern language sequences need to add value. Often related patterns are better documented independently from each other even if there is some potential for them to be organized into a sequence. The primary purpose of any application sequence established by a pattern language is not to provide a logical organization for a set of related patterns but to demonstrate a proven process that provides value on its own.
-
Patterns do not need to be normalized. There is often a perception that each design pattern should own an individual domain. In reality, the problem and solution space represented by individual patterns sometimes naturally overlaps. For example, you can easily have two patterns that propose different solutions to the same problem.
Beyond just the idea of organizing solutions into a pattern format, Alexander helped advocate the importance of clarity in how pattern catalogs need to be documented. He preached that patterns need to be individually clear as to their purpose and applicability and that pattern languages need to further communicate the rationale behind any sequences they may propose.
Object-Oriented Patterns
A variety of design patterns in support of object-orientation surfaced over the past 15 years, the most recognized of which is the pattern catalog published in Design Patterns: Elements of Reusable Object-Oriented Software (Gamma, Helm, Johnson, Vlissides; Addison-Wesley, 1995). This set of 23 patterns produced by the “Gang of Four” expanded and helped further establish object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation, albeit within an augmented context and new names.
For example, the following patterns in this book are related:
- Capability Composition (521) is associated with Composite
- Service Façade (333) is derived from Façade
- Legacy Wrapper (441) is derived from Adapter
- Non-Agnostic Context (319) is associated with Mediator
- Decoupled Contract (401) is associated with Bridge
Concepts established by several additional object-orientation patterns have factored into other SOA patterns. The incorporation of these patterns within service-orientation is a testament to their importance and evidence of how object-orientation as a whole has influenced the evolution of SOA.
Another relevant object-oriented-related influence is the paper “Using Pattern Languages for Object-Oriented Programs” published by Kent Beck and Ward Cunningham for the 1987 OOPSLA conference. This paper is notable not only for its brevity, but for its vision and its explicit emphasis on the use of sequences in organizing patterns.
Software Architecture Patterns
As design patterns became a mainstream part of IT, a set of important books emerged establishing formal conventions for pattern documentation and providing a series of common design patterns for software architecture in general. These pattern catalogs were developed in five separate volumes over a period of a dozen years as part of the Pattern-Oriented Software Architecture series (F. Buschmann, K. Henney, M. Kircher, R. Meunier, H. Rohnert, D. Schmidt, P. Sommerlad, M. Stal, Wiley 1996–2007).
Because of the general nature of the patterns, the contributions made by this series are too voluminous to document individually. Here are some examples of how SOA design patterns relate:
- Service Layers (143) is associated with Layers
- Service Broker (707) compound pattern is associated with Broker
- Concurrent Contracts (421) is associated with Extension Interface
- Metadata Centralization (280) is associated with Lookup
- Event-Driven Messaging (599) is derived from Publisher-Subscriber
- Process Abstraction (182) is associated with Whole-Part
- Atomic Service Transaction (623) is associated with Coordinator and Task Coordinator
- Partial State Deferral (356) is associated with Partial Acquisition
It is also worth noting that Volume 4 of the series (entitled A Pattern Language for Distributed Computing) focuses on connecting existing patterns relevant to building distributed systems into a larger pattern language. This book documents the roots of various previously published patterns, including those that are part of other pattern catalogs listed in this section.
Enterprise Application Architecture Patterns
As distributed computing became an established platform for solution design, an emphasis on enterprise architecture emerged bringing with it its own set of design patterns, many of which built upon object-oriented concepts and patterns. A respected pattern catalog in this field was published in Patterns of Enterprise Application Architecture (Fowler, Addison-Wesley, 2003).
You might notice that many of the influences originating from enterprise architecture patterns are located in the two pattern languages provided in Chapters 6 and 11. Service-orientation is, at heart, a design paradigm for distributed computing, and although distinct, it still relies and builds upon the fundamental patterns and concepts associated with enterprise application architecture in general.
For example, the following patterns in this book are related:
- Service Encapsulation (305) is associated with Gateway and Service Layer
- Decoupled Contract (401) is associated with Separated Interface
- Service Façade (333) is derived from Remote Façade
- Stateful Services (248) is derived from Server Session State
- Partial State Deferral (356) is derived from Lazy Load
- State Repository (242) is derived from Database Session State
Studying these types of influences can lead to further revelations as to how SOA has evolved into a unique architectural model.
EAI Patterns
Several pattern catalogs centered around the use of messaging to fulfill integration requirements emerged during the EAI era. These patterns establish sound approaches for robust messaging-based communication and address various integration-related challenges. A recognized publication in this field is Enterprise Integration Patterns (Hohpe, Woolf, Addison-Wesley, 2004).
Because EAI is one of the primary influences of service-orientation, this book contains service interaction patterns based on the use of messaging primarily in support of service composition scenarios.
Some examples of SOA patterns related to design patterns documented in Enterprise Integration Patterns:
- Service Messaging (533) is derived from Message, Messaging, and Document Message
- Data Model Transformation (671) is derived from Message Translator
- Canonical Schema (158) is associated with Canonical Data Model
- Service Agent (543) is associated with Event-Driven Consumer
- Process Centralization (193) is associated with Process Manager
- Intermediate Routing (549) is derived from Content-Based Router
Several references to additional EAI patterns are interspersed in the upcoming chapters (Chapter 18, in particular).
SOA Patterns
The intention behind this collection of SOA patterns is not to replace or compete with the catalogs provided by previous publications, but instead to build upon and complement them with a catalog focused solely on attaining the strategic goals associated with service-orientated computing.
This catalog is comprised of new patterns, existing patterns that have been augmented, and patterns that are intentionally similar to patterns in other catalogs. The latter group is included so that these patterns can be explained within the context of SOA and to also formally highlight them as a supporting part of the service-orientation design paradigm.
Learning about the design solutions and techniques provided by SOA design patterns can provide insight into the mechanics required to enable service-orientation and also help clarify exactly how SOA represents a distinct architectural model. When exploring these distinctions, it is important to take into account:
- which of the past design techniques are preserved and emphasized
- which of the past design techniques are de-emphasized
- new design techniques
- new approaches to carrying out existing techniques
Note that there are several more useful design patterns in the previously mentioned books which are not mentioned in this pattern catalog. Some provide detailed solutions that are not necessarily specific to SOA, but still very helpful.