OSGi Extender Model启示录

Peter在2月23的时候在OSGi的官方网站上贴了这么一篇blog，挺经典，至少让我学到了一些东西，建议关注OSGi或者关心系统设计中资源管理的人都看看，在这篇blog中我简单的将peter写的blog的意思大概写一下，也不全部翻译了，另外说一下自己的看法。
引起Peter写这篇blog的主要原因是对于使用程序的资源文件的例子的介绍，例如在windows中，当我们安装了editplus后，假设我们把txt的打开方式已经设置为了editplus，但此时我们不能随意的将editplus目录随意的转移，当转移后就会出现txt无法再用editplus打开了，而在mac中，程序的文件目录是可以随意转移的，转移并不会影响到使用它的文件，显然后者强于前者，其实也就类似于现在倡导的绿色软件的概念，Peter也提及了为什么在mac中实现了这个，而在windows中没实现，mac使用了小型数据库来记录程序所在的路径等等信息，windows通常使用注册表来记录，这里并没有什么很大的差别，差别在于在mac中当移动目录或删除目录时会发送消息给小型数据库，使得其做出相应的同步动作，而windows则不会，这也就决定了在mac中可以随意的去移动或删除程序，而在windows中则不能。
从这样的一个问题中，peter想到了基于OSGi也实现一个这样的智能的资源管理的东西，他把它称为Extender Model，其实我觉得有点象扩展点，不过不同的地方就在于它增加了一个资源管理的概念，资源管理最重要的其实就是关注资源的改变(安装、删除、移动等)，peter以servlet这个为例，来说明了OSGi Extender Model的实现方法以及意义，基于OSGi Extender Model的话，就可以使得servlet本身不用再去主动调用HttpService.registerServlet来注册，而是由一个Servlet Extender Model实现的Bundle Listener来根据Bundle的安装、卸载、更新等状态来主动的加载、卸载、更新servlet，可以看到，在这样的情况下的好处就是Servlet Bundle本身不用再去关注Http Service的状态，同时也不用去调用HttpService的东西，这呢，从另外一个角度去看，大家就会发现，这也是一种非常符合DI思想的设计，采用Extender Model这种设计方法就可以做到资源不用主动的去调用容器来实现对于其自身生命周期的管理，这样就使得整个系统处于更加灵活的体系中了，非常的爽。
其实实现OSGi Extender Model非常的简单，编写一个Bundle Listener，监听Bundle的安装、卸载、更新动作，同时根据Bundle的元信息中的描述做出相应的反应(如Servlet Bundle Listener就是当监听到有Bundle安装时，即解析Bundle的元信息，如其中含有ServletMap这样的信息，则获取其具体信息，并注册其中的Servlet)。
如果感兴趣的话，请同学们去查看Peter的这两个帖子：
http://www.osgi.org/blog/2007/02/osgi-extender-model.html
http://www.aqute.biz/Snippets/Extender

这个OSGi Extender Model给了我们什么启示呢：
1、Declarative方式的使用
      Declarative无非是现在一种非常非常流行的软件设计理念，在这样的理念中，可以尽量的保证当前组件的简单，而通过Declarative的方式去增强的描述该组件，其实在spring中最重要的也是这个思想，而在OSGi的DS中也是这么一个思想，声明式的编程自然让整个系统的体系变得非常的简单和灵活，并且大大提升系统组件的可重用性，特别是对于编译型的语言而言，在OSGi Extender Model中通过Declarative的方式说明了定义Bundle中的资源，容器则自动的对其生命周期进行管理，这充分的发挥了Declarative的优势(声明式的增强功能)以及DI思想(运行于容器中的东西不需要主动调用容器来实现注入、生命周期管理这些功能等)的特点。
2、跨Bundle的资源管理方式
      跨Bundle的资源管理其实是之前基于OSGi搭建Webwork+Spring+Hibernate这样结构的难处，总是没想到很好的方法去管理Hibernate的PO文件，采用OSGi Extender这种思想的话这个就很容易实现了，不过Hibernate还存在的一个问题就是SessionFactory的重建，这个对于动态化来讲是有一定的影响的，因为sessionfactory的重建消耗的时间太长了点，同样的道理，对于Webwork Action的管理也是如此。

评论

2 楼 BlueDavy 2007-03-21  

准确的说应该是置于某种容器中的跨Bundle的容器资源的管理，如Webwork的Action就属于放入webwork容器(虽然不准确，但可以这么看)的资源，在这样的情况下OSGi Extender Model还是非常的有意义的。

1 楼 shaucle 2007-03-21  

好文
那几个swf很不错！

Declarative增强使得设计起来更简单和优美，而且更强大．

资源能不跨Bundle当然是最好的，跨Bundle的话配制管理会很烦