基于osgi开发大型的企业应用

我们在2009年度基于OSGi重新设计了我们的自助终端服务的后台系统。技术方面，主要基于：
* OSGi
* Spring DM
* 每个业务设计成为相对隔离的服务（我们称之为交易码），每个服务对应于一个OSGi的服务，在开发上对应一个Spring POJO Bean
* 业务开发除按着OSGi的规范进行隔离、打包外，POJO本身基于Spring的DI模式，不依赖于OSGi（没有任何与OSGi直接相关的依赖）
在应用OSGi的过程中，我的感觉是：
* OSGi帮助我们更好的实现了业务的隔离和模块化设计工作。没有依赖关系是最好的关系，这个是我们的目标。
* 每个模块有更清晰的职责、更简单的依赖关系、更简单的代码、更容易进行单元测试。
* OSGi对于服务部署来说，是非常合适的一个容器。相比一个整体的软件，OSGi帮助我们更好的实施服务。
* 基本上，OSGi在我们的项目中，没有给我们的开发带来额外的开销。不过，单元测试方面，大部分的单元测试都需要在容器内进行，更麻烦一些。这个可能与我们现在的开发方式有关系。后续可能需要再改进。

总的说来，感觉Spring DM与OSGI相结合是一个很佳的选择，基本上可以实现业务代码与OSGi本身的隔离。

关注OSGI的web开发

还没有应用到WEB项目中， blueDavy在淘宝

no,no,我不大关心WEB项目的。。。。

blueDavy的大名早就知道了，我就是从看他的opendoc和书开始学osgi的。

我看osgi是个好东西，但凡事都有代价。
一个插件系统，首先就是允许你选择可加载的插件（所谓disable/enable)，然后更进一步允许动态启动/停止/升级。
普通的插件系统就已经如此强大了，osgi则更进一步，把插件体系做得更灵活，允许自定义扩展点。这一点对于ide这样的应用显然是很有价值的。但对于我们通常的应用场合，一般不需要，比如不需要为插件再定义几个扩展点，然后再定义几个插件。总之，那是一种树型的结构，插件依赖插件。
我想大部分人对普通的插件系统已经很满意了，就像firefox的插件系统。插件之间反正也没什么关系。比如传统的企业应用，我们只要把一个表单作为一个插件，对应一个菜单项即可。
但无论是firefox还是eclipse，只要你升级了一个插件，都强烈建议你你重启整个系统。虽然eclipse号称是osgi的。

再说个个人感觉，呵呵

做OSGI前，前确定你真的需要插件机制吗？各个插件之间真的能相互隔离吗？
插件可以分为基础插件和非基础插件，基础插件就是不启动这几个插件，系统就无法运行；其他插件之间就应该是可以相互隔离的了。
如果你所有的插件间，都是互相依赖的，那还是算了吧，直接用传统的也许更简单。

当然，如果你想单独升级，插件之间的通信是异步的，用OSGI还是有用的，但是设计目的（目标）就不一样了。

SeviceMix 4就是基于osgi开发的，大家可以看看他的代码

2010年，可能会有比较大的突破吧，现在都在尝试，blueDavy主管的项目，已经是基于了OSGI开发的，是个高性能通信的框架

可以做PAAS呀，试想：
1）前台Swing(SWT)架构，自动升级插件，富客户端完美用户体验。
2）后台可根据用户需求定制bundle，热插拔，随改随上线。

All in java，开发速度与产品竞争力兼得，嘿嘿。

扯淡，没有osgi，硬件成本和部署成本都不知道被吃掉多少，开发还得忍受沟通和协调的无尽的折磨。