OSGI Buleprint(4)

原创作品，允许转载，转载时请务必以超链接形式标明文章  原始出处 、作者信息和本声明。否则将追究法律责任。 http://killko.blog.51cto.com/3419292/1151440

    上一篇提及了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节点来达到这样的目的。

 

 

  
  
<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>。

本文出自 “色声香味触法” 博客，请务必保留此出处http://killko.blog.51cto.com/3419292/1151440