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

    

评论

16 楼 fireflyc 2010-02-01  

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

15 楼 fireflyc 2010-02-01  

其实模块化和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程序无法划分模块，我不知道是指什么。

14 楼 scott.s 2010-02-01  

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

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

13 楼 xyz20003 2010-02-01  

skydream 写道

xyz20003 写道

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

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

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

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

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

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

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

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

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

12 楼 yefeng 2010-02-01  

risemanjavaeye 写道

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

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

11 楼 risemanjavaeye 2010-02-01  

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

10 楼 yefeng 2010-02-01  

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

9 楼 fkpwolf 2010-02-01  

LZ说的1和2好像没有可比性。app server可能是基于osgi来实现j2ee标准的，但是对于一般的j2ee开发者来说，并没有暴露osgi的特性给开发者。

个人感觉OSGI是一个复杂的系统架构，是独立运行的；而一般的web应用只是系统架构下的运行的程序。

8 楼 skydream 2010-02-01  

xyz20003 写道

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

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

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

7 楼 srdrm 2010-02-01  

你对内存占用的认识是有问题的, 吃了1g内存, 实际上只能算是app server "保留"的内存, 这个值与MinMem有关, 你要查看真正的占用内存, 需要用jconsole, jprofile, visualjvm等工具可看到真正的内存占用情况. 实际上估计也就,2, 3, 百兆.

6 楼 xyz20003 2010-02-01  

如果把jar当做bundle，的确太细了。个人更倾向于使用业务或者功能模块作为bundle的分界。

还有一个问题就是，你使用OSGi是把整个服务器都考虑做一个OSGi容器，还是像我希望的一样，将OSGi嵌入WAR中。

如果是像多数人考虑的那样，使用OSGi连服务器都管理起来了，那几百个bundle确实很正常。但是我更期望不对原有服务器进行任何改动，直接在WAR中建立嵌入式的host，以此为基础实现动态模块扩展，这样一来基本上bundle就等于业务模块的数量了。

PS:我选用的felix，从功能强度来说，equnox无疑是最强大，但是个人对eclipse社区不怎么熟悉，所以还是选择apache社区的felix。按理说只要使用OSGi-4.2标准api，应该不会有大问题。

不过felix存在的不同bundle中同一package无法import的问题的确麻烦，一年多了还没改。

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

5 楼 skydream 2010-02-01  

melin 写道

在企业单个web应用项目上如果纯粹为了动态模块引入osgi，有点折腾。只有在整个企业全部的范围考虑，结合SCA进行模块的开发，结合osgi的动态性，才能适应快速变化。不过这对领导人才的要求太高了，要从战略的高度去设计，包括业务和技术。

非常期待Tuscany2，SCA和OSGI的结合，正在朝这方面努力。

门槛的确有点高，也由此带来了比较大的风险，个人认为这应该是osgi目前推广的一个很大阻力。

目前主要是想深入学习，用于自己开发的一个系统，反正主要是练手用，没有商业方面的顾忌。

对Tuscany2完全不了解，刚才去Apache Tuscany看了一眼，发现真是不错，新的2.0版本正如你说的，“SCA和OSGI的结合”。这正是我想要的东西，稍后认真研究一下。

感谢melin同学！

4 楼 skydream 2010-02-01  

zhangdp_neu 写道

但是因为服务端缺少良好的设计，造成开发人员接触到的工具都不能利用OSGi，他们本身又不懂怎么将这些组件移植到OSGi中。

这个深有感悟。
我们就用OSGi做服务器端，也没有相关成熟的架构可以参考，Bundle粒度划分起来总感觉不爽。

能否分享一下你们用osgi做服务器端的经验？因为实在是太缺少经验了，第一次接触第一次使用，最重要的是很难找到可以交流讨论的人，而网上也极度缺乏实战方面的资料。

对于Bundle粒度的问题，我个人的感觉是粒度有点太细了，而且没有层次，这样如果bundle数量多的情况下有点乱，比如100个bundle，或者500个？管理是个问题。而且有些service可能是只适用于某些功能模块，没有必要暴露给所有模块，这个问题目前我没有找到解决的方法。

顺便可以问一下，你们使用的osgi框架是哪个？我目前主要在研究apache的felix。能否介绍一下你们做选择的主要依据是什么？

3 楼 melin 2010-02-01  

在企业单个web应用项目上如果纯粹为了动态模块引入osgi，有点折腾。只有在整个企业全部的范围考虑，结合SCA进行模块的开发，结合osgi的动态性，才能适应快速变化。不过这对领导人才的要求太高了，要从战略的高度去设计，包括业务和技术。

非常期待Tuscany2，SCA和OSGI的结合，正在朝这方面努力。

2 楼 zhangdp_neu 2010-02-01  

但是因为服务端缺少良好的设计，造成开发人员接触到的工具都不能利用OSGi，他们本身又不懂怎么将这些组件移植到OSGi中。

这个深有感悟。
我们就用OSGi做服务器端，也没有相关成熟的架构可以参考，Bundle粒度划分起来总感觉不爽。

1 楼 xyz20003 2010-02-01  

OSGi更多用于IDE这类客户端的开发上，主要是因为客户端的数据源分散，因此在使用OSGi切分模块时，每个模块对应操作本身的数据，对应的数据和操作只要放在一个bundle里就行了。

像server端这类应用，基本所有数据都来自于单独的数据源，比如DataBase。因此server遇到的最大问题在于如何在一个整体的数据源上，对功能模块进行切分。这方面不是技术实现的问题，而是设计架构的问题。

理论上OSGi是绝对可以胜任模块切分的，无所谓客户端还是服务端。但是因为服务端缺少良好的设计，造成开发人员接触到的工具都不能利用OSGi，他们本身又不懂怎么将这些组件移植到OSGi中。

其中的鸿沟如果没有能够填平，OSGi就不会出现在企业应用中。这也是为什么网上根本找不到OSGi复杂应用的原因，因为没人研究相关的设计架构。

去年我做个一个slide《富客户端Ext JS和系统模块切分》。有兴趣的同志可以下载pdf看一下。http://www.family168.com/images/wide/ria-and-module.pdf。

实际上这里的设计还很稚嫩，没有上升到可以具体实施的高度，如果有时间的话，希望今年有时间把这部分继续加深一下。本人是非常推崇OSGi的动态模块机制的。