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

    

评论

76 楼 cherishmmo2004 2015-04-14  

感觉你们都很牛掰，我们做的一个运维平台也是用karaf的，用karaf+mq做巡检功能，但是karaf这个鬼东西太占资源了，100多m，消耗10%的cpu，弄的客户很不满意，现在我们想找一个替代方案，都不知道怎么搞。有没有这方面的经验，借鉴下啊。

75 楼 liu_swei 2010-02-21  

jnn 写道

liu_swei 写道

jnn 写道

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的，有空可以聊一聊。

我们重构了声明式服务，重构了日志服务，重构了热部署，定义了部署框架，现在可以部署war包，还可以随时扩展新的部署器、定义了协议处理器框架，定义了web容器框架同时集成了tomcat和jetty，并开发了dservice容器、集成opensso、集成数据源事物等等，下一步要重构karaf的内核
目前我们开源的只是微内核框架，以后会陆续开源所有的源码！

不知道你说的重构主要做了那方面的工作。
据我所知你上面提到的大部分功能 都是由karaf是通过pax－xxx 来实现的。
dservice容器、集成opensso、集成数据源事物， 这几个功能到是有点意思。

我现在有个问题就是如果Karaf升级了，你们的微内核框架需要做多大的修改才能使用新版本的Karaf.

呵呵，我们的重构更多的是功能上的，至于karaf内核，我们正准备重写它的内核
这样就不必依赖于它了，至于集成的jetty我们最初采用的的确是pax-web的，后来为了集成tomcat我们自己定一个了web容器框架，并重新集成了jetty，已经完全和pax-web无关了。

74 楼 pufan 2010-02-09  

更普遍的需求就是版本升级，当然这也是所有bundle的共有需求。

理论上来说，任何需求都不一定要热插拔，当然这也要求你的代码设计的“更好”。

73 楼 skydream 2010-02-09  

DB bundle：更换数据库连接池大小、更改连接参数
Log bundle：更改log级别
Cache bundle：停用或启用cache，甚至从本地cache无缝切换到远程cache。

我怎么感觉这几个需求，不是只有通过热拔插才能完成。如果这几个模块设计的好，完全可以做到runtime 的动态配置。当然热拔插相当于推倒重来，做起来更简单一些。

72 楼 pufan 2010-02-08  

skydream 写道

pufan 写道

skydream 写道

     再次更新，分成3个层次

老兄，service定义bundle在哪里，你这样做common bundle怎么能够热插拔？

对于热拔插的支持，我个人感觉在business bundle这个层面上比较有可能有需求，对于common bundle，似乎实际意义不大。

打个比方说，有一个短信网关之类的应用，在business层面上，增加，卸载或更新某个业务能力是可能的，比如对smpp sms模块的更新，增加一个rest方式的sms模块，这个热拔插请求是比较合理的。对于common层，我不大理解为什么需要热拔插？比如说从提供datasource的bundle，难道是从mysql数据库切换到oracle？我对这块的需求和背景不大了解，pufan同学能否简单的介绍一下你遇到的场景：在类似我图中的common bundle的功能模块中，需要实现热拔插。这可以帮助我理解，谢谢！

很常见的需求，举几个例子：
DB bundle：更换数据库连接池大小、更改连接参数
Log bundle：更改log级别
Cache bundle：停用或启用cache，甚至从本地cache无缝切换到远程cache。
等等

用osgi最大的思想转变就是活用service，要注意这个‘活’字，不但要面向接口设计，更要充分利用osgi框架的service依赖及查找特性进行whiteboard pattern设计，那时你就会发现开发速度达到甚至超越传统框架也并不是不无可能的了。

71 楼 fcoffee 2010-02-08  

OSGi只是让"热插拔"成为了可能, 而不是一定能.

70 楼 skydream 2010-02-08  

pufan 写道

skydream 写道

     再次更新，分成3个层次

