SCA的演化

　　SCA（Service Component Architecture）即服务组件架构（其他称法有服务构件架构、面向服务的体系架构等），它提供了一个编程模型来构建和开发基于SOA（Service Oriented Architecture）的应用系统。SCA于2005年11月30日，由IBM、BEA、Oracle、SAP、Iona、Siebel和 Sybase等公司正式推出，版本号为0.9。2007年，IBM、BEA等SCA规范参与厂商共同成立OSOA（Open Service Oriented Architecture）组织来制定和推动 SCA以及SDO（Service Data Objects）规范，同年3月，OSOA组织正式发布SCA系列规范1.0版本。

　　开发一个SOA应用系统，编程模型和数据模型是其两个重要方面，SCA用于提供编程模型，SDO则提供了数据模型，SDO致力于为应用系统中处理数据提供统一的方式，SCA和SDO并不需要一起使用，本文也只讨论SCA。SCA并不仅仅只有一个规范，它目前共包含了16个规范。这16个规范可以归于三类：1.核心规范，由装配模型规范（Assembly Model）和策略框架规范（Policy Framework）组成，用于定义SCA中的组件装配模型和策略框架；2.服务组件实现技术规范，用于定义SCA的组件实现技术，SCA支持多种语言和技术作为SCA的组件实现，并且SCA还提供了可扩展框架来支持开发人员添加新的组件实现技术，目前SCA规范已经定义了Java，C++等实现技术；3.绑定（Binding）技术支持规范，在一个大型SOA应用中，一个常见的问题便是不同的服务间需要通过不同的访问协议来进行互操作，绑定技术规范便是用于定义SCA服务或引用所支持的访问协议，SCA支持多种绑定技术，其可扩展框架同时支持开发人员添加其他绑定技术，目前SCA定义了JMS、Web Service等绑定技术。

　　下面给出了SCA目前所包含的16个规范，所有规范的最新版本号都是 1.0：

　　核心规范

　　SCA Assembly Model

　　SCA Policy Framework

　　SCA Transaction Policy

　　SCA Assembly Extensions for Event Processing

　　组件实现技术规范

　　SCA Java Common Annotations and APIs

　　SCA Java Component Implementation

　　SCA Spring Component Implementation

　　SCA BPEL Client and Implementation

　　SCA C++ Client and Implementation

　　SCA COBOL Client and Implementation

　　SCA C Client and Implementation

　　SCA Java EE Integration Specification

　　绑定技术规范

　　SCA Web Services Binding

　　SCA JMS Binding

　　SCA EJB Session Bean Binding

　　SCA JCA Binding

　　SCA在推出之初，并没有这么多规范，一些规范是随着SCA的发展而诞生的，在今后的发展中，OSOA组织亦可能推出更多的规范，下面介绍下SCA的演化及演化过程中各版本的主要区别。

　　IBM等公司虽然于2005年11月才第一次正式发布SCA规范，但实际上，IBM WebSphere Process Server 6.0版本中便已经实现了一个最初的 SCA，同时IBM WebSphere Integration Developer 还提供了开发工具用于开发 SCA 应用。目前，SCA 系列规范已经发展到了1.0版本，在运行容器方面，IBM、Oracle等主流厂商亦在开发支持SCA的运行容器，IBM WebSphere Process Server 7.0通过利用Apache Tuscany项目的核心代码，已经可以支持SCA 1.0部分规范。

　　SCA发展至今，已经经历了多个版本，我们可以根据时间顺序，把SCA的发展分为三个阶段：1.起源阶段，即IBM首次在WPS 6.0中所支持的SCA；2.发展阶段，即IBM联合其他厂商在05年首次公开推出的SCA 0.9版本；3.成熟阶段，即OSOA于07年推出的SCA 1.0版本。下面，我们主要介绍这三个阶段中SCA核心规范的发展和带来的区别。

　　起源- WPS中所支持的SCA

　　SCA由IBM于WebSphere Process Server 6.0版本中首次提出，WPS为部署和运行SCA应用的容器，IBM WebSphere Integration Developer则提供了基于Eclipse 3.0的开发工具来开发和部署SCA应用。

　　IBM WPS V6.0中的SCA已经给出了完整的SCA装配模型，并提供了一个实现QoS（Quality of Service）的机制。下面，我们就将WPS 6.0中的SCA的装配模型和QoS机制和1.0版本做个比较。由于本文主要介绍SCA各版本演化过程中的区别，而不会详细介绍各版本的具体内容，读者可通过参考文献章节，获取各版本的详细资料。

