Transcription
Reference Architecture for ServiceOriented Architecture Version 1.0Public Review Draft 123 April 2008Specification URIs:This a-rm/soa-ra/v1.0/soa-ra-pr-01.pdf oa-ra/v1.0/soa-ra-pr-01.docPrevious Version:N/ALatest oa-ra/v1.0/soa-ra.pdf oa-ra/v1.0/soa-ra.docLatest Approved Version:N/ATechnical Committee:OASIS Service Oriented Architecture Reference Model TCChair(s):Francis G. McCabeEditor(s):Jeff A. Estefan, Jet Propulsion Laboratory, jeffrey.a.estefan@jpl.nasa.govKen Laskey, MITRE Corporation, klaskey@mitre.orgFrancis G. McCabe, Individual, frankmccabe@mac.comDanny Thornton, danny.thornton@soamodeling.orgRelated 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-pr-01Copyright OASIS 1993–2008. All Rights Reserved.23 April 2008Page 1 of 104
This architecture follows the recommended practice of describing architecture in terms of models,views, and viewpoints, as prescribed in ANSI 1 /IEEE 2 1471 Std. This Reference Architecture isprincipally targeted at Enterprise Architects; however, Business and IT Architects as well as CIOsand other senior executives involved in strategic business and IT planning should also find thearchitectural views and models described herein to be of value.The Reference Architecture has three main views: the Business via Service view which lays thefoundation for conducting business in the context of Service Oriented Architecture; 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 (http://www.oasisopen.org/committees/tc home.php?wg abbrev soa-rm.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 Engineerssoa-ra-pr-01Copyright OASIS 1993–2008. All Rights Reserved.23 April 2008Page 2 of 104
NoticesCopyright OASIS 1993–2008. 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-pr-01Copyright OASIS 1993–2008. All Rights Reserved.23 April 2008Page 3 of 104
Table of Contents1Introduction . 81.1 What is a Reference Architecture? . 81.1.1 What is this Reference Architecture? . 81.1.2 Relationship to the Reference Model . 91.1.3 Relationship to other Reference Architectures. 91.1.4 Expectations set by this Reference Architecture. 91.2 Service Oriented Architecture – An Ecosystems perspective . 101.3 Viewpoints, Views and Models . 101.3.1 ANSI/IEEE Std 1471-2000::ISO/IEC 42010-2007. 101.3.2 UML Modeling Notation . 121.4 Viewpoints of this Reference Architecture . 131.4.1 Business via Services Viewpoint . 141.4.2 Realizing Service Oriented Architectures Viewpoint . 141.4.3 Owning Service Oriented Architectures Viewpoint. 141.5 Terminology . 141.6 References. 151.6.1 Normative References . 151.6.2 Non-Normative References . 152 Architectural Goals and Principles . 172.1 Goals of this Reference Architecture . 172.1.1 Effectiveness . 182.1.2 Confidence . 182.1.3 Scalability . 192.2 Principles of this Reference Architecture. 193 Business via Services View . 223.1 Stakeholders and Participants Model . 223.2 Resources Model . 243.2.1 Ownership Model . 253.3 Needs and Capabilities Model . 263.4 Social Structure Model. 273.4.1 Shared State and social facts. 283.5 Acting in a Social Context . 303.5.1 Actions, Real World Effect and Events . 303.5.2 Social Actions . 313.5.3 Interaction as Joint Action . 313.5.4 Semantics of Communication Model . 323.5.5 Transactions and Exchanges Model . 333.6 Roles in Social Structures. 343.7 Governance and Social Structures . 363.8 Proposition Model . 374 Realizing Service Oriented Architectures View . 394.1 Service Description Model . 394.1.1 The Model for Service Description . 40soa-ra-pr-01Copyright OASIS 1993–2008. All Rights Reserved.23 April 2008Page 4 of 104
4.1.2 Use Of Service Description . 464.1.3 Relationship to Other Description Models . 524.1.4 Architectural Implications . 524.2 Service Visibility Model . 544.2.1 Visibility to Business . 544.2.2 Attaining Visibility . 554.2.3 Mechanisms for Attaining Visibility . 624.2.4 Architectural Implications . 644.3 Interacting with Services Model . 644.3.1 Actions and Events . 654.3.2 Message Exchange . 654.3.3 Composition of Services. 684.4 Policies and Contracts Model . 724.4.1 Automating Support for Policies and Contracts . 724.4.2 Policy and Contract Types . 734.4.3 IT Mechanisms Supporting Policies and Contracts. 754.4.4 Policy and Contract Principles. 774.4.5 Architectural Implications . 785 Owning Service Oriented Architectures View . 795.1 Governance Model . 795.1.1 Understanding Governance . 795.1.2 A Generic Model for Governance . 805.1.3 Governance Applied to SOA . 835.1.4 Architectural Implications of SOA Governance . 875.2 Security Model . 885.2.1 Security Concepts . 885.2.2 Where SOA Security is Different . 895.2.3 Trust Model. 895.2.4 Security Layers . 935.2.5 Threat Model . 945.2.6 Security Response Model . 955.2.7 Architectural Implications of SOA Security. 965.3 Services as Managed Entities Model . 975.3.1 Management and Governance . 1005.3.2 Management Contracts and Policies . 1005.3.3 Management Infrastructure . 1015.3.4 Service Life-cycle . 1016 Conformance . 102A. Acknowledgements . 103B. Critical Factors Analysis . 104B.1 Goals . 104B.1.1 Critical Success Factors . 104B.1.2 Requirements .
foundation for conducting business in the context of Service Oriented Architecture; the Realizing Services view which addresses the requirements for constructing a Service Oriented Architecture; and the Owning Service Oriented Architecture view which focuses on the
