这两天才看了BlueDavy的《OSGI实战》和《OSGI进阶》,2篇写得很好的文档。实战可做OSGI的入门资料,进阶可做OSGI的实践资料。很感谢BlueDavy大大的文档,他的BLOG是http://bluedavy.javaeye.com/。进阶中讲解了一个留言板的例子,基于Spring/Hibernate/WebWork2/OSGI.
其中提供了Hibernate和WebWork2的OSGI集成方案实现,很精彩。
51CTO编辑推荐:OSGi入门与实践全攻略
Spring则采用Spring osgi.其留言板的例子是按应用模块进行划分的,并用Equinox的扩展点方式展现了菜单的加载和卸载实例。虽然这个菜单仅仅是一个链接,但也颇有参考意义。
此外还有如何将现有系统重构成OSGI系统的讲解,并总结了自己对OSGI应用中的设计模式和最佳实践的理解。这是目前我看到的最好的OSGI的中文资料了。
该书对模块的划分很细(其实不是基于功能模块,而是基于用例了),可能是因为留言板的例子太过简单,只好如此来演示。我想,在实际的项目中不会以这样的细粒度进行分模块的开发,否则BUNDLE会多不胜数,反而给维护带来麻烦。
在BlueDavy总结的最佳实践中,我认为“接口和实现分离为不同的Bundle”不是一个好的实践,搞太多的BUNDLE不是好事情。把接口BUNDLE挂着只对实现BUNDLE进行热插拔,与将接口和实现放在一个BUNDLE中做热插拔是一样的。
使用Spring osgi时就需要导入那么多的BUNDLE,我想最好能提供一个集成的BUNDLE,让开发者更容易搭建开发环境。当然也提供零散的 BUNDLE让开发者可以自行选择需要的,就像有spring.jar也有spring-bens.jar/spring-context.jar /spring-aop.jar一样。
现在搭建一个Spring osgi的开发环境还是挺麻烦的,在下载的Spring osgi1.0M3的lib中还少了一些BUNDLE,只好在M2中去找。spring2.5发行的jar包将会同时支持普通开发和OSGI开发,那时可能会方便一点,现在还是rc1的版本,没有试验是否可用。
现在在实际项目中运用OSGI风险还是太大,spring2.5和strut2的2.1正式发布时,应该才是引入OSGI到实际项目的时机。
【编辑推荐】