(转自：IBM http://www.ibm.com/developerworks/cn/webservices/0912_zhonggq_scaosgi/）

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：

1. 核心规范

   SCA Assembly Model

   SCA Policy Framework

   SCA Transaction Policy

   SCA Assembly Extensions for Event Processing

2. 组件实现技术规范

   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

3. 绑定技术规范

   SCA Web Services Binding

   SCA JMS Binding

   SCA EJB Session Bean Binding

   SCA JCA Binding

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

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）等概念。

1. 概念名称的修改

   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. 从本质上看，模块层次上的导出和导入相比组件层次上的服务和引用，实际上是同一个东西，只不过可见性不同。

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 的装配模型示意图。

同 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 组件装配模型示意图。下面将分别介绍这三点。

概念整理

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

嵌套组件装配模型的提出

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

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

				 
 <compositexmlns="http://www.osoa.org/xmlns/sca/1.0"
                xmlns:bb="http://bigbank.com"
                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 在三个阶段中的演化和区别，下面通过表格的形式，对演化中产生的三个重要版本做一个对比总结：

本节将 SCA 的演化分为三个阶段，并分别介绍了这三个阶段中 SCA 的发展和区别，下面几个小节，我们将 SCA 与另一个当前的热点技术 OSGi 作相关比较。

OSGi

什么是 OSGi

OSGi 联盟成立于 1999 年 3 月，致力于制定管理本地网络设备服务的规范。OSGi 联盟是为家用设备、汽车、手机、桌面、小型办公环境以及其他环境制定下一代网络服务标准的领导者。OSGi 全名原为 Open Services Gateway initiative，但现在这个全名已经废弃。

OSGi 联盟基于它成立之初的使命，推出了 OSGi 服务平台规范，用于提供开放和通用的架构，使得服务提供商、开发人员、软件提供商、网关操作者和设备提供商以统一的方式开发、部署和管理服务。

目前最广为认可和应用的是 OSGi 规范 4（R4，Release 4），其最新版本是 4.2，共由核心规范、标准服务（Standard Services）、框架服务（Framework Services）、系统服务（System Services）、协议服务（Protocol Services）、混合服务（Miscellaneous Services）等几部分共同组成。核心规范是 OSGi 规范中的核心部分，它通过一个分层的框架，实现了 OSGi 最为成功的动态插件机制，它主要提供了：1. OSGi Bundle 的运行环境；2. OSGi Bundle 间的依赖管理；3. OSGi Bundle 的生命周期管理；4. OSGi 服务的动态交互模型。

虽然 OSGi 在嵌入式应用方面有成功的案例，比如宝马汽车的嵌入式应用，但真正让 OSGi 得到认可和关注的则是 Eclipse 项目。Eclipse 是目前著名的一个 IDE，其最大的两个特点是插件和扩展，而其实插件机制正是通过实现 OSGi 规范实现的。下面我们了解下 Eclipse 的核心 Equinox 项目。

Equinox – OSGi R4 的实现

Equinox 作为 Eclipse 项目中的一个子项目，是 Eclipse 的运行核心（runtime），它是 OSGi R4 核心规范的参考实现。Eclipse 构建在 Equinox 项目之上，提供了 OSGi 所定义的对 Bundle 动态插拔的功能。

Equinox 项目的目的是成为一个一流的 OSGi 社区项目，并作为 Eclipse 项目的试验田，来开发和发布 Eclipse 项目中所需要用到的 OSGi 框架实现，具体的讲，Equinox 项目有以下几方面的职责：

• 实现 OSGi 规范中所定义的所有内容
• 调查和预研 OSGi 规范的未来版本
• 开发非标准的但是必要的基础设施（Infrastructure），用于运行和维护基于 OSGi 的系统
• 实现 Eclipse 中所需要的框架服务和扩展，比如 Eclipse Adaptor 和 Extension registry（OSGi 规范中没有定义扩展机制）

Equinox 目前是随着 Eclipse 版本而发布的，同时，它也提供独立的下载，在独立的下载页面中可以下载到 Equinox 对于 OSGi R4 的所有实现以及 Equinox 扩展 OSGi R4 而提供的 Bundle。

了解了 OSGi 以及 SCA，我们便可以将 SCA 与 OSGi 做相关分析比较。

SCA 与 OSGi 的分析比较

SCA 和 OSGi 有着不同的提出背景和出发点，SCA 规范是为了企业应用集成而制定，OSGi 规范的初衷则是为移动设备计算而制定的。由于二者的出发点不一样，导致了两个规范的侧重点不一样。但是随着 OSGi 的成熟，OSGi 联盟于最近成立了企业专家组（EEG，Enterprise Expert Group），开始带领 OSGi 进军企业应用领域，这将使得 OSGi 与 SCA 有了越来越多的交叉。因此，分析这两种技术，将有助于对这两种技术的理解，并可以通过集成或借鉴对方来促进这两种技术的发展。下面我们将首先介绍这两种技术的关注点，然后对这两种技术做分析比较。

SCA 和 OSGi 各自的关注点分析

只有了解了 SCA 和 OSGi 的关注点，我们才能更好的了解这两种技术的应用场景，也才能更为客观的将这两种技术做比较，下面讨论下这两种技术的各自关注点。

SCA的关注点

SCA 的目的是成为构建 SOA 应用的编程模型，它的应用领域是企业应用集成领域。SOA 虽然提了很多年，但到目前，在概念方面，各大厂商关于 SOA 也都有着不同的理解；在实现技术方面，也大都是在使用具体的 Web Service，但 Web Service 是一种运程调用技术，对于如何开发本地 SOA 应用中的服务，目前也无统一认知；在组件模型方面，目前也没有统一的组件模型来装配和管理服务。所以，当前的 SOA 应用开发缺乏服务组件模型支持，缺乏从组件层次上来进行服务声明、发布、组装以及定义互操作性。另外，基于企业应用的特点，不同的应用系统可能有不同的实现技术，如何能将这些采用不同的技术实现的功能发布为 SOA 中的服务，并能够更多的关注服务的声明，而屏蔽底层的实现，也是 SOA 应用开发中需要关注的一个问题。

而 SCA 通过一系列规范的定义，解决了上述问题：组件装配模型提供了对服务声明、发布、组装，并通过绑定功能，来屏蔽不同服务间的通信细节；支持不同的编程技术作为服务组件的实现，从而可以更好的将遗留系统封装为系统中的服务；策略框架同时提供了对应用系统中 QoS 的支持，以保证企业应用中的质量需求。

OSGi的关注点

OSGi 规范因为最初的出发点是为移动设备创建计算环境，因此更多的考虑了框架和服务在运行时刻的动态匹配等问题。移动设备通常都是在同一个嵌入式环境中工作，所 OSGi 不需要关心 QoS，不需要支持多种不同的实现技术，也不需要支持分布式调用。

详细比较列表和介绍

在了解了 SCA 和 OSGi 的关注点之后，我们就可以对 SCA 和 OSGi 做一个详细比较，下面先给出 SCA 和 OSGi 的异同点对比表，然后再针对各个比较项，作相关分析。

容器实现

SCA 规范的最初目的是成为 SOA 的编程模型，着重解决的是如何创建、组装、部署和使用服务，它是面向应用开发人员的，所以它并不关心如何去开发支持 SCA 应用运行的容器。

而 OSGi 规范因为最初的出发点是为移动设备创建计算环境，因此更多的考虑了框架和服务在运行时刻的动态匹配等问题。所以，它首先关心的就是如何构建一个运行环境，以便能够运行 OSGi 应用。

目前来看，SCA 规范中对 SCA 容器的实现尚没有一个指导性的意见，但业界有着基于 OSGi 构建 SCA 容器的讨论，这也是一种将 OSGi 集成到 SCA 中的一个比较好的方式。

模块定义

在模块的定义方面，SCA 规范只是定义了 SCA 复合组件作为最小可部署单元，但并没有定义个明确的打包格式要求，也没有定义模块的动态更新和绑定以及模块间的包依赖，更没有定义模块中的包的可见性。其实也可以说，SCA 规范在模块的定义方面几乎没有做工作，SCA 规范着重定义了设计期的服务声明和绑定。相比 SCA 规范，OSGi 规范则定义了明确的模块层，并在模块层中定义了类加载机制、包的可见性、包依赖以及模块的打包和描述文件格式。模块化的定义目前引起了越来越多的重视，JCP 正在制定 Java 的模块化规范 JSR277。

组件实现语言/ 技术

SCA 组件的实现可以是 Java、C++、BPEL、Spring、EJB、WebService 等，而 OSGi 只支持 Java 语言实现，这也是由于二者的出发点不同导致。OSGi 应用都是运行在同一个 JVM 中，所以并不需要考虑多种实现技术，而企业应用中，则会有多种实现技术，这就需要 SCA 能够支持多种实现技术

装配模型和服务绑定

SCA 服务装配模型是整个 SCA 规范中的核心，而 OSGi 在早期版本中并没有服务装配模型，在 OSGi DS（Declarative Service）规范出来之后，OSGi 才有了明确的组件装配模型。

SCA 和 OSGi 的装配模型都可以声明和发布服务，但 SCA 更偏重设计期的组件组装，而且定义了灵活的组件装配模型，特别是提供了可嵌套的组件装配模型，可以由最小的原子组件组装成一个大系统，而 OSGi 则缺乏组件组装模型。

在服务绑定方面，SCA 的服务绑定需要从两个层次上看，在同一个复合组件内部中的引用，如果没有设定自动连线，那它实际上采用的设计期绑定，因为在设计期就需要指定所需要引用的组件及其服务，这是因为 SCA 不支持组件和服务的版本管理，所以在运行期永远只有一个同名组件存在，所以也就没必要支持运行期绑定；在跨复合组件和跨域间的引用，SCA 采用的是运行期绑定，因为复合组件是 SCA 的最小可部署单元，开发人员可能会在运行期重新部署同名的复合组件。这两者的差异，相信也是由于目标不同导致，OSGi 容器作为一个嵌入式运行环境，必然需要考虑到各种 OSGi 应用的热插拔和服务的动态绑定，从而更重视运行期的服务装配，而 SCA 作为企业应用，既需要考虑支持设计期服务绑定（其实就是目前广泛应用的利用构造方法和 set 方法进行依赖注入），也需要考虑跨复合组件和域间的动态引用。

OSGi 核心规范中并没有定义装配模型， OSGi DS 规范作为补足性规范提出了面向服务的装配模型。OSGi DS 中的装配模型并不支持在设计期绑定服务，而是在运行期通过服务描述来查找并绑定服务，基于这种绑定策略，会有一定的效率问题，但是将极大的提高系统的灵活性和可扩展性。

生命周期管理

SCA 规范由于忽视运行期 SCA 系统的变化需求，从而没有定义组件的生命周期，但不同的组件实现技术可能会有其自己的生命期周期定义，比如在 SCA Java 版的客户和实现模型规范中，它定义了两个用于组件初始化和销毁时需要调用的方法，供 SCA 组件在初始化和销毁时作一些预处理。相比 SCA，OSGi 则提供了完善的生命周期管理。

QoS

由于 OSGi 规范是面向在同一个 JVM 中运行的网络设备以及像 Eclipse 这样的插件系统，所以在 OSGi 中的服务不需要 QoS 问题，也不需要支持远程服务、回调服务和会话服务。SCA 规范则是面向企业集成领域，所以 SCA 规范需要考虑 QoS、分布式访问、服务的回调和会话等问题。

依赖管理及其它

OSGi 规范支持运行期的服务和包依赖，而 SCA 规范只支持设计期的服务依赖，这使得 SCA 系统与 OSGi 系统相比，欠缺灵活性和可扩展性。

从现有的应用来看，OSGi 更多的是用来作为一个技术框架来开发一个产品，如开发 SCA 容器等，而 SCA 规范更多的是被用在面向企业应用的组件的组装规范。

由于 SCA 不强调在运行期的服务管理，服务管理应该会利用其它软件来实现，所以它也没有提供版本管理机制，而 OSGi 则提供了版本管理机制，拿 Eclipse 而言，我们可以装多个不同版本的同一个插件，而不会影响系统的使用。

限于 OSGi 最初是为了为移动设备而准备，所以 OSGi 服务只能在同一个 JVM 中调用，且不能支持远程调用，这是其企业应用领域的一大缺点，但目前，已经有很多关于分布式 OSGi 这方面的讨论。

通过以上分析，可看出 SCA 和 OSGi 有着很多明显的区别，而这些不同其实也造就了他们之间有着很强的互补性。下面将简单介绍下，如何将 OSGi 集成到 SCA 中来，以便利用 OSGi 的特性来增强 SCA 应用。

SCA 与 OSGi 的集成探讨

正如上文介绍，SCA 和 OSGi 由于最初定位的不同，造成了两者之间有诸多不同之处，但两者实际上更多的是一种互补，而不是竞争。基于当前已有的规范和实现，SCA 和 OSGi 的集成工作可以在下面三个方面展开：1. 可以充分利用已有的 OSGi 应用，并能够将 OSGi 应用中的服务发布成为 SCA 的服务；2. 能够让 SCA 通过引用来调用外部 OSGi 服务，这也是另外一种可以让 OSGi 服务变为 SCA 服务的途径；3. 基于 OSGi 构建 SCA 容器。下面简单介绍下，如何在这三个方面来集成 SCA 和 OSGi。

将 OSGi 集成到 SCA 中

使用OSGi 作为 SCA 的组件实现

一种能够充分利用 OSGi 特性的方法，是将 OSGi 作为 SCA 服务组件的实现，而 SCA 的可扩展模型也支持 OSGi 作为 SCA 服务组件实现，这样就可以将 OSGi 服务作为 SCA 服务发布，通过这种途径，可以将 OSGi 服务变成可支持远程访问的 SCA 服务，从某种程度上克服 OSGi 服务不支持跨 OSGi 容器访问这种缺陷。虽然目前 OSOA 组织并没有发布将 OSGi 作为组件的实现的规范，但目前 Apache Tuscany 项目已经尝试将 OSGi 作为 SCA 的服务组件实现。

使用SCA OSGi 绑定

SCA 和 OSGi 集成的第二个方面是 SCA 应用能够通过引用来访问 OSGi 服务，SCA 应用可以通过绑定来声明所需要访问服务的协议，目前 OSOA 组织已经发布了 JMS、JCA、Web Service、EJB 这几种绑定协议，同将 OSGi 作为 SCA 的组件实现一样，虽然 OSOA 目前没有发布 OSGi 绑定规范，但 Apache Tuscany 项目目前已经尝试支持 OSGi 绑定。

使用OSGi 构建 SCA 容器

另一种可以将 OSGi 和 SCA 进行集成的方式，就是基于 OSGi 规范来开发 SCA 容器。这种方式可以最大化的将 OSGi 集成到 SCA 中来。首先，由于利用 OSGi 来构建 SCA 容器，这就可以较简单的做到前两个方面的集成；其次，可以将 OSGi 服务注册中心以及 SCA 服务注册中心合并为一个，甚至可以做到在同一个 SCA 域中，支持 SCA 应用通过 SCA 绑定的方式来访问 OSGi 服务。

集成 OSGi 后的 SCA 将有更多的优点，下面作一个简单讨论。

集成 OSGi 后的 SCA 的优点

SCA 和 OSGi 是互补的，通过以上这三种方式来将 OSGi 集成到 SCA 中，可以使 SCA 具有以下几个方面的特点：1. 支持 OSGi 这种主流技术作为服务组件的实现，给开发人员提供了更多的技术选择；2. 可以更容易的通过 SCA 的装配模型，将已有的 OSGi 服务发布为 SCA 服务，从而实现 OSGi 服务的远程调用支持；3. 可以利用 OSGi 在模块化、动态性方面的优势来弥补 SCA 在这两方面的不足。

目前业界关于 SCA 和 OSGi 集成的讨论也越来越多，可以预见，这两种技术可以通过互补的方式，来促进这两种技术的发展。

总结

本文介绍了 SCA 在各个演化阶段中的发展和变化，并将 SCA 与 OSGi 技术进行了对比分析，最后还探讨了如何将 OSGi 集成到 SCA 中。通过以上介绍，可以发现，SCA 经过短短几年的发展，已经有了长足的进步，再加上诸多主流厂商的支持，使得其极有可能成为下一代 SOA 编程模型。