android模块化 osgi,OSGI模块化的真相

OSGI带来了模块化的讨论，原来我们认为架构是基于组件的架构，Modularity & Architecture(模块化和架构)一文谈论了基于模块化的架构，这不仅让我个人有些疑惑，组件不等于模块化？组件和模块化

是什么关系？是划分标准不一样还是粒度不一样。

文中首先谈论了众多的架构定义：

1.软件系统组织重要的结构元素

2.是一些组件和组件之间的关系

3.TOGAF定义：构件级别指导实施的计划，代表组件的结构

4.是一种体系结构中关键的设计决策，能够减轻以后因为变化带来的成本。

架构的目标是减少因为变化拓展带来的成本，实现这一目标是通过提高灵活性，同时驯服复杂性达到的。

面向对象设计中的开闭原则：禁止修改，鼓励拓展继承。我们可以通过不断的继承和抽象，但是带来的问题是复杂性，不断增多的之类和父子家族？如何组织管理他们？

文章提出一个系统是由模块和连接体joints组成的，连接体就是跨越模块之间的设计。变化被隔离封装在一个模块中，这样变化带来的影响就变得很小。也就是说，不要让变化跨越模块。虽然很难做到，但是这应该是架构设计的目标。

基于组件化的SOA好像是另外一种思路，将一定功能封装在组件中，组件以服务形式向外提供接口，通过对不同服务的多样化调用流程组合实现不同的业务。这也是一种开闭原则。

直觉告诉我：这两种开闭原则好像正好相反，一个是在模块中封装变化，让变化不要跨越模块；一个是在组件中封装不变性，通过跨越组件的不同调用应付变化。

我们可以从OSGI具体模块化实现来看，也验证了这样设计思路，在META-INF/MANIFEST.MF中需要指定当前包的依赖包，试想想：如果依赖包关系经常变化，那不是要经常更改META-INF/MANIFEST.MF，有几百个，不是改得头晕眼花，形成闭环依赖？头大啊。

所以，使用OSGI前提就是：依赖关系不经常变，变化的是bundle中的类，可以在运行时，动态插拔一个对象。

进一步设想：我们使用IOC/DI就是为解决类的依赖关系变化带来的麻烦，由IOC框架帮助我们自动解决依赖，而OSGI和IOC这种解决类依赖目的的模式正好相反哦。

看来：模块化的OSGI从另外一个架构思路为我们解决问题提供可选方案。当初OSGI诞生于微系统，因为微系统因为资源有限，不可能有太多组件或类，所以，包之间的依赖关系不复杂，可以看成是不变的，而将在微系统中运行的内容组件看成是变化的。

结论：OSGI模块化最大的特点是其开闭原则的独特性，OSGI优势不是在动态插拔，XML/类动态加载/AOP都可以在运行时动态插拔，我想后者是很多吹捧OSGi优点的一个误区。

OSGI这种独特的模块化设计思路为我们架构设计提供了一条新的选择。

参考：

[该贴被banq于2009-09-17 17:31修改过]

[该贴被banq于2009-09-17 17:32修改过]