　　装配模型

　　WPS 6.0中的SCA中的装配模型和SCA装配模型1.0相比，主要有两点区别：1.修改了组件模型中部分概念名称；2.缺乏如复合组件（Composite）及嵌套装配（Recursive Assemble）等概念。

　　概念名称的修改

　　WPS 6.0中的SCA装配模型和SCA装配模型相比，基本内容相似，但部分概念名称已经发生了变化，图1给出了WPS 6.0中SCA组件模型示意图。

图1 . WPS 6.0中的SCA组件模型示意图

图中的箭头1所指的导入（Import）就是目前SCA中的引用（Reference），箭头2所指的导出（Export）就是目前的服务（Service），箭头 3 所指的独立引用（Standalone reference）在0.9以及后续版本中已经消失，非SCA应用的客户端可以通过当前模块的上下文对象（context）来获取指定名称的服务实例。

　　上面的这3个变化都发生在SCA模块（Module）层次，实际上，在组件（Component）层次上，WPS 6.0中的SCA依然包含服务和引用两个概念。那么为什么在最新版本中要修改这几个概念名称，原因有两点：1. 可以简化SCA中的概念，并能够对SCA的组件模型有一个一致的描述；2. 从本质上看，模块层次上的导出和导入相比组件层次上的服务和引用，实际上是同一个东西，只不过可见性不同。

　　缺乏如复合组件等概念

　　自SCA 0.95 起，SCA新增了复合组件这个概念来代替模块这个概念，并且复合组件可以作为组件的实现，从而形成嵌套组件装配，嵌套组件装配模型更灵活强大，更容易支持组件装配开发。

　　在部署和打包方面，WPS V6.0中的SCA并没有对这方面做详细定义，而SCA自0.9起，增加了对打包和部署作了相关定义。

　　另外，WPS V6.0中的SCA中的Java实现并不支持用Annotation来描述组件信息。

　　在可扩展性支持方面，WPS V6.0中的SCA不支持任何接口、实现和绑定的扩展。

　　QoS的机制

　　在WPS V6.0中，开发人员可以通过限定符（qualifier）来对引用、接口和实现三个地方来进行声明式的QoS应用，该QoS声明机制可以支持事务、安全性和可靠的异步调用。而 SCA 最新版本中已经没有了限定符这个概念，其QoS机制由策略框架规范定义，主要由Intent和Policy　Set两部分组成，并同时支持Annotation和XML声明式定义。

　　通过以上的分析介绍，可以发现起源阶段的SCA和最新的SCA 1.0相比，变化较多，下面我再来了解下SCA的发展阶段。

　　发展-SCA 0.9系列规范

　　在SCA 0.9版本发布之前，SCA只是IBM内部的一个组件编程规范，而自0.9起，IBM、Oracle 等主流厂商开始走到一起共同合作并推动 SCA 成为 SOA 的编程规范。0.9版于2005年11月正式发布，它是在WPS V6.0的基础上发展的，主要有以下3个方面的发展：1.修改了部分概念名称；2.提出了一个可扩展模型；3.提出了新的策略框架并给出了关于SCA应用打包和部署方面的定义。下面作分别介绍。

　　概念名称的修改

　　SCA 0.9同WPS V6.0中的SCA相比，组件模型变化不大。在概念上，主要是取消了独立引用这个概念，非SCA客户端通过获取模块的上下文对象来获取服务实例，导入变成了外部服务（External Service），模块内部的组件一律通过外部服务来调用外部SCA或非SCA服务，另外导出变成了服务入口（Entry Point），图2为SCA 0.9的装配模型示意图。

图 2 .SCA 0.9装配模型示意图

同SCA 1.0相比，上面的概念名称又发生了变化，服务入口变成了服务，外部服务改为引用。

　　可扩展模型的提出

　　可扩展模型是SCA 0.9同之前版本的最大区别之一，在之前的版本中，开发人员只能使用WPS所支持的实现、接口以及绑定，但在0.9版本，开发人员可以通过遵循可扩展模型，开发自己所想要的接口、实现和绑定技术。可扩展模型的出现，使得SCA变得更加灵活，毕竟目前有多种实现、接口以及绑定技术，并且今后还会有更多的技术出现。SCA作为一个侧重于将传统应用封装为服务的一个组件模型，有必要通过可扩展的方式，支持开发人员来增加其所需要的各种实现、接口以及绑定。

　　策略框架和打包与部署的提出

