服务模型vs Extender模型？

Question

我刚完成彻底检查Apache Felix Application Demonstration形状。文章状态：

当创建一个基于OSGi的应用主要有两个正交 问题需要考虑：

1. 服务模式与扩展模式
2. 捆绑的应用程序和托管框架

第一个问题实际上是创建基于OSGi的 应用程序时的一个普遍问题。当创建可扩展的OSGi应用程序时，可以使用两种通用方法。服务模型方法 使用OSGi服务概念和服务注册表作为 可扩展性机制。扩展模型方法使用OSGi 已安装的捆绑集作为可扩展性机制。两种方法 都有它们的优点和缺点，并且它们可以独立地或一起使用 。

我认为这是一个普遍接受的最佳实践，关于第二点，更喜欢捆绑的应用程序，除非有一个真正的理由，您被迫使用托管框架。

关于第一点，在研究了服务模型和扩展模型之后，我理解了它们之间的区别，但我仍然试图找出不同模型的优缺点。

每个模型（Service vs Extender）的优点和缺点是什么？确定使用哪一个或什么时候使用两者的最佳实践有哪些？

Answer 1

服务更常用，它们通常应该是您的首选，除非您有充足的理由设计新的扩展器。

OSGi是一个面向服务的平台。服务API形成双方（消费者和提供者）之间的合同。合同是根据包含接口的Java包定义的，提供者通过实现这些接口来提供它。消费者使用服务注册表来查找想要使用的接口的实例。

扩展模式有点更灵活和抽象，但更难以理解和使用。本质上，扩展器软件包代表代表提供了其他一些软件包，它们通常通过包含某种声明来加入。

例如，假设您想为您的应用程序实现帮助系统。软件包可以简单地包含一些商定路径下的HTML文档，中央帮助系统软件包可以扫描软件包以查找这些文档并将它们添加到主帮助索引。用服务做这件事将会非常麻烦：假设你遵循“白板”风格，你将不得不用getHelpDocuments()方法定义一个HelpProvider Java接口;希望提供帮助的每个包都必须实现此接口并将其注册为服务。另一方面，帮助系统扩展器包必须相对聪明，因为它必须跟踪来来往往的包。但至少你只需要编写一次这个智能代码。是

扩展的现实生活中的例子如下：

• 声明式服务是一个扩展，看起来在其他包的Service-Component声明，并做各种东西代表他们 - 实例化的组件，出版服务等
• 蓝图是一种类似的扩展器。它寻找Bundle-Blueprint声明，或在约定的路径下的XML文件。
• OSGi企业规范定义了一个JPA扩展器，该扩展器查找包含由Meta-Persistence标头声明的persistence.xml文件的包。当它找到一个时，它为该捆绑创建一个持久单元。
• Eclipse包含用于创建诸如视图，透视图，菜单等的扩展器（令人困惑地称为扩展注册表）。这些都是在包的根目录中的plugin.xml文件中声明的。

总结...服务用于基于合同注册和查找对象。扩展器用于扩展bundle的功能，通常基于某种声明性资源或头部而不是可执行代码。

Answer 2

扩展模型主要用于框架。它需要深入研究捆绑impl来完成它的工作。所以它不适合松散耦合。其优点是它可以定义一个全新的抽象，如蓝图或声明式服务或cdi。所有这些框架都使用扩展模型来根据规范来连接你的bundle。

服务模型对您的应用程序本身来说是正确的。服务允许隐藏实现的细节以及来自服务用户的实例化。所以这对松耦合非常有用。

最后，两者通常一起使用。例如，您可以使用cdi注释来在您的套件内进行连接，并指定您提供并使用服务。因此，当您使用服务模型松散地连接您的包时，cdi框架利用扩展器在内部连线您的包。