OSGi模块化技术手册.pdfVIP

OSGi 模块化技术手册 OSGi 模块化技术手册 最近有一些争论，主要是关于是否完全成熟的 OSGi 模块化是严格意义上必须的东 西，或者 Jigsaw 是否一种足够好的“更简单”的方法。但是也许关键点在于对于任何既 定的组件在哪里适合什么模块化。OSGi 是 Java 领域里无可辩驳的最成熟的模块系统，它 与 Java 几乎是如影相随。在这本技术手册中我们将分三部分来和大家聊聊 OSGi 模块化以 及它和 Java 千丝万缕的关系。 OSGI 模块化 规范的模块化开发是需要 OSGi 的重要理由之一，模块化的开发方式一直就是现在的 主流开发方式，但业界却一直缺乏这样的标准，当然，如果 Java 本身具备这样的标准自 然就更好了。对于开发者而言，OSGi 更重要的特点则是：在开发应用时，它将成为更加优 秀的组件模型。下面我们就来看看 osgi 模块化。  OSGi 是所有模块化应用的框架  用 OSGi 架构实现模块化 OSGi 和 Java 当我们在 Java 的世界中使用组件开发时，OSGi 会成为我们的备选工具之一吗？有一 点可以肯定的是 OSGi 的动态组件模型将会支持由组件组装应用和在组件之间隐藏实现细 节，同时还会提供组件的生命周期管理功能。  OSGi 框架协助管理 Java 组件 TT SOA 技术专题之“OSGi 模块化技术手册” Page 2 of 25  Java 开源 OSGi 框架 专家谈 OSGi OSGi 最重要的事情是支持模块化。但由于大多数应用程序和系统的目的不是为模块 化，或被设计并建造为土生土长的模块化设计，采用的 OSGi 通常包含某种程度的困难。 让我们听听专家怎么看待这件事情。  采用 OSGI 不易，但利益重大  专家观点：选择 OSGi 或 Java EE？  Jeff McAffer 谈 OSGi 和 Eclipse TT SOA 技术专题之“OSGi 模块化技术手册” Page 3 of 25 OSGi 是所有模块化应用的框架 OSGi （Open Service Gateway Initiative）是关于通过在框架中安装一套（可重用 的）模块，如何创建一个有用的应用。基本上，我们在 1998 年开始着手解决组件编程模 型；令人惊奇的是，我觉得我们主要的成功来源于很多成功的 OSGi 项目。那么，任务已 经完成了吗？ 不见得，看看企业世界中关于 OSGi 的探讨：Spring、Jigsaw 等等。很多人喜欢它， 一些人似乎极度讨厌它（伙计们，别烦了，它就是个技术而已）。我的解释是 OSGi 违反 了一些企业开发者的基本期望值，OSGi 应该就是类路径上的一个库，提供一些有用的且便 捷的功能，但是在别的方面要置身事外。 模块化是关于你的代码基的；OSGi 仅仅是一个微小层，为性能良好的模块提供运行时 环境。OSGi 并不是什么会让应用瞬间模块化的 “神秘酱汁”。就像面向对象强制结构化程 序员差异思考，模块化迫使现在的开发者摆脱框框（和代码基），开始收获好处。模块化 是架构！ 正如我们长久以来在 OSGi 内部进行模块化，我们发现很多现有的软件模式本质上是 非模块的，而且已经开发了模块替代物。此外，我们发现这些模块化解决方案仅仅被开发 者所理解，这些开发者是实际工作在模块化环境中的。对于其他人来说，它就像是官方文 件。 就像所有的 next-next 问题一样（在你解决下一个问题的时候就会遇到这个问题）， 模块化 OSGi 解决方案常常会让人觉得过于复杂且不必要，如果一个人还没有体会道 next- next 问题的痛苦，这样像也合乎逻辑。本文中我为目前的一些最佳实践来尝试解释稳健的 模块化所带来的意想不到的结果。 TT SOA 技术专题之“OSGi 模块化技术手册” Page 4 of 25 Java 中的模块化是关于（简言之）将你的JAR 转到一个模块中。模块依赖于其他模 块，而且它们可以隐藏实施细节。模块之间的领域就仅仅是精确的共享包。正如实施细节 是保密的，我们可以在未来的版本中改变它们，这也正是模块化的主要好处。在我们的编 程模型中，这种隐