老兄，service定义bundle在哪里，你这样做common bundle怎么能够热插拔？

对于热拔插的支持，我个人感觉在business bundle这个层面上比较有可能有需求，对于common bundle，似乎实际意义不大。

打个比方说，有一个短信网关之类的应用，在business层面上，增加，卸载或更新某个业务能力是可能的，比如对smpp sms模块的更新，增加一个rest方式的sms模块，这个热拔插请求是比较合理的。对于common层，我不大理解为什么需要热拔插？比如说从提供datasource的bundle，难道是从mysql数据库切换到oracle？我对这块的需求和背景不大了解，pufan同学能否简单的介绍一下你遇到的场景：在类似我图中的common bundle的功能模块中，需要实现热拔插。这可以帮助我理解，谢谢！

69 楼 pufan 2010-02-06  

skydream 写道

     再次更新，分成3个层次

老兄，service定义bundle在哪里，你这样做common bundle怎么能够热插拔？

68 楼 skydream 2010-02-05  

     再次更新，分成3个层次

67 楼 skydream 2010-02-05  

   更新一下图，看看是否是这个意思：

   

66 楼 zhangdp_neu 2010-02-05  

skydream 写道

to zhangdp_neu： 我想我应该明白了，你是因为通用的bundle太多，因此将其中一些类似的bundle合并成为一个bundle，依旧提供原有的service。

    也就是说从1service / 1bundle  修改为 n service / 1bundle ，从而减少bundle的物理数量，但还是保留原有的service封装。

    这样理解是否正确？

恩，有点这个意思。在你那个图上再加一个Bundle，不暴露服务，只是对外export工具类一类的。

不好意思，下班了，跑了

65 楼 skydream 2010-02-05  

to zhangdp_neu： 我想我应该明白了，你是因为通用的bundle太多，因此将其中一些类似的bundle合并成为一个bundle，依旧提供原有的service。

    也就是说从1service / 1bundle  修改为 n service / 1bundle ，从而减少bundle的物理数量，但还是保留原有的service封装。

    这样理解是否正确？

64 楼 skydream 2010-02-05  

简单的画了一个图：

63 楼 zhangdp_neu 2010-02-05  

skydream 写道

zhangdp_neu 写道

skydream 写道

erbin 写道

osgi是个好东西，但是它还是存在Bundle粒度粗细问题，比如我要建立一个分布式系统，数据源层，dao层，业务层
显示层，每层都会有好多的Bundle有时候要新建一个模块的话需要引入很多Bundle而且引入的Bundle还要引入其他的Bundle这样整体的结构依然是紧密耦合的，没有达到osgi原本的初衷。
所以我觉得osgi的关键还在Bundle的粒度问题，怎么划分才是合理的 才能高度解耦。

“所以我觉得osgi的关键还在Bundle的粒度问题，怎么划分才是合理的 才能高度解耦”-----这个我非常赞成！

有关这个粒度的问题，比较头疼的是如果太小bundle太多管理起来太痛苦了，而有些bundle的功能可能比较简单，比如一些工具类。对于这种我感觉不如直接嵌入到使用它的bundle里面，以lib包的形式存在（当然这个也会造成多个bundle之间重复的问题）。

bundle的划分应该是基于service来做，而且应该以功能模块的边界为划分原则：同一个功能模块内，如果不对本功能模块外暴露，就应该尽量隐藏在该bundle(先假设该功能模块只有一个bundle的情况)内部，比如我上面说的直接打包在bundle的jar中。

以erbin同学的例子，“数据源层，dao层，业务层”，其中数据源层应该是被几乎所有需要数据库访问的bundle使用，有必要做成bundle提供service来操作数据源，而在这个数据库的bundle内部，如何使用就应该屏蔽起来，比如说使用c3p0来做连接池，这个c3p0的jar包就没有必要暴露给外部了。"dao层，业务层"，如果不是被多bundle公用，就应该封装然后以service的形式供其他bundle调用。

