采用OSGi框架开发项目的十个问题

小编辑 发布于 2010/03/21 23:15
阅读 12K+
收藏 12

OSGi是Java领域里无可辩驳的最成熟的模块系统,它与Java几乎是如影相随,最早出现于JSR 8,但是最新规范是JSR 291。 OSGi在JAR的MANIFEST.MF文件中定义了额外的元数据,用来指明每个包所要求的依赖。这就让模块能够(在运行时)检查其依赖是否满足要求, 另外,可以让每个模块有自己的私有 classpath(因为每个模块都有一个ClassLoader)。这可以让dependency hell尽早被发现,但是不能完全避免。

不过,Java社区领袖Adam Bien最近在其博客中认为,从技术角度讲,OSGi的确是实现模块化的可行办法,但OSGi的主要挑战不是技术,而是模块和bundle的管理。他建议在决定采用 OSGi框架开发项目之前,考虑以下问题:

  1. 针对模块(bundle),采取何种版本 控制方案?大、小版本如何定义?
  2. 采用何种软件配置管理策略?允许开放和维 护模块所有版本的分支吗?预计要维护多少个分支?通过SVN吗?
  3. 在生产环境中,同时存在多少不同版本的模 块?
  4. 针对模块和模块组合,如何进行测试?每一 个版本都会显著增加复杂度。
  5. 采用何种发布管理策略?提供客户专属的模 块组合吗?缺陷修补/补丁策略是什么?
  6. 需要在系统运行中替换模块吗?如何处理正 在进行的事务?
  7. 对于Eclipse RCP应用,是否应该开放插件给最终用户?
  8. 采用何种软件分发系统?很多公司已经有了 一套软件分发系统。应用和JVM经常打包到一个二进制文件中整体安装。增量更新几乎是不可能的。
  9. 模块之间如何交互?只通过Java接口 吗?如果是,那么JPA实体的直接关联如何处理?
  10. 是否采用Maven描述模块和 OSGi?Maven模块版本会在OSGi bundle版本中得到体现吗?

 

Adam Bien认为,在深入思考这十个问题之后,OSGi可能就不再是项目的最佳选择。

读者朋友是否同意Adam Bien的观点,针对他的十个问题,有何看法?在实际开发中又是如何解决的?欢迎踊跃发表意见。

加载中
0
撼地神牛
撼地神牛

刚来,回复一个沉了好久的帖子貌似不太地道

不过现在NetBeans RCP的开发,貌似能解决大多数问题

建议楼主过去研究看看哈

0
M
MISO
说的很好,ISGI这个东西目前还是解决不了项目当中很多实际的问题。
0
l
leochang

不知所云,还是大家。我针对这几个问题一一回答:

上面的问题中,模块等同于组件、插件、bundle。

1. 既然决定要采用OSGi体系,bundle版本及依赖的管理,遵循OSGi规范进行。版本分为major, minor, micro bugs fix count, qualifier的方式,其中qualifier时间戳可选。minor版本有义务对一个低版本进行兼容。

2.至于OSGi组件分支管理,这个不属于使用OSGi前要考虑的问题,这是所有软件开发之前都要考虑的问题。版本管理软件就足够了, 和OSGi有什么关系,OSGi中只涉及代码的产物 组件bundle。

3. 在现实的运行环境中,的确存在多个组件bundle版本并存的情况。比如不同组件依赖某个组件的不同版本。比如Spring2.5.6和3.0.3,同时存在于OSGi环境中,其他组件可以根据情况分别依赖。OSGi对这种情况提供了完美的支持。

4. 关于组件测试问题,每个组件只负责自己的对外的接口和服务的正确性。这个比起将所有组件一起测试,单个组件内更容易测试。有点像JUnit的思想,怎么会使得测试复杂?

5. 关于版本修正和补丁的问题,这是所有软件开发都关注的问题,何止OSGi, 何况OSGi也提供了完美的版本兼容和组件bundle补丁的支持,没有用过Bundle Fragment类型的bundle吗?对于bug修正比较大,使得已有部署的项目中bundle兼容不好的问题,只能说明你组件设计时,没有遵循接口隔离稳定的规范,使得修了小bug,现有工程出现了兼容性问题。OSGi默认的版本策略是,第三个bugs版本号之间都应该是互相兼容的。小版本号,默认兼容低一个版本。

6. 替换组件的问题确实存在,比如现有一个上线的JEE OSGi项目,要不停服务器的前提下,更新和修改某些功能,就需要OSGi的动态更新组件的机制了。关于怎么做到正在运行事物的同步处理,这个是组件设计者的素质决定的,如果他监听了像OSGi框架注册了BundleListener或者ServiceTracker,当有组件更新、卸载、激活的,或者总线上服务有这些事件的时候,自己的事物也要相应的相应,进行同步的更新。如果该事物有状态数据,则需要持久化或者刷新状态数据。这个不属于OSGi框架的责任,完全看开发者对OSGi的应用能力。

7. 是否开发Eclipse插件或者OSGi组件给最终用户?不明白什么意思?你当然可以使用EPL开源协议,免费提供,也可以商业发布你的产品。

