WIXLIB

Reference Architecture Foundation forService Oriented ArchitectureVersion 1.0Committee Draft 0214 October 2009Specification URIs:This -open.org/soa-rm/soa-ra/v1.0/soa-ra-cd-02.pdf (Authoritative)Previous t a-rm/soa-ra/v1.0/soa-ra.pdf (Authoritative)Technical Committee:OASIS Service Oriented Architecture Reference Model TCChair(s):Ken Laskey, MITRE CorporationEditor(s):Jeff A. Estefan, Jet Propulsion Laboratory, jeffrey.a.estefan@jpl.nasa.govKen Laskey, MITRE Corporation, klaskey@mitre.orgFrancis G. McCabe, Individual, fmccabe@gmail.comDanny Thornton, Northrop Grumman, danny.thornton@ngc.comRelated work:This specification is related to:OASIS Reference Model for Service Oriented ArchitectureAbstract:This document specifies the OASIS Reference Architecture for Service Oriented Architecture. Itfollows from the concepts and relationships defined in the OASIS Reference Model for ServiceOriented Architecture. While it remains abstract in nature, the current document describes onepossible template upon which a SOA concrete architecture can be built.Our focus in this architecture is on an approach to integrating business with the informationtechnology needed to support it. The issues involved with integration are always present, but, wefind, are thrown into clear focus when business integration involves crossing ownershipboundaries.soa-ra-cd-02Copyright OASIS 1993–2009. All Rights Reserved14 October 2009Page 1 of 119

This architecture follows the recommended practice of describing architecture in terms of models,1234views, and viewpoints, as prescribed in ANSI /IEEE 1471-2000 and ISO /IEC 42010-2007Standards. This Reference Architecture is principally targeted at Enterprise Architects; however,Business and IT Architects as well as CIOs and other senior executives involved in strategicbusiness and IT planning should also find the architectural views and models described herein tobe of value.The Reference Architecture has three main views: the Service Ecosystem view which focuses onthe way that participants are part of a Service Oriented Architecture ecosystem; the RealizingServices view which addresses the requirements for constructing a Service Oriented Architecture;and the Owning Service Oriented Architecture view which focuses on the governance andmanagement of SOA-based systems.Status:This document was last revised or approved by the SOA Reference Model TC on the above date.The level of approval is also listed above. Check the “Latest Version” or “Latest ApprovedVersion” location noted above for possible later revisions of this document.Technical Committee members should send comments on this specification to the TechnicalCommittee’s email list. Others should send comments to the Technical Committee by using the“Send A Comment” button on the Technical Committee’s web page at http://www.oasisopen.org/committees/tc home.php?wg abbrev soa-rm.For information on whether any patents have been disclosed that may be essential toimplementing this specification, and any offers of patent licensing terms, please refer to theIntellectual Property Rights section of the Technical Committee web page .The non-normative errata page for this specification is located at http://www.oasisopen.org/committees/tc home.php?wg abbrev soa-rm.1American National Standards Institute2Institute of Electrical and Electronics Engineers3International Organization for Standardization4International Electrotechnical Commissionsoa-ra-cd-02Copyright OASIS 1993–2009. All Rights Reserved14 October 2009Page 2 of 119

NoticesCopyright OASIS 1993–2009. All Rights Reserved.All capitalized terms in the following text have the meanings assigned to them in the OASIS IntellectualProperty Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.This document and translations of it may be copied and furnished to others, and derivative works thatcomment on or otherwise explain it or assist in its implementation may be prepared, copied, published,and distributed, in whole or in part, without restriction of any kind, provided that the above copyright noticeand this section are included on all such copies and derivative works. However, this document itself maynot be modified in any way, including by removing the copyright notice or references to OASIS, except asneeded for the purpose of developing any document or deliverable produced by an OASIS TechnicalCommittee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, mustbe followed) or as required to translate it into languages other than English.The limited permissions granted above are perpetual and will not be revoked by OASIS or its successorsor assigns.This document and the information contained herein is provided on an "AS IS" basis and OASISDISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANYWARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANYOWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR APARTICULAR PURPOSE.OASIS requests that any OASIS Party or any other party that believes it has patent claims that wouldnecessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard,to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses tosuch patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee thatproduced this specification.OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership ofany patent claims that would necessarily be infringed by implementations of this specification by a patentholder that is not willing to provide a license to such patent claims in a manner consistent with the IPRMode of the OASIS Technical Committee that produced this specification. OASIS may include suchclaims on its website, but disclaims any obligation to do so.OASIS takes no position regarding the validity or scope of any intellectual property or other rights thatmight be claimed to pertain to the implementation or use of the technology described in this document orthe extent to which any license under such rights might or might not be available; neither does itrepresent that it has made any effort to identify any such rights. Information on OASIS' procedures withrespect to rights in any document or deliverable produced by an OASIS Technical Committee can befound on the OASIS website. Copies of claims of rights made available for publication and anyassurances of licenses to be made available, or the result of an attempt made to obtain a general licenseor permission for the use of such proprietary rights by implementers or users of this OASIS CommitteeSpecification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes norepresentation that any information or list of intellectual property rights will at any time be complete, orthat any claims in such list are, in fact, Essential Claims.The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should beused only to refer to the organization and its official outputs. OASIS welcomes reference to, andimplementation and use of, specifications, while reserving the right to enforce its marks againstmisleading uses. Please see http://www.oasis-open.org/who/trademark.php for above guidance. Unified Modeling Language , UML , Object Management Group , and OMG are trademarks of theObject Management Group.soa-ra-cd-02Copyright OASIS 1993–2009. All Rights Reserved14 October 2009Page 3 of 119

