java - OSGi:Import-Package/Export-Package 和Require-Capability/Provide Capability 有什么区别？

Question

我目前正在使用 OSGi 框架，但我对一些对我来说不是 100% 清楚的概念有疑问。我自己在寻找它，但我找不到一个能清楚解释它的体面的答案。

在一个包中，他使用的 header 的 list header 2 是 Import-Package和 Export-Package .名称不言自明:对某种包装的需求和对某种包装的提供。为了获得该包(或提供该包)，必须在需要导入的框架中安装完整的包。

但是我们到了 Requirements-Capabilities 的部分模型。这实际上可以与 Import-Package 相同和 Export-Package标题。此 Requirements-Capability 也有标题型号:Require-Capability和 Provide-Capability .这些再次代表要求某物和提供某物。

我知道Requirements-Capability模型只是后来在 OSGi 规范的开发中被引入。无法准确找到它是在什么年份和版本中呈现的。

但是，

为什么将其添加到规范中？我看不出它比 Import 还能提供什么/Export-package已经提供:创建对其他包/包的依赖？

有人能让我更好地理解这两组概念之间的区别(赞成和反对)吗？

Answer 1

当我们在 1998 年开始使用 OSGi 时，我们有一些明确的要求，但当然，并不清楚会产生什么结果。所以我们开始对我们拥有的需求和能力进行明确的建模:包。 Import-Package 需要一个能力，而这个能力是由一个 Export-Package 提供的。

2003 年 Eclipse 想开始使用 OSGi，但他们需要一个工具来要求另一个包，他们不喜欢导出和导入所有包的想法。实际上，当时他们并没有看到套餐的好处。为了满足他们，我们添加了 Require-Bundle 和 Fragment-Host(他们的另一个愿望，结果证明并不是那么好。)

在我们使用这些扩展指定 OSGi 4.x 之后，我们开始考虑存储库，Richard 开发了 Oscar Bundle 存储库。分析 OSGi 4.0 中的新 header 的情况，很明显，Import-Package 的实现看起来很像 Require-Bundle，甚至类似于 Fragment-Host 处理。

2006 年，Richard S. Hall 和我写道 RFC 112提出了一个更通用的模型，该模型捕获了现有依赖模型的语义，但并非针对每种类型的需求。即对于框架解析器，Import-Package 和 Require-Bundle 仅在命名空间上有所不同。将 Import-Package 视为通用需求并将 Export-Package 视为通用功能使存储库模型变得非常简单。更好的是，它是可扩展的，因为我们总是可以添加更多的命名空间。这使得解析器完全独立于实际使用的命名空间。

经过一些非常激烈的讨论，OSGi 核心平台专家组决定接受基本思想并制定需求和能力规范。尽管这最初是存储库的模型，但结果证明它对框架本身非常有用。因此，我们决定将现有规范调整为该型号。 OSGi 4.3 在内部将 Import-Package、Export-Package、Require-Bundle 等建模为资源(包)的需求和功能。为了向后兼容，我们保留了现有的 header ，但在内部将它们转换为需求和功能。

然后终于回答你的问题。随着时间的推移，OSGi 规范添加了越来越多的命名空间。命名空间就像是需求和能力的类型。它定义了该命名空间中能力的一组属性的语义。 Requirement 是在这些属性上断言的过滤器表达式。资源具有一组在满足其所有要求时提供给运行时的能力。 Resolver 的任务是找到一组资源，这些资源都满足彼此的能力和运行时提供的能力。

例如，我们添加了 osgi.ee命名空间，它准确定义了包可以运行的 VM。我们添加了 osgi.extender对外部程序(如服务组件运行时 (SCR))的依赖关系建模的命名空间。大多数 SCR 组件不需要 SCR 本身的任何封装，我们努力使它们尽可能独立。但是，除非运行时中的某个包提供 SCR 功能，否则 SCR 组件将毫无用处。请注意，这不能使用 Require-Bundle，因为 SCR 有多种实现。我认为大约有 20 个命名空间。每个命名空间都在 Namespace 中定义类。

该模型为 OSGi 带来了许多优势:

凝聚力尽管规范添加了许多命名空间，但解析器实现从来没有改变过，因为它们在通用模型上工作。

细粒度 OSGi 包的独特之处在于它们以非常细粒度的方式描述它们的依赖关系。我所知道的所有模块系统都倾向于使用不允许替换的简单模块到模块依赖关系。

灵活 由于框架具体化了 bundle 之间的依赖关系，因此可以在运行时利用这些依赖关系。例如，在 OSGi enRoute 中，我将一个包链接到它的网页，遍历这些运行时线路。

我个人认为 OSGi 的需求和能力模型是其最保守的 secret 之一。据我所知，它可以用于许多领域，以将许多开发项目改进为软件工程领域。

这个问题唯一令人失望的部分是我认为我们在 Core specification 中已经很好地描述了这一点。 ? :-)