1.1 简介

本文档介绍了SCA组装模型，内容包括：

l         紧密耦合和松散耦合的服务组装模型；

l         对服务和服务交互，包括安全和事务，提供基础（infrastructure）的性能（capabilities）支持模型；

文档首先概要地介绍了SCA组装模型。第二部分介绍了SCA、SCA组件（components）和SCA构件（composites）的核心原理。第三部分定义了SCA组装模型如何扩展。

关键词： 组件（component）；构件（composite）；部件（artifact）；提升（promote）；服务（service）；引用（reference）；实现（implementation）；属性（property）；QName（限定名，通常由两部分组成）

1.2 概论

基于SOA（Service Oriented Architecture），服务组件架构（SCA）提供了构建应用和解决方案的编程规范。业务功能（business function）由一系列服务提供，这些服务可以组装到一起来为一个特定的业务需求创建解决方案。这些composite应用包含为特定应用而创建的新服务，也包括已有系统或应用提供的业务功能，这些已有的业务功能作为组合（composition）中一部分被重用。SCA规范为服务组合及服务组件（component）的创建提供了模型，包括已有的应用在SCA composites中的复用。

SCA模型的目的是为服务组件及用来联结它们的访问方法包含（encompass）更宽范围的领域。组件可以使用不用的编程语言以及框架和运行环境。SCA组合（compositions）允许使用通用的服务访问技术，比如Web services、消息系统（Messaging systems）和远程过程调用（Remote Procedure Call，RPC）。

SCA组装模型由一系列部件（artifacts）组成，这些artifacts根据composites（包括服务组件和联系的组装）定义了一个SCA域的配置以及描述组件如何连接到一起。

组件是SCA应用程序的原子。一个组件是一个可以配置的实现（implementation）的实例，这里实现是提供业务功能的代码块。业务功能以服务（services）的形式提供给其它组件使用。实现可以依赖于其它组件提供的服务，这些依赖（dependencies）称为引用（references）。实现还能有可设置的属性（properties），这些属性是可以改变业务功能操作的数据。组件通过设置属性的值及引用其它组件提供的服务来配置实现（implementation）。

SCA允许使用更多种类的实现技术，包括传统的编程语言，如Java，C++和BPEL，以及脚本语言PHP，JavaScript和声明式语言，如XQuery，SQL。

SCA把组装中的内容和应用系统中的关联（linkage）称为构件（composites）。composites可以包含组件（component）、服务（services,）、引用（references）、property声明和连线（wiring），其中连线描述了这些元素之间的联系。composites可以分组和联结通过不同的应用技术构建的components，允许为不同的任务使用合适的技术。相反，一个composite可以被用作一个完整的component实现：提供服务、依赖引用和提供可设置的property值。一些composite实现可以被用在其它composite中的组件里，允许作为一个业务解决方案中的等级结构，即高层次的服务可以由一些低层次的服务实现。composite的内容可以组合被使用在更高层的组合中。

Composite部署在SCA域中。一个SCA域通常代表着一些服务的组合，这些服务提供了一个被单一组织控制的业务功能区域。举个例子，对于业务中的账目（accounts）部门，SCA域可能覆盖了所有金融相关的功能，它还可能包含了一系列composites来处理特定领域的账目，其中有负责客户的账目，也有处理账目的应付。为了帮助构建和配置SCA域，构件（composites）可以用来分组和配置相关的部件（artifacts）。

SCA为它的部件定义了一个XML文件，这些XML文件定义了这些部件的方便的表示法。一个SCA运行时可以还有XML之外的其它的表示法。特别地，使用一些编程语言实现的组件可能具有属性（attributes）、特性（properties）或注释（annotations），它们可以指定SCA组装模型元素中的一部分。XML文件为SCA域的配置定义了静态的格式。SCA运行时也允许域进行动态配置。

1.2.1 用图来表示SCA部件（Artifacts）

本文引入图（diagrams）表来表示各种SCA部件，用可视化的方式来说明特定组装应用中组件间的关系。文中的这些图用以说明SCA部件的示例。