上述的想法暂时还不成熟，我还没有实际使用，有点纸上谈兵的感觉。但是基本的出发点就是，bundle的粒度不能太细，数量不是越多越好。

我坚持bundle最少的原则。

业务层面的基于Service的划分，这个层面实现了业务级的复用。
系统划分成模块后，如果此模块内部组件没有热插拔方面的特殊要求，那么整个模块就为一个bundle.
可以同时对外提供一个或多个服务。

如果此模块中某个组件（或功能点）有热插拔等特殊需求，此模块为一个主Bundle。
只定义出热插拔组件的一些接口。
热插拔需求的组件和相关类等划分出来，单独为一个bundle。

业务层面的类库划分，实现代码级别的复用。
将一些业务相关的公共类划分，只是定义抽象类，公共类一类，业务异常等。

    bundle最少的原则，我也有这个倾向，不过没有你这么强烈。可能我还没有在实际的开发中正式使用，感触不够深刻，呵呵。
    我目前的想法倾向于将service按照是否带有business含义划分为两种类型：有business内容的serive，比如说取一个用户资料，执行一个客户请求；没有business内容的service，主要是指内部实现，比如获取数据库datasource，一些公共的工具类或者工具模块。
    后者理论上也可以不单独出来而是以类库的方式分别打包在不同的带business内容的service所在的bundle里面，但是这样就有重复的问题。因此对于一些比较重要而又被很多bundle使用的service，即使它不带business内容，也没有热拔插的要求，我还是倾向于将这个service提取为单独的bundle。

我的经历是这样，开始的时候，日志，数据库datasource等都是单独的bundle，对外提供服务，后来发现这样Bundle多的控制不住。

后来，日志，datasource等都提取到一个bundle中，做成及系统级组件，都是对外提供服务（业务无关的服务），另外有一部分做不成服务的，直接对外export了。

没有将所有其作为jar吧打在lib里。而是做为一起部署的一个bundle。

62 楼 skydream 2010-02-05  

zhangdp_neu 写道

skydream 写道

erbin 写道

osgi是个好东西，但是它还是存在Bundle粒度粗细问题，比如我要建立一个分布式系统，数据源层，dao层，业务层
显示层，每层都会有好多的Bundle有时候要新建一个模块的话需要引入很多Bundle而且引入的Bundle还要引入其他的Bundle这样整体的结构依然是紧密耦合的，没有达到osgi原本的初衷。
所以我觉得osgi的关键还在Bundle的粒度问题，怎么划分才是合理的 才能高度解耦。

“所以我觉得osgi的关键还在Bundle的粒度问题，怎么划分才是合理的 才能高度解耦”-----这个我非常赞成！

有关这个粒度的问题，比较头疼的是如果太小bundle太多管理起来太痛苦了，而有些bundle的功能可能比较简单，比如一些工具类。对于这种我感觉不如直接嵌入到使用它的bundle里面，以lib包的形式存在（当然这个也会造成多个bundle之间重复的问题）。

bundle的划分应该是基于service来做，而且应该以功能模块的边界为划分原则：同一个功能模块内，如果不对本功能模块外暴露，就应该尽量隐藏在该bundle(先假设该功能模块只有一个bundle的情况)内部，比如我上面说的直接打包在bundle的jar中。

以erbin同学的例子，“数据源层，dao层，业务层”，其中数据源层应该是被几乎所有需要数据库访问的bundle使用，有必要做成bundle提供service来操作数据源，而在这个数据库的bundle内部，如何使用就应该屏蔽起来，比如说使用c3p0来做连接池，这个c3p0的jar包就没有必要暴露给外部了。"dao层，业务层"，如果不是被多bundle公用，就应该封装然后以service的形式供其他bundle调用。

上述的想法暂时还不成熟，我还没有实际使用，有点纸上谈兵的感觉。但是基本的出发点就是，bundle的粒度不能太细，数量不是越多越好。

