Home > Introduction


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 Related 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):

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.

Click here for more information about Service-Orientation Design Principles.

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 SOA Glossary 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).


This site contains published and unpublished work Copyright 2006-2013 Arcitura Education Inc. and Pearson Education, All Rights Reserved Published work published by Pearson Education, Inc. publishing as Prentice Hall Professional Technical Reference, Upper Saddle River, NJ 07458

The content on this Web site (the "Draft"), including all words, text, images, and graphics, is provided by the publisher, Pearson Education, Inc. ("Pearson") and Arcitura Education Inc. ("Arcitura"), for the express purpose of allowing readers to review and provide commentary. The Draft is protected by copyright and no rights are granted to the Draft other than for the express purposes stated above. Use of the Draft for any purpose other than for the foregoing review and commentary purposes is strictly prohibited. Reproduction, manipulation, modification, reverse engineering, storage in a retrieval system, distribution and/or transmission of the Draft in any form or by any means, electronic, mechanical, photocopying, recording, or likewise, is strictly prohibited. You shall be liable for any unauthorized use of the Draft. Pearson and Arcitura do not guarantee the accuracy or completeness of any information or content contained in this Draft. You agree that you must evaluate and bear all risks associated with the use of any content, including any reliance on the accuracy, completeness, or usefulness of such content. Pearson and Arcitura disclaim any and all liability for any damages of any kind or character, including without limitation any compensatory, incidental, direct or indirect, special, punitive, or consequential damages, loss of income or profit, loss of or damage to property or person, claims of third parties, or other losses of any kind or character arising out of or in connection with the use of this Draft or the accuracy of the information contained herein, even if Pearson or Arcitura has been advised of the possibility of such damages or losses. Pearson and Arcitura reserves the right at any time, and from time to time, to modify or discontinue, temporarily or permanently, the online publication of this Draft, with or without notice to you.