服务模型与Extender模型？

Question

我刚刚用形状彻底审查Apache Felix Application Demonstration。文章指出：

  

创建基于OSGi的应用程序时，有两个主要的正交   需要考虑的问题：

     

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

第一个问题实际上是创建基于OSGi的一般问题   应用。有两种常用方法可供使用   创建可扩展的OSGi应用程序。服务模式方法   使用OSGi服务概念和服务注册表作为   可扩展性机制。扩展器模型方法使用OSGi   安装捆绑设置为可扩展性机制。两种方法   有它们的优点和缺点，它们可以使用   独立或一起。

我认为这是一个普遍接受的最佳做法，关于第二点，更喜欢捆绑的应用程序，除非出于一个非常好的理由，你被迫使用托管框架。

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

每种型号（服务与扩展器）的优缺点是什么？确定使用哪种型号或何时适合使用两种型号的最佳做法是什么？

Answer 1

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

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

扩展器模式更灵活，更抽象，但理解和使用更复杂。从本质上讲，扩展程序包代表其他一些程序包提供了附加功能，这些程序包通常通过包含某种声明来选择。

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

扩展器的现实例子如下：

• 声明性服务是一种扩展器，可以在其他捆绑包中查找Service-Component声明，并代表他们执行各种操作 - 实例化组件，发布服务等。
• 蓝图是一种类似的扩展器。它在商定的路径下查找Bundle-Blueprint声明或XML文件。
• OSGi企业规范定义了一个JPA扩展程序，用于查找包含persistence.xml标头声明的Meta-Persistence文件的包。当它找到一个时，它会为该包创建一个持久性单元。
• Eclipse包含一个扩展器（混淆地称为扩展注册表），用于创建视图，透视图，菜单等内容。这些都在包的根目录中的plugin.xml文件中声明。

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

Answer 2

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

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

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