OSGi联盟对于模块化应用开发的未来怎么看呢？他们认为应用开发总体而言包括一个基于组件的应用开发社区，足够支持这种蒸蒸日上的组件市场。就像消费者现在下载应用，使其手机能够执行最新最棒的效果，应用开发者也许某天能够下载模块化组件，将其插入到现有的企业应用中去。

　　在JavaOne 2011上，Peter Kriens关于OSGi做了两个有益的介绍。Kriens的演讲解释了为什么尽管OSGi表现的很难，用OSGi实现模块化对于今天的应用开发者来说是很有价值的。他也解释了如何进入这个领域，同时澄清了一些关于OSGi和模块化应用的错误概念。

　　一种假设是局外人可能让开发服务网关（Open Services Gateway）计划中的“服务”代表面向服务架构（SOA）中的Web服务。结果正如Kreins指出的，OSGi服务实际上是本地服务，谈不上什么冗长，所以相当快速。但是，很多的面向服务想法适用于OSGi模块化。

　　在这两种情况下，服务是系统间模块化（SOA中称之为“松耦合”）的代理人。不同之处在于Web服务通常可以通过互联网进行分布式系统通信，而在OSGi本地服务连接子系统（模块）中交互形成复合应用。

　　这些本地服务在OSGi模块化模型中极其重要。这些服务正确实行时，就可以实现模块之间真正的松耦合。根据Kriens所说，确保每一个模块看不到所有其他模块的内部操作十分重要。也就是说，它们没有对任何事物有依赖性，除了产出表示。也意味着这些产出如何得到也无所谓。这样模块就成为可交换零件。

　　如果你已经模块化产出数据X、Y和Z，而且正在构建一个模块，需要输入数据X、Y和Z，它可以很轻易地将你的新模块抓取到现有模块中。Kriens强调这并不是实现它的最佳方法。你所有的新模块实际需要的是X、Y和Z，所以那也正是依赖所在。

　　如果在彻底一点，另一个开发者需要取代现有模块，他们所要做的就是确保替换模块仍旧提供X、Y和Z即可。他们甚至可以将模块分离成两部分，只要在二者之间即可，它们仍旧提供X、Y和Z。这对于未来的开发者来说更具有灵活性。

　　这也是为什么Kriens建议首先通过服务转移到OSGi的原因。构建真正的模块化模块确实很难，尤其是如果剩余的子系统还没有模块化。OSGi框架感觉有点想只许成功，不许失败。但是你可以用模块化的方式设置服务，无论模块实际上是否实现了模块化。合适位置上定义良好的服务，能够以一种迭代的形式更轻松地转移到OSGi。

　　让模块化盈利并不会立即将一个完全模块化的系统的所有好处呈现给你，但是如果实施的恰当，就会获得好处。这些好处可以用于证明模块化的价值，并鼓励其他开发者加入，构建现有的模块化，同时创造已近实现模块化的新的组件。