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集成的讨论也越来越多，可以预见，这两种技术可以通过互补的方式，来促进这两种技术的发展。