0

在我们的OSGi系统设计中，我们有一个重复的场景，其中一个服务想要对已部署服务的子集应用一些特定的处理（“处理”）。在简单的情况下，我们会让目标服务分配一些服务属性以指示他们想要特殊处理，然后让处理服务找到它们的白板样式。

但是，当决定哪些服务子集作为目标的算法需要用Java逻辑实现并且不容易用包本身设置的静态属性表示时，如何最好地设计呢？

此外，如果我们有多个处理服务想要重用相同的服务目标，理想情况下，选择算法应该在其自己的服务中实现。我们称之为SelectService，并说它具有动态识别“abc”和“xyz”类别服务的逻辑。

我可以想到这些主要的替代方案来解决这个问题，也许还有更多？

  1. 让我们SelectService检查部署的服务，然后在适用时以某种方式（如何？）在它们上设置属性“abc”和“xyz”。然后治疗服务可以使用ServiceTracker带有属性过滤器的标准来找到他们想要的服务。

  2. 让SelectService提供方法getAbcServices()并getXyzServices()返回一些ServiceTracker类似的对象。治疗服务可以调用这些方法来寻找目标服务。

  3. 让处理服务在服务注册表中声明一些东西（服务接口或服务属性）来表达对服务选择的兴趣。SelectService然后找到这些愿望白板样式并通知治疗服务有关选择。

  4. 这是在系统中思考的错误方式OSGi，您甚至不应该这样做:-)

编辑1：

总结一下这个场景，你可以说它类似于声明式服务或蓝图等扩展服务：

targeted  <-->  extender
service         service

此外，扩展器服务分为两部分/层，以便重用选择逻辑：

targeted        extender         extender
service   <-->  service    <-->  service
                treatment   **   selection
                logic            logic

有趣的部分是处理和选择逻辑之间的 API (**)，因为它提到了其他服务，并且还需要一些添加/删除事件机制。为了便于理解，还希望尽可能多地使用标准 OSGi 模式和支持功能。

[Meta：将讨论划分为一个答案线程（答案+评论）可能会更好吗？]

4

2 回答 2

0

你可以看看服务代理。使用 OSGi 服务挂钩，您可以有选择地隐藏服务并注册代理。这个模型允许你做几乎任何事情，而这些服务的消费者仍然对正在发生的事情一无所知。

soapbox { 也就是说，总的来说，我会尽量保持简单。尽管作者认为这些“扩展”中的许多对于一些简单的工作非常有用，但随着时间的推移，它们往往会成为瓶颈。缺乏大量文档并且随着时间的推移通常没有所需的功能，这使得它们成为未来开发人员的 PITA。

我见过很多系统变得非常复杂，不是因为他们的领域，而是因为随着时间的推移，太多的开发人员添加了他们自己的中间件以试图减少他们自己的工作量，即自己造成的复杂性。有时，一些冗余更容易理解/维护。 }

于 2013-06-13T07:18:56.083 回答
0

如果您需要对服务进行“动态”或编程过滤，则需要使用静态过滤器来接收所有可能被选中的服务。最简单的这种过滤器是空过滤器，它只接收正确类型的所有服务。

例如使用声明式服务实现：

@Reference(multiple = true, dynamic = true, optional = true)
public void addFooService(Foo foo, Map<String, Object> serviceProps) {
    // TODO: implement logic here to read serviceProps. Return early from
    // this method if the service doesn't match your dynamic criteria.
}
public void removeFooService(Foo foo, Map<String, Object> serviceProps) {
    // Be careful here, you will get services back that you didn't care about in the
    // 'add' method.
}

现在解决问题的第二部分......将选择逻辑本身变成服务是一个有趣的想法，但它会让你的生活变得复杂。我主要关心的是：如果SelectService动态更改会发生什么？我将不得不根据新的选择算法重新过滤整套服务。在出现之前会发生什么SelectService......我是否看到所有服务都未经过滤？还是零服务？ETC

关于你是否走在正确的道路上的最后一个问题......很难说对真正的用例没有任何想法。但是，我认为您可能使事情变得比需要的更复杂。例如，也许您不应该拥有这么多相同类型的服务？也许您应该将它们划分为多种类型？

作为在许多客户端中复制选择逻辑或将其拉入选择服务的替代方案，为什么不创建一个实现选择逻辑的单个组件，然后基于聚合集提供一些更高级别或包装功能？

于 2013-06-12T22:28:49.863 回答