SCA同OSGI的比较

　　首先，两个规范制定的出发点和初衷是不一样的。SCA规范是为了企业应用集成而制定，OSGI规范的初衷则是为移动设备计算而制定的。由于二者的出发点不一样，导致了两个规范的侧重点不一样。SCA规范现在的版本是0.95，相对OSGI规范的4.0版本还显得多少有些稚嫩。

　　SCA规范中着重解决了现有企业应用之间的相互调用和企业应用如何以面向服务的思想来建立和部署。但是对于构件容器的实现方面的规定则有些不足，仅仅是站在使用者的角度描述了客户端API的规格。

　　而OSGI规范因为最初的出发点是为了移动设备的计算环境，因此更多的考虑了运行时框架和服务在运行时刻的动态匹配等问题。此外，提供了运行时刻应用程序的热部署、解析、运行、卸载等能力。应该说，OSGI规范发展到4.0已经是一个比较完善的规范了。

　　SCA规范中目前对SCA容器的实现尚没有一个指导性的意见，但是OSGI规范在这方面已经做的很完善了。OSGI规范中定义了Framework、Start Level、Package Admin、Security，详细描述了不同组件之间的依赖规则(静态依赖，动态导入)，不同组件之间使用独立的类名称空间。

　　由于SCA规范面向企业应用集成，因此SCA构件的实现可以是Java，BPEL，EJB，WebService。而OSGI的实现只面向Java语言。这也是由于二者的出发点不同导致的。

　　对于SCA和OSGI的装配模型，二者是大同小异。二者都可以对外提供服务(Service)，但SCA更偏重设计时刻的构件组装，而且定义了灵活的构件装配模型，可以由最小的原子构件组装成一个大系统。

　　从现有的已经实现的产品来看，OSGI更多的被用来作为单一产品的整体架构，SCA规范更多的是被用在面向业务的构件的组装规范，至于SCA产品的架构如何则不是SCA规范所关心的。

　　从上边的比较可以显而易见的看出二者分别的缺点，SCA规范过于强调集成，但是对SCA构件的运行时刻行为描述太弱，所有的构件实现都是在设计时刻绑定的。也许在SCA产品中可以实现运行时刻的动态绑定，但是作为一个规范，这是它所欠缺的。OSGI规范对组件的运行时刻描述很完备，但是所有的组件必须运行在同一个虚拟机中，不同虚拟机中的组件服务互操作则稍显不足。

查看本文来源