图1说明了一个SCA component组件的一些特征：

                图1. SCA 组件图

图2使用一个组件（component）集来说明构件（composite）的特征： 

                                图2. SCA构件图

图3说明SCA 域，它由一系列的高层构件组成，这些高层构件中的一些也依序由更低层次的构件实现：

                                                     图3. SCA域

1.3 组件（component）

组件是一个SCA集成应用中业务功能的基本元素，被构件（composites）组合起来以完成一个完整的业务解决方案。

Component组件以实现的实例进行配置，它提供并且使用服务。不止一个组件可以使用和配置同一个实现，每个组件都是独立的配置它的实现。

在一个xxx.composite文件中，Component组件被声明为一个composite组件的子元素。一个component组件使用component元素表示，它是composite元素的子元素。Composite元素下可以有0或多个component元素。下面的代码片段展示了带有component组件子元素的composite 模式。

Component元素有下面的属性：

l         name（必需）：component组件的名称，在composite所有的组件中名称必须唯一；

l         autowire（可选）：包含的component组件引用是否被自动关联，具体在Autowire章节有详细描述，默认为false；

l         requires（可选）：策略意图列表，参见Policy Framework specification [10]查看其详细描述；

l         policySets（可选）：策略组列表，参考Policy Framework specification [10]查看其详细描述；

l         constrainingType（可选）：constrainingType的名称，当指定以后，component组件的服务、引用、属性，以及相关的意图（intents），被约束在定义好的constrainingType集合内，查看the ConstrainingType部分获取更多细节。

一个component元素拥有0或1个implementation子元素，指向该component组件引用的实现。一个没有implementation元素的component是不可运行的，但这种component组件在自上向下的开发流程中，在代码实现之前作为一种特性定义的方式是很有用的。

一个component元素可以有0或多个service子元素，用以配置该Component元素所能提供的服务，这些可配置的服务是被implementation定义的。

Service元素的属性：

l         name（必需）：service的名称。必须对应implementation定义的service名称。

l         requires（可选）：策略意图列表，参考Policy Framework specification [10]。

l         policySets（可选）：策略集列表，参考Policy Framework specification [10]。

一个service元素有0或1个接口，描述该服务所提供的操作（operations）。元素使用interface表示，是service元素的子元素。如果没有指定接口，那么由implementation指定的接口是有效的。如果指定了接口，那么它必须提供一个由implementation提供的可兼容的接口子集，例如，提供服务的implementation所定义的操作的子集，详细可参看the Interface section章节。

一个service元素拥有0或多个binding子元素。如果没有指定binding，那么由implementation为service定义的binding有效。如果指定了，那么这些binding会覆盖掉由implementation提供的binding。具体细节，可参考the Bindings section章节。Binding及对binding生效的policySets必须满足service中的policy intents的规定。

一个component元素可以包含0或多个reference子元素，用来配置Component组件的引用，这些引用被implementation所定义。

Implementation元素的属性列表：

l         name（必需）：引用的名称，必须对应到implementation指定的名称。

l         autowire（可选）：引用是否自动连接，参考the Autowire section章节，默认为false。

l         requires（可选）：策略意图（policy intents）列表，细节参看Policy Framework specification [10]章节。

注：reference中policy intents的有效集合是由requires属性显式声明的任何一个intents，还可以是implementation中reference指定的任何一个intents。

l         policySets（可选）：策略集（policy sets）列表，参看Policy Framework specification [10]。

l         multiplicity（可选）：定义可连接到目标服务reference的连接数目，覆盖了implementation中为reference指定的multiplicity。它的值必须等于或更加严格，例如0..n到0..1，或者1..n到1..1，multiplicity可以具有以下值：

a)                1..1：1个连接可以使用该引用作为源引用

b)               0..1：0或1个连接可以使用该引用作为源引用

c)                1..n：1个或多个连接可以使用该引用作为源引用

d)               0..n：0或多个连接可以使用该引用作为源引用

