SCA服务组件架构
集成模型规范
SCA 1.00版本，2007年3月15日
※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※
英文原文版权归原作者所有，本译文转载请注明出处！
译者：abigfrog 联系：QQ：800736， MSN：J2EE@HOTMAIL.COM
※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※
本文介绍了SCA集成模型，包括：
■ 服务集成模型，包括紧耦合和松散耦合；
■ 对服务以及服务互动，包括安全和事务，提供基础的性能支持模型；
本文从一个对SCA集成模型的概括介绍开始。
接下来的部分介绍了SCA的核心元素，components组件以及composites组件（译者注：这里components组件，表示一个相对独立的功能元件，composites组件，为由多个组件组成的集成的组件，下同）。
文档的最后，详细说明了如何去扩展SCA集成模型。
服务组件架构（Service Component Architecture，SCA）提供了一个基于面向服务架构构件应用系统以及解决方案的编程模型。它是基于一种这样的理念，业务功能是以一系列的服务所提供，这些服务集成在一起为一个特定的业务需要提供服务。这些components应用既可以包括特别创建的新服务，也可包括既有系统或应用所提供的业务功能，作为composites组件的一部分被复用。SCA既为服务集成也为创建服务components组件提供模型，包括既有的应用提供的功能在composites组件中的复用。
SCA模型对准的是一个很广阔的技术领域：服务components组件以及联结这些组件的访问方法。对components组件来说，不但包括各种各样的编程语言，也包括为这些语言所使用的框架和环境；对于访问方法，composites组件允许使用各种通讯以及基于服务的访问技术，例如包括：Web service，消息系统以及远程过程调用（RPC）。
SCA的基础组成部分是component组件，是SCA的基本单元。一个component组件由一个配置的实现实例组成，该功能实现是一个提供业务功能的程序的一个组成部分。它提供的业务功能以服务的形式提供出来供其他组件使用。它可能还会依赖于其他组件提供的服务——这种依赖称作引用。它可以有可设置的属性，这些属性是可以改变业务功能操作的数据。Component组件通过为属性设置值以及引用其他组件提供的服务，来配置功能实现（implementation）。
SCA可以使用多种多样的实现技术，包括“传统”的编程语言如Java、C++、BPEL，也可以使用脚本语言如PHP和JAVASCRIPT，以及声明式语言如Xquery和SQL。
SCA将集成中的内容和应用系统中的关联叫做composites组件。一个composites组件可以包括component组件、服务、引用、属性声明、以及描述这些元素之间连接的联系，可以分组和联结由不同的实现技术构建的组件，允许对于不同的业务使用适当的技术。按照顺序，一个composites组件可以被用作一个完全的component组件实现：提供服务，依赖引用并且具有可设置的属性。这样的一个composites组件实现可以被用在其他composites组件中的component组件中，允许作为一个业务解决方案中的多级结构中组成部分，高层次的服务由内置的一系列低等级服务实现，composites组件的内容也可作为组合被用在更高层的composites组件中。
Composites组件部署在SCA域（domain）中。一个SCA域一般表示的是一系列服务，提供一个被单一组织控制的业务功能区域。举例来说，对于一个业务中的帐户部门，一个SCA域可能包括了全部金融相关的功能，并且还可能包括一系列的composites组件以处理某些特定领域的帐户事务，有处理客户帐户的，也有处理帐户支付的。为了协助和配置建立SCA域，composites组件用来分组和配置相关的部件（artifacts）。
SCA为了安排它的部件定义了一个XML，这些XML文件定义了这些部件的方便的表示法。一个SCA运行时可能还有XML之外的其他的表示法。尤其，使用一些编程语言实现的component组件可能具有属性（attributes）、特性（properties）或者注释，可以指定SCA集成模型元素中的一部分。XML文件为SCA域的配置定义了静态的格式。SCA运行时也允许域进行动态配置。
1.2.1. 用图来表示SCA部件（Artifacts）
本文使用图表来表示各种SCA部件，用可视化的方式来说明一个集成应用中组件间关系。文中的配图用以说明SCA部件的示例。
下图说明了一个SCA component组件的一些特征：
图表 1 SCA Component组件图
下面这张图使用一组component组件，来说明的是composite组件的特征：
图表 2 SCA Composite组件图
接下来的图，说明SCA Domain，它由一系列的高层composite组件组成，这些高层组件中的一些也依序由更低层次的composite组件实现：
图表 3 SCA Domain图
1.3. Component组件
Component组件是一个SCA集成应用中业务功能的基本元素，被composites组件组合起来以完成一个完整的业务解决方案。
Component组件以实现的实例进行配置，它提供并且使用服务。不止一个组件可以使用和配置同一个实现，每个组件都是独立的配置它的实现。
在一个xxx.composite文件中，Component组件被声明为一个组件的子单元。一个component组件使用component节点表示，它是composite节点的子节点。Composite节点下可以有0或多个composite节点。下面的文件片段显示了针对component组件子节点的Schema说明。
|
<?xml version="1.0" encoding="UTF-8"?>
<!-- Component schema snippet -->
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
targetNamespace="xs:anyURI"
name="xs:NCName" local="xs:boolean"?
autowire="xs:boolean"? constrainingType="QName"?
requires="list of xs:QName"? policySets="list of xs:QName"?>
<component name="xs:NCName" requires="list of xs:QName"?
autowire="xs:boolean"? requires="list of xs:QName"? policySets="list of xs:QName"?
constrainingType="xs:QName"?>*
<implementation/>?
<service name="xs:NCName" 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"?/>*
</service>
<reference name="xs:NCName" multiplicity="0..1 or 1..1 or 0..n or 1..n"?
autowire="xs:boolean"?
target="list of xs:anyURI"? policySets="list of xs:QName"?
wiredByImpl="xs:boolean"? requires="list of xs:QName"?>*
<interface/>?
<binding uri="xs:anyURI"? requires="list of xs:QName"?
policySets="list of xs:QName"?/>*
</reference>
<property name="xs:NCName" (type="xs:QName" | element="xs:QName")?
mustSupply="xs:boolean"?
many="xs:boolean"? source="xs:string"? file="xs:anyURI"?>*
property-value?
</property>
</component>
</composite>
|
Component元素拥有如下属性：
1、 name（必需）：component组件的名称，名称必须唯一；
2、 autowire（可选）：是否包含的component组件引用被自动关联，具体在
1.6.4.2 Autowire
章节有详细描述，默认为false；
3、 requires（可选）：策略列表，参考Policy Framework specification [10]查看详细描述；
4、 policySets（可选）：策略组列表，参考Policy Framework specification [10]查看详细描述；
5、 constrainingType（可选）：constrainingType的名称，当指定以后，component,组件的服务、引用、属性，以及相关的意图（intents），被约束在定义好的constrainingType集合内，查看
constrainingType
部分获取更多细节。
一个component节点拥有0或1个implementation子节点，指向该component组件引用的实现。一个没有implementation节点的component是不可运行的，但这种的component组件在自上向下的开发流程，在代码实现之前作为一种特性定义的方式的时候，是很有用的。
Component节点可以有0或n个service子节点，用以配置该Component节点所能提供的服务，这些可配置的服务是被implementatio定义的。
Service节点的属性：
1、 name（必需）：service的名称。必须对应implementation定义的service名称。
2、 requires（可选）：policy intents列表，参考Policy Framework specification [10]。
3、 policySets（可选）：policy sets列表，参考Policy Framework specification [10]。
Service有0或1个接口，描述该服务所提供的操作（operations）。节点使用interface表示，是service节点的子节点。如果没有指定接口，那么由implementation指定的接口是有效的。如果指定了接口，那么它必需提供一个implementation提供的接口的子集，例如，提供服务的implementation所定义的操作的子集，详细可参看the Interface section章节。
Service节点拥有0或n个binding子节点。如果没有指定binding，那么由implementation为service定义的binding有效。如果指定了，那么这些binding会覆盖掉由implementation提供的binding。具体细节，可参考the Bindings section章节。
Component节点可以包含0或n个c子节点，用来配置Component组件的引用，这些引用为implementation所定义。
Implementation节点的属性列表：
1、 name（必需）：引用的名称，必须对应到implementation指定的名称。
2、 autowire（可选）：reference是否自动连接，参考the Autowire section章节，默认为false。
3、 requires（可选）：policy intents列表，细节参看Policy Framework specification [10]章节。
4、 policySets（可选）：policy sets列表，参看Policy Framework specification [10]。
5、 multiplicity（可选）：定义可以连接到目标服务的连接数目，覆盖了implementation中为reference所做的设定。值必须等于或更加严格，例如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或多个连接可以使用该引用作为源引用
6、 Target（可选）：一个或多个目标服务URL列表，取决于multiplicity设定。每个值将该reference连接到一个component服务，该服务用以解析这个reference。细节请参看the section on Wires。覆盖implementation上任何指定的target数据。
7、 wiredByImpl（可选）：布尔值，默认为false，表示implementation动态的连接到reference，如果设为true，reference 的target是在运行时的实现代码中设置的（）。如果设置为了true，则reference不应在一个composite组件中进行静态绑定，而是不进行绑定。
一个reference包含0或1个接口，描述被reference所需要的操作。接口使用interface节点表示。是reference节点的子节点。如果没有指定interface，那么implementation为reference指定的interface是有效的。如果指定了interface，它必须提供一个由implementation提供的interface的超集，例如，提供一个implementation为reference定义的操作的超集，详细请参看the Interface section一章。
扫一扫
7482
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
