上节提到将war包改造成wab,通过pax web extender部署 在OSGI framework上的方式来发布 web应用。表面上,我们似乎只需要作少量的改 动,就能将旧的web应用OSGI化了,但是我们没 得到任何好处,只是为OSGI化而OSGI化了,既 没得到OSGI的模块化、动态化的好处,还得受 OSGI classloader机制的限制。既然如此,我们 何必自讨苦吃地将它改造成wab呢?
我们审视一下war的一般组成:部署描述文档,一 些配置文件,自有的一系列java类,自有的一堆 web静态资源文件和一大堆依赖的第三方jar 包......,可以说war是一个粗粒度的复合体。
假设我们需要部署若干个wab到OSGI framework 上,那么,被依赖的第三方jar包就需要在每个 wab各自的classloader重复加载,如果将这些第 三方jar包改造成bundle,独立加载,并export出 相应的package供所有wab共享使用,那么就不 需重复加载了。但是这样做,第三方jar包改造成 的bundle就和这些wab很紧密地藕合在一起,和 OSGI模块化的本义背道而驰了。
我们用OSGI模块化的其中一个目的就是软件构件 的复用,象war这样粗粒度的构件要复用的可能 性可以说是等于零。所以,要将war这个复合 体"分解"出一批细粒度的构件,才能发挥OSGI的 好处。
充分利用OSGI service是开发OSGI应用的一种好 的实践。如果我们将wab中公用的功能以SOA的 思路分离出来,用OSGI service的形式来实现和 组装成独立的公用服务,供各wab调用,就可以 将wab这个复合体逐步分离出细粒度的模块出 来,并采用OSGI service的方式与wab松散藕 合,就可以达到OSGI模块化的目的了。
但是具体的做法如何?是否有好的模式来实现?
研究一下基于OSGI的web应用(4)
猜你喜欢
转载自killko.iteye.com/blog/1810851
今日推荐
周排行