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

“所以我觉得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。

简单的画了一个图：

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

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

    这样理解是否正确？

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

不好意思，下班了，跑了

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

   

     再次更新，分成3个层次

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