l         target（可选）：一个或多个目标服务URI列表，取决于multiplicity的设定。每个值将该reference连接到一个component服务，该服务用以解析这个reference。细节请参看the section on Wires。覆盖implementation上任何指定的target数据。

l         wiredByImpl（可选）：布尔值，默认为false，表示implementation是否动态连接到reference，如果设为true，reference 的target是在运行时的实现代码中设置的（即，在代码中通过某种方式得到一个终点（endpoint）reference并通过使用相关客户（Client）和指定实现（Implementation）定义的程序接口把它作为reference的target设置，）。如果设置为true，则reference不应在一个composite组件中进行静态绑定，而是不进行绑定。

一个reference包含0或1个接口（interface），它们描述reference所需要的操作。接口使用interface元素表示，它是reference元素的子元素。如果reference没有指定interface，那么implementation为reference指定的interface是有效的。如果reference指定了interface，它必须提供一个由implementation提供的interface的超集，例如，提供一个implementation为reference定义的操作的超集，详细请参看the Interface section[A1] 。

一个reference包含1个或多个binding子元素。若reference没有指定binding，则implementation为reference指定的binding是有效的。如果它指定了binding，则这些banding会覆盖implementation指定的所有bindings，详细请参看Bindings section。Binding及生效的PolicySets必须满足reference的策略意图集（policy intents），参见the Policy Framework specification[10]。

注意，一个binding元素可以指定一个endpoint，endpoint是binding的目标（target）。一个reference不能混合使用binding元素指定的endpoint和target属性指定的endpoint。如果target属性设定了endpoint，那么binding元素只能列出一个或多个用来连线的绑定类型，这里连线（wires）由target属性指定。在这种情况下，所有被标识的用于每个连线的绑定类型都是有效的。如果endpoints在binding元素里被指定，每一个endpoint必须使用binding元素里定义的绑定类型。另外，每个binding元素需要指定一个endpoint。

一个component元素有0或多个property子元素，它们被用来配置implementation中property的值。每一个property元素提供一个传递给implementation的property的值。property及其类型可以在implementation定义中配置。一个implementation可以声明一个property为多值的，在这种情况下，一个给定的property会有多个属性值。

Property的值可以通过下面三种方式之一指定：

l         value属性，提供property元素的内容。

l         source属性，它引用一个包含此component的composite的property的值。

Source属性值的形式遵循XPath表达式的形式。这种形式允许通过名字引用composite中的一个特定属性。在属性复杂的地方，XPath表达式可以被扩展去引用一个复杂值的子部分（sub-part）。

举例来说，source=“$currency”用来引用composite的一个叫“currency”的property，而source=“$currency/a”引用一个复杂composite的叫做“currency”property的子部分“a”。

l         file属性，它指定一个解除参照（dereferencable）的指向文件的URI来获取属性值。被引用文件的内容作为此property的值。

如果当前指定超过一个属性值的时候，source属性优先于file属性。

可选地，Property的类型（type）可以通过下列两种方式之一指定：

l         type属性，定义在XML模式中的一个type的限定名

l         element属性，XML模式中的一个全局元素的限定名

指定的属性类型（property type）必须和在implementation中声明的属性类型一致。如果没有指定类型，将使用在implementation中声明的属性类型。

Property有下列属性：

l         name（必须）：property的名字。必须对应实现定义的property的名字。

l         type（可选）：property的类型，定义为一个XML 模式 type的限定名。

l         element（可选）：property的类型，定义为一个XML模式全局element的限定名。

l         source（可选）：一个XPath表达式，指向一个包含此组件的composite的property。

l         file（可选）：一个解除参照（dereferencable）的URI，指向包含一个值的文件。

l         many（可选）：值为false表示property是单值的，值为true表示property是多值的。它将覆盖实现指定的property的many属性。这个值必须相等或更加严格，比如，如果实现指定many为true，那么component可以说成false。在property多值的情形下，它将对应implementation中property值的一个Collection。