1 装配模型
1.1 简介
该文档描述SCA装配模型，其覆盖如下内容：
服务的装配模型，既适合紧偶合也适合松散偶合。
应用服务的和与服务交互的基础设施功能模型，包括安全性和事务性。
本文档由对SCA装配模型的简短概述开始。
文档的后半部分描述了SCA的核心元素，SCA component（译为：组件）和SCA composite（译为：构件）。
1.2 概述
SCA为构建应用和基于SOA的解决方案提供了编程模型。它基于将业务功能作为一系列的服务，并由该一系列的服务组装在一起来满足特定业务的需求的理念。这些组合的应用既包含新创建的服务，又包含已存在系统和应用作为复用的构件。SCA既为服务的组件也为组件服务的创建，包括对SCA构件中复用已存在的应用功能提供了模型。SCA就是一个致力于包含各种广泛的服务组件和服务组件访问方式的技术模型。对于访问方式，SCA构件允许各种通讯和广泛使用的服务访问技术的使用。其中包括象Web service、Messaging 系统和远程过程调用(RPC)技术等。
SCA装配模型由系列工件组成。这些工件定义了包含了服务组件(component)和连接(connection)的装配信息和描述了他们是如何连接在一起的相关工件的SCA域配置信息。
SCA的基础工件就是component，他是SCA的构成单元。组件(component)由一个被配置了的实现实例组成。在此当中，实现是一段提供了业务功能的程序代码。该业务功能被其他组件作为服务(service)来使用。实现也许依赖于由其他组件提供的服务，这些依赖就称作”引用”(reference)。实现可以有一个可以设置的属性(properties)，该属性是可以改变业务功能操作的数据值。组件通过提供属性值和引用来配置实现。
SCA允许各种广泛采用的实现技术，比如传统的象Java,C++,BPEL的编程语言，也包括象PHP，Javascript的脚本语言，还有象XQuery和SQL的声明性语言。
SCA在装配中描述的内容和应用的联接称为“composite”。构件能包含组件，服务，引用，属性声明还有描述这些元素连接方式的连线(wire)。构件可以分组和连接到用不同技术实现的组件。依次地，构件能作为完整的组件实现来使用：提供服务，依赖引用和可设置的属性值。构件实现能作为其他构件中的组件来使用，支持业务解决方案的分层构建。在该解决方案中，高层服务内部是由一系列的低层服务实现的。构件的内容能作为元素组来使用。该元素组被包含于高层构件中发挥作用。
构件是被部署于SCA Domain域中的。典型地，SCA域描述了一系列的服务，这些服务提供了由某个单一组织控制的业务功能范围。举个例子来说，商务中的会计部门，SCA域也许会涵盖所有的财务相关的功能，还会包含一系列的处理特定会计范围的、某个处理客户帐户的以及处理应付帐户的构件。为了方便构建和配置SCA域，构件被用于分组和配置相关的工件。
SCA为它的工件定义了XML文件格式。这些XML文件定义了轻便的SCA工件的描述。SCA运行时可以有其他的被这些XML文件所描述的工件的描述。特别地，用某种编程语言实现的组件实现可以有属性或用于指定SCA装配模型中某些元素的注解(annotation)。这些XML为SCA 域的配置定义了一个静态的格式。SCA运行时也运行动态地修改域的配置。
1.2.1 用于描述SCA工件图
该文档将用可视化工件之间的关系的方式来描述各种SCA工件图。这些图用来配合和阐述SCA工件的案例。下图说明了SCA组件的某些特征：
下列图阐述了使用一系列组件装配的构件的某些特征：
下图说明了由一系列高层构件装配成的SCA域，其中某些高层构件是由低层组件依次实现的。
1.3 组件
Component是SCA装配集中业务功能的基础元素。其被SCA composite组合成完成的业务解决方案。
Component是实现配置化的实例。组件提供和消费服务。多个的组件可以使用和配置为同一个实现。而在每个实现中，每个组件又可以配置为不同的实现。
组件在xxx.composite的文件中作为composite的子元素来声明。Component元素代表组件，它是composite元素的子元素。在composite中可以有零个或多个组件元素。以下片段展示了带有组件子元素schema的composite 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元素有如下属性：
l name(必须) –组件的名字。在构件里的所有组件中名字必须唯一。
l autowire(可选) –指示包含的组件引用是否自动连线，默认是false，autowire在“自动连线”节会讲到。
l requires(可选) –策略意图的列表。查看策略框架规范对该属性的描述。
l policySet(可选) –策略集列表。查看策略框架规范对该属性的描述。
l constrainingType(可选) –强制类型的名字。组件的服务、引用和属性的集合，加之相关的意图将被限顶为强制类型的定义设置。更多细节请查看“强制类型”节。
component元素有零个或多个implementation子元素，该子元素指出组件的实现。没有implementaion子元素的component是不能运行的,但这种组件也许在自顶向下的开发过程中，在实现被开发出来之前作为一种定义实现的特定需求的手段还是有用的。
Component元素有零个或多个service子元素，用于配置组件的服务。配置化的服务是由实现定义的。
Service元素有如下属性：
l name(必须) –服务名字。必须匹配由实现定义的服务名。
l requires(可选) --策略意图的列表。查看策略框架规范对该属性的描述。
注意：服务的有效的策略意图集由该requires属性中显式定义的任意的意图组成， 与任何指定的服务意图结合。
l policySet(可选) –策略集列表。查看策略框架规范对该属性的描述。
Service有零个或一个接口。该接口描述了服务提供的操作。接口是由作为service元素的子元素--interface元素来描述的。如果没有指定接口，那么实现为服务指定的接口有效。如果指定了接口，实现就必须提供一个兼容接口的子集。比如，提供一个服务实现定义的操作子集。Interface元素的细节信息，请看“接口”节。
service元素有一个或多个binding子元素。如没有指定binding，那么实现为服务指定的binding有效。如果指定了，那些绑定会覆盖实现指定的绑定。Bingding元素的细节信息，请查看”绑定”节。Binding和任意有效的PolicySet结合，必须满足服务的策略意图集。
component元素有一个或多个reference子元素，用于配置组件的引用。可以配置化的引用是由实现定义的。
reference元素有如下属性：
l name (必须) –引用名字。必须匹配由实现定义的引用名称。
l autowire(可选) -- autowire(可选) –指示包含的组件引用是否自动连线，默认是false，autowire在“自动连线”节会讲到。
l requires (可选) --策略意图的列表。查看策略框架规范对该属性的描述。
注意：服务的有效的策略意图集由该requires属性中显式定义的任意的意图组成， 与任何指定的服务意图结合。
l policySet(可选) –策略集列表。查看策略框架规范对该属性的描述。
l multiplicity(可选) –定义了能连接到目标服务引用的连线数目。覆盖实现上的引用指定的多重性。其值只能遵循或更进一步的限制：比如 0..n to 0..1 或 1..n to 1..1。multiplicity可以是如下取值：
Ø 1..1 –作为源，只能有一个引用的连线
Ø 0..1 –作为源，能有0个或1个引用的连线
Ø 1..n –作为源，能有1个或多个引用的连线
Ø 0..n –作为源，能有0个或多个引用的连线
l target (可选) –一个或多个目标服务URI的列表，依赖于multiplicty的设置。每个值都连线到解析引用的组件服务的引用。具体细节查看“连线”节。覆盖实现中该引用的任意指定的目标。
l wiredByImpl（可选）--一个boolean值。默认”false”，指示实现动态地连线该引用。如果设置为”true”，表示这个引用的目标由实现代码在运行时设置（比如，由代码用某总方式来维护endpoint引用，并通过使用相关的客户程序和实现规范中定义的编程接口设置该引用为目标）。如果设置为”true”，那么在构件中引用不应该被静态地连线，而是不要连线。
引用有零个或一个接口，描述引用必须的操作。接口用作为reference元素的子元素interface元素来描述。如果没有指定接口，那么实现为服务指定的接口有效。如果指定了接口，实现就必须提供一个兼容接口的子集。比如，提供一个服务实现定义的操作子集。Interface元素的细节信息，请看“接口”节。
Reference有0个或多个binding子元素。如没有指定binding，那么实现为服务指定的binding有效。如果指定了，那些绑定会覆盖实现指定的绑定。Bingding元素的细节信息，请查看”绑定”节。Binding和任意有效的PolicySet结合，必须满足服务的策略意图集。
注意：binding元素可以指定endpoint，它是绑定的目标。引用必须不能混用通过binding元素指定的endpoint和通过target属性指定的endpoint。如果target属性设置了，那么bingding元素只能列出一个或多个绑定类型，该绑定类型用于由target属性所标识的连线。这种情况下，所有的被标识的用于每个连线的绑定类型都是有效的。如果在binding元素中指定了endpoint，那么每个endpoint必须使用binding元素中定义的绑定类型。除此之外，这种情况下，每个binding元素必须指定endpoint。
component元素有零个或多个property子元素。该子元素用于配置实现的属性数据值。每个property元素都为命名的属性提供了一个传递给实现的值。可配置的属性和类型由实现定义。实现可以声明某个属性为multi-valued（多值），在这种情况下，给定的属性会存在多个属性值。
属性值可以按以下三种方式之一来指定：
l 提供属性元素的内容
l 通过引用包含组件的构件的属性值。该引用使用了property元素的source属性。
Source属性值的形式允许为某个XPath表达式的形式。该形式允许为能通过名字定 位的构件的特定属性。在属性复杂的地方，能扩展XPath表达式来涉及复杂值的子 部分。
所以，比如，source=”$currency”用于引用叫“currency”的构件属性，而 source=”$currency/a” 用于引用叫currency的复杂构件属性的”a”子部分。
l 通过使用file属性指定一个解除参照的指向文件的URI来获取属性值。引用文件的内容用于属性值。
如果存在多于一个的属性值，source属性优先，然后是file属性。
可选地，属性的类型可以按以下两种方式之一来指定：
l 通过在XML schema中定义的类型qualified name，使用type属性
l 通过在XML schema中的全局元素的qualified name，使用element属性
指定的属性类型必须和实现所声明的属性类型保持兼容。如果没有指定类型，就使用实现中定义的属性类型。
to be continue .....
