上一篇提及了OSGI service的发布和引用,在 Blueprint里,服务的发布和引用是最常用的一种 最佳实践,通过借助服务引用这样松散的藕合方 法,可以让OSGI的动态性发挥得淋漓尽致。
一些较低层的,细粒度的服务引用可以注入到 bean里,再将这个bean发布出更高层次的,粗粒 度的服务,而Blueprint container将会通过监听 来自OSGI framework的事件,跟踪这些服务的可 用性,当某服务mandatory地依赖那些失去可用 性的服务时,它也将会被Blueprint container从 OSGI framework上撤下来。而当这些被依赖服务 恢复可用时,上层的服务又会被重新发布出来。 从这个角度来看,OSGI也是一个SOA的实现。
这样的动态组装的服务使得提供服务的bundle不 再需要关注启动的次序(start level)了,而这恰 恰是很多习惯直接写代码的方式(例如用 servicelistener或servicetracker来组装服务)的 朋友经常考虑的问题,用了Blueprint就基本上不 必考虑了。
当我们需要引用多个实现同一接口的OSGI service(没有这样的需求?请参考OSGI的 whiteboard pattern)时,Blueprint还提供了 reference-list节点来达到这样的目的。
相应地在引用这个服务列表的bean的类的代码 里,应包含一个list<com.ponder.ICoder>的 setter方法,在Blueprint container发现有此接口 的服务就会用这个setter方法注入到这个bean实 例里。由于服务的动态性,这个list里的服务个数 也是动态变化的。另外,以上节点的member-type属性还可以设为”service-reference”,那么相 应的setter就应是注入list<ServiceReference>。
一些较低层的,细粒度的服务引用可以注入到 bean里,再将这个bean发布出更高层次的,粗粒 度的服务,而Blueprint container将会通过监听 来自OSGI framework的事件,跟踪这些服务的可 用性,当某服务mandatory地依赖那些失去可用 性的服务时,它也将会被Blueprint container从 OSGI framework上撤下来。而当这些被依赖服务 恢复可用时,上层的服务又会被重新发布出来。 从这个角度来看,OSGI也是一个SOA的实现。
这样的动态组装的服务使得提供服务的bundle不 再需要关注启动的次序(start level)了,而这恰 恰是很多习惯直接写代码的方式(例如用 servicelistener或servicetracker来组装服务)的 朋友经常考虑的问题,用了Blueprint就基本上不 必考虑了。
当我们需要引用多个实现同一接口的OSGI service(没有这样的需求?请参考OSGI的 whiteboard pattern)时,Blueprint还提供了 reference-list节点来达到这样的目的。
- <reference-list id=”RefList1” interface=”com.ponder.ICoder” member-type=”service-object”/>
<reference-list id=”RefList1” interface=”com.ponder.ICoder” member-type=”service-object”/>
相应地在引用这个服务列表的bean的类的代码 里,应包含一个list<com.ponder.ICoder>的 setter方法,在Blueprint container发现有此接口 的服务就会用这个setter方法注入到这个bean实 例里。由于服务的动态性,这个list里的服务个数 也是动态变化的。另外,以上节点的member-type属性还可以设为”service-reference”,那么相 应的setter就应是注入list<ServiceReference>。