Architecting Service-Oriented SystemsTable of ContentsList of FiguresList of TablesAbstract1 Introduction2 Summary of Existing Work3 SOA Architectural Principles4 Common Components of a Service-Oriented System5 ConclusionsReferencesArchitecting Service-Oriented Systems Philip Bianco Grace A. Lewis Paulo Merson Soumya Simanta August 2011 TECHNICAL NOTE CMU/SEI-2011-TN-008 Research, Technology, and System Solutions Program Unlimited distribution subject to the copyright. http://www.sei.cmu.eduSEI markings v3.0 / 19 July 2011 Copyright 2011 Carnegie Mellon University. This material is based upon work supported by United States Department of Defense under Contract No. FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded re-search and development center. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the United States Department of Defense. This report was prepared for the SEI Administrative Agent ESC/XPK 5 Eglin Street Hanscom AFB, MA 01731-2100 NO WARRANTY THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN “AS-IS” BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT. This material has been approved for public release and unlimited distribution except as restricted below. Internal use:* Permission to reproduce this material and to prepare derivative works from this material for internal use is granted, provided the copyright and “No Warranty” statements are included with all reproductions and derivative works. External use:* This material may be reproduced in its entirety, without modification, and freely distributed in written or electronic form without requesting formal permission. Permission is required for any other external and/or commercial use. Requests for permission should be directed to the Software Engineering Institute at [email protected]. For information about SEI publications, please visit the library on the SEI website (www.sei.cmu.edu/library). * These restrictions do not apply to U.S. government entities.CMU/SEI-2011-TN-008 | i Table of Contents Abstract vii 1 Introduction 1 2 Summary of Existing Work 3 2.1 SOA Design Patterns 3 2.2 Evaluating SOA 3 2.3 SOA Layers 5 3 SOA Architectural Principles 8 3.1 Standardization (Interoperability) 9 3.2 Loose Coupling 11 3.3 Reusability 13 3.4 Composability 14 3.5 Discoverability 15 4 Common Components of a Service-Oriented System 18 4.1 Enterprise Service Bus 18 4.1.1 Supporting Patterns and Tactics 18 4.1.2 Impact on System Quality 20 4.2 Service Registry and Repository 21 4.2.1 Supporting Patterns and Tactics 22 4.2.2 Impact on System Quality 23 4.3 Messaging System 23 4.3.1 Supporting Patterns and Tactics 23 4.3.2 Impact on System Quality 25 4.4 Business Process Engine 26 4.4.1 Supporting Patterns and Tactics 27 4.4.2 Impact on System Quality 28 4.5 Monitoring and Management Tools 29 4.5.1 Supporting Patterns and Tactics 29 4.5.2 Impact on System Quality 30 5 Conclusions 31 References 32CMU/SEI-2011-TN-008 | iiCMU/SEI-2011-TN-008 | iii List of Figures Figure 1: SOA Layers 6 Figure 2: High-Level Notional View of a Service-Oriented System 8 Figure 3: WS* Web Services Protocol and Standards Stack 10 Figure 4: ESB Patterns and Sub-Patterns (adapted from [Erl 2009]) 19 Figure 5: Asynchronous Messaging Pattern, Specializations, and Sub-Patterns 25 Figure 6: Orchestration Pattern and Sub-Patterns (adapted from [Erl 2009]) 27CMU/SEI-2011-TN-008 | ivCMU/SEI-2011-TN-008 | v List of Tables Table 1: Effect of Standardization 10 Table 2: Effect of Loose Coupling 12 Table 3: Effect of Reusability 13 Table 4: Effect of Composability 15 Table 5: Effect of Discoverability 16 Table 6: ESB Aspects that Negatively Affect System Qualities 20 Table 7: ESB Aspects that Positively Affect Systems Qualities 21 Table 8: Service Registry and Repository Aspects that Negatively Affect System Qualities 23 Table 9: Service Registry and Repository Aspects that Positively Affect System Qualities 23 Table 10: Messaging System Aspects that Negatively Affect System Qualities 25 Table 11: Messaging System Aspects that Positively Affect System Qualities 26 Table 12: Business Process Engine Aspects that Negatively Affect System Qualities 28 Table 13: Business Process Engine Aspects that Positively Affect System Qualities 28 Table 14: Monitoring and Management Tools Aspects that Negatively Affect System Qualities 30 Table 15: Monitoring and Management Tools Aspects that Positively Affect System Qualities 30CMU/SEI-2011-TN-008 | viCMU/SEI-2011-TN-008 | vii Abstract Service orientation is an approach to software systems development that has become a popular way to implement distributed, loosely coupled systems, because it offers such features as standar-dization, platform independence, well-defined interfaces, and tool support that enables legacy sys-tem integration. From a quality attribute point of view, the primary drivers for service orientation adoption are interoperability and modifiability. However, a common misconception is that an ar-chitecture that uses a service-oriented approach can achieve these qualities by simply putting to-gether a set of vendor products that provide an infrastructure and then using this infrastructure to expose a set of reusable services to build systems. In reality, there are many architectural deci-sions that need to be made. An architectural decision that promotes interoperability or modifiabili-ty can negatively impact other qualities, such as availability, reliability, security, and perfor-mance. The goal of this report is to present general guidelines for architecting service-oriented systems, how common service-oriented system components support these principles, and the ef-fect that these principles and their implementation have on system quality attributes.CMU/SEI-2011-TN-008 | viiiCMU/SEI-2011-TN-008 | 1 1 Introduction Despite a highly