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

    前端时间认真的学习了一下osgi相关的知识，个人感觉是非常的不错。

    但是看了一下目前osgi的时候，几个成功案例都是基于osgi开发ide，比如eclipse之类。还没有看到用于企业应用的成功案例，是osgi不适合开发企业应用？还是说，目前没有人这样开始使用osgi？或者只是我孤陋寡闻，其实大家已经用开了？

    顺便说明一下为什么有这种的疑问，这个要冲java开发application的方式说起，我接触过的无非是两种：

    1. 简单的j2se的application
        就是自己写代码，编译打包，然后写一个命令行脚本或者shell，通过java 和main class启动java进程，里面爱干嘛干嘛。
        好处是简单，小巧，灵活，没有额外的负载。缺点嘛，没有模块化的支持，想安装，卸载，启动，停止，更新其中部分功能时，完全没辙，只能整个退出，更新之后重启启动。不过对于小程序倒不是问题，大型系统就不大可能了。
        这个是轻量级的解决方法。

    2. 大而全的app server
        这个就是标准的j2ee，weblogic，glassfish，jboss之类的都是了，提供标准的j2ee容器，完整的j2ee支持，诸如ejb之类，总之什么都有了。自己写代码，打包为app，通过ear，war等方式发布，对其中的任何一个app，安装，卸载，启动，停止都是可以通过控制台搞定的。
        很强大，但是很“重“，非常的重，像我在的团队，目前开发的东东，启动起来什么不跑就吃了1g内存......
        这个方案会带来一个问题，当模块被打包在不同ear中时，无法使用java的方法调用，只能通过ejb，或者自己开端口等方式进行远程调用。效率方面不好，而且感觉也挺傻的：同一个机器同一个进程，彼此直接访问还要走远程......在weblogic上可以通过将功能模块打包在同一个ear中，开启 ejb的local call优化为本地访问，但是限制是只能在一个ear中，这又破坏了模块化。
      
    从个人爱好和经历来说，我喜欢第一种方式的轻巧，比较讨厌2的笨重。但是1的缺点也很明显，当程序大到一定程度，功能模块越来越多的情况下，就不适用了。上面的例子，那个启动就吃1g内存的家伙，它的java project现在都超过200个了，可以想象有多大吗？如果用1的方式来开发，根本不可能啊。

    再有就是个人审美观的问题，我这个人生性比较反感庞大而复杂的东西，可以说j2ee 容器/ejb(尤其是ejb3.0以前)是完全违背我的美感的，虽然我现在靠这个吃饭，恩，似乎有点偏激......

    所以现在想看看有没有第三条路可以走(恩，当然工作方面2是肯定无法避免的了)，我自己现在想到解决方案就是基于osgi，将不同的功能模块划分为不同的 bundle（当然可以继续按照service细分）。这就避免了1原有的最大不足：无法划分模块来适用和管理，同时也绕开了app server这个大块头。

    稍后准备按照这个思路来开发一个application来练练手，试试可行性如何。比较看好这个思路的前景，但是目前没有信心，呵呵，主要是没有看到类似的案例，不知道该怎么着手，更别提什么最佳实践之类的可供参考。

    颇有摸石头过河的感觉，有朋友可以帮忙指点一二吗？网上可以找到的osgi的内容，基本都停留在简单介绍和高度评价上，没有找到实际的可供参考的东西。哪位同学如有osgi方面的知识请不吝赐教，不胜感激啊！

    非常有诚意的希望能有人和我一起深入探讨这个话题，无论是赞成还是反对.

ps: 因为在标题中有“请教”的字眼，被自动转移到问答频道了。我想了一下，我发这个帖子的主要目的还是为了可以找人讨论，而不是一个简单的问答。因此厚颜将请教二字从标题中去除后再发贴一次，

    

评论

36 楼 yefeng 2010-02-02  

应该说osgi要大规模推广，还有很多路要走，现在小搞搞不少，运用到大规模系统几乎没有，这其中有很多考虑，技术成本，学习成本，还有遇到问题的时候，解决问题的成本， 风险太大

