基于OSGi实现服务框架的分析

根据上一篇服务框架的要素的blog,来分析下基于OSGi实现一个这样的服务框架时需要对目前的OSGi框架做出哪些方面的修改,以及预估一下实现的难度。
1、如何注册服务
      OSGi服务采用的是xml+pojo的方式,应该说还是符合要求的,但如果要把这个服务注册到一个服务中心的话,目前是不支持的,但这个对于分布式部署服务的需求而言,是必须实现的了。 
      要实现注册服务至远程的服务中心,这个可以通过编写一个监听服务生命周期变化的对象来实现,当监听到服务的生命周期发生变化时,发送消息至远端的服务中心,这里也就需要做出一个服务中心和各OSGi应用与服务中心远程通讯的机制(消息机制、RPC机制、Webservice机制等等)。
2、如何调用服务
      调用服务涉及的点比较的多,来看看基于OSGi如何来实现所有的需求:
      injection方式和显示调用方式
      OSGi支持injection方式的调用服务,在显示调用方式方面,OSGi不支持在OSGi框架范围外的显示调用,这个是有一定的不足的,因为这样会导致和第三方框架集成的复杂,不过由于目前有了Spring-OSGi,所以呢,可以选用Spring-OSGi,这样就两种方式都支持了,如果不想使用Spring-OSGi的话,那么可以选择查看OSGi框架的代码,找出显示调用的实现方法。
      另外一个就是可以通过服务中心来实现显示的服务调用和injection方式。
      本地调用和远程调用的区别
      OSGi并不支持远程服务的调用,在《OSGi进阶》Opendoc中我曾经写过基于webservice调用的方式,但这个对于高性能的分布式调用时其实是不可用的,要屏蔽本地调用和远程调用的区别,就得在现有的DS模型的基础上做改进了,需要支持引用服务时从当前的OSGi环境中或从服务中心中注册了,这个需要对现有的OSGi框架的DS实现做出改进,才能做到屏蔽本地调用和远程调用的区别,就可以仅仅通过在xml中做动作就可以了。
       同步调用和异步调用
       这个不用说,目前OSGi自然也是不支持的,只能是对DS的实现进行改进了,增加服务的同步调用和异步调用的支持,同步调用的话就没什么改动的了,异步调用的话就得对ds做比较大的改动了,注入引用的服务时注入的不能像目前的ds实现一样直接注入服务实例对象了,而是只能注册一个proxy对象了。
       lazy式的调用和固定的引用调用
       lazy式的调用目前OSGi并不支持,只能是自己对DS进行改动了,在引用远程服务和异步调用时,lazy调用是非常重要的。
      至于查找服务方面,这个OSGi目前的模型就可以了,只是要增加查找服务中心服务的功能,这个在修改DS实现调用远程OSGi服务时会去实现。   
      在服务的安全性等方面这个也只能基于DS扩展实现了。
3、如何测试服务
      由于OSGi的服务是POJO的方式,在服务的测试方面是完全不会有问题的。
4、服务的生命周期
      在服务的生命周期方面,我想OSGi服务目前的机制就是不错的,即如果当前这个服务组件是对外暴露服务的,那么只有当其被引用且其本身所引用的服务可用时才被激活,如组件没有对外暴露服务,那么只需其引用的服务可用就可激活了,至于服务的卸载就是在上面条件不符合的情况下就应该卸载了。
      如果有必要的话,可以把服务的状态区分出installed、active、deactive。
      另外一个值得注意的问题就是,OSGi的DS是当服务的生命周期发生变化时,会通过bind-method和unbind-method去通知引用服务的组件的,这个特性我想即使是对于lazy式的调用也应该保持,这里也就需要DS关于服务通知的部分实现的代码了。
      来看看在这种服务框架的需求下的服务的生命周期的处理情况:
      安装服务:
      
      服务被激活:
      
      服务被钝化:
      
      服务被卸载:      
     
5、服务的管理和维护
      在服务的管理和维护上,应该说目前OSGi的DS模型提供的已经是很完整了,不过在服务中心点的服务的管理上则需自己实现了,基本可以参照OSGi的实现,需要考虑和增加的仍然是服务中心和各远程的OSGi应用的通讯。
6、服务的组装
      服务的组装方面,这个OSGi也是完全没有支持的,这个可以考虑基于服务中心去实现,抑或完全可以单独实现,只需可组装远程的服务中心中的服务即可了。
7、服务的出错处理
      服务的出错处理,这个对于OSGi来说还是有点的麻烦的,就像erlang强调的一点一样,不是进程隔离方式,自然很难保证当在同一VM中的一个OSGi服务出错时不影响到整个VM。
      只能尽量的去考虑另外一种方式了,当服务处理出错时的广播了,这样可以做到fail-fast。
8、服务事件的广播和订阅
      服务事件的广播和订阅,这方面OSGi目前支持的还是挺好的,不过在增加服务中心后,就需要增加事件广播至多个服务中心了。
 
在增加考量的两个因素方面,OSGi的DS是不支持aop方式的,不过要搭建一个服务库不是一件什么难事,其实服务中心本身就已经是服务库了。
上面的实现分析还是有点的虎头蛇尾吧,最后就按照上面的分析总结成一张图吧,来管窥下基于OSGi实现的分布式服务框架会是个什么样的结构:

从上图并结合服务的生命周期管理的部分可以看出要基于OSGi实现一个这种适合分布式场景的服务框架还是比较麻烦的,需要重写的部分是非常的多,以此来看的话,目前OSGi最适合的场景应该还是如下几种:
1、不需要分布式部署的应用场景;
2、需要分布式部署,但仅仅是分层的分布式部署,例如业务层在一台机器上,数据层在另外的机器上。
不过基于OSGi实现一个这样的服务框架也是一件很不错的事,估计这也是EEG目前正在做的事,希望以后能在自己有空的时候动手做做这个基于OSGi的服务框架。

posted on 2008-01-09 23:23 BlueDavy 阅读(4066) 评论(3)  编辑  收藏 所属分类: OSGi、SOA、SCA

评论

# re: 基于OSGi实现服务框架的分析[未登录] 2008-01-13 18:20 guitarpoet

新的SCA(目前已经是OASIS的规范了)标准的实现应该就是基于OSGi的吧?

好久没有看这个方面,都有点儿生疏了。呵呵。  回复  更多评论   

# re: 基于OSGi实现服务框架的分析 2008-01-13 23:24 BlueDavy

@guitarpoet
还没有明确的把OSGi列入实现的规范,因为目前SCA规范基本还就是一个介绍如何用的规范,至于怎么实现没有规范,所以...,不过OSGi应该会列为RI级别的东西。  回复  更多评论   

# re: 基于OSGi实现服务框架的分析 2015-06-08 20:08 xMan

http://osgi.jxtech.net 是一个基于OSGi的企业级快速开发平台,对于信息管理系统来说,开发相当容易、快速,还能自适应移动端呢。  回复  更多评论   


只有注册用户登录后才能发表评论。


网站导航:
 

公告

 









feedsky
抓虾
google reader
鲜果

导航

<2008年1月>
303112345
6789101112
13141516171819
20212223242526
272829303112
3456789

统计

随笔分类

随笔档案

文章档案

Blogger's

搜索

最新评论

阅读排行榜

评论排行榜