OSGi：Import-Package / Export-Package和Require-Capability / Provide Capability之间有什么区别？

Question

我目前正在使用OSGi框架，但我对一些不是100％明确的概念有疑问。 我自己一直在寻找，但我找不到一个明确解释它的体面答案。

在捆绑包中，他使用的标题的清单头2是Import-Package和Export-Package 。 这些名称不言自明：对特定包装的需求和某种包装的提供。 为了获得该包（或提供该包），必须在需要Import的框架中安装完整的包。

但后来我们得到了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中的新标题分析情况很明显，Import-Package的实现看起来很像Require-Bundle，甚至类似于Fragment-Host处理。

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

经过一番激烈的讨论后，OSGi核心平台专家组决定接受基本思想，并制定了要求和能力规范。 虽然这最初是存储库的一个模型，但它对框架本身非常有用。 因此，我们决定使现有规格适应该模型。 OSGi 4.3内部将Import-Package，Export-Package，Require-Bundle等建模为资源 （bundle）的要求和功能。 为了向后兼容，我们保留了现有标头，但它们在内部转换为要求和功能。

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

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

该模型为OSGi提供了许多优势：

• 内聚尽管规范添加了许多名称空间，但解析器实现从不需要改变，因为它们在泛型模型上工作。
• 他们是如何描述一个非常精细的方式及其依赖性细粒度 OSGi包是独一无二的。 我所知道的所有模块系统都倾向于使用不允许替换的简单的模块到模块依赖。
• 灵活由于Framework为bundle之间的依赖关系提供了灵活性，因此在运行时可以利用这些依赖关系。 例如，在OSGi enRoute中，我将一个包链接到遍历这些运行时布线的网页。

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

这个问题中唯一令人失望的部分是我认为我们在核心规范中已经很好地描述了这一点？ :-)

Answer 2

需求和功能模型是Import / Export包模型的扩展。 实际上，您可以将包导入表示为需求，将包导出表示为功能。

导出/导入包允许松散耦合。 您导出API并且客户端导入它。 这样客户端只需要知道API就可以实现松耦合。

在稍后阶段，当您将应用程序从捆绑中组装出来时，这种松散的耦合会使该过程自动化变得困难。

如果您只是将客户端软件包提供给解析程序，那么它只能自动发现您需要提供API的软件包。 如果API的实现位于不同的包中，则解析器无法知道您是否需要它。

这是需求可以帮助的地方。 我们来看看HTTP Whiteboard模型吧 。 想要发布servlet的bundle需要导入servlet api包，但也需要表示它想要osgi http白板的实现。

这可以用namespace =“osgi.implementation”，name =“osgi.http”，version =“1.1.0”的要求来表示。 由于这很难手工编写，因此有一个注释支持。

@HttpWhiteboardServletPattern("/myservlet")
@Component(service = Servlet.class)
public class MyServlet extends HttpServlet {
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) 
            throws IOException {
        resp.getWriter().println("Hello");
    }
}

@HttpWhiteboardServletPattern注释间接转换为上述要求。

因此，当您使用此类构建一个bundle时，它将导入servlet api包，并且还需要一个http whiteboard实现。

现在，如果您查看像felix http服务这样的实现包，您将看到它提供了白板impl的功能。

因此，如果您有一个包含bundle，OSlet API和felix http服务的OSGi存储库。 然后解析器可以为您提供完整的应用程序，如果您只提供捆绑。