在《OSGi是所有模块化应用的框架（上）》中，我们介绍了在编程模型中，实现细节是保密的，这种隐藏会有哪些影响。下面，我们将具体介绍一些消除这些影响的办法。

　　在2000年初，Rod Johnson写了一本非常成功的书，主要关于控制反转（IoC），并演示了对于企业应用来说，这个模式是多么有用。随后，他用开源Spring框架普及了这个模型。IoC或者好莱坞原则（Hollywood principle）：“不要呼叫我们，我们来呼叫你，”意味着消费者失去了其所拥有的任何控制。取而代之的是在需要的时候创建一个对象，在时间注入前它通过一套方法或者构造函数获得这个对象，a.k.a.依赖注入（Dependency Injection）。在IoC图中，箭头展示了控制的方向。

IoC图

　　不幸的是，IoC容器让实施细节的耦合更糟糕。IoC容器需要知道消费者（在哪里注入）以及提供者（创建了什么）的实施细节。因而，在我们的UML图表中，令人难以置信地它好像解耦了。罪魁祸首就是IoC配置，浓缩了（因此耦合）实施细节，例如Spring中的XML。

　　问题是IoC要求我们放弃在代码中的控制，我们实际上完全了解的唯一的地方就是内部细节。没有一种模式我们可以拥有所有优势，但是也不会违反模块边界吗？消费者和提供者就没有哪里都没有边界贯穿其中吗？

　　正如我们不愿意知道制造了多少香肠，但是仍旧希望吃掉它们一样，这是个比喻。我们能否不用知道其任何生产过程而得到一个德式小香肠（Bratwurst）呢？当然，在实际世界中，我们只要去当地的商店，在冰箱里拿出来就好了。

　　那么，商店知道它们是怎么做出来的吗？也不知道，它不是工厂，屠夫每天来提供新鲜的香肠，只有他们知道那个“残酷的细节”。这里的秘密就是中介：那个商店。消费者和提供者拥有控制，商店是一个被动的中间人。这就是典型的发布、查找、捆绑模式。

　　如果一个提供者模块可以发布其实例，一个消费者可以查找到这些实例，然后中介将这一切结合在一起。在OSGi中，这个模式被作为“μservices”来实现，同时它也支持Java Service Loader。

μservices

　　因此，我们都在涅槃，除了现在的令人讨厌的动态依赖问题。正如消费者和提供着都拥有独立控制，我们可能不再去上商店，也不用找到香肠。使用Java代码来控制这种依赖性很棘手，会导致很多样板代码（boiler plate code）。

　　早期OSGi版本强迫你或多或少的用手来操作；做起来有难又讨厌。然而，对于依赖注射来说是个完美的工作。每一个模块能够制定其依赖性；中心控制器可以监控这些依赖性，并按需激活/停用组件。

　　在OSGi中，μservices的DI由Spring DM、Blueprint、iPojo、Declarative Services以及其他完全彼此协作的机制来提供。中间件模式是我知道的唯一一个为消费者和提供者提供控制的模式，不会强迫他们来无偿地暴露其私有部分。

　　讲了这么多，我希望对于为什么模块化破坏了如此多的代码有个清晰的思路：我们的产业正在使用很多模式，这些模式并不能同模块世界和谐相处。在模块边界收到尊重的前提下，OSGi出人意外地灵敏，但是当你的代码试图触犯它们的时候，它就有些残忍了。这也正是它的本质所在，因为如果没有这个强制执行，模块化就是个空壳。