与OSGi的相关的问题

SCA（Service Component Architecture）即服务组件架构

sca 把方法作为对象使用

OSGi是面向单个jvm的，SOA是分布式的

SCA的Component和OSGI的Bundle一样其实是对Java封装的一种贯彻，它有需要Import的服务引用，需要Export的服务

SCA支持远程调用其他组件的服务，而这点正是OSGi的一个巨大的缺点，也是EEG现在正在努力做的;SCA对于远程调用其他组件的服务支持象Webservice、JMS、JCA、RMI、CORBA等等方式的调用。 

SCA和OSGI之间的优缺点是可以互相弥补的。SCA和OSGI的优劣，但其实作为这两个规范面向的解决问题都是不同的， SCA是SOA的一个实现， SOA是解决分布式服务的互通问题，  而OSGI是针对单机服务的动态绑定义及组装，因此两者不存在着可比性，但是在我看来，两者却有着很好的互补性，在平台的现有情况下，用SCA来实现服务框架，同时通过OSGI来实现组件装配

SCA 与 OSGi 的分析比较

SCA 和 OSGi 有着不同的提出背景和出发点，SCA 规范是为了企业应用集成而制定，OSGi 规范的初衷则是为移动设备计算而制定的。由于二者的出发点不一样，导致了两个规范的侧重点不一样。

SCA的关注点   SCA 的目的是成为构建 SOA 应用的编程模型，它的应用领域是企业应用集成领域。

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

OSGI 的简单思想:

1.      为Java而来的模块化系统, 做了两件事情

a)        定义了一种创建真正的模块的方式。为什么叫真正的模块, 实际上Jar并非是一个真正的模块, 因为它没有满足上面提到的模块应具备的三大定义(自治, 高内聚,低耦合)。显然jar的public方法太多, 造成模块对外的复杂性很高。这点很蛋疼。

b)        定义了软件系统运行时模块之间交互的方法。

2.      OSGI处理方式的思路(传统Jar带来的问题主要是Java扁平化，全局的Classpath造成, 因此围绕这个问题解决也在此)

a)        每个Bundle/模块都有自己的classpath, 各个模块的classpath独立于其它模块。这样便消除了Jar包的一切问题。当然这个并没有解决Class之间共享的问题。

b)        通过显示的Import和export机制, 实现类的共享。指明模块之间的共享/依赖关系

模块的实现和传统的编程方法确实有一些差别，主要体现在模块之间类访问的隔离、版本选择这两个方面。

使用OSGi的问题是：

1. 对没有接触过OSGi的Java开发而言开发习惯绝对是巨大的挑战

通常都会使用Maven来管理Java工程，肯定很希望mvn eclipse:clean eclipse:eclipse就可以生成导进eclipse里没问题的project吧，但对于OSGi而言，如果是依赖外部的非OSGi Bundle的jar，那么则需要在META-INF/MANIFEST.MF里写明，也就是不是仅仅修改pom.xml就可以的；另外一点是OSGi对于其他bundle的jar的依赖，不是通过pom.xml去增加依赖，而是直接import package或require-bundle之类的，并且要求这个bundle是已经安装了的（可以想象，如果是业务型的应用，那得装多少bundle…），否则在eclipse之类的ide里再去import什么的时候会找不到，同时为了确保mvn clean package之类的还是能用，因此会被逼在开发的时候要同时维护pom、MANIFEST.MF。

上面的这两个问题要解决好，可以通过开发IDE插件，但这个插件是不太好做的…

而OSGi的classloader机制则会给初入门的带来很多疑惑，会觉得经常碰到各种各样的class找不到等问题。

测试也是个麻烦，因为得把所有的bundle都装进framework，否则单元测试就得全部靠mock了。

另外一点在文件的依赖上就更折腾了，OSGi只能是通过require-bundle来去获取需要依赖的文件，否则是做不了的。

2. 动态化  OSGi确实具备了很强的动态化机制，但这里的要求是必须对OSGi bundle/OSGi Declarative Services的生命周期管理机制非常清楚，否则设计出来的系统其实是完全不可动态化的，具体的细节大家可以看看我之前写的另外一篇文章。 

而仅仅借助OSGi的动态化机制，其实是不足以实现真正的热部署的，这里的一个原因是通常代码里是带状态信息的，或者说一些全局变量信息，而OSGi的替换其实主要是通过创建新对象实例，然后替换引用的方式来实现，这也就意味着对于有状态信息的，得自己处理好状态的保存以及还原，否则是会有问题的，我们当年为了在通信层面做到这点，折腾了一个多月还是没搞定，而且系统变得超级复杂。

另外还有个更麻烦的是， 如果应用是OSGi和非OSGi混用，又要做动态化，那就得 让非OSGi拿到的只是一个OSGi里对象的一个假的引用，以便随时替换，这个改造起来就更麻烦了。

Virgo项目Web服务器是EclipseRT项目的一部分，是一个完全模块化的Java运行时。 Virgo自身就是设计为在标准OSGi框架实现（Equinox）之上的一个OSGi bundle集合。Virgo可以运行企业级Java应用以及基于Spring（Spring - powered）的应用，具有很强的灵活性和可靠性，它提供了一个支持企业级Java应用开发、部署和服务的简单而强大的平台。