35 楼 jnn 2010-02-02  

skydream 写道

zhangdp_neu 写道

skydream 写道

delphixp 写道

个人的看法就是，就目前而言，除非你真的想做实验，或希望开发一个框架来实现你的想法，否则。。还是不建议用 OSGI 来做 Web 的开发。。。。因为，太多的不成熟的东西要你去研究，去摸索。。

sorry，可能我误导大家了，osgi的确是不大适合通常的web开发，至少目前还是如此。我也没有打算在osgi上做web开发，目前考虑都是普通的application，不是web app。

不过osgi支持一些简单的http，做一些非web的http支持，比如rest webservice，简单的http交互还是不错的。或者简单的web应用，比如做一个系统自己的console，可以自己用jetty之类的嵌入式web容器来简单实现。正统的web app，还是交给tomcat，resin，weblogic，jboss之类吧。

对于HTTP的支持的话，嵌入式的jetty是一个比较好的。
就自身带的HTTP来说，灵活性，配置，性能，一直是问题，玩玩可以，实际用途不大，或许我没用明白。

osgi自带的http，我个人感觉它只是解决了有没有的问题，离好用和值得信赖还有很大的距离。
可以用来做一些非常简单的，非关键的，访问量极少的东西，不用引入其他的东西，聊胜于无吧。
再有就是做一些基于http协议的信息传输，不过没有测试过性能。这块不熟

