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

osgi的开发门槛还是有点高的，个人感觉现在还没有整套的解决方案.打包,单元测试,classload,数据库连接池,JNDI等一些问题

曾经做过一段基于osgi的web应用开发，当时是按功能模块划分boundle，接口和实现，view层各划分为一个boundle，集成了ww和spring，hibernate，测试一个bd，但是一直没有很好的解决应用和web容器的集成关系，当时是把jetty一起打包，但这种方式一直也是处于开发测试阶段，没有进入正式的生产环境，不知道效果怎么样，个人也很想了解行业内osgi的应用情况，不知道有没有成功的案例。

这个问题我也碰到过,感觉打成war直接在tomcat部署就不成功, 如果只是用serlvet是可以的，有个briget模块,你可以试一下

使用框架的目的是简化开发，如果为了实现系统模块动态化，结果导致开发过程变得痛苦不堪，那肯定是捡了芝麻丢了西瓜，得不偿失。

所以才说，OSGi现在欠缺的不是技术实现，而是设计架构方面的研究。

据我所知，现在项目中即使引入了OSGi，也没有进行相应的架构改造。不知道是头儿想的太简单，还是根本没重视，以为只要使用了OSGi就可以实现动态了，结果各个模块之间依然是紧耦合状态，使用了OSGi不但没有带来任何灵便性，反而加大了开发的难度。最后就是开发者怨声载道，对OSGi避之不及。

有机会的话，可以去问问，项目中用过OSGi的，没有一个人叫好的。为什么？就是看起来很美丽。实际真想用好的话，首先要推翻之前积累的所有设计，从头开始。

对一般公司来说，难啊。他们本身的平台设计可能都不够严谨，更别提重头改造了。

说实话，以目前的OSGi积累来看，与其从头设计一套框架，奢望满足一切需求情况，还不如找一个旧有系统进行改造，看能不能把原来的系统使用OSGi改造成动态模块的架构，然后将两套结构进行对比，评价一下OSGi带来的优势与缺点，再考虑是否有继续研究下去的必要吧。

如果觉得ejb太重，为什么不考虑spring等轻量级的JEE框架，现在的spring等轻量级的解决方案应对大型的工业级系统也还是能够胜任的，并且有不少经验可以参考。

osgi这个东东熟悉的人不多，期望LZ能够在试验成功，分享一点经验：）

其实模块化和OSGI没有多大关系，楼主的问题是，当系统启动时会加载很多东西。如果这些东西是有必要的，那么必须加载，无论是用什么技术。如果是没有必要一次性加载的那么可以放到后面惰式加载。

OSGI所做的无非是隔离了classload，这样当需要某个对象时可以用classload扫描jar得到对象这一切都在你的控制之中（动态加载），更新的时候可以重新加载jar里面的内容（动态更新）。所以OSGI没有什么魔法可以让你一次不加载很多东西，除非是你自己做这样的惰式加载的设计。

我觉得OSGI就像裹脚布，很长很臭。当需要设计一个组件的时候我写一个bundle，然后写一个配置文件，然后发布，配置文件中写的是裹脚布一样的东西——import和export出的类。当我需要使用一个bundle实际上我依然不可避免的需要一个bundle的接口包，然后把我的bundle再经历三步骤发布（再次强调，最为恶心的是裹脚布的配置）。
看吧，OSGI带来的无非是动态加载，动态更新。假如是传统的java se项目那么一切尽在掌握，我们进行模块划分，如果需要动态加载class和动态更新的特点，我们实现一下classload的管理就可以了，根本不需要去搞OSGI的裹脚布原则。
如果是java ee程序那么就麻烦了，classload由web容器接管了，我们无能为力。这也就是为什么osgi容器想在web上跑就必须把web容器和osgi容器合为一体的原因。（spring dm就是这样一个web容器）。

即使没有OSGI世界一样很好，jboss为了可扩展性拉出来JMX，一样很实用。OSGI的裹脚布原则有点学院化，除了所谓的规范、标准我找不出它优秀的理由。（当然规范和标准是可以被任意践踏的，正如sun的portal标准，sun的java me标准。。等等等。。标准。）

楼主说java se程序无法划分模块，我不知道是指什么。

如果你确信OSGI是你正确的方向，想了解OSGI的应用，我推荐spring的spring dm。

没有整套的解决方案的确是个问题，osgi框架只是解决了osgi规范的实现问题，对于如何开发osgi本身并不关注，比如说打包，根本不在考虑范围之类的感觉。只能其他人去解决了，比如felix就有maven的插件用于打包bundle。

不过这个问题是可以自己解决的，只是辛苦一点：
1.打包的问题我尝试过maven，不是特别理想，后来转向ivy，发现ant + ivy是个不错的解决方案，功能强大而灵活，当然对打包脚本的编写要求比较高，全部自己动手写，有利有弊吧。但至少提供了解决打包问题的一个好的思路。
2. 单元测试方面，由于ivy良好的依赖管理，基本上可以很好的在java project中近乎完美的控制好项目间依赖和第三方依赖，正常情况下单元测试是可行的。但有个前提是osgi的import/export之类的设置和ivy文件设置之间要求一致，如果有差异那在单元测试阶段是没有办法的。只能等到集成测试时才能发现，比如说该import的没有import。这个问题似乎无解，ivy和maven的依赖管理是基于artifact的，而osgi通常是基于package的。
3. classload 这个不是很理解，是不是和2一样如果import、export设置有误导致classload出错？
4. 数据库连接池，这个似乎通过自己使用诸如c3p0等可以自己搞定，但是终究还是要自己动手开发，如果想像j2ee容器那样方便查看和管理，那就麻烦。
5. jndi等j2ee的内容，没有在osgi内实验过，不知道离开j2ee容器后是否能支持，稍后再研究

这样看来要做的事情还真是挺多的。

这个问题理论上不是osgi的问题，任何新的理念出来时都会遇到这个问题，以固有的思路来理解使用新的知识，很难逃脱“画虎不成反类犬”的令人痛心的结果。诸如敏捷开发尤其是tdd，持续重构这些，如果执行不好反而造成巨大的浪费：花费大量人力去做，却没有做到该有的样子，结果好处没有捞到一堆坏处出来了。所谓做的不对还不如不做。

osgi的问题更加尖锐，这个东西本身就是针对整体架构的，级别本来就比较高，而且又不适合小系统，平时都基本没有机会做实践。而一个大到可以考虑使用osgi的系统通常又不大可能由新手来实现，风险太大，因此很难发展出用户群。目前我感觉只能寄希望于java在语言层次中引入模块化，大势所趋之下可能会有更多的公司开始尝试。

    目前我手头有两个原型可以考虑来尝试，一个是java版本的邮件系统，这将会是一个全新设计，完全自己来搭建的玩具，用于实验我喜欢的一些技术，这个东东我已经准备了近两年，希望2010年能有第一个初级的勉强可用的版本出现。其次是公司目前在用的系统，准备从中提起一些典型功能模块来重新考虑实现方式，恩，当然是简化简化再简化的版本，仅仅是验证可行性而已。后者和xyz20003提出的旧有系统改造的想法是一致的。

个人觉得OSGI等这些东西的关键不是技术，而是系统设计的思想了。
更关键的问题是你如何划分模块等规划上的事情。
模块划分小了，互相调用就会频繁，性能就会降低；模块划分大了，就很难重用。
所以觉得还是应该有一套技术框架，重用技术角度的代码；在技术框架上建立业务框架；在业务框架上建立商务组件。
一个OSGI模块就应该是商务组件，各个商务组件之间的通信应该不是十分频繁；每个组件应该可以独立运行。