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专家体会的深，欢迎批评指正。

有任何技术问题，可以加入iOpenWorks插件仓库平台QQ交流群： 121369588。

本文基于Creative Commons Attribution 2.5 China Mainland License发布，欢迎转载，演绎或用于商业目的，但是必须保留本文的署名道法自然（包含链接）。如您有任何疑问或者授权方面的协商，请给我留言。