首页 > 代码库 > OSGi——面向服务架构规范简述

OSGi——面向服务架构规范简述

OSGi——面向服务架构规范简述

去年我们组要开发一个新的产品,在讨论产品架构路线的时候,美国的架构师向大家征集了架构设计思想(我推荐了SCSF),有一位工程师向他推荐了OSGi。以前我还没有听过OSGi这玩意,虽然我参加工作后,现学了Java和Flex,但非常菜。在工作之前我用了4年的.NET。接触了OSGi后,发现它是一个面向Java的服务规范,还没有一个像样的面向.NET的框架(有个EgeyeAddIn,据说兼容OSGi,我看了源代码了,觉得它离OSGi较远http://www.codeplex.com/EgeyeAddIn)。随着对其概念的模糊了解,我觉得这玩意不错,于是我准备自己做个基于.NET的OSGi框架(因为我在业余的时候在设计一个UI框架,原先准备采用SCSF,接触了OSGi后,我决定将二者合并,重新设计OSGi+CAB的框架)。于是,我在互联网找了很多次关于OSGi的资料,但很失望,没有得到多少需要的东西。因此,我只好自己翻译了OSGi规范前6章,边翻译,边理解(当我翻译完第6章的时候,发现网上已经有OSGi规范中文版了,给自己省了点事),期间我翻译了SCSF英文指南,看了EgeyeAddIn、SharpDeveloper Core和Eclipse OSGi的源代码,最终设计了基于.NET的OSGi规范和OSGi.NET概要图,目前OSGi.NET测试版已经完成,预计年底可以发布。因此,对OSGi和SOA有了更深一步的了解。

在我理解中(对于SOA,我不专业,如果有误,大家批评),目前大部分应用的SOA中的S,已经不是传统意义的Web Service或者远程Service类似的Heavy Service,而更偏向于暴露出一个接口,向其它模块提供通用功能的服务(或类)。在分层应用,上层类将调用下层的类,这种依赖是层与层之间的依赖,相比没有分层的混沌状态的类间依赖要好很多;在SOA应用,模块间通过服务依赖,这种依赖是可以管理的,非常清晰,每一个模块也很容易被重用。下图是我理解的分层和SOA的比较。

OSGi规范是一个服务框架的规范,在OSGi中,(1)每一个模块叫Bundle,即服务包,每个服务包向其它服务包暴露其服务,服务包间服务的引用是可以管理的;(2)每一个服务包类似一个模块,其实更是一个插件,可以被动态的加载到OSGi框架,动态注册、引用、回收和卸载服务,也可以被动态的卸载;(3)服务包在运行时的依赖是通过可管理的服务来体现,在设计时,从功能复用的角度,即一个服务包会使用另一个服务包的类,服务包之间在设计时有一种依赖,这种依赖在服务包清单配置文件中定义,由Export、Import、Require、DynamicImport配置节组成。Export即这个服务包暴露出的可被别的包使用的类型集合定义,Import是服务包引用其他服务包Export的定义,Require则是引用了另一个服务包的所有Export定义。因此,OSGi还定义了类型加载模型,用于实现一个服务包从OSGi系统加载其依赖的类型。

OSGi内核在实现上,有点复杂,在此不过说,估计关心的人会少一点,能把OSGi的SOA思想和应用用好就Very Good了。OSGi.NET是我们团队利用业余时间开发的,从2008年10月份开始,借鉴了SharpDevelop、EgeyeAddin和Eclipse OSGi设计,用分层方式,划分成配置成、解析元数据层、解析层、运行时加载层、Bundle层、Core层和Adapter层,当然最重要的是面向最终用户的公共接口层了,第一个版本的设计是大部分兼容OSGi规范,把认为复杂的需求给去掉了,也简化了Service的设计。由于接触SOA时间比较晚,对SOA的理解没有SOA专家体会的深,欢迎批评指正。

OSGi——面向服务架构规范简述