Declarative Services中的服务引用

当某个Component依赖某一服务的时候，这个服务很有可能会被在任何时候注销，框架对这种情况只是做了简化处理，开发人员必须关心这个事情，做出相应的处理。

 

target services：写入到reference元素中的服务。这个时候Component configuration并没有真正引用这个服务。

bound service：被绑定到Component configuration的target services。

 

1、Accessing Services

Component实例取得bound service有两种方式：

（1）Event strategy

当你在reference元素中指定policy属性为dynamic时，也应该同时在reference元素中指定bind和unbind属性，这两个属性指定绑定和取消绑定的方法。

 

（2）Lookup strategy

Component实例可以通过ComponentContext的locateService方法获取bound service。

 

在实际使用中，两个方法可以用其一，也可以都使用。

如果使用Event strategy，bind和unbind指定的方法应该具有下面的形式：

1 void <method-name>(ServiceReference);
2 void <method-name>(<parameter-type>);
3 void <method-name>(<parameter-type>, Map);

 

如果bind和unbind方法具有第一种形式，ServiceReference参数将被传递给locateService(String,ServiceReference)方法，以获取bound service。如果需要在访问bound service之前检查service properties，这个方法是很有用的。Event strategy允许bound service的延迟激活。

 

如果是第二种形式，则bound service的实例对象直接被传递给方法。

 

如果是第三种形式，则bound service的实例对象直接被传递给方法作为第一个参数，第二个参数Map包含了bound service的properties，并且这个Map是不能修改的。

 

对于每一个bound service，bind和unbind方法必须要被调用一次。这意味着如果Reference元素中的基数属性指定是N多个的，那么这两个方法可能会被调用很多次。

 

例如，一个Component需要调用Log Service，并且使用Lookup strategy，那么Reference元素就无须指定bind和unbind方法。

<?xml version="1.0" encoding="UTF-8"?>
<scr:component name="example.listen"
xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0">
<implementation class="com.acme.LogLookupImpl"/>
<reference name="LOG"
interface="org.osgi.service.log.LogService"/>
</scr:component>

 

Component的实现类必须去搜索服务，如下：

public class LogLookupImpl {
private void activate(ComponentContext ctxt) {
LogService log = (LogService)
ctxt.locateService("LOG");
log.log(LogService.LOG_INFO, "Hello Components!"));
}
}

 

 

另一种方法是使用Event strategy，如下：

<?xml version="1.0" encoding="UTF-8"?>
<scr:component name="example.listen"
xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0">
<implementation class="com.acme.LogEventImpl"/>
<reference name="LOG"
interface="org.osgi.service.log.LogService"
bind="setLog"
unbind="unsetLog"
/>
</scr:component>

Component的实现类，如下：

public class LogEventImpl {
private LogService log;
private void setLog( LogService l ) { log = l; }
private void unsetLog( LogService l ) { log = null; }
private void activate() {
log.log(LogService.LOG_INFO, "Hello Components!"));
}
}

 

 

2、Reference Cardinality

一个Component通常要指定引用服务的基数范围，这个基数有两方面的意思：

（1）Multiplicity（多重，多个）

例如，一个Component只需要使用到一个Log Service就可以了。但是，当the Configuration Admin使用Configuration Listener services时，它必须绑定所有在服务注册表里的此类服务，只有这样，它才可以正确分发事件。

 

（2）Optionality（可选择的）

如果bound service不存在，Component也可以正常工作吗？对于有些来说，这是可以的，但有些就不行，比如，有个程序存在一个Servlet，但是如果Http Service如果不存在，显然它是无法正常工作的。

 

cardinality可以被指定成下面四种：

• 0..1 – Optional and unary.（0个或1个）
• 1..1 – Mandatory and unary (Default) （强制必须有一个）
• 0..n – Optional and multiple.（0个或多个）
• 1..n – Mandatory and multiple.（1个或多个）

 

对于2和4两种情况，当激活Component Configuration时，必须至少存在一个可以引用的bound service。

如果cardinality只指定最多1个，但是存在多个target service情况，那么Component Configuration将去绑定某个service.ranking值最大的target service，如果service.ranking也一样，那么就去比较service.id（启动号），谁最低，就绑定谁（谁先启动先绑定谁）。

 

 

 

3、Reference Policy

如果Component的所有references都已具备，Component Configuration可以被激活并绑定这些服务。但是，OSGI的动态性可能会使得某个被绑定的target service已经又被修改、注册或者取消注册了，因此，Component应该指定一个策略来处理这些变化。

 

static策略是最简单的策略也是默认的策略。如果有一个target service可以去替换一个失效的target service，那么Component Configuration应该要被重新激活并绑定到替代的target service。如果Component引用的服务频繁地取笑注册和重新注册，或者激活和取笑激活一个Component Configuration花销很大，static策略的的开销将是很大的。如果cardinality指定的是多个services，static策略是不适用的。

 

dynamic策略就有点复杂了，因为Component必须正确处理变化。SCR可以修改bound services的设置而无须注销Component Configuration，如果Component使用event strategy访问服务，那么通过bind和unbind方法，Component实例将会被通知到bound service的变化。

 

像前面注册资源的例子，使用的是static策略，这表明如果Http Services的设置有所改变，那么Component Configuration必须要被注销。

 

选择Target Services

 

Circular References

最好不要去循环引用，即ComponentA和ComponentB不要互相引用。

评论

1 楼 李嘉铭 2015-03-16  

你知道 Component可以当注解使用吗？像这样@Component(service=HTTPService.class,name="respon")？