OSGi 声明式服务在运行时过滤引用 [英] OSGi Declarative services filter references at runtime

问题描述

我一直在尝试在 Karaf 上使用 OSGi 声明式服务(其中包括蓝图)的一些示例.我现在试图解决的问题是如何在运行时获取对某些服务的引用(因此注释和/或 XML 在这里并不是真正的选择)

I've been trying some examples with OSGi Declarative Services (among other things, such as Blueprint) on Karaf. The problem I am trying to solve now, is how to get references to certain services at runtime (so annotations and/or XML are not really an option here)

我将解释我的用例:

我正在尝试设计(到目前为止只是在我的脑海中，这就是为什么我仍然只尝试使用 OSGi :))一个系统来控制工业中的某些自动化过程.为了与设备通信，使用了一组特殊的协议.为了使组件尽可能可重用，我设计了一个基于层的通信模型(例如用于网络的 ISO/OSI 模型，但要简单得多)

I am trying to design (so far only in my head, that's why I am still only experimenting with OSGi :) ) a system to control certain automation processes in industry. To communicate with devices, a special set of protocols is being used. To make the components as reusable as possible, I designed a communication model based on layers (such as ISO/OSI model for networking, but much more simple)

为了将其转换为 OSGi，我系统的每一层都将由一组包组成.一个用于该层的接口，然后一个用于该层的每个实现的插件(将其想象为 OSI 传输层上的 TCP 与 UDP).

To transform this into OSGi, each layer of my system would be composed of a set of bundles. One for interfaces of that layer, and then one plugin for each implementation of that layer (imagine this as TCP vs. UDP on the Transport layer of OSI).

要引用此类网络中的任何设备，将使用自定义地址格式(此类地址的两个示例可以是 xpa://12.5/03FE 或 xpb://12.5/03FE).此类地址包含有关访问所请求设备所需的层及其值的所有信息.你可以猜到，这个地址的每一部分都代表了我的网络模型的一层.

To reference any device in such network, a custom address format will be used (two examples of such addresses can be xpa://12.5/03FE or xpb://12.5/03FE). Such address contains all information about layers and their values needed in order to access the requested device. As you can guess, each part of this address represents one layer of my networking model.

这些地址将存储在一些配置数据库中(因此，简单的 .cfg 或 .properties 文件不是一个选项)，以便它们可以在运行时远程更改.

These addresses will be stored in some configuration database (so, again, simple .cfg or .properties files are not an option) so that they can be changed at runtime remotely.

我正在考虑创建一个工厂，它将解析这个地址，并根据它的所有组件创建一个对象链(从 OSGi 获取适当的服务)，实现所有层并相应地配置它们.

I am thinking about creating a Factory, that will parse this address and, according to all its components, will create a chain of objects (get appropriate services from OSGi) that implement all layers and configure them accordingly.

由于单层可以有更多实现(因此，实现单个接口的服务更多)，因此该工厂需要在运行时(当它获取作为字符串传递的设备地址时)决定选择哪个特定实现(根据服务将声明的其他属性).

As there can be more implementations of a single layer (therefore, more services implementing a single interface), this factory will need to decide, at runtime (when it gets the device address passed as string), which particular implementation to choose (according to additional properties the services will declare).

这如何在 OSGi 中实现?哪种方法更适合这种情况，DS、蓝图或其他什么?

How could this be implemented in OSGi? What approach is better for this, DS, Blueprint or something else?

推荐答案

我意识到现在这是对这个问题的一个很晚的答案，但两个答案都忽略了对声明式服务中过滤的明显内置支持.

I realise that this is now a very late answer to this question, but both answers miss the obvious built-in support for filtering in Declarative Services.

可以使用@Reference 注释为 DS 引用定义目标过滤器:

A target filter can be defined for a DS reference using the @Reference annotation:

@Component
public class ExampleComponent {
    @Reference(target="(foo=bar)")
    MyService myService;
}

也可以使用配置添加(或覆盖)此目标过滤器.对于组件:

This target filter can also be added (or overriden) using configuration. For the component:

@Component(configurationPid="fizz.buzz")
public class ExampleComponent {
    @Reference
    MyService myService;
}

pid fizz.buzz 的配置字典然后可以使用键 myService.target 设置新过滤器.

A configuration dictionary for the pid fizz.buzz can then set a new filter using the key myService.target.

这是一个比跳到原始 OSGi API 更好的选择，并且已可用于多个规范版本.

This is a much better option than jumping down to the raw OSGi API, and has been available for several specification releases.

这篇关于OSGi 声明式服务在运行时过滤引用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！