PAX－WEB就是基于Jetty实现的。
其实用OSGi做企业集应用可以参考一下[url＝http://servicemix.apache.org/home.html]Apache ServicMix4[/url]，里面集中了大量得企业级应用服务。

34 楼 zhangdp_neu 2010-02-02  

我个人的认为

技术本身上也有些问题。
例如分布式的解决方案，目前是有了，但是谁愿意做第一个吃螃蟹的人？

更关键在与设计，有的时候甚至放弃传统的设计思想。
前面的也提到了现在缺少的是设计上的研究，而不是本身技术的研究。
划分的时候，bundle 多了也不是，少了也不是，管理起来真挺麻烦的。
我们曾经重几十个bundle较少到十几个。

用了一年多的感觉是，重构，重构，重构。。。。。。。。。。。

33 楼 jnn 2010-02-02  

liu_swei 写道

目前国外很多开源的应用服务器都开始转向osgi了，比如：glassfish、jonas、geronimo、spring-dm、spring-osgi、pax-web等，我们目前做的是开发微内核集成框架，用的内核是karaf，karaf是felix的子项目，项目是开源的，大家感兴趣可以申请加入来为国产中间件做一份贡献：
http://www.trustie.net/projects/project/show/loong

不知道你们在Karaf基础上做了哪些改进，我们公司的Fuse ESB也是基于Karaf的，有空可以聊一聊。

32 楼 skydream 2010-02-02  

zhangdp_neu 写道

skydream 写道

delphixp 写道

个人的看法就是，就目前而言，除非你真的想做实验，或希望开发一个框架来实现你的想法，否则。。还是不建议用 OSGI 来做 Web 的开发。。。。因为，太多的不成熟的东西要你去研究，去摸索。。

sorry，可能我误导大家了，osgi的确是不大适合通常的web开发，至少目前还是如此。我也没有打算在osgi上做web开发，目前考虑都是普通的application，不是web app。

不过osgi支持一些简单的http，做一些非web的http支持，比如rest webservice，简单的http交互还是不错的。或者简单的web应用，比如做一个系统自己的console，可以自己用jetty之类的嵌入式web容器来简单实现。正统的web app，还是交给tomcat，resin，weblogic，jboss之类吧。

对于HTTP的支持的话，嵌入式的jetty是一个比较好的。
就自身带的HTTP来说，灵活性，配置，性能，一直是问题，玩玩可以，实际用途不大，或许我没用明白。

osgi自带的http，我个人感觉它只是解决了有没有的问题，离好用和值得信赖还有很大的距离。
可以用来做一些非常简单的，非关键的，访问量极少的东西，不用引入其他的东西，聊胜于无吧。
再有就是做一些基于http协议的信息传输，不过没有测试过性能。这块不熟

31 楼 zhangdp_neu 2010-02-02  

skydream 写道

delphixp 写道

个人的看法就是，就目前而言，除非你真的想做实验，或希望开发一个框架来实现你的想法，否则。。还是不建议用 OSGI 来做 Web 的开发。。。。因为，太多的不成熟的东西要你去研究，去摸索。。

sorry，可能我误导大家了，osgi的确是不大适合通常的web开发，至少目前还是如此。我也没有打算在osgi上做web开发，目前考虑都是普通的application，不是web app。

不过osgi支持一些简单的http，做一些非web的http支持，比如rest webservice，简单的http交互还是不错的。或者简单的web应用，比如做一个系统自己的console，可以自己用jetty之类的嵌入式web容器来简单实现。正统的web app，还是交给tomcat，resin，weblogic，jboss之类吧。

对于HTTP的支持的话，嵌入式的jetty是一个比较好的。
就自身带的HTTP来说，灵活性，配置，性能，一直是问题，玩玩可以，实际用途不大，或许我没用明白。

30 楼 skydream 2010-02-02  

liu_swei 写道

目前国外很多开源的应用服务器都开始转向osgi了，比如：glassfish、jonas、geronimo、spring-dm、spring-osgi、pax-web等，我们目前做的是开发微内核集成框架，用的内核是karaf，karaf是felix的子项目，项目是开源的，大家感兴趣可以申请加入来为国产中间件做一份贡献：
http://www.trustie.net/projects/project/show/loong

ide和app server转向osgi早就是大势所趋，如今如果还有那个app server不用osgi，都有不好意思见人的感觉

然而今天我们这个帖子讨论的是osgi开发企业应用的问题，从osgi的4.0，4.2规范的开展上看，目前osgi极力增强对企业应用的支持，这个意图非常的明显。但是目前实际应用中osgi开发企业应用却还是少之又少，有头有脸的知名的成功案例目前好像还没有 巨大反差啊

29 楼 delphixp 2010-02-02  

我也用过 OSGI 来开发系统，发现系统的设计确实是一个比较大的挑战。。。模块的划分，即有充分的灵活性（开发性），又不会因粒度过细而难以管理。确实是一个对自己设计能力的挑战。

我用 OSGI 来开发的是一个对某种协议进行监控的网控系统。这个系统，并不需要大量、复杂的界面。。。只有一个规则定义界面和一个Log 的实时查看界面。。

由于监控是希望 24 小时运行，并且在添加新的模块时，尽量减少系统的停启。。所以当时就选用 OSGI。。。根据客户的需求添加新模块时，系统不用停止并且立即生效。。

OSGI，没有 JBOSS ，没有 Weblogic ，甚至没有 tomcat 。。。。这些只会给你添加额外的维护工作。。。

没有 JSP 、HTML 。。。不用为美工，或设计漂亮的界面而烦恼。。。。

28 楼 zhangdp_neu 2010-02-02  

skydream 写道

xyz20003 写道

补充一句：就像我之前和其他人谈到的，如果为了采用OSGi，却将开发难度增大了哪怕10%，那么这个技术选择也是失败的。

这个10%，估计是远远不止了，考虑到现阶段很少有人熟悉osgi，整个team为此需要付出非常大的努力。

恩，这是一个很郁闷的话题，基本上断绝了短时间内osgi的大规模推广。或许只有java的模块化特性加入到jdk之后才有可能将osgi的理念推广开。好遥远啊

开始的时候我们曾经以为使用OSGi可以提高效率，但是实际上并不能，学习成本不低啊。

另外所谓的“热插拔” ，OSGi并不能真正的提供，要真正的热插拔的设计，难度也不小，考虑的问题也会很多。

使用OSGi的最大的改变 就是架构的改变，如果直接把原来的系统移植过来，不重新设计架构的话，可以认为是为了
OSGi而OSGi的。

27 楼 skydream 2010-02-02  

zhangdp_neu 写道

yuanyi_wang 写道

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

我也这么认为的，我们目前也是按照这个逻辑。

看来大家的认知比较趋近了，我学了一段时间，也有上述yuanyi_wang的想法，不过目前还不是很成熟。估计要练手一段时间后才能更加深刻。

不过始终认为，意osgi的bundle为代表的模块化概念 和soa/sca中的service概念，颇有天作之合的感觉，未来两者应该会逐渐融合，从而成为新的系统架构的基石。当然目前看来要走的路还很长......

26 楼 liu_swei 2010-02-02  

目前国外很多开源的应用服务器都开始转向osgi了，比如：glassfish、jonas、geronimo、spring-dm、spring-osgi、pax-web等，我们目前做的是开发微内核集成框架，用的内核是karaf，karaf是felix的子项目，项目是开源的，大家感兴趣可以申请加入来为国产中间件做一份贡献：
http://www.trustie.net/projects/project/show/loong

25 楼 skydream 2010-02-02  

delphixp 写道

个人的看法就是，就目前而言，除非你真的想做实验，或希望开发一个框架来实现你的想法，否则。。还是不建议用 OSGI 来做 Web 的开发。。。。因为，太多的不成熟的东西要你去研究，去摸索。。

sorry，可能我误导大家了，osgi的确是不大适合通常的web开发，至少目前还是如此。我也没有打算在osgi上做web开发，目前考虑都是普通的application，不是web app。

不过osgi支持一些简单的http，做一些非web的http支持，比如rest webservice，简单的http交互还是不错的。或者简单的web应用，比如做一个系统自己的console，可以自己用jetty之类的嵌入式web容器来简单实现。正统的web app，还是交给tomcat，resin，weblogic，jboss之类吧。

24 楼 zhangdp_neu 2010-02-02  

yuanyi_wang 写道

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

我也这么认为的，我们目前也是按照这个逻辑。

23 楼 berlou 2010-02-02  

还是有做企业应用的， 我们项目的一个大模块就是以OSGI为基础设计的， 主要想法是客户可以按模块（功能）定制服务，然后付款。

22 楼 delphixp 2010-02-02  

由于 OSGI 最初的发展并不是以 WEB 开发为目前的，即便到现在 OSGI 4.2 出来，EEG 也弄了很多规范出来，但仍然还没达到成熟可用的程度。。。

所以用 OSGI 来做 WEB 开发，仍然是高风险，低收益。。。。当然，这也存在让人发挥的很大空间， Spring DM (现在是 Eclipse Virgo 项目)就是一个很好的尝试。。。

不过，对于非 Web 项目而言，OSGI 其良好的动态性，错误的有较分隔，清晰规范的接口，以及 Eclipse 这个日益好用的开发环境，仍然有非常好的吸引力。。。

Eclispe 就是一个用 OSGI 发展起来的示范生态系统。。。。不错，OSGI 要做的就是一个生态系统的基础。。。。这个生态系统，由很多相互联系，又相互独立的部件组成。。添加、移除、变更部件不需要停止或启动整个系统。。并且由于OSGI本身的精小，不需要太多的运行配置和学习成本。。。

个人的看法就是，就目前而言，除非你真的想做实验，或希望开发一个框架来实现你的想法，否则。。还是不建议用 OSGI 来做 Web 的开发。。。。因为，太多的不成熟的东西要你去研究，去摸索。。

21 楼 zuozhengfeng 2010-02-02  

OSGi的门槛确实有点高，目前都只是练手阶段啊

20 楼 zhaoyta 2010-02-02  

个人感觉服务划分比较重要

19 楼 yuanyi_wang 2010-02-02  

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

18 楼 skydream 2010-02-02  

xyz20003 写道

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

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

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

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

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

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

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

17 楼 skydream 2010-02-01  

yefeng 写道

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

没有整套的解决方案的确是个问题，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容器后是否能支持，稍后再研究

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