ࡱ > i j k l m n o p q r s t u v w x y z { | } ~ b0 bjbjcTcT n > > m f' f' 4 4 4 4 4 $ 4 4 4 P 5 ) ^ 4 }n NL ˺ d / / / M : h u w w w w w w V w 4 w 4 4 / / h n %L %L %L "0 4 / 4 / u %L u %L %L Ů ٸ / E 4 J/ p a T & 6
& ٸ & 4 ٸ %L w w A Z
& f' o3 :
Service Component Architecture Assembly Model Specification Version 1.1
Committee Draft 05
12 January 2010
Specification URIs:
This Version:
HYPERLINK "http://docs.oasis-open.org/opencsa/sca-assembly/sca-assembly-1.1-spec-cd05.html" http://docs.oasis-open.org/opencsa/sca-assembly/sca-assembly-1.1-spec-cd05.html
HYPERLINK "http://docs.oasis-open.org/opencsa/sca-assembly/sca-assembly-1.1-spec-cd05.doc" http://docs.oasis-open.org/opencsa/sca-assembly/sca-assembly-1.1-spec-cd05.doc
HYPERLINK "http://docs.oasis-open.org/opencsa/sca-assembly/sca-assembly-1.1-spec-cd05.pdf" http://docs.oasis-open.org/opencsa/sca-assembly/sca-assembly-1.1-spec-cd05.pdf (Authoritative)
Previous Version:
HYPERLINK "http://docs.oasis-open.org/opencsa/sca-assembly/sca-assembly-1.1-spec-cd03.html" http://docs.oasis-open.org/opencsa/sca-assembly/sca-assembly-1.1-spec-cd03.html
HYPERLINK "http://docs.oasis-open.org/opencsa/sca-assembly/sca-assembly-1.1-spec-cd03.doc" http://docs.oasis-open.org/opencsa/sca-assembly/sca-assembly-1.1-spec-cd03.doc
HYPERLINK "http://docs.oasis-open.org/opencsa/sca-assembly/sca-assembly-1.1-spec-cd03.pdf" http://docs.oasis-open.org/opencsa/sca-assembly/sca-assembly-1.1-spec-cd03.pdf (Authoritative)
Latest Version:
HYPERLINK "http://docs.oasis-open.org/opencsa/sca-assembly/sca-assembly-1.1-spec.html" http://docs.oasis-open.org/opencsa/sca-assembly/sca-assembly-1.1-spec.html
HYPERLINK "http://docs.oasis-open.org/opencsa/sca-assembly/sca-assembly-1.1-spec.doc" http://docs.oasis-open.org/opencsa/sca-assembly/sca-assembly-1.1-spec.doc
HYPERLINK "http://docs.oasis-open.org/opencsa/sca-assembly/sca-assembly-1.1-spec.pdf" http://docs.oasis-open.org/opencsa/sca-assembly/sca-assembly-1.1-spec.pdf (Authoritative)
Technical Committee:
HYPERLINK "http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sca-assembly"OASIS Service Component Architecture / Assembly (SCA-Assembly) TC
Chair(s):
Martin Chapman, Oracle
Mike Edwards, IBM
Editor(s):
Michael Beisiegel, IBM
Khanderao Khand, Oracle
Anish Karmarkar, Oracle
Sanjay Patil, SAP
Michael Rowley, Active Endpoints
Related work:
This specification replaces or supercedes:
Service Component Architecture Assembly Model Specification Version 1.00, March 15, 2007
This specification is related to:
Service Component Architecture Policy Framework Specification Version 1.1
Declared XML Namespace(s):
HYPERLINK "http://docs.oasis-open.org/ns/opencsa/sca/200903"http://docs.oasis-open.org/ns/opencsa/sca/200912
Abstract:
Service Component Architecture (SCA) provides a programming model for building applications and solutions based on a Service Oriented Architecture. It is based on the idea that business function is provided as a series of services, which are assembled together to create solutions that serve a particular business need. These composite applications can contain both new services created specifically for the application and also business function from existing systems and applications, reused as part of the composition. SCA provides a model both for the composition of services and for the creation of service components, including the reuse of existing application function within SCA composites.
SCA is a model that aims to encompass a wide range of technologies for service components and for the access methods which are used to connect them. For components, this includes not only different programming languages, but also frameworks and environments commonly used with those languages. For access methods, SCA compositions allow for the use of various communication and service access technologies that are in common use, including, for example, Web services, Messaging systems and Remote Procedure Call (RPC).
The SCA Assembly Model consists of a series of artifacts which define the configuration of an SCA Domain in terms of composites which contain assemblies of service components and the connections and related artifacts which describe how they are linked together.
This document describes the SCA Assembly Model, which covers
A model for the assembly of services, both tightly coupled and loosely coupled
A model for applying infrastructure capabilities to services and to service interactions, including Security and Transactions
Status:
This document was last revised or approved by the OASIS Service Component Architecture / Assembly (SCA-Assembly) TC on the above date. The level of approval is also listed above. Check the Latest Version or Latest Approved Version location noted above for possible later revisions of this document.
Technical Committee members should send comments on this specification to the Technical Committees email list. Others should send comments to the Technical Committee by using the Send A Comment button on the Technical Committees web page at HYPERLINK "http://www.oasis-open.org/committees/sca-assembly/"http://www.oasis-open.org/committees/sca-assembly/.
For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page (HYPERLINK "http://www.oasis-open.org/committees/sca-assembly/"http://www.oasis-open.org/committees/sca-assembly/ipr.php.
The non-normative errata page for this specification is located at HYPERLINK "http://www.oasis-open.org/committees/sca-assembly/"http://www.oasis-open.org/committees/sca-assembly/
Notices
Copyright OASIS 2005, 20092010. All Rights Reserved.
All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property 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 that comment 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 notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be 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 successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily 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 to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.
OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims 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 that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.
The names "OASIS", MACROBUTTON NoMacro [insert specific trademarked names and abbreviations here] "SCA" and "Service Component Architecture" are trademarks of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see HYPERLINK "http://www.oasis-open.org/who/trademark.php" http://www.oasis-open.org/who/trademark.php for above guidance.
Table of Contents
TOC \o "1-3" \h \z \u HYPERLINK \l "_Toc254031687" Committee Draft 05 PAGEREF _Toc254031687 \h 1
HYPERLINK \l "_Toc254031688" Notices PAGEREF _Toc254031688 \h 3
HYPERLINK \l "_Toc254031689" Table of Contents PAGEREF _Toc254031689 \h 4
HYPERLINK \l "_Toc254031690" 1 Introduction PAGEREF _Toc254031690 \h 8
HYPERLINK \l "_Toc254031691" 1.1 Terminology PAGEREF _Toc254031691 \h 8
HYPERLINK \l "_Toc254031692" 1.2 Normative References PAGEREF _Toc254031692 \h 8
HYPERLINK \l "_Toc254031693" 1.3 Naming Conventions PAGEREF _Toc254031693 \h 10
HYPERLINK \l "_Toc254031694" 2 Overview PAGEREF _Toc254031694 \h 11
HYPERLINK \l "_Toc254031695" 2.1 Diagram used to Represent SCA Artifacts PAGEREF _Toc254031695 \h 12
HYPERLINK \l "_Toc254031697" 3 Implementation and ComponentType PAGEREF _Toc254031697 \h 15
HYPERLINK \l "_Toc254031699" 3.1 Component Type PAGEREF _Toc254031699 \h 15
HYPERLINK \l "_Toc254031701" 3.1.1 Service PAGEREF _Toc254031701 \h 16
HYPERLINK \l "_Toc254031702" 3.1.2 Reference PAGEREF _Toc254031702 \h 17
HYPERLINK \l "_Toc254031703" 3.1.3 Property PAGEREF _Toc254031703 \h 19
HYPERLINK \l "_Toc254031704" 3.1.4 Implementation PAGEREF _Toc254031704 \h 20
HYPERLINK \l "_Toc254031705" 3.2 Example ComponentType PAGEREF _Toc254031705 \h 21
HYPERLINK \l "_Toc254031706" 3.3 Example Implementation PAGEREF _Toc254031706 \h 21
HYPERLINK \l "_Toc254031707" 4 Component PAGEREF _Toc254031707 \h 24
HYPERLINK \l "_Toc254031708" 4.1 Implementation PAGEREF _Toc254031708 \h 25
HYPERLINK \l "_Toc254031710" 4.2 Service PAGEREF _Toc254031710 \h 26
HYPERLINK \l "_Toc254031711" 4.3 Reference PAGEREF _Toc254031711 \h 27
HYPERLINK \l "_Toc254031712" 4.3.1 Specifying the Target Service(s) for a Reference PAGEREF _Toc254031712 \h 30
HYPERLINK \l "_Toc254031713" 4.4 Property PAGEREF _Toc254031713 \h 31
HYPERLINK \l "_Toc254031714" 4.4.1 Property Type Compatibility PAGEREF _Toc254031714 \h 35
HYPERLINK \l "_Toc254031715" 4.5 Example Component PAGEREF _Toc254031715 \h 35
HYPERLINK \l "_Toc254031716" 5 Composite PAGEREF _Toc254031716 \h 38
HYPERLINK \l "_Toc254031718" 5.1 Service PAGEREF _Toc254031718 \h 39
HYPERLINK \l "_Toc254031719" 5.1.1 Service Examples PAGEREF _Toc254031719 \h 41
HYPERLINK \l "_Toc254031720" 5.2 Reference PAGEREF _Toc254031720 \h 42
HYPERLINK \l "_Toc254031721" 5.2.1 Example Reference PAGEREF _Toc254031721 \h 45
HYPERLINK \l "_Toc254031722" 5.3 Property PAGEREF _Toc254031722 \h 47
HYPERLINK \l "_Toc254031723" 5.3.1 Property Examples PAGEREF _Toc254031723 \h 48
HYPERLINK \l "_Toc254031724" 5.4 Wire PAGEREF _Toc254031724 \h 50
HYPERLINK \l "_Toc254031726" 5.4.1 Wire Examples PAGEREF _Toc254031726 \h 52
HYPERLINK \l "_Toc254031727" 5.4.2 Autowire PAGEREF _Toc254031727 \h 53
HYPERLINK \l "_Toc254031729" 5.4.3 Autowire Examples PAGEREF _Toc254031729 \h 54
HYPERLINK \l "_Toc254031731" 5.5 Using Composites as Component Implementations PAGEREF _Toc254031731 \h 57
HYPERLINK \l "_Toc254031732" 5.5.1 Component Type of a Composite used as a Component Implementation PAGEREF _Toc254031732 \h 58
HYPERLINK \l "_Toc254031733" 5.5.2 Example of Composite used as a Component Implementation PAGEREF _Toc254031733 \h 59
HYPERLINK \l "_Toc254031734" 5.6 Using Composites through Inclusion PAGEREF _Toc254031734 \h 60
HYPERLINK \l "_Toc254031736" 5.6.1 Included Composite Examples PAGEREF _Toc254031736 \h 61
HYPERLINK \l "_Toc254031737" 5.7 Composites which Contain Component Implementations of Multiple Types PAGEREF _Toc254031737 \h 64
HYPERLINK \l "_Toc254031738" 5.8 Structural URI of Components PAGEREF _Toc254031738 \h 64
HYPERLINK \l "_Toc254031806" 6 Interface PAGEREF _Toc254031806 \h 67
HYPERLINK \l "_Toc254031807" 6.1 Local and Remotable Interfaces PAGEREF _Toc254031807 \h 68
HYPERLINK \l "_Toc254031808" 6.2 Interface Compatibility PAGEREF _Toc254031808 \h 68
HYPERLINK \l "_Toc254031809" 6.2.1 Compatible Interfaces PAGEREF _Toc254031809 \h 69
HYPERLINK \l "_Toc254031810" 6.2.2 Compatible Subset PAGEREF _Toc254031810 \h 69
HYPERLINK \l "_Toc254031811" 6.2.3 Compatible Superset PAGEREF _Toc254031811 \h 70
HYPERLINK \l "_Toc254031812" 6.3 Bidirectional Interfaces PAGEREF _Toc254031812 \h 70
HYPERLINK \l "_Toc254031813" 6.4 Long-running Request-Response Operations PAGEREF _Toc254031813 \h 71
HYPERLINK \l "_Toc254031814" 6.4.1 Background PAGEREF _Toc254031814 \h 71
HYPERLINK \l "_Toc254031815" 6.4.2 Definition of "long-running" PAGEREF _Toc254031815 \h 72
HYPERLINK \l "_Toc254031816" 6.4.3 The asyncInvocation Intent PAGEREF _Toc254031816 \h 72
HYPERLINK \l "_Toc254031817" 6.4.4 Requirements on Bindings PAGEREF _Toc254031817 \h 72
HYPERLINK \l "_Toc254031818" 6.4.5 Implementation Type Support PAGEREF _Toc254031818 \h 72
HYPERLINK \l "_Toc254031819" 6.5 SCA-Specific Aspects for WSDL Interfaces PAGEREF _Toc254031819 \h 72
HYPERLINK \l "_Toc254031820" 6.6 WSDL Interface Type PAGEREF _Toc254031820 \h 73
HYPERLINK \l "_Toc254031821" 6.6.1 Example of interface.wsdl PAGEREF _Toc254031821 \h 74
HYPERLINK \l "_Toc254031822" 7 Binding PAGEREF _Toc254031822 \h 75
HYPERLINK \l "_Toc254031823" 7.1 Messages containing Data not defined in the Service Interface PAGEREF _Toc254031823 \h 77
HYPERLINK \l "_Toc254031824" 7.2 WireFormat PAGEREF _Toc254031824 \h 77
HYPERLINK \l "_Toc254031825" 7.3 OperationSelector PAGEREF _Toc254031825 \h 77
HYPERLINK \l "_Toc254031826" 7.4 Form of the URI of a Deployed Binding PAGEREF _Toc254031826 \h 78
HYPERLINK \l "_Toc254031827" 7.4.1 Non-hierarchical URIs PAGEREF _Toc254031827 \h 78
HYPERLINK \l "_Toc254031828" 7.4.2 Determining the URI scheme of a deployed binding PAGEREF _Toc254031828 \h 78
HYPERLINK \l "_Toc254031829" 7.5 SCA Binding PAGEREF _Toc254031829 \h 79
HYPERLINK \l "_Toc254031830" 7.5.1 Example SCA Binding PAGEREF _Toc254031830 \h 80
HYPERLINK \l "_Toc254031831" 7.6 Web Service Binding PAGEREF _Toc254031831 \h 81
HYPERLINK \l "_Toc254031832" 7.7 JMS Binding PAGEREF _Toc254031832 \h 81
HYPERLINK \l "_Toc254031833" 8 SCA Definitions PAGEREF _Toc254031833 \h 82
HYPERLINK \l "_Toc254031834" 9 Extension Model PAGEREF _Toc254031834 \h 83
HYPERLINK \l "_Toc254031835" 9.1 Defining an Interface Type PAGEREF _Toc254031835 \h 83
HYPERLINK \l "_Toc254031836" 9.2 Defining an Implementation Type PAGEREF _Toc254031836 \h 84
HYPERLINK \l "_Toc254031837" 9.3 Defining a Binding Type PAGEREF _Toc254031837 \h 86
HYPERLINK \l "_Toc254031838" 9.4 Defining an Import Type PAGEREF _Toc254031838 \h 88
HYPERLINK \l "_Toc254031839" 9.5 Defining an Export Type PAGEREF _Toc254031839 \h 89
HYPERLINK \l "_Toc254031840" 10 Packaging and Deployment PAGEREF _Toc254031840 \h 92
HYPERLINK \l "_Toc254031841" 10.1 Domains PAGEREF _Toc254031841 \h 92
HYPERLINK \l "_Toc254031842" 10.2 Contributions PAGEREF _Toc254031842 \h 92
HYPERLINK \l "_Toc254031843" 10.2.1 SCA Artifact Resolution PAGEREF _Toc254031843 \h 93
HYPERLINK \l "_Toc254031844" 10.2.2 SCA Contribution Metadata Document PAGEREF _Toc254031844 \h 95
HYPERLINK \l "_Toc254031845" 10.2.3 Contribution Packaging using ZIP PAGEREF _Toc254031845 \h 97
HYPERLINK \l "_Toc254031846" 10.3 States of Artifacts in the Domain PAGEREF _Toc254031846 \h 97
HYPERLINK \l "_Toc254031847" 10.4 Installed Contribution PAGEREF _Toc254031847 \h 98
HYPERLINK \l "_Toc254031848" 10.4.1 Installed Artifact URIs PAGEREF _Toc254031848 \h 98
HYPERLINK \l "_Toc254031849" 10.5 Operations for Contributions PAGEREF _Toc254031849 \h 98
HYPERLINK \l "_Toc254031850" 10.5.1 install Contribution & update Contribution PAGEREF _Toc254031850 \h 98
HYPERLINK \l "_Toc254031851" 10.5.2 add Deployment Composite & update Deployment Composite PAGEREF _Toc254031851 \h 99
HYPERLINK \l "_Toc254031852" 10.5.3 remove Contribution PAGEREF _Toc254031852 \h 99
HYPERLINK \l "_Toc254031853" 10.6 Use of Existing (non-SCA) Mechanisms for Resolving Artifacts PAGEREF _Toc254031853 \h 99
HYPERLINK \l "_Toc254031854" 10.7 Domain-Level Composite PAGEREF _Toc254031854 \h 100
HYPERLINK \l "_Toc254031855" 10.7.1 add To Domain-Level Composite PAGEREF _Toc254031855 \h 100
HYPERLINK \l "_Toc254031856" 10.7.2 remove From Domain-Level Composite PAGEREF _Toc254031856 \h 100
HYPERLINK \l "_Toc254031857" 10.7.3 get Domain-Level Composite PAGEREF _Toc254031857 \h 100
HYPERLINK \l "_Toc254031858" 10.7.4 get QName Definition PAGEREF _Toc254031858 \h 100
HYPERLINK \l "_Toc254031859" 10.8 Dynamic Behaviour of Wires in the SCA Domain PAGEREF _Toc254031859 \h 101
HYPERLINK \l "_Toc254031860" 10.9 Dynamic Behaviour of Component Property Values PAGEREF _Toc254031860 \h 101
HYPERLINK \l "_Toc254031861" 11 SCA Runtime Considerations PAGEREF _Toc254031861 \h 103
HYPERLINK \l "_Toc254031862" 11.1 Error Handling PAGEREF _Toc254031862 \h 103
HYPERLINK \l "_Toc254031863" 11.1.1 Errors which can be Detected at Deployment Time PAGEREF _Toc254031863 \h 103
HYPERLINK \l "_Toc254031864" 11.1.2 Errors which are Detected at Runtime PAGEREF _Toc254031864 \h 103
HYPERLINK \l "_Toc254031865" 12 Conformance PAGEREF _Toc254031865 \h 105
HYPERLINK \l "_Toc254031866" 12.1 SCA Documents PAGEREF _Toc254031866 \h 105
HYPERLINK \l "_Toc254031867" 12.2 SCA Runtime PAGEREF _Toc254031867 \h 105
HYPERLINK \l "_Toc254031868" 12.2.1 Optional Items PAGEREF _Toc254031868 \h 106
HYPERLINK \l "_Toc254031869" A. XML Schemas PAGEREF _Toc254031869 \h 107
HYPERLINK \l "_Toc254031870" A.1 sca.xsd PAGEREF _Toc254031870 \h 107
HYPERLINK \l "_Toc254031871" A.2 sca-core.xsd PAGEREF _Toc254031871 \h 107
HYPERLINK \l "_Toc254031873" A.3 sca-binding-sca.xsd PAGEREF _Toc254031873 \h 115
HYPERLINK \l "_Toc254031875" A.4 sca-interface-java.xsd PAGEREF _Toc254031875 \h 115
HYPERLINK \l "_Toc254031877" A.5 sca-interface-wsdl.xsd PAGEREF _Toc254031877 \h 115
HYPERLINK \l "_Toc254031879" A.6 sca-implementation-java.xsd PAGEREF _Toc254031879 \h 116
HYPERLINK \l "_Toc254031880" A.7 sca-implementation-composite.xsd PAGEREF _Toc254031880 \h 116
HYPERLINK \l "_Toc254031882" A.8 sca-binding-webservice.xsd PAGEREF _Toc254031882 \h 116
HYPERLINK \l "_Toc254031883" A.9 sca-binding-jms.xsd PAGEREF _Toc254031883 \h 116
HYPERLINK \l "_Toc254031884" A.10 sca-policy.xsd PAGEREF _Toc254031884 \h 116
HYPERLINK \l "_Toc254031886" A.11 sca-contribution.xsd PAGEREF _Toc254031886 \h 116
HYPERLINK \l "_Toc254031888" A.12 sca-definitions.xsd PAGEREF _Toc254031888 \h 118
HYPERLINK \l "_Toc254031890" B. SCA Concepts PAGEREF _Toc254031890 \h 119
HYPERLINK \l "_Toc254031891" B.1 Binding PAGEREF _Toc254031891 \h 119
HYPERLINK \l "_Toc254031893" B.2 Component PAGEREF _Toc254031893 \h 119
HYPERLINK \l "_Toc254031894" B.3 Service PAGEREF _Toc254031894 \h 119
HYPERLINK \l "_Toc254031895" B.3.1 Remotable Service PAGEREF _Toc254031895 \h 119
HYPERLINK \l "_Toc254031896" B.3.2 Local Service PAGEREF _Toc254031896 \h 120
HYPERLINK \l "_Toc254031898" B.4 Reference PAGEREF _Toc254031898 \h 120
HYPERLINK \l "_Toc254031900" B.5 Implementation PAGEREF _Toc254031900 \h 120
HYPERLINK \l "_Toc254031901" B.6 Interface PAGEREF _Toc254031901 \h 120
HYPERLINK \l "_Toc254031903" B.7 Composite PAGEREF _Toc254031903 \h 121
HYPERLINK \l "_Toc254031905" B.8 Composite inclusion PAGEREF _Toc254031905 \h 121
HYPERLINK \l "_Toc254031907" B.9 Property PAGEREF _Toc254031907 \h 121
HYPERLINK \l "_Toc254031909" B.10 Domain PAGEREF _Toc254031909 \h 121
HYPERLINK \l "_Toc254031911" B.11 Wire PAGEREF _Toc254031911 \h 121
HYPERLINK \l "_Toc254031913" C. Conformance Items PAGEREF _Toc254031913 \h 122
HYPERLINK \l "_Toc254031914" C.1 Mandatory Items PAGEREF _Toc254031914 \h 122
HYPERLINK \l "_Toc254031915" C.2 Non-mandatory Items PAGEREF _Toc254031915 \h 132
HYPERLINK \l "_Toc254031916" D. Acknowledgements PAGEREF _Toc254031916 \h 134
HYPERLINK \l "_Toc254031917" E. Non-Normative Text PAGEREF _Toc254031917 \h 136
HYPERLINK \l "_Toc254031918" F. Revision History PAGEREF _Toc254031918 \h 137
Introduction
This document describes the SCA Assembly Model, which covers
A model for the assembly of services, both tightly coupled and loosely coupled
A model for applying infrastructure capabilities to services and to service interactions, including Security and Transactions
The document starts with a short overview of the SCA Assembly Model.
The next part of the document describes the core elements of SCA, SCA components and SCA composites.
The final part of the document defines how the SCA assembly model can be extended.
This specification is defined in terms of Infoset and not in terms of XML 1.0, even though the specification uses XML 1.0 terminology. A mapping from XML to infoset is trivial and it is suggested that this is used for any non-XML serializations.
Terminology
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in REF rfc2119 \h [RFC2119].
Normative References
[RFC2119]
S. Bradner, Key words for use in RFCs to Indicate Requirement Levels,
IETF RFC 2119, March 1997.
HYPERLINK "http://www.ietf.org/rfc/rfc2119.txt" http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997.
[SCA-Java]
OASIS Committee Draft 01, "SCA JavaPOJO Component Implementation Specification Version 1.1", May 2009
HYPERLINK "http://wwwdocs.oasis-open.org/apps/org/workgroupopencsa/sca-j/download.php/31447/sca-javaci-1.1-spec-wd03cd01.pdf" http://wwwdocs.oasis-open.org/apps/org/workgroupopencsa/sca-j/download.php/31447/sca-javaci-1.1-spec-wd03cd01.pdf
[SCA-Common-Java]
OASIS Committee Draft 03, "SCA Java Common Annotations and APIs Specification Version 1.1", May 2009
HYPERLINK "http://wwwdocs.oasis-open.org/apps/org/workgroupopencsa/sca-j/download.php/31427/sca-javacaa-1.1-spec-cd02cd03.pdf" http://wwwdocs.oasis-open.org/apps/org/workgroupopencsa/sca-j/download.php/31427/sca-javacaa-1.1-spec-cd02cd03.pdf
[SCA BPEL]
OASIS Committee Draft 02, "SCA WS-BPEL Client and Implementation Specification Version 1.1", March 2009
HYPERLINK "http://docs.oasis-open.org/opencsa/sca-bpel/sca-bpel-1.1-spec-cd-0102.pdf%20" http://docs.oasis-open.org/opencsa/sca-bpel/sca-bpel-1.1-spec-cd-0102.pdf
[SDO] SDO
OASIS Committee Draft 02, "Service Data Objects Specification Version 3.0", November 2009
HYPERLINK "http://www.osoa.org/download/attachments/36/Java-SDO-Spec-v2.1.0-FINAL.pdf" HYPERLINK "http://docs.oasis-open.org/opencsa/sdo/sd0-core-3.0-spec-cd02.pdf" http://www.osoa.org/download/attachments/36/Java-SDO-Spec-v2.1.0-FINAL.pdfhttp://docs.oasis-open.org/opencsa/sdo/sd0-core-3.0-spec-cd02.pdf
[3] SCA Example Code document
[JAX-WS]
JAX-WS Specification
HYPERLINK "http://www.osoajcp.org/download/attachments/28/SCA_BuildingYourFirstApplication_V09.pdf" en/jsr/detail?id=224" http://www.osoa.org/download/attachments/28/SCA_BuildingYourFirstApplication_V09.pdfhttp://jcp.org/en/jsr/detail?id=224
[4] JAX-WS SpecificationWSI-BP]
HYPERLINK "http://jcp.org/en/jsr/detail?id=101" http://jcp.org/en/jsr/detail?id=101
[5] WS-I Basic Profile
HYPERLINK "http://www.ws-i.org/deliverables/workinggroup.aspx?wg=basicprofile" http://www.ws-i.org/deliverables/workinggroup.aspx?wg=basicprofile
[6] WSI-BSP]
WS-I Basic Security Profile
HYPERLINK "http://www.ws-i.org/deliverables/workinggroup.aspx?wg=basicsecurity" http://www.ws-i.org/deliverables/workinggroup.aspx?wg=basicsecurity
[7]WS-BPEL]
OASIS Standard, "Web Services Business Process Execution Language (BPEL)Version 2.0"
HYPERLINK "http://wwwdocs.oasis-open.org/committees/documents.php?wg_abbrev=wsbpel" /2.0/OS/wsbpel-v2.0-OS.pdf"http://wwwdocs.oasis-open.org/committees/documents.php?wg_abbrev=wsbpel/2.0/OS/wsbpel-v2.0-OS.pdf
[8] WSDL-11]
WSDL Specification version 1.1
WSDL 1.1: HYPERLINK "http://www.w3.org/TR/wsdl" http://www.w3.org/TR/wsdl
WSDL 2.0:
[SCA-WSBINDING]
OASIS Committee Draft 03, "SCA Web Services Binding Specification Version 1.1", July 2009
HYPERLINK "http://www.w3docs.oasis-open.org/TR/wsdl20/opencsa/sca-bindings/sca-wsbinding-1.1-spec-cd03.pdf" http://www.w3docs.oasis-open.org/TR/wsdl20/opencsa/sca-bindings/sca-wsbinding-1.1-spec-cd03.pdf
[9] SCA Web Services Binding Specification
[SCA-POLICY]
OASIS Committee Draft 02, "SCA Policy Framework Specification Version 1.1", February 2009
HYPERLINK "http://docs.oasis-open.org/opencsa/sca-bindingspolicy/sca-wsbindingpolicy-1.1-spec-cd01cd02.pdf" "http://docs.oasis-open.org/opencsa/sca-bindingspolicy/sca-wsbindingpolicy-1.1-spec-cd01cd02.pdf
[10] SCA Policy Framework-JMSBINDING ]
OASIS Committee Draft 03, "SCA JMS Binding Specification Version 1.1 Version 1.1", July 2009
HYPERLINK "http://docs.oasis-open.org/opencsa/sca-policybindings/sca-policyjmsbinding-1.1-spec-cd-0103.pdf" http://docs.oasis-open.org/opencsa/sca-policybindings/sca-policyjmsbinding-1.1-spec-cd-0103.pdf
[11]
[SCA JMS Binding-CPP-Client]
OASIS Committee Draft 04, "SCA Client and Implementation for C++ Specification Version 1.1", March 2009
HYPERLINK "http://docs.oasis-open.org/opencsa/sca-bindingsc-cpp/sca-jmsbindingcppcni-1.1-spec-cd01cd04.pdf" "http://docs.oasis-open.org/opencsa/sca-bindingsc-cpp/sca-jmsbindingcppcni-1.1-spec-cd01cd04.pdf
[SCA-CPP-Client]
OASIS Committee Draft 03, "SCA C++ Client and Implementation for C Specification Version 1.1", March 2009
HYPERLINK "http://docs.oasis-open.org/opencsa/sca-c-cpp/sca-cppcniccni-1.1-spec-cd-0104.pdf" http://docs.oasis-open.org/opencsa/sca-c-cpp/sca-cppcniccni-1.1-spec-cd-0104.pdf
[SCA-C-Client] SCA C Client and Implementation SpecificationZIP-FORMAT]
HYPERLINK "http://docs.oasis-open.org/opencsa/sca-c-cpp/sca-ccni-1.1-spec-cd-01.pdf" http://docs.oasis-open.org/opencsa/sca-c-cpp/sca-ccni-1.1-spec-cd-01.pdf
[12] ZIP Format Definition
HYPERLINK "http://www.pkware.com/documents/casestudies/APPNOTE.TXT" http://www.pkware.com/documents/casestudies/APPNOTE.TXT
[13] XML-INFOSET]
Infoset Specification
HYPERLINK "http://www.w3.org/TR/xml-infoset/" http://www.w3.org/TR/xml-infoset/
[WSDL11_Identifiers]
WSDL 1.1 Element Identiifiers
HYPERLINK "http://www.w3.org/TR/wsdl11elementidentifiers/" http://www.w3.org/TR/wsdl11elementidentifiers/
Naming Conventions
This specification follows some naming conventions for artifacts defined by the specification,
as follows:
For the names of elements and the names of attributes within XSD files, the names follow the CamelCase convention, with all names starting with a lower case letter.e.g.
For the names of types within XSD files, the names follow the CamelCase convention with all names starting with an upper case letter. eg.
For the names of intents, the names follow the CamelCase convention, with all names starting with a lower case letter, EXCEPT for cases where the intent represents an established acronym, in which case the entire name is in upper case. An example of an intent which is an acronym is the "SOAP" intent.
Overview
Service Component Architecture (SCA) provides a programming model for building applications and solutions based on a Service Oriented Architecture. It is based on the idea that business function is provided as a series of services, which are assembled together to create solutions that serve a particular business need. These composite applications can contain both new services created specifically for the application and also business function from existing systems and applications, reused as part of the composition. SCA provides a model both for the composition of services and for the creation of service components, including the reuse of existing application function within SCA composites.
SCA is a model that aims to encompass a wide range of technologies for service components and for the access methods which are used to connect them. For components, this includes not only different programming languages, but also frameworks and environments commonly used with those languages. For access methods, SCA compositions allow for the use of various communication and service access technologies that are in common use, including, for example, Web services, Messaging systems and Remote Procedure Call (RPC).
The SCA Assembly Model consists of a series of artifacts which define the configuration of an SCA Domain in terms of composites which contain assemblies of service components and the connections and related artifacts which describe how they are linked together.
One basic artifact of SCA is the component, which is the unit of construction for SCA. A component consists of a configured instance of an implementation, where an implementation is the piece of program code providing business functions. The business function is offered for use by other components as services. Implementations can depend on services provided by other components these dependencies are called references. Implementations can have settable properties, which are data values which influence the operation of the business function. The component configures the implementation by providing values for the properties and by wiring the references to services provided by other components.
SCA allows for a wide variety of implementation technologies, including "traditional" programming languages such as Java, C++, and BPEL, but also scripting languages such as PHP and JavaScript and declarative languages such as XQuery and SQL.
SCA describes the content and linkage of an application in assemblies called composites. Composites can contain components, services, references, property declarations, plus the wiring that describes the connections between these elements. Composites can group and link components built from different implementation technologies, allowing appropriate technologies to be used for each business task. In turn, composites can be used as complete component implementations: providing services, depending on references and with settable property values. Such composite implementations can be used in components within other composites, allowing for a hierarchical construction of business solutions, where high-level services are implemented internally by sets of lower-level services. The content of composites can also be used as groupings of elements which are contributed by inclusion into higher-level compositions.
Composites are deployed within an SCA Domain. An SCA Domain typically represents a set of services providing an area of business functionality that is controlled by a single organization. As an example, for the accounts department in a business, the SCA Domain might cover all financial related function, and it might contain a series of composites dealing with specific areas of accounting, with one for customer accounts, another dealing with accounts payable. To help build and configure the SCA Domain, composites can be used to group and configure related artifacts.
SCA defines an XML file format for its artifacts. These XML files define the portable representation of the SCA artifacts. An SCA runtime might have other representations of the artifacts represented by these XML files. In particular, component implementations in some programming languages might have attributes or properties or annotations which can specify some of the elements of the SCA Assembly model. The XML files define a static format for the configuration of an SCA Domain. An SCA runtime might also allow for the configuration of the Domain to be modified dynamically.
Diagram used to Represent SCA Artifacts
This document introduces diagrams to represent the various SCA artifacts, as a way of visualizing the relationships between the artifacts in a particular assembly. These diagrams are used in this document to accompany and illuminate the examples of SCA artifacts and do not represent any formal graphical notation for SCA.
The following picture REF _ R e f 2 3 8 8 9 3 3 4 6 \ h F i g u r e 2 1 F i g u r e 2 1 i l l u s t r a t e s s o m e o f t h e f e a t u r e s o f a n S C A c o m p o n e n t :
F i g u r e S E Q F i g u r e \ * A R A B I C 1 S T Y L E R E F 1 \ s 2 2 S E Q F i g u r e \ * A R A B I C \ s 1 1 : S C A C o m p o n e n t D i a g r a m
T h e f o l l o w i n g p i c t u r e R E F _ R e f 2 3 8 8 9 3 4 0 4 \ h F i g u r e 2 2 F i g u r e 2 2 i l l u s t r a t e s s o m e o f t h e f e a t u r e s o f a c o m p o s i t e a s s e m b l e d u s i n g a s e t o f c o m p o n e n t s :
F i g u r e S E Q F i g u r e \ * A R A B I C 2 S T Y L E R E F 1 \ s 2 2 S E Q F i g u r e \ * A R A B I C \ s 1 2 : S C A C o m p o s i t e D i a g r a m
T h e f o l l o w i n g p i c t u r e R E F _ R e f 2 3 8 8 9 3 4 4 7 \ h F i g u r e 2 3 F i g u r e 2 3 i l l u s t r a t e s a n S C A D o m a i n a s s e m b l e d f r o m a s e r i e s o f h i g h - l e v e l c o m p o s i t e s , s o m e o f w h i c h a r e i n t u r n i m p l e m e n t e d b y l o w e r - l e v e l c o m p o s i t e s :
F i g u r e S E Q F i g u r e \ * A R A B I C 3 S T Y L E R E F 1 \ s 2 2 S E Q F i g u r e \ * ARABIC \s 1 3: SCA Domain Diagram
Implementation and ComponentType
Component implementations are concrete implementations of business function which provide services and/or which make references to services provided elsewhere. In addition, an implementation can have some settable property values.
SCA allows a choice of any one of a wide range of implementation types, such as Java, BPEL or C++, where each type represents a specific implementation technology. The technology might not simply define the implementation language, such as Java, but might also define the use of a specific framework or runtime environment. Examples include SCA Composite, Java implementations done using the Spring framework or the Java EE EJB technology.
Services, references and properties are the configurable aspects of an implementation. SCA refers to them collectively as the component type.
Depending on the implementation type, the implementation can declare the services, references and properties that it has and it also might be able to set values for all the characteristics of those services, references and properties.
So, for example:
for a service, the implementation might define the interface, binding(s), a URI, intents, and policy sets, including details of the bindings
for a reference, the implementation might define the interface, binding(s), target URI(s), intents, policy sets, including details of the bindings
for a property the implementation might define its type and a default value
the implementation itself might define policy intents or concrete policy sets
The means by which an implementation declares its services, references and properties depend on the type of the implementation. For example, some languages like Java, provide annotations which can be used to declare this information inline in the code.
Most of the characteristics of the services, references and properties can be overridden by a component that uses and configures the implementation, or the component can decide not to override those characteristics. Some characteristics cannot be overridden, such as intents. Other characteristics, such as interfaces, can only be overridden in particular controlled ways (see HYPERLINK \l "_Component" the Component section for details).
Component Type
Component type represents the configurable aspects of an implementation. A component type consists of services that are offered, references to other services that can be wired and properties that can be set. The settable properties and the settable references to services are configured by a component that uses the implementation.
An implementation type specification (for example, the WS-BPEL Client and Implementation Specification Version 1.1 [SCA BPEL]) specifies the mechanism(s) by which the component type associated with an implementation of that type is derived.
Since SCA allows a broad range of implementation technologies, it is expected that some implementation technologies (for example, the Java Component Implementation Specification Version 1.1 [SCA-Java]) allow for introspecting the implementation artifact(s) (for example, a Java class) to derive the component type information. Other implementation technologies might not allow for introspection of the implementation artifact(s). In those cases where introspection is not allowed, SCA encourages the use of a SCA component type side file. A component type side file is an XML file whose document root element is sca:componentType.
The implementation type specification defines whether introspection is allowed, whether a side file is allowed, both are allowed or some other mechanism specifies the component type. The component type information derived through introspection is called the introspected component type. In any case, the implementation type specification specifies how multiple sources of information are combined to produce the effective component type. The effective component type is the component type metadata that is presented to the using component for configuration.
REF ASM40001 \h The extension of a componentType side file name MUST be .componentType. [ASM40001] The name and location of a componentType side file, if allowed, is defined by the implementation type specification.
If a component type side file is not allowed for a particular implementation type, the effective component type and introspected component type are one and the same for that implementation type.
For the rest of this document, when the term 'component type' is used it refers to the 'effective component type'.
The following s n i p p e t R E F _ R e f 2 3 8 8 9 3 5 7 5 \ h S n i p p e t 3 1 S n i p p e t 3 1 s h o w s t h e c o m p o n e n t T y p e p s e u d o - s c h e m a :
<