我使用OSGi蓝图已有两年了，对此我感到很满意。 蓝图是Apache Karaf内部最明显的选择，并且由于它通常是一种运行良好的解决方案，所以我不需要寻找替代方案。
今年早些时候，我有机会观看了Scott England Sulivan的演讲，其中包括一个使用OSGi声明式服务的小项目的演示，使我认为我应该开始更深入地研究OSGi声明式服务 。
因此，这里有一些关于OSGi中依赖项注入/管理的两种不同方法的想法。
蓝图
蓝图是OSGi的依赖项注入解决方案。 它与Spring框架几乎完全相同，但对OSGi服务提供了额外的支持（实际上，它是受Spring框架的启发） 。 它与Spring的相似之处使其使用起来非常简单，特别是如果您已经熟悉Spring。
蓝图为您处理OSGi服务注入，同时考虑了服务的可用性。 当使用被认为是可选的服务时，将创建并注入该服务的代理。 对该服务的调用将一直阻塞，直到该服务可用或超时为止。
声明式服务
声明式服务是一个组件模型，它简化了发布或使用OSGi服务的组件的创建。 我不认为Declarative Services是依赖注入解决方案，因为它更像是具有依赖管理功能的组件模型。
在声明式服务中，您以声明性方式和框架定义组件及其依赖关系，它将基于是否满足其依赖关系来管理组件的生命周期。 这意味着仅当满足所有依赖关系时，组件才会被激活，而当依赖关系消失时，组件将被停用。 因此，它100％没有代理，但仍保证只要一个组件处于活动状态，它的内部依赖关系就可以实现。
代理与级联
所讨论的两种方法之间的主要区别之一是，Blueprint使用代理，而声明式服务则使用级联方法（根据依赖关系可用性激活/停用组件） 。 我倾向于使用级联而不是代理（不仅是因为代理不流行，而是…） ，主要是因为使用代理时，您不知道底层对象的状态/可用性是什么。 另一方面，级联似乎更适合OSGi内部，因为它可以更好地处理框架的动态特性。
代理引起头部疼痛的典型情况是，您需要使用参考侦听器进行可选服务。 如果您需要在服务对象消失（解除绑定）时对其做出反应，它将失败。
代理的另一个问题是，它们将允许您发布依赖关系尚未得到满足的服务。 调用该服务可能最终会挂起，因为代理正在等待不满意的依赖关系变得可用。 这可以防止您快速失败，而无法快速失败甚至会损害您的整个系统（如果不那么明显，为什么您可能想读一本优秀的书Release It！ ） 。
一个例子
让我们使用一个接近真实的示例来仔细研究上述方法。 假设我们正在为Items构建一个简单的CRUD Web应用程序。
该应用程序可以由以下部分组成：
- 表示层
- 项目服务
- 数据存储
- 数据库
在OSGi中，表示层可以是在Http服务中注册的servlet，项目服务可以是封装逻辑的OSGi服务，而DataStore也可以是可用于与数据库交互的OSGi服务。
如上图所示，Web应用程序取决于项目服务，而项目服务取决于数据存储。
如果数据存储未配置或不可用，会发生什么？
代理：
使用代理方法，项目服务将被注入到数据存储的代理，如果数据存储不可用，该代理将阻塞。 项目服务将被注册到服务注册表，并且即使没有数据存储，Web应用程序也会尝试使用它。 对Web应用程序的请求可能最终被阻塞，等待数据存储（这是不理想的） 。
级联：
使用级联方法时，仅在存在数据存储时才注册项目服务。 以相同的方式，仅当项目服务可用时，Web应用程序才可用。 因此，我们保证，如果满足层次结构中的所有依赖关系，则Web应用程序将可用。 在存在不令人满意的依赖关系时发出的请求将导致HTTP 404错误，从而产生“快速失败”的行为。 请注意，只要数据存储可用，项目服务和Web应用程序都将自动检测到更改，并且自身也将变为可用。
最后的想法
声明式服务是管理组件依赖关系的好工具。 级联方法可能是构建健壮的动态模块化应用程序的宝贵工具。
蓝图确实非常易于使用，并且熟悉Spring的用户会觉得很自然。 在某些情况下，代理行为也可能有用。
那么什么时候使用其中一个？
我倾向于认为，在构建没有服务依赖项或没有将自身公开为服务的组件的情况下，Blueprint会大放异彩。 另一种情况是“等待服务”更为自然。 这样的例子可以是：
- shell命令（通常，其他组件不将其用作服务）
- 骆驼路线（需要等待依赖）
在依赖链较长的情况下，组件是高度动态的等，我认为声明式服务是更好的选择。
无论您选择哪种方式，都需要了解工具的优缺点！
我希望这会有所帮助！
1530
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