Table of Contents1Introduction. 91.1 Context for Reference Architecture for SOA . 91.1.1 What is a Reference Architecture? . 91.1.2 What is this Reference Architecture Foundation?. 91.1.3 Relationship to the OASIS Reference Model for SOA . 101.1.4 Relationship to other Reference Architectures. 101.1.5 Relationship to other SOA Open Standards . 101.1.6 Expectations set by this Reference Architecture. 121.2 Service Oriented Architecture – An Ecosystems Perspective . 121.3 Viewpoints, Views and Models . 131.3.1 ANSI/IEEE 1471-2000::ISO/IEC 42010-2007 . 131.3.2 UML Modeling Notation. 141.4 Viewpoints of this Reference Architecture. 151.4.1 Service Ecosystem Viewpoint . 161.4.2 Realizing Service Oriented Architectures Viewpoint . 161.4.3 Owning Service Oriented Architectures Viewpoint. 171.5 Terminology. 171.5.1 Usage of Terms. 171.6 References . 171.6.1 Normative References . 171.6.2 Non-Normative References. 182Architectural Goals and Principles. 192.1 Goals and Critical Success Factors of this Reference Architecture . 192.1.1 Goals . 202.1.2 Critical Success Factors. 202.2 Principles of this Reference Architecture. 213Service Ecosystem View . 243.1 Acting in a SOA Ecosystem Model. 253.1.1 Actors, Delegates and Participants . 263.1.2 Action and Joint Action. 273.1.3 Communication as Joint Action. 303.1.4 Using Communication for Service Action . 323.2 Social Structure Model . 333.2.1 Roles in Social Structures . 353.2.2 Shared State and Social Facts. 363.3 Acting in a Social Context Model. 393.3.1 Service Providers and Consumers. 403.3.2 Needs and Capabilities . 413.3.3 Resources . 423.3.4 Ownership . 433.3.5 Trust, Risk and Willingness . 443.3.6 Transactions and Exchanges. 464Realizing Service Oriented Architectures View . 48soa-ra-cd-02Copyright OASIS 1993–2009. All Rights Reserved14 October 2009Page 4 of 119

4.1 Service Description Model. 484.1.1 The Model for Service Description . 494.1.2 Use Of Service Description . 574.1.3 Relationship to Other Description Models. 624.1.4 Architectural Implications . 634.2 Service Visibility Model. 644.2.1 Visibility to Business. 644.2.2 Visibility . 654.2.3 Architectural Implications . 704.3 Interacting with Services Model. 714.3.1 Interaction Dependencies . 714.3.2 Actions and Events . 714.3.3 Message Exchange. 724.3.4 Composition of Services . 744.3.5 Architectural Implications of Interacting with Services . 794.4 Policies and Contracts Model . 804.4.1 Policy and Contract Principles . 804.4.2 Policy Metrics . 834.4.3 Automating Support for Policies and Contracts . 834.4.4 Architectural Implications . 845Owning Service Oriented Architectures View. 855.1 Governance Model . 855.1.1 Understanding Governance . 855.1.2 A Generic Model for Governance. 875.1.3 Governance Applied to SOA . 915.1.4 Architectural Implications of SOA Governance . 955.2 Security Model. 965.2.1 Secure Interaction Concepts . 965.2.2 Where SOA Security is Different . 995.2.3 Security Threats . 995.2.4 Security Responses . 1005.2.5 Architectural Implications of SOA Security. 1015.3 Management Model. 1025.3.1 Management and Governance. 1055.3.2 Management Contracts and Policies . 1055.3.3 Management Infrastructure . 1055.3.4 Service Life-cycle . 1065.4 SOA Testing Model . 1065.4.1 Traditional Software Testing as Basis for SOA Testing . 1065.4.2 Testing and the SOA Ecosystem . 1085.4.3 Elements of SOA Testing . 1095.4.4 Testing SOA Services . 1135.4.5 Architectural Implications for SOA Testing. 1166Conformance . 117A.Acknowledgements . 118soa-ra-cd-02Copyright OASIS 1993–2009. All Rights Reserved14 October 2009Page 5 of 119

B.Critical Factors Analysis. 119B.1 Goals. 119Critical Success Factors. 119Requirements . 119CFA Diagrams. 119soa-ra-cd-02Copyright OASIS 1993–2009. All Rights Reserved14 October 2009Page 6 of 119