这两天才看了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到实际项目的时机。

【编辑推荐】

1. Spring AOP的一些概念
2. acegi到Spring security的转换方式
3. Spring Framework的理解
4. 解决Spring2.0向spring2.5迁移的问题
5. Spring框架人气暴涨