　　WPS V6.0中的SCA通过限定符来支持QoS，但其并没有提出一个完整的可扩展的策略框架，而SCA0.9首次在附录中提出了一个可扩展的声明式的策略框架。

　　SCA 0.9还在附录中给出了SCA应用的打包和部署，并因此增加了子系统（Subsystem）这个概念，因为在实际应用，同一个业务子系统中必然会由多个模块共同组成，那么子系统则是用于将这些模块包含在一起，一个子系统可以包含多个模块，并且也可以提供服务入口供其他客户端调用，同时也可以通过外部服务来调用外部SCA和非SCA服务。子系统的提出使得SCA组件模型可以在粗粒度上支持组件的装配。在打包和部署方面，SCA既允许打包和部署SCA模块，亦可以打包和部署SCA子系统。

　　SCA 0.9虽然是第一个正式公开发布的版本，但是它实际上是一个过渡版本，相比WPS V6.0中的SCA，虽然有些区别，但差别并不明显，策略框架虽然有很大的差别，但是它只是提出了一个大概的框架。在0.9版本发布后不久，OSOA组织相继发布了0.95、0.96等版本，并于07年发布了SCA系列规范的1.0版本。下面我们就来了解下SCA在成熟阶段中的变化。

　　成熟-SCA 1.0

　　作为一个成熟的版本，SCA 1.0更为完善，同SCA 0.9 相比，主要有三点变化：1. 重新整理了部分概念名称，使得整个装配模型中的概念表述更加一致；2.提出了新的嵌套装配模型；3.提出了完善的策略框架。图3为SCA 1.0组件装配模型示意图。下面将分别介绍这三点。

图 3 .SCA 1.0组件装配模型图

　　概念整理

　　SCA 1.0重新修改了模块层次上的服务和引用的名称，改为使用组件层次中使用的服务和引用，使得组件模型概念的表述更为一致。另外它抛弃了模块这个概念，而使用复合组件这个当前更广为使用的名称，同时在打包和部署方面，抛弃了子系统这个概念，并由域（domain）这个概念代替，另外还增加了贡献（contribution）这个概念，并由XML描述文件来描述这些一起打包的构件间的依赖关系以及所需要的其他构件，如Java类等。

　　嵌套组件装配模型的提出

　　早期版本的SCA只能支持模块包含组件，而不能支持组件再嵌套包含模块，如果需要将另一模块中的服务作为本模块的服务公开，需要通过调用目标模块的服务入口，才能使用其他模块的服务，由于不能支持嵌套装配，组件很难使用已有的模块中提供的功能，导致模块的可复用性降低，另外由于组件的粒度太细，不支持组件嵌套，容易导致一个模块包含大量组件的现象，这将会增加程序维护的复杂度。

　　嵌套组件装配模型去掉了模块这个概念，转而由复合组件代替。复合组件由多个组件装配而成，各组件的实现可以是另外的复合组件，从而实现了组件的递归嵌套，这样可以很方便的重用已有的复合组件。清单1是OSOA网站给出的示例复合组件的描述文件，可以发现SCA通过 implementation.composite 来将复合组件作为组件的实现。

　　清单 1. 复合组件作为组件实现的示例代码

以下是引用片段：
<composite

                targetNamespace=”http://bigbank.com”
      name=”bigbank.AccountManagement”>
<component name=”bigbank.Account”>
<implementation.composite name=”bb:bigbank.Account” />
<property name=”currency”>EURO</property>
<reference name=”stockQuoteService”>
http://www.eurosq.com/SQService
</reference>
</component>
</composite>

　　策略框架的完善

　　SCA 1.0给出了一个完善的策略框架，该框架通过声明式的设定，可以使得同一个SCA组件能够通过配置实现不同的QoS的需求。该框架有两个重要的概念：1.Intent，intent是一个抽象的QoS需求，比如消息传输中需要关注的保密性（confidentiality）和可靠性（reliability）等；2.Policy Set，系统在SCA应用部署时期，将intent通过policy set映射到具体的policy，从而为SCA组件应用具体的 policy。由于 SCA 的策略框架并不是本文的重点，读者可以通过参考文献中给出的链接，获取更多有关策略框架的信息。

　　通过上面的介绍，可以看出SCA 1.0更加成熟和完善，目前各大厂商也正基于SCA 1.0来开发运行容器。

　　各版本区别对照表

　　前面的三个小节介绍了SCA在三个阶段中的演化和区别，下面通过表格的形式，对演化中产生的三个重要版本做一个对比总结：

　　表 1. SCA三个版本的主要区别对照