2006年11月10日

这段时间看了不少的文章都是关于 SCA 与 OSGi 之间比较的。且不论他们之间到底有没有关系，我们来看看他们的定义

SCA

       服务构件架构 (Service Component Architecture) 是一套规范，它描述了采用面向服务的体系结构来搭建应用和系统时的模型。 SCA 扩展并完善了以前实现服务的方法，并且 SCA 构建在开放的标准之上，

例如： Web Service

服务构件架构 SCA （ Service Component Architecture ）为建设基于面向服务的体系结构的应用和系统提供了一种编程模型。这基于一种观点，即业务功能以一系列服务的形式被对外提供出来，然后它们被组合在一起去实现满足特定业务需求的解决方案。这些复合的应用，可以包含专门为此应用程序创建的新服务，也可以包含来自已有的系统和应用程序的业务功能，重复利用就像其中的一部分一样。 SCA 即为组合服务提供了模型，也为服务构件的创建，包括在 SCA 组装中重用已有应用系统的功能提供了模型。

OSGi

       OSGi 是什么， OSGi 是一种服务运行平台。通过实现能够提供服务的符合 OSGi 规范的组件，用户可以将其组件发布到 OSGi 运行平台，供用户和其他组件使用。 OSGi 组件提供的服务具有两个层面的含义：系统层面，即一个组件为其他组件提供服务，这些服务体现为 Java 接口的实现；业务层面，即一个组件为外部系统或用户提供某种业务服务实现。

从概念看我们可以很快发现他们的相同点和不同点。

         他们都是一种组件模型，而且是面向服务的编成模型，都对服务组件模型作了相应的定义。在两种模型中都有“模块”，“组件”，“服务”这 3 种共同的概念。我们分别从这三种感念来看看他们之间的差别

模块：

         可能 OSGi 对于模块的概念定义的更完善一点，支持模块的动态更新和依赖，而 SCA 对于模块的概念中没有涉及动态更新的概念 ( 实际如果把 SCA 中的模块映射到 JEE 中的 EAR 块就可以做到了 ) ，对于模块间依赖关系的定义也没有 OSGi 中 Export/import 定义的完美，对于一个包的引用，要存在 2 个不同的副本，至少 WPS （ IBM 中 SCA 的实现）中是这样。所以说模块的定义 OSGi 要比 SCA 要完善，实际上这样是两种模型出发点是完全不同的， OSGi 设计之初主要是面向网络设备的，最后被 Eclipse 所采用才为大家所知的，而 SCA 从一开始就是面向企业级应用的，所以这方面没有 OSGi 定义的完善。模块的定义 OSGi 是在 MANIFEST.MF 文件中通过元数据定义的，而 SCA 是在 sca.module 文件中定义的 xml 格式。从这点上我们就可以看出来， OSGi 只能是在 java 平台上（他的规范中说明也是只适合 java 平台的，规范的 0layer 定义了它的最小 runtime ），而 SCA 是一种跨平台的规范，它不依赖于平台，你可以是 Java 环境也可以 C++ 环境。

         对于组件的概念，个人感觉 OSGi 是在 DS （ OSGI R4 的 Declarative Services ）出来以后才有了比较定性的定义，而 SCA 从一开始就非常强调组件的定义，对于 SCA 组件可以是一个 webservice ，一个 java 对象，一个有限状态机中的规则对象，也可以是一个 BPEL 流程对象，还可以一个人工干预的工作流对象，更可以是许多组件的组合对象，这一点 OSGi 组件是做不到，也不要想 OSGi 能够做到，因为他们的设计出发点根本是不同的，不要把企业级应用的东西强加到 OSGi 中来，在 OSGi 中的组件可以发布 / 查找服务， SCA 也可以这么做，对于服务的引用， OSGi 只能是在 single JVM 中，不要怪 OSGi 要知道他当初设计的目标就是网络设备，不用考虑企业级应用中的分布式，服务质量什么的。但是组件概念上 SCA 有一点还是弱于 OSGi ， OSGi 对服务的引用可以做到动态更新，一个服务改变了，它可以动态的或者是静态的更新应用它服务的组件对象，这一点在网络设备中是非常重要的，但是在 SCA 这种企业级应用中到底需不许多要我们还需要考虑，毕竟如果我们是面向接口编成，而不用关心细节是什么，你的服务再怎么更新，只要我们的接口不变就不会用什么问题。

         而服务，最大的差别可能就是 OSGi 是在 single JVM 内的所以对于服务的引用永远都是直接的内存引用吧，而 SCA 在服务的引用上附加了 Binding 的概念也就多了一个协议的选择层，很象 jmx 中 distributed layer ， SCA 对于服务的 Export/Import 都需要 Binding 一个具体的实现，你的服务可以通过 WebService 来发布，也可以通过 RMI ， JMS 等等来发布。这一点是 SCA 的设计出发点来决定的（面向企业级的应用开发）。对于服务的调用，不仅仅是必须在环境内的调用，也可以在环境外进行调用，比如你在一个 JSP 页面想要调用 SCAExport 出来的服务，你就可以通过 SCA 提供的 Tools 直接调用， OSGi 是不支持环境外调用的。

         从以上来看 OSGi 和 SCA 除了基于同样的设计方法，其他的不具什么可以比较性，因为他们设计的根本意图上是不同的，一个是用在单一个的 JVM 中的面向网络设备或者像 Eclipse 这种应用，不需要考虑服务质量，服务的可靠性，分布式，等等。而 SCA 从诞生之初就为了解决 SOA 应用中的规范性，而且与他同级别的还有 SDO 来定义服务的数据对象，这一点也是 OSGi 中没有定义的。

         有人会说 OSGi 最近正在定义在企业级应用的规范（ EEG ）， Eclipse 的 RSP 也在做相应的努力。但是如果是在 SCA 之外另开辟出一个新的模型空间，个人觉得不太可能，毕竟 SCA 是 IBM ， BEA ， Oracle ， Sap 这些厂商在认识到许多现有技术的不足之后总结出来的设计模型，是这些厂商经验的积累，就像 OSGi 是 OSGi 组织在网络设备应用中的积累的一样，这两种技术只能出现互补性，再说 SCA 模型的定义充分体现的软件界一贯的规则“重用”，不管是 IBM 的 WPS ，还是 Apache 的 Tuscany 都是以现有平台为出发点设计的，是把 SCA 这种模型与现实技术做一定的映射，例如，如何实现异步调用就可以以借助 JEE 环境中的消息或者 Corba 中消息机制。

         真希望看到 OSGi 的 EEG 组织和 SCA 规范定制组织合作的场景。这样不仅可以让组件服务思想得到升华，还能为企业级开发开辟一个新的天地。

         以上观点纯属个人感触，不代表任何特别的言论，其实最近正打算吧原有的平台迁移到 OSGi 平台上，在研究过程中发现了许多有趣的地方。

         欢迎大家一起讨论 OSGi 和 SCA 技术。