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

    

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的动态模块机制的。

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

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

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

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

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

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

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

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

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

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

感谢melin同学！

如果把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%，那么这个技术选择也是失败的。

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

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

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

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

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