这两天才看了BlueDavy的《OSGI实战》和《OSGI进阶》，2篇写得很好的文档。实战可做OSGI的入门资料，进阶可做OSGI的实践资料。很感谢BlueDavy大大的文档，他的BLOG是http://bluedavy./。进阶中讲解了一个留言板的例子，基于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到实际项目的时机。
【编辑推荐】