我坚持bundle最少的原则。

业务层面的基于Service的划分，这个层面实现了业务级的复用。
系统划分成模块后，如果此模块内部组件没有热插拔方面的特殊要求，那么整个模块就为一个bundle.
可以同时对外提供一个或多个服务。

如果此模块中某个组件（或功能点）有热插拔等特殊需求，此模块为一个主Bundle。
只定义出热插拔组件的一些接口。
热插拔需求的组件和相关类等划分出来，单独为一个bundle。

业务层面的类库划分，实现代码级别的复用。
将一些业务相关的公共类划分，只是定义抽象类，公共类一类，业务异常等。

    bundle最少的原则，我也有这个倾向，不过没有你这么强烈。可能我还没有在实际的开发中正式使用，感触不够深刻，呵呵。
    我目前的想法倾向于将service按照是否带有business含义划分为两种类型：有business内容的serive，比如说取一个用户资料，执行一个客户请求；没有business内容的service，主要是指内部实现，比如获取数据库datasource，一些公共的工具类或者工具模块。
    后者理论上也可以不单独出来而是以类库的方式分别打包在不同的带business内容的service所在的bundle里面，但是这样就有重复的问题。因此对于一些比较重要而又被很多bundle使用的service，即使它不带business内容，也没有热拔插的要求，我还是倾向于将这个service提取为单独的bundle。

61 楼 zhangdp_neu 2010-02-05  

skydream 写道

erbin 写道

osgi是个好东西，但是它还是存在Bundle粒度粗细问题，比如我要建立一个分布式系统，数据源层，dao层，业务层
显示层，每层都会有好多的Bundle有时候要新建一个模块的话需要引入很多Bundle而且引入的Bundle还要引入其他的Bundle这样整体的结构依然是紧密耦合的，没有达到osgi原本的初衷。
所以我觉得osgi的关键还在Bundle的粒度问题，怎么划分才是合理的 才能高度解耦。

“所以我觉得osgi的关键还在Bundle的粒度问题，怎么划分才是合理的 才能高度解耦”-----这个我非常赞成！

有关这个粒度的问题，比较头疼的是如果太小bundle太多管理起来太痛苦了，而有些bundle的功能可能比较简单，比如一些工具类。对于这种我感觉不如直接嵌入到使用它的bundle里面，以lib包的形式存在（当然这个也会造成多个bundle之间重复的问题）。

bundle的划分应该是基于service来做，而且应该以功能模块的边界为划分原则：同一个功能模块内，如果不对本功能模块外暴露，就应该尽量隐藏在该bundle(先假设该功能模块只有一个bundle的情况)内部，比如我上面说的直接打包在bundle的jar中。

以erbin同学的例子，“数据源层，dao层，业务层”，其中数据源层应该是被几乎所有需要数据库访问的bundle使用，有必要做成bundle提供service来操作数据源，而在这个数据库的bundle内部，如何使用就应该屏蔽起来，比如说使用c3p0来做连接池，这个c3p0的jar包就没有必要暴露给外部了。"dao层，业务层"，如果不是被多bundle公用，就应该封装然后以service的形式供其他bundle调用。

上述的想法暂时还不成熟，我还没有实际使用，有点纸上谈兵的感觉。但是基本的出发点就是，bundle的粒度不能太细，数量不是越多越好。

我坚持bundle最少的原则。

业务层面的基于Service的划分，这个层面实现了业务级的复用。
系统划分成模块后，如果此模块内部组件没有热插拔方面的特殊要求，那么整个模块就为一个bundle.
可以同时对外提供一个或多个服务。

如果此模块中某个组件（或功能点）有热插拔等特殊需求，此模块为一个主Bundle。
只定义出热插拔组件的一些接口。
热插拔需求的组件和相关类等划分出来，单独为一个bundle。

