Service Component Architecture Assembly Model Specification
Version 1.1
12 January 2010
Specification URIs:
This Version:
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.doc
http://docs.oasis-open.org/opencsa/sca-assembly/sca-assembly-1.1-spec-cd05.pdf (Authoritative)
Previous Version:
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.doc
http://docs.oasis-open.org/opencsa/sca-assembly/sca-assembly-1.1-spec-cd03.pdf (Authoritative)
Latest Version:
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.doc
http://docs.oasis-open.org/opencsa/sca-assembly/sca-assembly-1.1-spec.pdf (Authoritative)
Technical Committee:
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:
This specification is related to:
Declared XML Namespace(s):
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 Committee’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.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 (http://www.oasis-open.org/committees/sca-assembly/ipr.php.
The non-normative errata page for this
specification is located at
http://www.oasis-open.org/committees/sca-assembly/
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", "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 http://www.oasis-open.org/who/trademark.php for above guidance.
2.1 Diagram used to Represent SCA Artifacts
3 Implementation and ComponentType
4.3.1 Specifying the Target Service(s) for a Reference.
4.4.1 Property Type Compatibility
5.5 Using Composites as Component Implementations
5.5.1 Component Type of a Composite used as a Component Implementation
5.5.2 Example of Composite used as a Component Implementation
5.6 Using Composites through Inclusion
5.6.1 Included Composite Examples
5.7 Composites which Contain Component Implementations of Multiple Types
5.8 Structural URI of Components
6.1 Local and Remotable Interfaces
6.4 Long-running Request-Response Operations
6.4.2 Definition of "long-running"
6.4.3 The asyncInvocation Intent
6.4.4 Requirements on Bindings
6.4.5 Implementation Type Support
6.5 SCA-Specific Aspects for WSDL Interfaces
6.6.1 Example of interface.wsdl
7.1 Messages containing Data not defined in the Service Interface
7.4 Form of the URI of a Deployed Binding
7.4.2 Determining the URI scheme of a deployed binding
9.1 Defining an Interface Type
9.2 Defining an Implementation Type
10.2.1 SCA Artifact Resolution
10.2.2 SCA Contribution Metadata Document
10.2.3 Contribution Packaging using ZIP
10.3 States of Artifacts in the Domain
10.4.1 Installed Artifact URIs
10.5 Operations for Contributions
10.5.1 install Contribution & update Contribution
10.5.2 add Deployment Composite & update Deployment Composite
10.6 Use of Existing (non-SCA) Mechanisms for Resolving Artifacts
10.7.1 add To Domain-Level Composite
10.7.2 remove From Domain-Level Composite
10.7.3 get Domain-Level Composite
10.8 Dynamic Behaviour of Wires in the SCA Domain
10.9 Dynamic Behaviour of Component Property Values.
11.1.1 Errors which can be Detected at Deployment Time
11.1.2 Errors which are Detected at Runtime
A.6 sca-implementation-java.xsd
A.7 sca-implementation-composite.xsd
A.8 sca-binding-webservice.xsd
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.
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 [RFC2119].
S. Bradner, Key words for use in RFCs to Indicate Requirement
Levels,
IETF RFC 2119, March 1997.
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
OASIS Committee Draft 03, "SCA Java Common Annotations and APIs Specification Version 1.1", May 2009
[SCA BPEL]
OASIS Committee Draft 02, "SCA WS-BPEL Client and Implementation Specification Version 1.1", March 2009
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
[3] SCA Example Code document
JAX-WS Specification
[4] JAX-WS SpecificationWSI-BP]
http://jcp.org/en/jsr/detail?id=101
[5] WS-I
Basic Profile
http://www.ws-i.org/deliverables/workinggroup.aspx?wg=basicprofile
WS-I Basic Security Profile
http://www.ws-i.org/deliverables/workinggroup.aspx?wg=basicsecurity
OASIS Standard,
"Web Services Business Process Execution Language (BPEL)Version
2.0"
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: http://www.w3.org/TR/wsdl
WSDL 2.0:
OASIS Committee Draft 03, "SCA Web Services Binding Specification Version 1.1", July 2009
http://www.w3docs.oasis-open.org/TR/wsdl20/opencsa/sca-bindings/sca-wsbinding-1.1-spec-cd03.pdf
[9] SCA Web
Services Binding Specification
OASIS Committee Draft 02, "SCA Policy Framework Specification Version 1.1", February 2009
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
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
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
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]
http://docs.oasis-open.org/opencsa/sca-c-cpp/sca-ccni-1.1-spec-cd-01.pdf
[12] ZIP Format Definition
http://www.pkware.com/documents/casestudies/APPNOTE.TXT
[13] XML-INFOSET]
Infoset Specification
http://www.w3.org/TR/xml-infoset/
[WSDL11_Identifiers]
WSDL 1.1 Element Identiifiers
http://www.w3.org/TR/wsdl11elementidentifiers/
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. <element name="componentType"
type="sca:ComponentType"/>
·
For the names of types within XSD files, the names follow the
CamelCase convention with all names starting with an upper case letter.
eg. <complexType name="ComponentService">
·
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.
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.
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 pictureFigure
2‑1Figure
2‑1
illustrates some of the features of an SCA component:
Figure 122‑1:
SCA Component Diagram
The following pictureFigure
2‑2Figure
2‑2
illustrates some of the features of a composite assembled using a set of
components:
Figure 222‑2:
SCA Composite Diagram
The following pictureFigure
2‑3Figure
2‑3
illustrates an SCA Domain assembled from a series of high-level composites,
some of which are in turn implemented by lower-level composites:
Figure 322‑3:
SCA Domain Diagram
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 the Component section for details).
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.
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 snippetSnippet 3‑1Snippet 3‑1 shows the componentType pseudo-schema:
<?xml version="1.0" encoding="ASCII"?>
<!-- Component type schema snippet -->
<componentType
xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200903"
constrainingType="xs:QName"? 200912">
<service … />*
<reference … />*
<property … />*
<implementation … />?
</componentType>
The componentType element has the
following attribute:
·constrainingType :
QName (0..1) – If present, the @constrainingType attribute of a
<componentType/> element MUST reference a <constrainingType/>
element in the Domain through its QName. [ASM40002]
When specified, the set of services, references and properties of the
implementation, plus related intents, is constrained to the set defined by the
constrainingType. See the
ConstrainingType Section for more details.
The componentType element has the
following child elements:
Snippet 33‑1: componentType Pseudo-Schema
The componentType element has the child elements:
· service : Service (0..n) – see component type service section.
· reference : Reference (0..n) – see component type reference section.
· property : Property (0..n) – see component type property section.
· implementation : Implementation (0..1) – see component type implementation section.
A Service represents an addressable
interface of the implementation. The service is represented by a service
element which is a child of the componentType element. There can be zero
or more service elements in a componentType. The following
snippetSnippet
3‑2Snippet
3‑2
shows the component type componentType pseudo-schema
with the pseudo-schema for a service child
element:
<?xml version="1.0" encoding="ASCII"?>
<!-- Component type service schema snippet -->
<componentType
xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200903200912" … >
<service name="xs:NCName"
requires="list of xs:QName"? policySets="list of xs:QName"?>*
<interface … />
<binding … />*
<callback>?
<binding … />+
</callback>
<requires/>*
<policySetAttachment/>*
</service>
<reference … />*
<property … />*
<implementation … />?
</componentType>
Snippet 33‑2: componentType Pseudo-Schema with service Child Element
The service element has the following
attributes:
· name : NCName (1..1) - the name of the service. The @name attribute of a <service/> child element of a <componentType/> MUST be unique amongst the service elements of that <componentType/>. [ASM40003]
·
requires : QNamelistOfQNames (0..n1)
- a list of policy intents. See the Policy Framework specification
[10]SCA-POLICY] for a description of this attribute.
·
policySets : QNamelistOfQNames (0..n1)
- a list of policy sets. See
the Policy Framework specification [10]SCA-POLICY] for a description of this attribute.
The service element has the following
child elements:
· interface : Interface (1..1) - A service has one interface, which describes the operations provided by the service. For details on the interface element see the Interface section.
· binding : Binding (0..n) - A service element has zero or more binding elements as children. If the binding element is not present it defaults to <binding.sca>. Details of the binding element are described in the Bindings section.
· callback (0..1) / binding : Binding (1..n) - A callback element is used if the interface has a callback defined, and the callback element has one or more binding elements as subelements. The callback and its binding subelements are specified if there is a need to have binding details used to handle callbacks. If the callback element is not present, the behaviour is runtime implementation dependent. For details on callbacks, see the Bidirectional Interfaces section.
· requires : requires (0..n) - A service element has zero or more requires subelements. See the Policy Framework specification [SCA-POLICY] for a description of this element.
· policySetAttachment : policySetAttachment (0..n) - A service element has zero or more policySetAttachment subelements. See the Policy Framework specification [SCA-POLICY] for a description of this element.
A Reference represents a requirement that the implementation
has on a service provided by another component. The reference is represented by
a reference element which is a child of the componentType element.
There can be zero or more reference elements in a component type definition. The following snippetSnippet 3‑3Snippet 3‑3 shows the component
type componentType pseudo-schema
with the pseudo-schema for a reference child element:
<?xml version="1.0" encoding="ASCII"?>
<!-- Component type reference schema snippet -->
<componentType
xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200903200912" … >
<service … />*
<reference name="xs:NCName"
autowire="xs:boolean"?
multiplicity="0..1 or 1..1 or 0..n or 1..n"?
wiredByImpl="xs:boolean"?
requires="list of xs:QName"?
policySets="list of xs:QName"?>*
<interface … />
<binding … />*
<callback>?
<binding … />+
</callback>
<requires/>*
<policySetAttachment/>*
</reference>
<property … />*
<implementation … />?
</componentType>
Snippet 33‑3: componentType Pseudo-Schema with reference Child Element
The reference element has the following
attributes:
· name : NCName (1..1) - the name of the reference. The @name attribute of a <reference/> child element of a <componentType/> MUST be unique amongst the reference elements of that <componentType/>. [ASM40004]
· multiplicity : 0..1|1..1|0..n|1..n (0..1) - defines the number of wires that can connect the reference to target services. The multiplicity can have the following values
– 0..1 – zero or one wire can have the reference as a source
– 1..1 – one wire can have the reference as a source
– 0..n - zero or more wires can have the reference as a source
– 1..n – one or more wires can have the reference as a source
If @multiplicity is not specified, the default value is "1..1".
· autowire : boolean (0..1) - whether the reference is autowired, as described in the Autowire section. Default is false.
· wiredByImpl : boolean (0..1) - a boolean value, "false" by default. If set to "false", the reference is wired to the target(s) configured on the reference. If set to "true" it indicates that the target of the reference is set at runtime by the implementation code (e.g. by the code obtaining an endpoint reference by some means and setting this as the target of the reference through the use of programming interfaces defined by the relevant Client and Implementation specification). If @wiredByImpl is set to "true", then any reference targets configured for this reference MUST be ignored by the runtime. [ASM40006]
·
requires : QNamelistOfQNames (0..n1)
- a list of policy intents. See the Policy Framework specification
[10]SCA-POLICY] for a description of this attribute.
·
policySets : QNamelistOfQNames (0..n1)
- a list of policy sets. See
the Policy Framework specification [10]SCA-POLICY] for a description of this attribute.
The reference element has the following
child elements:
· interface : Interface (1..1) - A reference has one interface, which describes the operations used by the reference. The interface is described by an interface element which is a child element of the reference element. For details on the interface element see the Interface section.
· binding : Binding (0..n) - A reference element has zero or more binding elements as children. Details of the binding element are described in the Bindings section.
When used with a reference element, a binding element specifies an endpoint which is the target of that binding. A reference cannot mix the use of endpoints specified via binding elements with target endpoints specified via the @target attribute. If the @target attribute is set, the reference cannot also have binding subelements. If binding elements with endpoints are specified, each endpoint uses the binding type of the binding element in which it is defined.
· callback (0..1) / binding : Binding (1..n) - al callback element is used if the interface has a callback defined and the callback element has one or more binding elements as subelements. The callback and its binding subelements are specified if there is a need to have binding details used to handle callbacks. If the callback element is not present, the behaviour is runtime implementation dependent. For details on callbacks, see the Bidirectional Interfaces section.
· requires : requires (0..n) - A service element has zero or more requires subelements. See the Policy Framework specification [SCA-POLICY] for a description of this element.
· policySetAttachment : policySetAttachment (0..n) - A service element has zero or more policySetAttachment subelements. See the Policy Framework specification [SCA-POLICY] for a description of this element.
For a full description of the setting of target service(s) for a reference, see the section "Specifying the Target Service(s) for a Reference".
Properties allow for the configuration of an implementation
with externally set values. Each Property is defined as a property element.
The componentType element can have zero
or more property elements as
its children. The following
snippetSnippet 3‑4Snippet 3‑4 shows the component type componentType pseudo-schema
with the pseudo-schema for a reference child element:
<?xml version="1.0" encoding="ASCII"?>
<!-- Component type property schema snippet -->
<componentType
xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200903200912" … >
<service … />*
<reference … >*
<property name="xs:NCName" (type="xs:QName" | element="xs:QName")
many="xs:boolean"?
mustSupply="xs:boolean"?
requires="list of
xs:QName"?
policySets="list of
xs:QName"?>*
default-property-value?
</property>
<implementation … />?
</componentType>
Snippet 33‑4: componentType Pseudo-Schema with property Child Element
The property element has the following
attributes:
· name : NCName (1..1) - the name of the property. The @name attribute of a <property/> child element of a <componentType/> MUST be unique amongst the property elements of that <componentType/>. [ASM40005]
· one of (1..1):
– type : QName - the type of the property defined as the qualified name of an XML schema type. The value of the property @type attribute MUST be the QName of an XML schema type. [ASM40007]
– element : QName - the type of the property defined as the qualified name of an XML schema global element – the type is the type of the global element. The value of the property @element attribute MUST be the QName of an XSD global element. [ASM40008]
A single property element MUST NOT contain both a @type attribute and an @element attribute. [ASM40010]
· many : boolean (0..1) - whether the property is single-valued (false) or multi-valued (true). In the case of a multi-valued property, it is presented to the implementation as a collection of property values. If many is not specified, it takes a default value of false.
· mustSupply : boolean (0..1) - whether the property value needs to be supplied by the component that uses the implementation. Default value is "false". When the componentType has @mustSupply="true" for a property element, a component using the implementation MUST supply a value for the property since the implementation has no default value for the property. [ASM40011] If the implementation has a default-property-value then @mustSupply="false" is appropriate, since the implication of a default value is that it is used when a value is not supplied by the using component.
· file : anyURI (0..1) - a dereferencable URI to a file containing a value for the property.
§requires
: QName (0..n) - a list of policy
intents. See the Policy Framework specification [10] for a
description of this attribute.
§policySets
: QName (0..n) - a list of policy
sets. See the Policy Framework specification [10] for a
description of this attribute.
The property element can contain a default property value as its content. The form of the default property value is as described in the section on Component Property.
The value for a property is supplied to the implementation of a component at the time that the implementation is started. The implementation can use the supplied value in any way that it chooses. In particular, the implementation can alter the internal value of the property at any time. However, if the implementation queries the SCA system for the value of the property, the value as defined in the SCA composite is the value returned.
The componentType property element can contain an SCA default value for the property declared by the implementation. However, the implementation can have a property which has an implementation defined default value, where the default value is not represented in the componentType. An example of such a default value is where the default value is computed at runtime by some code contained in the implementation. If a using component needs to control the value of a property used by an implementation, the component sets the value explicitly. The SCA runtime MUST ensure that any implementation default property value is replaced by a value for that property explicitly set by a component using that implementation. [ASM40009]
Implementation represents characteristics inherent to the
implementation itself, in particular intents and policies. See the Policy
Framework specification [10]SCA-POLICY] for a description of intents and policies. The following snippetSnippet 3‑5Snippet 3‑5 shows the component
typecomponentType pseudo-schema with the pseudo-schema for a
implementation child element:
<?xml version="1.0" encoding="ASCII"?>
<!-- Component type implementation schema snippet -->
<componentType
xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200903200912" … >
<service … />*
<reference … >*
<property … />*
<implementation requires="list of xs:QName"?
policySets="list of xs:QName"?/"?>
<requires/>*
<policySetAttachment/>*
</implementation>?
</componentType>
Snippet 33‑5: componentType Pseudo-Schema with implementation Child Element
The implementation element has the following
attributes:
·
requires : QNamelistOfQNames (0..n1)
- a list of policy intents. See the Policy Framework specification
[10]SCA-POLICY] for a description of this attribute.
·
policySets : QNamelistOfQNames (0..n1)
- a list of policy sets. See
the Policy Framework specification [10]SCA-POLICY] for a description of this attribute.
The implementation element has the subelements:
· requires : requires (0..n) - A service element has zero or more requires subelements. See the Policy Framework specification [SCA-POLICY] for a description of this element.
· policySetAttachment : policySetAttachment (0..n) - A service element has zero or more policySetAttachment subelements. See the Policy Framework specification [SCA-POLICY] for a description of this element.
The following snippetSnippet 3‑6Snippet 3‑6 shows the contents of the componentType file for
the MyValueServiceImpl implementation. The componentType file shows the
services, references, and properties of the MyValueServiceImpl implementation.
In this case, Java is used to define interfaces:
<?xml version="1.0" encoding="ASCII"?>
<componentType
xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200903">
<componentType xmlns=http://docs.oasis-open.org/ns/opencsa/sca/200912
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<service name="MyValueService">
<interface.java interface="services.myvalue.MyValueService"/>
</service>
<reference name="customerService">
<interface.java interface="services.customer.CustomerService"/>
</reference>
<reference name="stockQuoteService">
<interface.java
interface="services.stockquote.StockQuoteService"/>
</reference>
<property name="currency" type="xsd:string">USD</property>
</componentType>
Snippet 33‑6: Example componentType
The following is an example implementation, written
in Java. See the SCA Example Code document [3] for details.
Snippet 3‑7Snippet 3‑7 and Snippet 3‑8Snippet 3‑8 are an example implementation, written in Java.
AccountServiceImpl implements the AccountService interface, which is defined via a Java interface:
package services.account;
@Remotable
public interface AccountService {
AccountReport getAccountReport(String customerID);
}
The followingSnippet 33‑7:
Example Interface in Java
Snippet 3‑8Snippet 3‑8 is a full listing of the AccountServiceImpl class, showing the Service it implements, plus the service references it makes and the settable properties that it has. Notice the use of Java annotations to mark SCA aspects of the code, including the @Property, @Reference and @Service annotations:
package services.account;
import java.util.List;
import commonj.sdo.DataFactory;
import org.oasisopen.sca.annotation.Property;
import org.oasisopen.sca.annotation.Reference;
import org.oasisopen.sca.annotation.Service;
import services.accountdata.AccountDataService;
import services.accountdata.CheckingAccount;
import services.accountdata.SavingsAccount;
import services.accountdata.StockAccount;
import services.stockquote.StockQuoteService;
@Service(AccountService.class)
public class AccountServiceImpl implements AccountService {
@Property
private String currency = "USD";
@Reference
private AccountDataService accountDataService;
@Reference
private StockQuoteService stockQuoteService;
public AccountReport getAccountReport(String customerID) {
DataFactory dataFactory = DataFactory.INSTANCE;
AccountReport accountReport =
(AccountReport)dataFactory.create(AccountReport.class);
List accountSummaries = accountReport.getAccountSummaries();
CheckingAccount checkingAccount = accountDataService.getCheckingAccount(customerID);
AccountSummary checkingAccountSummary =
(AccountSummary)dataFactory.create(AccountSummary.class);
checkingAccountSummary.setAccountNumber(checkingAccount.getAccountNumber());
checkingAccountSummary.setAccountType("checking");
checkingAccountSummary.setBalance(fromUSDollarToCurrency(checkingAccount.getBalance()));
accountSummaries.add(checkingAccountSummary);
SavingsAccount savingsAccount = accountDataService.getSavingsAccount(customerID);
AccountSummary savingsAccountSummary =
(AccountSummary)dataFactory.create(AccountSummary.class);
savingsAccountSummary.setAccountNumber(savingsAccount.getAccountNumber());
savingsAccountSummary.setAccountType("savings");
savingsAccountSummary.setBalance(fromUSDollarToCurrency(savingsAccount.getBalance()));
accountSummaries.add(savingsAccountSummary);
StockAccount stockAccount = accountDataService.getStockAccount(customerID);
AccountSummary stockAccountSummary =
(AccountSummary)dataFactory.create(AccountSummary.class);
stockAccountSummary.setAccountNumber(stockAccount.getAccountNumber());
stockAccountSummary.setAccountType("stock");
float balance =
(stockQuoteService.getQuote(stockAccount.getSymbol()))*stockAccount.getQuantity();
stockAccountSummary.setBalance(fromUSDollarToCurrency(balance));
accountSummaries.add(stockAccountSummary);
return accountReport;
}
private float fromUSDollarToCurrency(float value){
if (currency.equals("USD")) return value; else
if (currency.equals("EURO")) return value * 0.8f; else
return 0.0f;
}
}
Snippet 33‑8: Example Component Implementation in Java
The following is the SCA componentType definition for the AccountServiceImpl, derived by introspection of the code above:
<?xml version="1.0" encoding="ASCII"?>
<componentType
xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200903200912"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<service name="AccountService">
<interface.java interface="services.account.AccountService"/>
</service>
<reference name="accountDataService">
<interface.java
interface="services.accountdata.AccountDataService"/>
</reference>
<reference name="stockQuoteService">
<interface.java
interface="services.stockquote.StockQuoteService"/>
</reference>
<property name="currency" type="xsd:string"/>
</componentType>
Snippet 33‑9: Example componentType for Implementation in Snippet 3‑8Snippet 3‑8
Note that the componentType property element for "currency" has no default value declared, despite the code containing an initializer for the property field setting it to "USD". This is because the initializer cannot be introspected at runtime and the value cannot be extracted.
For full details about Java implementations, see the Java Component Implementation Specification [SCA-Java]. Other implementation types have their own specification documents.
Components are the basic elements of business function in an SCA assembly, which are combined into complete business solutions by SCA composites.
Components are configured instances of implementations. Components provide and consume services. More than one component can use and configure the same implementation, where each component configures the implementation differently.
Components are declared as subelements of a
composite in a file with a .composite extension. A component is represented by a component element which is a child of the composite element. There
can be zero or more component elements within a composite. The following snippetSnippet 4‑1Snippet 4‑1 shows the composite pseudo-schema with the pseudo-schema for the component child element.:
<?xml version="1.0" encoding="UTF-8"?>
<!-- Component schema snippet -->
<composite
xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200903200912" … >
…
<component name="xs:NCName" autowire="xs:boolean"?
requires="list
of xs:QName"? policySets="list
of xs:QName"? "?>*
constrainingType="xs:QName"?>*
<implementation … />?
<service … />*
<reference … />*
<property … />*
<requires/>*
<policySetAttachment/>*
</component>
…
</composite>
The component element has the
following attributes:
·name : NCName
(1..1) – the name of the component. The @name attribute of a <component/> child
element of a <composite/> MUST be unique amongst the component elements
of that <composite/> [ASM50001]
Snippet 44‑1: composite Pseudo-Schema with component Child Element
The component element has the attributes:
· name : NCName (1..1) – the name of the component. The @name attribute of a <component/> child element of a <composite/> MUST be unique amongst the component elements of that <composite/>The @name attribute of a <component/> child element of a <composite/> MUST be unique amongst the component elements of that <composite/> [ASM50001]
· autowire : boolean (0..1) – whether contained component references are autowired, as described in the Autowire section. Default is false.
·
requires : QNamelistOfQNames (0..n1)
– a list of policy intents. See the Policy Framework specification
[10]SCA-POLICY] for a description of this attribute.
·
policySets : QNamelistOfQNames (0..n1)
– a list of policy sets. See
the Policy Framework specification [10]SCA-POLICY] for a description of this attribute.
·constrainingType :
QName (0..1) – the name of a
constrainingType. When specified, the set of services, references and
properties of the component, plus related intents, is constrained to the set
defined by the constrainingType. See the ConstrainingType
Section for more details.
The component element has the following
child elements:
· implementation : ComponentImplementation (0..1) – see component implementation section.
· service : ComponentService (0..n) – see component service section.
· reference : ComponentReference (0..n) – see component reference section.
· property : ComponentProperty (0..n) – see component property section.
· requires : requires (0..n) - A service element has zero or more requires subelements. See the Policy Framework specification [SCA-POLICY] for a description of this element.
· policySetAttachment : policySetAttachment (0..n) - A service element has zero or more policySetAttachment subelements. See the Policy Framework specification [SCA-POLICY] for a description of this element.
A component element has zero or one implementation element as its child, which points to the implementation
used by the component. A
component with no implementation element is not runnable, but components of
this kind can be useful during a "top-down" development process as a
means of defining the necessary characteristics of the implementation before
the implementation is written.
<?xml version="1.0" encoding="UTF-8"?>
<!-- Component Implementation schema snippet -->
<composite xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200903200912" … >
…
<component … >*
<implementation … />?requires="list
of xs:QName"?
policySets="list of xs:QName"?>
<requires/>*
<policySetAttachment/>*
</implementation>
<service … />*
<reference … />*
<property … />*
</component>
…
</composite>
Snippet 44‑2: component Psuedo-Schema with implementation Child Element
The component provides the extensibility point in the assembly model for different implementation types. The references to implementations of different types are expressed by implementation type specific implementation elements.
For example the elements implementation.java, implementation.bpel, implementation.cpp, and implementation.c point to Java, BPEL, C++, and C implementation types respectively. implementation.composite points to the use of an SCA composite as an implementation. implementation.spring and implementation.ejb are used for Java components written to the Spring framework and the Java EE EJB technology respectively.
The following snippetsSnippet 4‑3Snippet 4‑3 – Snippet 4‑5Snippet 4‑5 show implementation elements for the Java and BPEL
implementation types and for the use of a composite as an implementation:
<implementation.java class="services.myvalue.MyValueServiceImpl"/>
Snippet 44‑3: Example implementation.java Element
<implementation.bpel process="ans:MoneyTransferProcess"/>
Snippet 44‑4: Example implementation.bpel Element
<implementation.composite name="bns:MyValueComposite"/>
Snippet 44‑5: Example implementation.composite Element
New implementation types can be added to the model as described in the Extension Model section.
At runtime, an implementation instance is a specific runtime instantiation of the implementation – its runtime form depends on the implementation technology used. The implementation instance derives its business logic from the implementation on which it is based, but the values for its properties and references are derived from the component which configures the implementation.
Figure 444‑1:
Relationship of Component and Implementation
The component element can have zero or more service elements as children which are used to configure the services
of the component. The services that can be configured are defined by the
implementation. The following
snippetSnippet 4‑6Snippet 4‑6 shows the component pseudo-schema with the pseudo-schema for a service child element:
<?xml version="1.0" encoding="UTF-8"?>
<!-- Component Service schema snippet -->
<composite xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200903200912" … >
…
<component … >*
<implementation … />?
<service
name="xs:NCName" requires="list
of xs:QName"?
policySets="list
of xs:QName"?>*
<interface
… />?
<binding
… />*
<callback>?
<binding
… />+
</callback>
<requires/>*
<policySetAttachment/>*
</service>
<reference … />*
<property … />*
</component>
…
</composite>
Snippet 44‑6: component Psuedo-Schema with service Child Element
The component service element has the following
attributes:
·
name : NCName (1..1) - the name of the service. The @name attribute of
a service element of a <component/> MUST be unique amongst the service
elements of that <component/>The @name attribute of
a service element of a <component/> MUST be unique amongst the service
elements of that <component/> [ASM50002] The @name attribute of
a service element of a <component/> MUST match the @name attribute of a
service element of the componentType of the <implementation/> child
element of the component.The @name attribute of a service element of a
<component/> MUST match the @name attribute of a service element of the
componentType of the <implementation/> child element of the component. [ASM50003]
·
requires : QNamelistOfQNames (0..n1)
– a list of policy intents. See the Policy Framework specification
[10]SCA-POLICY] for a description of this attribute.
Note: The effective set of policy intents for the service consists of any
intents explicitly stated in this @requires attribute, combined with any
intents specified for the service by the implementation.
·
policySets : QNamelistOfQNames (0..n1)
– a list of policy sets. See
the Policy Framework specification [10]SCA-POLICY] for a description of this attribute.
The component
service element has the following child elements:
·
interface : Interface
(0..1) - A service has zero or one interface, which describes the operations provided by the
service. The interface is described by an interface
element which is a child
element of the service element. If no interface is specified, then the
interface specified for the service in the componentType of the implementation
is in effect. If a <service/>
element has an interface subelement
specifiedis declared for a component service, the interface MUST provide a compatible subset of
the interface declared onfor the equivalent
service in the componentType of the implementationIf an interface is
declared for a component service, the interface MUST provide a compatible
subset of the interface declared for the equivalent service in the
componentType of the implementation [ASM50004] For details on the interface element see the
Interface section.
·
binding : Binding (0..n) - A service element has zero or more binding
elements as children. If no binding elements
are specified for the service, then the bindings specified for the equivalent
service in the componentType of the implementation MUST be used, but if the
componentType also has no bindings specified, then <binding.sca/> MUST be
used as the binding. If binding elements are specified for the service, then
those bindings MUST be used and they override any bindings specified for the
equivalent service in the componentType of the implementation.If no binding elements
are specified for the service, then the bindings specified for the equivalent
service in the componentType of the implementation MUST be used, but if the
componentType also has no bindings specified, then <binding.sca/> MUST be
used as the binding. If binding elements are specified for the service, then
those bindings MUST be used and they override any bindings specified for the
equivalent service in the componentType of the implementation. [ASM50005] Details
of the binding element are described in the Bindings section. The binding, combined with any PolicySets in
effect for the binding, needs to satisfy the set of policy intents for the
service, as described in the Policy Framework
specification [10]SCA-POLICY].
·
callback (0..1) / binding
: Binding (1..n) - A callback element is used if the interface has a callback defined and the
callback element has one or more binding elements as subelements. The callback and its binding subelements are specified if there is a need to
have binding details used to handle callbacks. If the callback
element is present and contains one or more binding child elements, then those
bindings MUST be used for the callback.If the callback
element is present and contains one or more binding child elements, then those
bindings MUST be used for the callback. [ASM50006] If the callback element is not present, the
behaviour is runtime implementation dependent.
· requires : requires (0..n) - A service element has zero or more requires subelements. See the Policy Framework specification [SCA-POLICY] for a description of this element.
· policySetAttachment : policySetAttachment (0..n) - A service element has zero or more policySetAttachment subelements. See the Policy Framework specification [SCA-POLICY] for a description of this element.
The component element can have zero or more reference elements
as children which are used to configure the references of the component. The
references that can be configured are defined by the implementation. The following snippetSnippet 4‑7Snippet 4‑7 shows the component pseudo-schema with the pseudo-schema for a reference child element:
<?xml version="1.0" encoding="UTF-8"?>
<!-- Component Reference schema snippet -->
<composite
xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200903200912" … >
…
<component … >*
<implementation … />?
<service … />*
<reference name="xs:NCName"
target="list of xs:anyURI"? autowire="xs:boolean"?
multiplicity="0..1 or 1..1 or 0..n or 1..n"?
nonOverridable="xs:boolean"
wiredByImpl="xs:boolean"? requires="list
of xs:QName"?
policySets="list of xs:QName"?>*
<interface … />?
<binding uri="xs:anyURI"? requires="list
of xs:QName"?
policySets="list
of xs:QName"?/>*
<callback>?
<binding … />+
</callback>
<requires/>*
<policySetAttachment/>*
</reference>
<property … />*
</component>
…
</composite>
Snippet 44‑7: component Psuedo-Schema with reference Child Element
The component
reference element has the following attributes:
·
name : NCName (1..1) – the name of the reference. The @name attribute of
a service element of a <component/> MUST be unique amongst the service
elements of that <component/>The @name attribute of
a service element of a <component/> MUST be unique amongst the service
elements of that <component/> [ASM50007] The @name attribute of
a reference element of a <component/> MUST match the @name attribute of a
reference element of the componentType of the <implementation/> child
element of the component.The @name attribute of a reference element of a
<component/> MUST match the @name attribute of a reference element of the
componentType of the <implementation/> child element of the component. [ASM50008]
·autowire : boolean
(0..1) – whether the reference is autowired, as described in the Autowire section. Default is false.
· The default value of the @autowire attribute MUST be the value of the @autowire attribute on the component containing the reference, if present, or else the value of the @autowire attribute of the composite containing the component, if present, and if neither is present, then it is "false".The default value of the @autowire attribute MUST be the value of the @autowire attribute on the component containing the reference, if present, or else the value of the @autowire attribute of the composite containing the component, if present, and if neither is present, then it is "false". [ASM50043]
·
requires : QNamelistOfQNames (0..n1)
– a list of policy intents. See the Policy Framework specification
[10]SCA-POLICY] for a description of this attribute.
Note: The effective set of policy intents for the reference consists of any
intents explicitly stated in this @requires attribute, combined with any
intents specified for the reference by the implementation.
·
policySets : QNamelistOfQNames (0..n1)
– a list of policy sets. See
the Policy Framework specification [10]SCA-POLICY] for a description of this attribute.
· multiplicity : 0..1|1..1|0..n|1..n (0..1) - defines the number of wires that can connect the reference to target services. Overrides the multiplicity specified for this reference in the componentType of the implementation. The multiplicity can have the following values
– 0..1 – zero or one wire can have the reference as a source
– 1..1 – one wire can have the reference as a source
– 0..n - zero or more wires can have the reference as a source
– 1..n – one or more wires can have the reference as a source
The value of multiplicity for a component reference
MUST only be equal or further restrict any value for the multiplicity of the
reference with the same name in the componentType of the implementation, where
further restriction means 0..n to 0..1 or 1..n to 1..1.The value of multiplicity for a component reference
MUST only be equal or further restrict any value for the multiplicity of the
reference with the same name in the componentType of the implementation, where
further restriction means 0..n to 0..1 or 1..n to 1..1. [ASM50009]
If not present, the value of multiplicity is equal to the multiplicity specificed for this reference in the componentType of the implementation - if not present in the componentType, the value defaults to 1..1.
· target : anyURI (0..n) – a list of one or more of target service URI’s, depending on multiplicity setting. Each value wires the reference to a component service that resolves the reference. For more details on wiring see the section on Wires. Overrides any target specified for this reference on the implementation.
·
wiredByImpl : boolean
(0..1) – a boolean value,
"false" by default, which indicates that the implementation wires
this reference dynamically. If set to "true" it indicates that the
target of the reference is set at runtime by the implementation code (e.g. by
the code obtaining an endpoint reference by some means and setting this as the
target of the reference through the use of programming interfaces defined by
the relevant Client and Implementation specification). If
@wiredByImpl="true" is set for a reference, then the reference MUST
NOT be wired statically within a composite, but left unwired.If
@wiredByImpl="true" is set for a reference, then the reference MUST
NOT be wired statically within a composite, but left unwired. [ASM50010]
·
nonOverridable : boolean
(0..1) - a boolean value,
"false" by default, which indicates whether this component reference
can have its targets overridden by a composite reference which promotes the
component reference.
If @nonOverridable==false, the
if any target(s) ofare configured onto the promoting composite references which promote the component reference,
then those targets replace all the targets explicitly declared on the
component reference for any value of @multiplicity on the component reference. If the
component reference has @nonOverridable==false and @multiplicity 1..1 and no targets are defined on any of the reference
has a target, then any composite
referencereferences which promotes the component reference has @multiplicity 0..1.by default and MAY have an
explicit @multiplicity of either 0..1 or 1..1.,
then any targets explicitly declared on the component reference are used. This
means in effect that any targets declared on the component reference
If @nonOverridable==true, and the has
@multiplicity 0..1 or 1..1 and the componentact as default targets for that reference
also declares a target, promotion implies that the promoting composite
reference has @wiredbyImpl==true and the composite reference cannot supply a
target, but can influence the policy attached to the component reference. .
If a component
reference has @multiplicity 0..1 or 1..1 and @nonOverridable==true, then the
component reference MUST NOT be promoted by any composite reference.If a component
reference has @multiplicity 0..1 or 1..1 and @nonOverridable==true, then the
component reference MUST NOT be promoted by any composite reference. [ASM50042]
If @nonOverridable==true, and the component reference @multiplicity is 0..n or
1..n, promotion targeting
isany targets configured
onto the composite references which promote the component reference are added
to any references declared on the component reference - that is, the targets
are additive.
The component reference element has the following
child elements:
·
interface : Interface
(0..1) - A reference has zero or one interface, which describes the operations of the reference.
The interface is described by an interface
element which is a child
element of the reference element. If no interface is specified, then the
interface specified for the reference in the componentType of the
implementation is in effect. If an interface is declared for a component
reference, the interface MUST provide a compatible superset of the interface
declared for the equivalent reference in the componentType of the
implementation, i.e. provide the same operations or a .If an interface is
declared for a component reference, the interface MUST provide a compatible
superset of the operations defined byinterface declared for
the equivalent reference in the componentType of the implementation for the reference. [ASM50011] For
details on the interface element see the Interface section.
·
binding : Binding (0..n) - A reference element has zero
or more binding elements as children.If no binding elements are specified for the
reference, then the bindings specified for the equivalent reference in the
componentType of the implementation MUST be used. If binding elements are
specified for the reference, then those bindings MUST be used and they override
any bindings specified for the equivalent reference in the componentType of the
implementation.If
no binding elements are specified for the reference, then the bindings
specified for the equivalent reference in the componentType of the
implementation MUST be used. If binding elements are specified for the
reference, then those bindings MUST be used and they override any bindings
specified for the equivalent reference in the componentType of the
implementation. [ASM50012] It is valid for there to be no binding
elements on the component reference and none on the reference in the
componentType - the binding used for such a reference is determined by the
target service. See the section on the bindings of
component services for a description of how the binding(s) applying to a
service are determined.
Details of the binding element are described in the Bindings
section. The binding,
combined with any PolicySets in effect for the binding, needs to satisfy the
set of policy intents for the reference, as described in the
Policy Framework specification [10]SCA-POLICY].
A reference identifies zero or more target services that satisfy the reference. This can be done in a number of ways, which are fully described in section "Specifying the Target Service(s) for a Reference"
·
callback (0..1) / binding : Binding (1..n) - A callback element used if the interface has a callback
defined and the callback element has one or more binding
elements as subelements. The callback and its binding subelements are specified if there
is a need to have binding details used to handle callbacks. If the callback
element is present and contains one or more binding child elements, then those
bindings MUST be used for the callback.If the callback
element is present and contains one or more binding child elements, then those
bindings MUST be used for the callback. [ASM50006] If the callback element is not present, the
behaviour is runtime implementation dependent.
· requires : requires (0..n) - A service element has zero or more requires subelements. See the Policy Framework specification [SCA-POLICY] for a description of this element.
· policySetAttachment : policySetAttachment (0..n) - A service element has zero or more policySetAttachment subelements. See the Policy Framework specification [SCA-POLICY] for a description of this element.
A reference defines zero or more target services that satisfy the reference. The target service(s) can be defined in the following ways:
1. Through a value specified in the @target attribute of the reference element
2. Through a target URI specified in the @uri attribute of a binding element which is a child of the reference element
3. Through the setting of one or more values for binding-specific attributes and/or child elements of a binding element that is a child of the reference element
4. Through the specification of @autowire="true" for the reference (or through inheritance of that value from the component or composite containing the reference)
5. Through the specification of @wiredByImpl="true" for the reference
6. Through the promotion of a component reference by a composite reference of the composite containing the component (the target service is then identified by the configuration of the composite reference)
7. Through the presence of a <wire/> element which has the reference specified in its @source attribute.
Combinations of these different methods are allowed, and the following rules MUST be observed:
·
If @wiredByImpl="true", other methods of
specifying the target service MUST NOT be used.If @wiredByImpl="true", other methods of
specifying the target service MUST NOT be used. [ASM50013]
·
If @autowire="true", the autowire
procedure MUST only be used if no target is identified by any of the other ways
listed above. It is not an error if @autowire="true" and a target is
also defined through some other means, however in this case the autowire
procedure MUST NOT be used.If @autowire="true", the autowire
procedure MUST only be used if no target is identified by any of the other ways
listed above. It is not an error if @autowire="true" and a target is
also defined through some other means, however in this case the autowire
procedure MUST NOT be used.
[ASM50014]
·
If a reference has a value specified for one or
more target services in its @target attribute, there MUST NOT be any child
<binding/> elements declared for that reference.If a reference has a value specified for one or
more target services in its @target attribute, there MUST NOT be any child
<binding/> elements declared for that reference. [ASM50026]
·
If a binding element has a value specified for a
target service using its @uri attribute, the binding element MUST NOT identify
target services using binding specific attributes or elements.If a binding element has a value specified for a
target service using its @uri attribute, the binding element MUST NOT identify
target services using binding specific attributes or elements. [ASM50015]
·
It is possible that a particular binding type MAY require that uses
more than a simple URI for the address of a target service uses more than a simple URI. . In
cases where a reference element has a binding subelement of such a typethat
uses more than simple URI, the @uri attribute of the binding element MUST NOT
be used to identify the target service - instead,in this case binding
specific attributes and/or child elements MUST be used.It is possible that a particular binding type uses
more than a simple URI for the address of a target service. In cases where a
reference element has a binding subelement that uses more than simple URI, the
@uri attribute of the binding element MUST NOT be used to identify the target
service - in this case binding specific attributes and/or child elements MUST
be used. [ASM50016]
·
If any <wire/> element with its @replace
attribute set to "true" has a particular reference specified in its
@source attribute, the value of the @target attribute for that reference MUST
be ignored and MUST NOT be used to define target services for that reference.If any <wire/> element with its @replace
attribute set to "true" has a particular reference specified in its
@source attribute, the value of the @target attribute for that reference MUST
be ignored and MUST NOT be used to define target services for that reference. [ASM50034]
The number of target services configured for a reference are constrained by the following rules.
·A reference with multiplicity 0..1 or 0..n MAYMUST have no more than one target service defined.A
reference with multiplicity 0..1 MUST have no more than one target service
defined. [ASM50018]
·
A reference with multiplicity 0..1 or 1..1 MUST NOT have more thatexactly
one target service defined.A reference with multiplicity 1..1 MUST have
exactly one target service defined. [ASM50019ASM50040]
·A reference with multiplicity 1..1 orn
MUST have at least one target service defined.A
reference with multiplicity 1..n MUST have at least one target service defined. [ASM50020]
· A reference with multiplicity 0..n can have any number of target services defined.
·A
reference with multiplicity 0..n or 1..n MAY have one or more target services
defined.Where
it is detected that the rules for the number of target services for a reference
have been violated, either at deployment or at execution time, an SCA Runtime
MUST raise an error no later than when the reference is invoked by the
component implementation.Where it is detected
that the rules for the number of target services for a reference have been
violated, either at deployment or at execution time, an SCA Runtime MUST raise
an error no later than when the reference is invoked by the component
implementation. [ASM50021]
Where it is detected
that the rules for the number of target services for a reference have been violated,
either at deployment or at execution time, an SCA Runtime MUST raise an error
no later than when the reference is invoked by the component implementation. [ASM50022]
For example, where a composite is used as a component implementation, wires and target services cannot be added to the composite after deployment. As a result, for components which are part of the composite, both missing wires and wires with a non-existent target can be detected at deployment time through a scan of the contents of the composite.
A contrasting example is a component deployed to the SCA Domain. At the Domain level, the target of a wire, or even the wire itself, can form part of a separate deployed contribution and as a result these can be deployed after the original component is deployed. For the cases where it is valid for the reference to have no target service specified, the component implementation language specification needs to define the programming model for interacting with an untargetted reference.
Where a component reference is promoted by a
composite reference, the promotion MUST be treated from a multiplicity
perspective as providing 0 or more target services for the component reference,
depending upon the further configuration of the composite reference. These
target services are in addition to any target services identified on the
component reference itself, subject to the rules relating to multiplicity.Where a component reference is promoted by a
composite reference, the promotion MUST be treated from a multiplicity
perspective as providing 0 or more target services for the component reference,
depending upon the further configuration of the composite reference. These
target services are in addition to any target services identified on the
component reference itself, subject to the rules relating to multiplicity. [ASM50025]
The component element has zero or more property elements as its children, which are used to configure data values of properties of the implementation. Each property element provides a value for the named property, which is passed to the implementation. The properties that can be configured and their types are defined by the component type of the implementation. An implementation can declare a property as multi-valued, in which case, multiple property values can be present for a given property.
The property value can be specified in one of five ways:
·
As a value, supplied in the @value attribute of the
property element.
If the @value attribute of a component property
element is declared, the type of the property MUST be an XML Schema simple type
and the @value attribute MUST contain a single value of that type.If the @value attribute of a component property element
is declared, the type of the property MUST be an XML Schema simple type and the
@value attribute MUST contain a single value of that type. [ASM50027]
For example,
<property name="pi" value="3.14159265" />
·As a value,
supplied as the content of the value subelement(s) of the
property element.
If the value subelement of a component property is
specified, the type of the property MUST be an XML Schema simple type or an XML
schema complex type. [ASM50028]
Snippet 44‑8: Example property using @value attribute
· As a value, supplied as the content of the value subelement(s) of the property element.
If the value subelement of a component property is specified, the type of the property MUST be an XML Schema simple type or an XML schema complex type.If the value subelement of a component property is specified, the type of the property MUST be an XML Schema simple type or an XML schema complex type. [ASM50028]
For example,
– property defined using a XML Schema simple type and which contains a single value
<property name="pi">
<value>3.14159265</value>
</property>
Snippet 44‑9: Example property with a Simple Type Containing a Single Value
– property defined using a XML Schema simple type and which contains multiple values
<property name="currency">
<value>EURO</value>
<value>USDollar</value>
</property>
Snippet 44‑10: Example property with a Simple Type Containing Multiple Values
– property defined using a XML Schema complex type and which contains a single value
<property name="complexFoo">
<value attr="bar">
<foo:a>TheValue</foo:a>
<foo:b>InterestingURI</foo:b>
</value>
</property>
Snippet 44‑11: Example property with a Complex Type Containing a Single Value
– property defined using a XML Schema complex type and which contains multiple values
<property name="complexBar">
<value anotherAttr="foo">
<bar:a>AValue</bar:a>
<bar:b>InterestingURI</bar:b>
</value>
<value attr="zing">
<bar:a>BValue</bar:a>
<bar:b>BoringURI</bar:b>
</value>
</property>
·As a value,
supplied as the content of the property element.
If a component property value is declared using a
child element of the <property/> element, the type of the property MUST
be an XML Schema global element and the declared child element MUST be an
instance of that global element. [ASM50029]
Snippet 44‑12: Example property with a Complex Type Containing Multiple Values
· As a value, supplied as the content of the property element.
If a component property value is declared using a child element of the <property/> element, the type of the property MUST be an XML Schema global element and the declared child element MUST be an instance of that global element.If a component property value is declared using a child element of the <property/> element, the type of the property MUST be an XML Schema global element and the declared child element MUST be an instance of that global element. [ASM50029]
For example,
– property defined using a XML Schema global element declartion and which contains a single value
<property name="foo">
<foo:SomeGED ...>...</foo:SomeGED>
</property>
Snippet 44‑13: Example property with a Global Element Declaration Containing a Single Value
– property defined using a XML Schema global element declaration and which contains multiple values
<property name="bar">
<bar:SomeOtherGED ...>...</bar:SomeOtherGED>
<bar:SomeOtherGED ...>...</bar:SomeOtherGED>
</property>
Snippet 44‑14 Example property with a Global Element Declaration Containing Multiple Values
·
By referencing a Property value of the composite which contains
the component. The reference is made using the @source attribute of the property element.
The form of the value of the @source attribute follows
the form of an XPath expression. This form allows a specific property of the
composite to be addressed by name. Where the composite property is of a
complex type, the XPath expression can be extended to refer to a sub-part of
the complex property value.
So, for example, source="$currency" is used to reference a property of the composite called "currency", while source="$currency/a" references the sub-part "a" of the complex composite property with the name "currency".
· By specifying a dereferencable URI to a file containing the property value through the @file attribute. The contents of the referenced file are used as the value of the property.
If more than one property value specification is present, the @source attribute takes precedence, then the @file attribute.
For a property defined using a XML Schema simple type and for which a single value is desired, can be set either using the @value attribute or the <value> child element. The two forms in such a case are equivalent.
When
a property has multiple values set, they MUST all be contained within the same
property element. A <component/> element MUST NOT contain two
<property/> subelements with the same value of the @name attribute.When a property has multiple values set, all the
values MUST be contained within a single property element.When a property has multiple values set, all the
values MUST be contained within a single property element. [ASM50030ASM50044]
The type of the property can be specified in one of two ways:
· by the qualified name of a type defined in an XML schema, using the @type attribute
· by the qualified name of a global element in an XML schema, using the @element attribute
The
property type specified for the property element of a component MUST be
compatible with the type of the property with the same @name declared in the
component type of the implementation used by the component. If no type is
declared in the component property element, the type of the property declared
in the componentType of the implementation MUST be used.The property type specified for the property
element of a component MUST be compatible with the type of the property with
the same @name declared in the component type of the implementation used by the
component. If no type is declared in the component property element, the type
of the property declared in the componentType of the implementation MUST be
used. [ASM50036]
The following snippetmeaning of
"compatible" for property types is defined in the section Property Type Compatibility.
Snippet 4‑15Snippet 4‑15 shows the component pseudo-schema with the pseudo-schema for a property child element:
<?xml version="1.0" encoding="UTF-8"?>
<!-- Component Property schema snippet -->
<composite xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200903200912" … >
…
<component … >*
<implementation … />?
<service … />*
<reference … />*
<property name="xs:NCName"
(type="xs:QName" | element="xs:QName")?
many="xs:boolean"?
source="xs:string"? file="xs:anyURI"?
requires="list
of xs:QName"?
policySets="list
of xs:QName"?
value="xs:string"?>*
[<value>+ | xs:any+ ]?
</property>
</component>
…
</composite>
The component property element has
the following attributes:
§name
: NCName (1..1) – the name of the
property. The @name attribute of a property element of a
<component/> MUST be unique amongst the property elements of that
<component/>. [ASM50031] The @name attribute of a property element of a
<component/> MUST match the @name attribute of a property element of the
componentType of the <implementation/> child element of the component. [ASM50037]
Snippet 44‑15: component Psuedo-Schema with property Child Element
The component property element has the attributes:
· name : NCName (1..1) – the name of the property. The @name attribute of a property element of a <component/> MUST be unique amongst the property elements of that <component/>.The @name attribute of a property element of a <component/> MUST be unique amongst the property elements of that <component/>. [ASM50031] The @name attribute of a property element of a <component/> MUST match the @name attribute of a property element of the componentType of the <implementation/> child element of the component.The @name attribute of a property element of a <component/> MUST match the @name attribute of a property element of the componentType of the <implementation/> child element of the component. [ASM50037]
· zero or one of (0..1):
– type : QName – the type of the property defined as the qualified name of an XML schema type
– element : QName – the type of the property defined as the qualified name of an XML schema global element – the type is the type of the global element
A single property element MUST NOT contain both a
@type attribute and an @element attribute.A single property element MUST NOT contain both a
@type attribute and an @element attribute. [ASM50035]
· source : string (0..1) – an XPath expression pointing to a property of the containing composite from which the value of this component property is obtained.
· file : anyURI (0..1) – a dereferencable URI to a file containing a value for the property
· many : boolean (0..1) – whether the property is single-valued (false) or multi-valued (true). Overrides the many specified for this property in the componentType of the implementation. The value can only be equal or further restrict, i.e. if the implementation specifies many true, then the component can say false. In the case of a multi-valued property, it is presented to the implementation as a Collection of property values. If many is not specified, it takes the value defined by the component type of the implementation used by the component.
· value : string (0..1) - the value of the property if the property is defined using a simple type.
§requires
: QName (0..n) - a list of policy
intents. See the Policy Framework specification [10] for a
description of this attribute.
§policySets
: QName (0..n) - a list of policy
sets. See the Policy Framework specification [10] for a
description of this attribute.
The component property element has
the following child element:
value :any (0..n) -
A property has zero or more, value elements that specify the
value(s) of a property that is defined using a XML Schema type. The component
property element has the child element:
· value :any (0..n) - A property has zero or more, value elements that specify the value(s) of a property that is defined using a XML Schema type. If a property is single-valued, the <value/> subelement MUST NOT occur more than once.If a property is single-valued, the <value/> subelement MUST NOT occur more than once. [ASM50032] A property <value/> subelement MUST NOT be used when the @value attribute is used to specify the value for that property.A property <value/> subelement MUST NOT be used when the @value attribute is used to specify the value for that property. [ASM50033]
There are a number of situations where the declared type of a property element is matched with the declared type of another property element. These situations include:
· Where a component <property/> sets a value for a property of an implementation, as declared in the componentType of the implementation
· Where a component <property/> gets its value from the value of a composite <property/> by means of its @source attribute. This situation can also involve the @source attribute referencing a subelement of the composite <property/> value, in which case it is the type of the subelement which must be matched with the type of the component <property/>
· Where the componentType of a composite used as an implementation is calculated and componentType <property/> elements are created for each composite <property/>
If a property is single-valued, the <value/>
subelement MUST NOT occur more than once.In these cases where the types of two property
elements are matched, the types declared for the two <property/> elements
MUST be compatibleIn
these cases where the types of two property elements are matched, the types
declared for the two <property/> elements MUST be compatible [ASM50032] A property <value/> subelement MUST NOT be used
when the @value attribute is used to specify the value for that property.
[ASM50033]
Two property types are compatible if they have the same XSD type (where declared as XSD types) or the same XSD global element (where declared as XSD global elements). For cases where the type of a property is declared using a different type system (eg Java), then the type of the property is mapped to XSD using the mapping rules defined by the appropriate implementation type specification
The following figureFigure 4‑2Figure 4‑2 shows the component
symbol that is used to
represent a component in an assembly diagram.
Figure 544‑2:
Component symbol
The following figureFigure
4‑3Figure
4‑3
shows the assembly diagram for the MyValueComposite containing the
MyValueServiceComponent.
Figure 644‑3:
Assembly diagram for MyValueComposite
The following snippetSnippet
4‑16: Example
compositeSnippet 4‑16:
Example composite shows the MyValueComposite.composite file for
the MyValueComposite containing the component element for the
MyValueServiceComponent. A value is set for the property named currency, and
the customerService and stockQuoteService references are promoted:
<?xml version="1.0" encoding="ASCII"?>
<!-- MyValueComposite_1 example -->
<composite
xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200903200912"
targetNamespace="http://foo.com"
name="MyValueComposite" >
<service name="MyValueService" promote="MyValueServiceComponent"/>
<component name="MyValueServiceComponent">
<implementation.java
class="services.myvalue.MyValueServiceImpl"/>
<property name="currency">EURO</property>
<reference name="customerService"/>
<reference name="stockQuoteService"/>
</component>
<reference name="CustomerService"
promote="MyValueServiceComponent/customerService"/>
<reference name="StockQuoteService"
promote="MyValueServiceComponent/stockQuoteService"/>
</composite>
Snippet 44‑16: Example composite
Note that the references of MyValueServiceComponent are explicitly declared only for purposes of clarity – the references are defined by the MyValueServiceImpl implementation and there is no need to redeclare them on the component unless the intention is to wire them or to override some aspect of them.
The following snippet gives an example of the layout of a composite file if both the currency property and the customerService reference of the MyValueServiceComponent are declared to be multi-valued (many=true for the property and multiplicity=0..n or 1..n for the reference):
<?xml version="1.0" encoding="ASCII"?>
<!-- MyValueComposite_2 example -->
<composite
xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200903200912"
targetNamespace="http://foo.com"
name="MyValueComposite" >
<service name="MyValueService" promote="MyValueServiceComponent"/>
<component name="MyValueServiceComponent">
<implementation.java
class="services.myvalue.MyValueServiceImpl"/>
<property name="currency">
<value>EURO</value>
<value>Yen</value>
<value>USDollar</value>
</property>
<reference name="customerService"
target="InternalCustomer/customerService"/>
<reference name="stockQuoteService"/>
</component>
...
<reference name="CustomerService"
promote="MyValueServiceComponent/customerService"/>
<reference name="StockQuoteService"
promote="MyValueServiceComponent/stockQuoteService"/>
</composite>
Snippet 44‑17: Example composite with Multi-Valued property and reference
….this assumes that the composite has another component called InternalCustomer (not shown) which has a service to which the customerService reference of the MyValueServiceComponent is wired as well as being promoted externally through the composite reference CustomerService.
An SCA composite is used to assemble SCA elements in logical groupings. It is the basic unit of composition within an SCA Domain. An SCA composite contains a set of components, services, references and the wires that interconnect them, plus a set of properties which can be used to configure components.
Composites can be used as component implementations in higher-level composites – in other words the higher-level composites can have components that are implemented by composites. For more detail on the use of composites as component implementations see the section Using Composites as Component Implementations.
The content of a composite can be used within another composite through inclusion. When a composite is included by another composite, all of its contents are made available for use within the including composite – the contents are fully visible and can be referenced by other elements within the including composite. For more detail on the inclusion of one composite into another see the section Using Composites through Inclusion.
A composite can be used as a unit of deployment.
When used in this way, composites contribute components and wires to an SCA
Domain. A composite can be deployed to the SCA Domain either by inclusion, or a composite can be deployed to the Domain as an
implementation. For more detail on the deployment of composites, see the
section dealing with the SCA Domain.
A composite is defined in an xxx.composite file. A composite is represented by a composite element. The
following snippetSnippet 5‑1Snippet 5‑1 shows the pseudo-schema for the composite element. :
<?xml version="1.0" encoding="ASCII"?>
<!-- Composite schema snippet -->
<composite xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200903200912"
targetNamespace="xs:anyURI"
name="xs:NCName" local="xs:boolean"?
autowire="xs:boolean"? constrainingType="xs:QName"?
requires="list of xs:QName"? policySets="list of xs:QName"?>
<include … />*
<requires/>*
<policySetAttachment/>*
<service … />*
<reference … />*
<property … />*
<component … />*
<wire … />*
</composite>
Snippet 55‑1: composite Pseduo-Schema
The composite element has the following
attributes:
·
name : NCName (1..1) – the name of the composite. The form of a
composite name is an XML QName, in the namespace identified by the @targetNamespace
attribute. A composite @name attribute value MUST be unique
within the namespace of the composite.A composite @name
attribute value MUST be unique within the namespace of the composite. [ASM60001]
· targetNamespace : anyURI (0..1) – an identifier for a target namespace into which the composite is declared
·
local : boolean (0..1) – whether all the components within the composite
all run in the same operating system process. @local="true" for a composite means that
all the components within the composite MUST run in the same operating system
process.@local="true"
for a composite means that all the components within the composite MUST run in
the same operating system process. [ASM60002]
local="false", which is the default, means that different components
within the composite can run in different operating system processes and they
can even run on different nodes on a network.
· autowire : boolean (0..1) – whether contained component references are autowired, as described in the Autowire section. Default is false.
·constrainingType :
QName (0..1) – the name of a
constrainingType. When specified, the set of services, references and
properties of the composite, plus related intents, is constrained to the set
defined by the constrainingType. See the ConstrainingType
Section for more details.
·
requires : QNamelistOfQNames (0..n1)
– a list of policy intents.
See the Policy Framework specification [10]SCA-POLICY] for a description of this attribute.
·
policySets : QNamelistOfQNames (0..n1)
– a list of policy sets. See
the Policy Framework specification [10]SCA-POLICY] for a description of this attribute.
The composite element has the following
child elements:
· service : CompositeService (0..n) – see composite service section.
· reference : CompositeReference (0..n) – see composite reference section.
· property : CompositeProperty (0..n) – see composite property section.
· component : Component (0..n) – see component section.
· wire : Wire (0..n) – see composite wire section.
· include : Include (0..n) – see composite include section
· requires : requires (0..n) - A service element has zero or more requires subelements. See the Policy Framework specification [SCA-POLICY] for a description of this element.
· policySetAttachment : policySetAttachment (0..n) - A service element has zero or more policySetAttachment subelements. See the Policy Framework specification [SCA-POLICY] for a description of this element.
Components contain configured implementations which hold the business logic of the composite. The components offer services and use references to other services. Composite services define the public services provided by the composite, which can be accessed from outside the composite. Composite references represent dependencies which the composite has on services provided elsewhere, outside the composite. Wires describe the connections between component services and component references within the composite. Included composites contribute the elements they contain to the using composite.
Composite services involve the promotion of one service of one of the components within the
composite, which means that the composite service is actually provided by one
of the components within the composite. Composite references involve the promotion of one or more references of one or more
components. Multiple component references can be promoted to the same
composite reference, as long as alleach of
the component references arehas
an interface that is a compatible with
one anothersubset
of the interface on the composite reference. Where multiple component references are promoted
to the same composite reference, then they all share the same configuration,
including the same target service(s).
Composite services and composite references can use the configuration of their promoted services and references respectively (such as Bindings and Policy Sets). Alternatively composite services and composite references can override some or all of the configuration of the promoted services and references, through the configuration of bindings and other aspects of the composite service or reference.
Component services and component references can be promoted to composite services and references and also be wired internally within the composite at the same time. For a reference, this only makes sense if the reference supports a multiplicity greater than 1.
The services of a composite are defined by promoting services defined by components contained in the composite. A component service is promoted by means of a composite service element.
A composite service is represented by a service element
which is a child of the composite element. There can be zero or more service elements in a composite. The following snippetSnippet 5‑2Snippet 5‑2 shows the composite
pseudo-schema with the pseudo-schema
for a service child element:
<?xml version="1.0" encoding="ASCII"?>
<!-- Composite Service schema snippet -->
<composite xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200903200912" … >
…
<service name="xs:NCName" promote="xs:anyURI"
requires="list of xs:QName"? policySets="list
of xs:QName"?>*
<interface … />?
<binding … />*
<callback>?
<binding … />+
</callback>
<requires/>*
<policySetAttachment/>*
</service>
…
</composite>
Snippet 55‑2: composite Psuedo-Schema with service Child Element
The composite
service element has the following attributes:
·
name : NCName (1..1) – the name of the service.The name of a
composite <service/> element MUST be unique across all the composite
services in the composite.The name of a composite <service/> element
MUST be unique across all the composite services in the composite. [ASM60003] The name of the
composite service can be different from the name of the promoted component
service.
·
promote : anyURI (1..1) – identifies the promoted service, the value is of
the form <component-name>/<service-name>. The service name can be
omitted if the target component only has one service. The same component service
can be promoted by more then one composite service. A composite
<service/> element's @promote attribute MUST identify one of the
component services within that composite.A composite
<service/> element's @promote attribute MUST identify one of the
component services within that composite. [ASM60004] <include/>
processing MUST take place before the processing of the @promote attribute of a
composite service is performed.<include/>
processing MUST take place before the processing of the @promote attribute of a
composite service is performed. [ASM60038]
·
requires : QNamelistOfQNames (0..n1)
– a list of policy intents. See the Policy Framework specification
[10]SCA-POLICY] for a description of this attribute. Specified intents add
to or further qualify the required intents defined by the promoted component
service.
·
policySets : QNamelistOfQNames (0..n1)
– a list of policy sets. See
the Policy Framework specification [10]SCA-POLICY] for a description of this attribute.
The composite
service element has the following child elements, whatever is not specified is defaulted from the
promoted component service.
·
interface : Interface
(0..1) - an interface which
decribes the operations provided by the composite service. If a composite service interface is specified it MUST be the same or a compatible
subset of the interface provided by the promoted component service, i.e. provide a
subset of the operations defined by the component service.If a composite service
interface is specified it MUST
be the same or a compatible subset of the interface provided by the promoted
component service, i.e. provide a
subset of the operations defined by the component service.If a composite
service interface is specified it
MUST be the same or a compatible subset of the interface provided by the
promoted component service, i.e. provide a subset of the operations defined by
the component service [ASM60005] The interface is described by zero or one interface element which is a child element of the service element.
For details on the interface element see the Interface section. .
· binding : Binding (0..n) - If bindings are specified they override the bindings defined for the promoted component service from the composite service perspective. The bindings defined on the component service are still in effect for local wires within the composite that target the component service. A service element has zero or more binding elements as children. Details of the binding element are described in the Bindings section. For more details on wiring see the Wiring section.
· callback (0..1) / binding : Binding (1..n) - A callback element is used if the interface has a callback defined and the callback has one or more binding elements as subelements. The callback and its binding subelements are specified if there is a need to have binding details used to handle callbacks. Callback binding elements attached to the composite service override any callback binding elements defined on the promoted component service. If the callback element is not present on the composite service, any callback binding elements on the promoted service are used. If the callback element is not present at all, the behaviour is runtime implementation dependent.
· requires : requires (0..n) - A service element has zero or more requires subelements. See the Policy Framework specification [SCA-POLICY] for a description of this element.
· policySetAttachment : policySetAttachment (0..n) - A service element has zero or more policySetAttachment subelements. See the Policy Framework specification [SCA-POLICY] for a description of this element.
The following figureFigure 5‑1Figure 5‑1 shows the service symbol that used to represent a
service in an assembly diagram:
Figure 755‑1:
Service symbol
The following figureFigure 5‑2Figure 5‑2 shows the assembly diagram for the MyValueComposite
containing the service MyValueService.
Figure 855‑2:
MyValueComposite showing Service
The following snippetSnippet 5‑3Snippet 5‑3 shows the MyValueComposite.composite file for the
MyValueComposite containing the service element for the MyValueService, which
is a promote of the service offered by the MyValueServiceComponent. The name of
the promoted service is omitted since MyValueServiceComponent offers only one
service. The composite service MyValueService is bound using a Web service
binding.
<?xml version="1.0" encoding="ASCII"?>
<!-- MyValueComposite_4 example -->
<composite
xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200903200912"
targetNamespace="http://foo.com"
name="MyValueComposite" >
...
<service name="MyValueService" promote="MyValueServiceComponent">
<interface.java interface="services.myvalue.MyValueService"/>
<binding.ws
portwsdlElement="http://www.myvalue.org/MyValueService#
wsdl.endpointport(MyValueService/MyValueServiceSOAP)"/>
</service>
<component name="MyValueServiceComponent">
<implementation.java
class="services.myvalue.MyValueServiceImpl"/>
<property name="currency">EURO</property>
<service name="MyValueService"/>
<reference name="customerService"/>
<reference name="stockQuoteService"/>
</component>
...
</composite>
Snippet 55‑3: Example composite with a service
The references of a composite are defined by promoting references defined by components contained in the composite. Each promoted reference indicates that the component reference needs to be resolved by services outside the composite. A component reference is promoted using a composite reference element.
A composite reference is represented by a reference element which is a child of a composite element. There can
be zero or more
reference elements in a composite. The following snippetSnippet 5‑4Snippet 5‑4 shows the composite pseudo-schema with the pseudo-schema for a reference element.:
<?xml version="1.0" encoding="ASCII"?>
<!-- Composite Reference schema snippet -->
<composite
xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200903200912" … >
…
<reference name="xs:NCName" target="list of xs:anyURI"?
promote="list
of xs:anyURI"
wiredByImpl="xs:boolean"?
multiplicity="0..1
or 1..1 or 0..n or 1..n"?
requires="list
of xs:QName"? policySets="list
of xs:QName"?>*
<interface … />?
<binding … />*
<callback>?
<binding … />+
</callback>
<requires/>*
<policySetAttachment/>*
</reference>
…
</composite>
Snippet 55‑4: composite Psuedo-Schema with reference Child Element
The composite
reference element has the following attributes:
·
name : NCName (1..1) – the name of the reference. The name of a
composite <reference/> element MUST be unique across all the composite
references in the composite.The name of a composite <reference/> element
MUST be unique across all the composite references in the composite. [ASM60006] The name of the
composite reference can be different than the name of the promoted component
reference.
·
promote : anyURI (1..n) – identifies one or more promoted component
references. The value is a list of values of the form
<component-name>/<reference-name> separated by spaces. The
reference name can be omitted if the component has only one reference. Each of the URIs
declared by a composite reference's @promote attribute MUST identify a
component reference within the composite.Each of the URIs
declared by a composite reference's @promote attribute MUST identify a
component reference within the composite. [ASM60007] <include/>
processing MUST take place before the processing of the @promote attribute of a composite reference is
performed.<include/>
processing MUST take place before the processing of the @promote attribute of a composite
reference is
performed. [ASM60037]
The same component reference can be promoted more than once, using different composite references, but only if the multiplicity defined on the component reference is 0..n or 1..n. The multiplicity on the composite reference can restrict accordingly.
Where a composite reference promotes two or more component references:
– the interfaces of the component references promoted
by a composite reference MUST be the same, or if the composite reference itself
declares an interface then alleach of the component
reference interfaces MUST be a compatible withsubset of the
composite reference interface. Compatible means that..the interfaces of the component references promoted
by a composite reference interface
isMUST be the same, or is a strictif the composite reference itself declares an
interface then each of the component reference interfaces MUST be a compatible
subset of the composite reference interface.. [ASM60008]
– the intents declared
on a composite reference and on the component references which it promoites
MUST NOT be mutually exclusive.the intents declared
on a composite reference and on the component references which it promoites
MUST NOT be mutually exclusive. [ASM60009] The intents which
apply to the composite reference in this case are the union of the intents
specified for each of the promoted component references plus any intents declared
on the composite reference itself. If any intents in the
set which apply to a composite reference are mutually exclusive then the SCA
runtime MUST raise an error.If any intents in the set which apply to a
composite reference are mutually exclusive then the SCA runtime MUST raise an
error. [ASM60010]
·
requires : QNamelistOfQNames (0..n1)
– a list of policy intents. See the Policy Framework specification
[10]SCA-POLICY] for a description of this attribute. Specified intents add
to or further qualify the intents defined for the promoted component reference.
·
policySets : QNamelistOfQNames (0..n1)
– a list of policy sets. See
the Policy Framework specification [10]SCA-POLICY] for a description of this attribute.
·
multiplicity : (01..1) -
Defines the number of wires that can connect the reference to target services.
When present, theThe
multiplicity of a composite
reference is always specified explicitly and can
have one of the following values
– 0..1 – zero or one wire can have the reference as a source
– 1..1 – one wire can have the reference as a source
– 0..n - zero or more wires can have the reference as a source
– 1..n – one or more wires can have the reference as a source
The default value for the @multiplicity attribute
is 1..1.The value specified for the @multiplicity attribute of a
composite reference MUST be compatible with the multiplicity specified on each
of the promoted component references, i.e. the multiplicity has to be equal or
further restrict. So multiplicity 0..1 can be used where the promoted component
reference has multiplicity 0..n, multiplicity 1..1 can be used where the
promoted component reference has multiplicity 0..n or 1..n and multiplicity 1..n
can be used where the promoted component reference has multiplicity 0..n.,
However, a composite reference of multiplicity 0..n or 1..n cannot be used to
promote a component reference of multiplicity 0..1 or 1..1 respectively.
The value specified
for the @multiplicity attribute of a
composite reference MUST be compatible with the multiplicity specified on each
of the promoted component references, i.e. the multiplicity has to be equal or
further restrict. So multiplicity 0..1 can be used where the promoted component
reference has multiplicity 0..n, multiplicity 1..1 can be used where the
promoted component reference has multiplicity 0..n or 1..n and multiplicity
1..n can be used where the promoted component reference has multiplicity 0..n.,
However, a composite reference of multiplicity 0..n or 1..n cannot be used to
promote a component reference of multiplicity 0..1 or 1..1 respectively.The value specified
for the @multiplicityThe multiplicity of a
composite reference MUST be equal to or further restrict the multiplicity of
each of the component references that it promotes, with the exception that the
multiplicity of the composite reference does not have to require a target if
there is already a target on the component reference. This means that a
component reference with multiplicity 1..1 and a target can be promoted by a
composite reference with multiplicity 0..1, and a component reference with
multiplicity 1..n and one or more targets can be promoted by a composite
reference with multiplicity 0..n or 0..1. attribute of a
composite reference MUST be compatible with the multiplicity specified on each
of the promoted component references, i.e. the multiplicity has to be equal or
further restrict. So multiplicity 0..1 can be used where the promoted component
reference has multiplicity 0..n, multiplicity 1..1 can be used where the
promoted component reference has multiplicity 0..n or 1..n and multiplicity
1..n can be used where the promoted component reference has multiplicity 0..n.,
However, a composite reference of multiplicity 0..n or 1..n cannot be used to
promote a component reference of multiplicity 0..1 or 1..1 respectively.The multiplicity of a
composite reference MUST be equal to or further restrict the multiplicity of
each of the component references that it promotes, with the exception that the
multiplicity of the composite reference does not have to require a target if
there is already a target on the component reference. This means that a
component reference with multiplicity 1..1 and a target can be promoted by a
composite reference with multiplicity 0..1, and a component reference with
multiplicity 1..n and one or more targets can be promoted by a composite
reference with multiplicity 0..n or 0..1. [ASM60011]
The valid values for
composite reference multiplicity are shown in the following tables:
Composite Reference multiplicity |
Component Reference multiplicity (where there are no targets declared) |
|||
0..1 |
1..1 |
0..n |
1..n |
|
0..1 |
YES |
NO |
YES |
NO |
1..1 |
YES |
YES |
YES |
YES |
0..n |
NO |
NO |
YES |
NO |
1..n |
NO |
NO |
YES |
YES |
Composite Reference multiplicity |
Component Reference multiplicity (where there are targets declared) |
|||
0..1 |
1..1 |
0..n |
1..n |
|
0..1 |
YES |
YES |
YES |
YES |
1..1 |
YES |
YES |
YES |
YES |
0..n |
NO |
NO |
YES |
YES |
1..n |
NO |
NO |
YES |
YES |
· target : anyURI (0..n) – a list of one or more of target service URI’s, depending on multiplicity setting. Each value wires the reference to a service in a composite that uses the composite containg the reference as an implementation for one of its components. For more details on wiring see the section on Wires.
·
wiredByImpl : boolean
(0..1) – a boolean value. If
set to "true" it indicates that the target of the reference is set at
runtime by the implementation code (for example by the code obtaining an
endpoint reference by some means and setting this as the target of the
reference through the use of programming interfaces defined by the relevant
Client and Implementation specification). If "true" is set, then the
reference is not intended to be wired statically within a using composite, but
left unwired.
All
the component references promoted by a single composite reference MUST have the
same value for @wiredByImpl.All the component references promoted by a single
composite reference MUST have the same value for @wiredByImpl. [ASM60035] If the @wiredByImpl
attribute is not specified on the composite reference, the default value is
"true" if all of the promoted component references have a wiredByImpl
value of "true", and the default value is "false" if all
the promoted component references have a wiredByImpl value of
"false". If the @wiredByImpl attribute is specified, its value MUST
be "true" if all of the promoted component references have a
wiredByImpl value of "true", and its value MUST be "false"
if all the promoted component references have a wiredByImpl value of
"false".If the @wiredByImpl attribute is not specified on
the composite reference, the default value is "true" if all of the
promoted component references have a wiredByImpl value of "true", and
the default value is "false" if all the promoted component references
have a wiredByImpl value of "false". If the @wiredByImpl attribute is
specified, its value MUST be "true" if all of the promoted component
references have a wiredByImpl value of "true", and its value MUST be
"false" if all the promoted component references have a wiredByImpl
value of "false".
[ASM60036]
The composite reference element has the following
child elements, whatever is not specified is
defaulted from the promoted component reference(s).
·
interface : Interface
(0..1) - zero or one interface element which declares an interface for the composite
reference. If a composite reference has an interface specified, it MUST provide an interface which is
the same or which is a compatible superset of the interface(s) declared by the
promoted component reference(s), i.e. provide a
superset of the operations in the interface defined by the component for the
reference.If a composite
reference has an interface specified, it MUST
provide an interface which is the same or which is a compatible superset of the
interface(s) declared by the promoted component reference(s), i.e. provide a
superset of the operations in the interface defined by the component for the
reference.If a composite reference has an interface specified, it MUST
provide an interface which is the same or which is a compatible superset of the
interface(s) declared by the promoted component reference(s), i.e. provide a
superset of the operations in the interface defined by the component for the
reference.). [ASM60012] If no interface is declared on a composite
reference, the interface from one of its promoted component references is used, which MUST be used for the same as or a
compatible superset of component type associated with the composite.If no interface(s) is declared byon a composite
reference, the interface from one of its promoted component reference(s). MUST be used for the
component type associated with the composite. [ASM60013] For
details on the interface element see the Interface section.
· binding : Binding (0..n) - A reference element has zero or more binding elements as children. If one or more bindings are specified they override any and all of the bindings defined for the promoted component reference from the composite reference perspective. The bindings defined on the component reference are still in effect for local wires within the composite that have the component reference as their source. Details of the binding element are described in the Bindings section. For more details on wiring see the section on Wires.
A reference identifies zero or more target services which satisfy the reference. This can be done in a number of ways, which are fully described in section "Specifying the Target Service(s) for a Reference".
· callback (0..1) / binding : Binding (1..n) - A callback element is used if the interface has a callback defined and the callback element has one or more binding elements as subelements. The callback and its binding subelements are specified if there is a need to have binding details used to handle callbacks. Callback binding elements attached to the composite reference override any callback binding elements defined on any of the promoted component references. If the callback element is not present on the composite service, any callback binding elements that are declared on all the promoted references are used. If the callback element is not present at all, the behaviour is runtime implementation dependent.
· requires : requires (0..n) - A service element has zero or more requires subelements. See the Policy Framework specification [SCA-POLICY] for a description of this element.
· policySetAttachment : policySetAttachment (0..n) - A service element has zero or more policySetAttachment subelements. See the Policy Framework specification [SCA-POLICY] for a description of this element.
The following figureFigure 5‑3Figure 5‑3 shows the reference symbol that is used to
represent a reference in an assembly diagram.
Figure 955‑3:
Reference symbol
The following figureFigure 5‑4Figure 5‑4 shows the assembly diagram for the MyValueComposite
containing the reference CustomerService and the reference StockQuoteService.
Figure 1055‑4:
MyValueComposite showing References
The following snippetSnippet 5‑5Snippet 5‑5 shows the MyValueComposite.composite file for the
MyValueComposite containing the reference elements for the CustomerService and
the StockQuoteService. The reference CustomerService is bound using the SCA
binding. The reference StockQuoteService is bound using the Web service
binding. The endpoint addresses of the bindings can be specified, for example
using the binding @uri attribute (for details see the Bindings
section), or overridden in
an enclosing composite. Although in this case the reference StockQuoteService
is bound to a Web service, its interface is defined by a Java interface, which
was created from the WSDL portType of the target web service.
<?xml version="1.0" encoding="ASCII"?>
<!-- MyValueComposite_3 example -->
<composite
xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200903200912"
targetNamespace="http://foo.com"
name="MyValueComposite" >
...
<component name="MyValueServiceComponent">
<implementation.java
class="services.myvalue.MyValueServiceImpl"/>
<property name="currency">EURO</property>
<reference name="customerService"/>
<reference name="stockQuoteService"/>
</component>
<reference name="CustomerService"
promote="MyValueServiceComponent/customerService">
<interface.java interface="services.customer.CustomerService"/>
<!-- The following forces the binding to be binding.sca -->
<!-- whatever is specified by the component reference or -->
<!-- by the underlying implementation -->
<binding.sca/>
</reference>
<reference name="StockQuoteService"
promote="MyValueServiceComponent/stockQuoteService">
<interface.java
interface="services.stockquote.StockQuoteService"/>
<binding.ws
portwsdlElement="http://www.stockquote.org/StockQuoteService#
wsdl.endpointport(StockQuoteService/StockQuoteServiceSOAP)"/>
</reference>
...
</composite>
Snippet 55‑5: Example composite with a reference
Properties allow for the configuration of an implementation with externally set data values. A composite can declare zero or more properties. Each property has a type, which is either simple or complex. An implementation can also define a default value for a property. Properties can be configured with values in the components that use the implementation.
The declaration of a property in a composite
follows the form described in the following schema snippet:
Snippet 5‑6Snippet 5‑6 shows the composite pseudo-schema with the pseudo-schema for a reference element:
<?xml version="1.0" encoding="ASCII"?>
<!-- Composite Property schema snippet -->
<composite
xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200903200912" … >
…
<property name="xs:NCName" (type="xs:QName" | element="xs:QName")
requires="list
of xs:QName"?
policySets="list
of xs:QName"?
many="xs:boolean"? mustSupply="xs:boolean"?>*
default-property-value?
</property>
…
</composite>
Snippet 55‑6: composite Psuedo-Schema with property Child Element
The composite
property element has the following attributes:
·
name : NCName (1..1) - the name of the property. The @name attribute of
a composite property MUST be unique amongst the properties of the same
composite.The @name attribute of a composite property MUST be
unique amongst the properties of the same composite. [ASM60014]
· one of (1..1):
– type : QName – the type of the property - the qualified name of an XML schema type
– element : QName – the type of the property defined as the qualified name of an XML schema global element – the type is the type of the global element
A
single property element MUST NOT contain both a @type attribute and an @element
attribute.A
single property element MUST NOT contain both a @type attribute and an @element
attribute. [ASM60040]
· many : boolean (0..1) - whether the property is single-valued (false) or multi-valued (true). The default is false. In the case of a multi-valued property, it is presented to the implementation as a collection of property values.
· mustSupply : boolean (0..1) – whether the property value has to be supplied by the component that uses the composite – when mustSupply="true" the component has to supply a value since the composite has no default value for the property. A default-property-value is only worth declaring when mustSupply="false" (the default setting for the @mustSupply attribute), since the implication of a default value is that it is used only when a value is not supplied by the using component.
§requires
: QName (0..n) - a list of policy
intents. See the Policy Framework specification [10] for a
description of this attribute.
§policySets
: QName (0..n) - a list of policy
sets. See the Policy Framework specification [10] for a
description of this attribute.
The property element can contain a default-property-value, which provides default value for the property. The form of the default property value is as described in the section on Component Property.
Implementation types other than composite can declare properties in an implementation-dependent form (e.g. annotations within a Java class), or through a property declaration of exactly the form described above in a componentType file.
Property values can be configured when an implementation is used by a component. The form of the property configuration is shown in the section on Components.
For the following
example of Property
declaration and value setting in Snippet 5‑8Snippet 5‑8, the following
complex type in Snippet 5‑7Snippet 5‑7 is
used as an example:
<xsd:schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://foo.com/"
xmlns:tns="http://foo.com/">
<!-- ComplexProperty schema -->
<xsd:element name="fooElement" type="tns:MyComplexType"/>
<xsd:complexType name="MyComplexType">
<xsd:sequence>
<xsd:element name="a" type="xsd:string"/>
<xsd:element name="b" type="xsd:anyURI"/>
</xsd:sequence>
<attribute name="attr" type="xsd:string" use="optional"/>
</xsd:complexType>
</xsd:schema>
Snippet 55‑7: Complex Type for Snippet 5‑8Snippet 5‑8
The following composite demostrates the declaration of a property of a complex type, with a default value, plus it demonstrates the setting of a property value of a complex type within a component:
<?xml version="1.0" encoding="ASCII"?>
<composite xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200903200912"
xmlns:foo="http://foo.com"
targetNamespace="http://foo.com"
name="AccountServices">
<!-- AccountServices Example1 -->
...
<property name="complexFoo" type="foo:MyComplexType">
<value>
<foo:a>AValue</foo:a>
<foo:b>InterestingURI</foo:b>
</value>
</property>
<component name="AccountServiceComponent">
<implementation.java class="foo.AccountServiceImpl"/>
<property name="complexBar" source="$complexFoo"/>
<reference name="accountDataService"
target="AccountDataServiceComponent"/>
<reference name="stockQuoteService" target="StockQuoteService"/>
</component>