SOA Patterns and Application Technologies
It is important to view and position SOA as an architectural model that is neutral to any one technology platform and service-orientation as a paradigm that is neutral to any distributed implementation medium. By doing so, you have the freedom to continually pursue the strategic goals associated with SOA and service-orientation by leveraging on-going technology advancements.
For example, a service can be built and implemented as a component, a SOAP-based Web service, or a REST service. Essentially, any implementation technology that can be used to create a distributed system may be suitable for service-orientation. Many of the design patterns in this catalog are not specific to any one of these three implementation mediums, but some are. Several examples are based on the use of SOAP-based Web services because this service implementation medium has been historically the most popular. This does not preclude you from applying the patterns with other suitable technologies. Some patterns in particular can be carried out with vendor-specific products and technologies that rely on alternative communication protocols and APIs that are not based on industry standards.
When deciding on what technologies to use for a given pattern, it can be helpful to take some of the standards-related patterns into account, such as Canonical Protocol, Dual Protocols, Canonical Resources, and Canonical Schema. These types of patterns can provide regulatory guidance to help you establish some baseline criteria for technology selection.
SOA Design Patterns 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 the following figure, 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 SOA design patterns.
Starting with the original pattern language created by Christopher Alexander, the SOA Design Pattern book explores these historical influences in more detail and further highlights specific patterns that act as the basis or inspiration of certain SOA design patterns.
Books that are highlighted as part of this exploration include:
- Design Patterns: Elements of Reusable Object-Oriented Software (Gamma, Helm, Johnson, Vlissides; Addison-Wesley, 1995)
- Pattern-Oriented Software Architecture series (F. Buschmann, K. Henney, M. Kircher, R. Meunier, H. Rohnert, D. Schmidt, P. Sommerlad, M. Stal, Wiley 1996–2007)
- Patterns of Enterprise Application Architecture (Fowler, Addison-Wesley, 2003)
- Enterprise Integration Patterns (Hohpe, Woolf, Addison-Wesley, 2004)
For more information about these and other patterns books, visit the Design Patterns Publications page.
SOA Design Patterns and Design Principles
The design patterns in this catalog reference the following service-orientation design principles where appropriate to highlight a dependency or relationship or perhaps to describe the effect a design pattern may have on service-orientation (or vice versa):
• Standardized Service Contract
• Service Loose Coupling
• Service Abstraction
• Service Reusability
• Service Autonomy
• Service Statelessnes
• Service Discoverability
• Service Composability
Specifically, the potential relationship between service-orientation design principles and patterns can be summarized as follows:
– Design principles are applied collectively to solution logic in order to shape it in such a manner that it fosters key design characteristics that support the strategic goals associated with service-oriented computing.
– Design patterns provide solutions to common problems encountered when applying design principles-and-when establishing an environment suitable for implementing logic designed in accordance with service-orientation principles.
In many ways, design principles and patterns are alike. Both provide design guidance in support of achieving overarching strategic goals. In fact, it would not be unreasonable to think of the eight service-orientation principles as super patterns that are further supported by the patterns in this book.
Service-orientation design principles have another role in that they collectively define service-orientation as a design paradigm. Ultimately, it is best to view design patterns as providing support for the realization of design principles and their associated goals.
SOA Design Patterns and Design Granularity
Design granularity, as it pertains to service-orientation, is itself something that you should be familiar with prior to reading the upcoming chapters. Specifically, it is suggested that you look up the following terms at SOAGlossary.com because several of the upcoming pattern descriptions reference these terms with no further explanation:
– Service Granularity – The overall quantity of functionality encapsulated by a service determines the service granularity. A service’s granularity is determined by its functional context, which is usually established during the service modeling phase.
– Capability Granularity – The quantity of functionality encapsulated by a specific service capability determines the level of corresponding capability granularity.
– Data Granularity – The quantity of data exchanged by a specific service capability determines the level of its data granularity.
– Constraint Granularity – The extent of validation logic detail defined for a given service capability within the service contract determines the capability’s level of constraint granularity. Generally, the more specific the constraints and the larger the amount of constraints, the more fine-grained the capability’s constraint granularity is.
The effect of design patterns on service-related design granularity can vary. For example, when applying multiple patterns (or compound patterns) to the same service, the end-levels of design granularity may be distinctly defined by that combination of patterns (and they may fluctuate between the application of one pattern to another).