业务层面的类库划分，实现代码级别的复用。
将一些业务相关的公共类划分，只是定义抽象类，公共类一类，业务异常等。

60 楼 skydream 2010-02-04  

erbin 写道

osgi是个好东西，但是它还是存在Bundle粒度粗细问题，比如我要建立一个分布式系统，数据源层，dao层，业务层
显示层，每层都会有好多的Bundle有时候要新建一个模块的话需要引入很多Bundle而且引入的Bundle还要引入其他的Bundle这样整体的结构依然是紧密耦合的，没有达到osgi原本的初衷。
所以我觉得osgi的关键还在Bundle的粒度问题，怎么划分才是合理的 才能高度解耦。

“所以我觉得osgi的关键还在Bundle的粒度问题，怎么划分才是合理的 才能高度解耦”-----这个我非常赞成！

有关这个粒度的问题，比较头疼的是如果太小bundle太多管理起来太痛苦了，而有些bundle的功能可能比较简单，比如一些工具类。对于这种我感觉不如直接嵌入到使用它的bundle里面，以lib包的形式存在（当然这个也会造成多个bundle之间重复的问题）。

bundle的划分应该是基于service来做，而且应该以功能模块的边界为划分原则：同一个功能模块内，如果不对本功能模块外暴露，就应该尽量隐藏在该bundle(先假设该功能模块只有一个bundle的情况)内部，比如我上面说的直接打包在bundle的jar中。

以erbin同学的例子，“数据源层，dao层，业务层”，其中数据源层应该是被几乎所有需要数据库访问的bundle使用，有必要做成bundle提供service来操作数据源，而在这个数据库的bundle内部，如何使用就应该屏蔽起来，比如说使用c3p0来做连接池，这个c3p0的jar包就没有必要暴露给外部了。"dao层，业务层"，如果不是被多bundle公用，就应该封装然后以service的形式供其他bundle调用。

上述的想法暂时还不成熟，我还没有实际使用，有点纸上谈兵的感觉。但是基本的出发点就是，bundle的粒度不能太细，数量不是越多越好。

59 楼 erbin 2010-02-04  

osgi是个好东西，但是它还是存在Bundle粒度粗细问题，比如我要建立一个分布式系统，数据源层，dao层，业务层
显示层，每层都会有好多的Bundle有时候要新建一个模块的话需要引入很多Bundle而且引入的Bundle还要引入其他的Bundle这样整体的结构依然是紧密耦合的，没有达到osgi原本的初衷。
所以我觉得osgi的关键还在Bundle的粒度问题，怎么划分才是合理的 才能高度解耦。

58 楼 linux888 2010-02-04  

CS的话个人感觉OSGi有相当好的适应性。我也正在学习OSGi，不过我们基本都是BS应用，其实初衷就是想利用bundle的封装给复用性一个很好的载体，至于动态加载这类的特性，倒不是很看重。很想学习一下web应用上的OSGi开发的测试、部署以及性能问题。

57 楼 wangzaixiang 2010-02-04  

skydream 写道

javaonejcy 写道

对应用过于复杂的技术就是无用的技术。osgi离成熟尙远。

这个不敢苟同，osgi已经足够成熟了，只是它设计的初衷不是针对企业开发，所以目前迁移到企业开发时遇到比较多的问题。至少在ide，app server基本是不二选择，怎么至少给出“无用”的评价。

成熟与否，不能看别人说的，还是要结合到自己的应用中。你希望OSGi提供哪些特性？他是否提供？是否满足你的要求？不可能有一个方案能满足你的100%需求的。
此外，还要看你个人、团队的驾驭能力，驾驭能力不够，就只能使用JSP等基础技术了。

OSGi不就是一个模块化的支持技术吗？如果你需要，且用得上，在目前也没有更好的技术的情况下，大可放心使用。毕竟，eclipse、spring等至少保证OSGi本身是基本完备的。剩下的问题，就只有自己发挥了