8. 增量发布几乎是不可能的?如果客户所用产品需要动态更新和增加新功能,通过OSGi的动态部署组件bundle功能,可以轻松实现在线的更新和安装。类似于现在C/S客户端软件常用的做法。这个特性仅仅是OSGi一个特征,如果不想改变公司软件分发方式,可以不用。

9. 模块之间的交互,主要是java API调用,也有资源互相访问,又有web service调用,http url调用,equinox的扩展点方式,OSGi自己的service总线方式,这些几乎涵盖所有可能,提供了无限的创新可能。比如,如果一个bundle中封装了一个jee 网站,对外交互的方式还可能是对外提供封装了业务的jsp tag.

10. 当然,在一个Bundle内部,如果使用过多的第三方jars, 可以使用maven类管理依赖。但是,对于组件bundle之间,OSGi已经提供了完美的支持,不需要maven再参与进来了。

我想,如果真的想在Java EE环境下用OSGi,首要的问题是 现有的JEE中间件,Spring, Struts, hibernate, cglib, log4j纳入OSGi组件体系后产生的类加载问题。主要解决好这个问题,OSGi在Java EE的应用才会得到较快的发展。

0
l
leochang

请大家关注国内第一个Java EE OSGi开发及运行框架——WebOSGi,支持中国OSGi开源创新和发展。

http://webosgi.hirisun.com/support

WebOSGi框架当前已发布1.0.0版本及eclipse开发工具支持,可以上该项目网站下载安装试用。完整的教程和例子也可以在该网站找到。

WebOSGi旨在将大型的JEE项目,按照功能划分合理的组件化,封装成若干个有依赖体系的Bundle组件,比如将普通的JEE项目,封装成一个组件jars,然后作为独立的JEE项目,运行于一个大型的网站war中。该框架已经对常用中间件比如,spring, struts, hibernate等多个版本进行封装,如果一个组件化web项目使用SSH架构,只需要在工具界面选择SSH三个已有组件即可,不需要导入一堆jars,导致头疼的包冲突。同时WebOSGi框架提供了内置的web console支持,有图形化和web page上命令行两种方式。

0
y
yahoowenyi
我对 WebOSGi蛮有兴趣的,不过 完整的例子你放在了svn上,需要用户名和密码才能下载,请给一下用户名和密码呗
0
l
leochang

说实话,对国内主做Web应用的公司,OSGi插件化的阻力非常大,因为除了spring, hibernate等中间件封装OSGi bundle相对容易,其他的通用功能都几乎是一穷二白。要用OSGi体系设计开发一套自己的基础组件库,阻力非常大。

一,国内公司却反技术很全面、对开发过程中模块耦合关系等问题有深入思考的领导者,凭个别技术人员的力量,这样一个庞大的系统工程很难推动。

二, 国内互联网软件公司,对于整个技术体系框架研发的投入很不够。可能是担心潜在的技术风险和投入多。这就导致项目驱动的开发模式很难转变成稳定产品线,公司发展的瓶颈解决不了。

三,国内的JEE开发人员,大多集中在熟悉的SSH框架的程度,对于OSGi插件化开发知识相当匮乏。这就使得很难组织起来一个高效的团队,这个团队里的成员对技术体系和细节实现都有统一的认识,而不是讨论半天发现谈论的不是一个层次的问题。不可否认,某些程序员适合在局部挖坑,最终把自己给埋了。二有些程序员,能从一个更高的角度去看问题,想把自己挖坑埋自己的那些人拉出来,最后才发现那些人根本不理解你的举动。

 

我也没有那个SVN的账号了,有兴趣给我邮件来讨论吧。

leomaggie365@163.com qq:278475286

i
ivaadin
不可否认,某些程序员适合在局部挖坑,最终把自己给埋了。二有些程序员,能从一个更高的角度去看问题,想把自己挖坑埋自己的那些人拉出来,最后才发现那些人根本不理解你的举动。 讲得挺好!所以,很多自认为自己是码农的人,可能还真的一辈子只能做码农!
0
laoniu11
laoniu11
OSGI先放放
0
y
yinace

09年(还是08年,忘记了)hello world了一把,但那时发现osgi在web方面基本没法做项目,就搁了下来。

现在(12年)没事又翻出来看看,发现在web方面还是那么蹩脚,不知是我没了解到最新的更新,还是确实现实就是这样的,继续研究一下。

新人王
新人王
不要乱说哦,看看dotCMS对于OSGI的扩展
0
yxtwang
yxtwang
http://webosgi.hirisun.com/support 是不是没有了!
0
m
mcgrady32303

我们已经搭建了一套相对成熟的OSGi Web企业级开发框架,其中确实遇到不少问题。

现在好几个项目一直使用该框架,已经习惯了OSGi下的敏捷开发,好处自然有不少!

想学习OSGi技术,可以关注http://www.osgi.com.cn/,有不少有营养的原创!

我们一直关注OSGi和Spring的发展!

返回顶部
顶部