OSGI Blueprint入门之十

 在传统的Ioc容器里，對象的生命周期一般为静态的，在初始化时创建后，就不会在运行期间撤下或替换。

在Blueprint容器中，可以引入OSGI服务引用，而OSGI服务是动态存在的，也就是说随时有可能由不可用变为可用或由可用变为不可用。

我们可以将一个bean发布出一个osgi服务，然后将这个服务的引用(reference)再注入另一个bean中，这个bean又可以再基于这个服务引用来实现并发布更高层次的服务……这样就可以一级级地装配出粗粒度的服务出来。

当在下层的服务被撤走时，上层强制依赖于它的服务也会被撤下，而下层服务再次恢复时，上层的服务又会快速地恢复，blueprint就是这样动态地装配这些服务。这种动态性可以得出一个推论:如果你能访问到上层服务，那么这个服务中依赖的下层服务的引用就不会为null,所以，用这种方式组装的应用就不会因OSGI的动态性而常抛出异常。

但是osgi服务始终只是个本地服务(暂抛开osgi remote service而言)，需要提供给一些外部应用系统调用，才能发挥作用。

所以，要么你将应用建筑在blueprint容器里，通过将服务引用注入的方式使用这些osgi服务。要么你就在外部应用系统中引用blueprint的context，通过此context来查找并调用这些osgi服务，还有一种方式就是:blueprint容器在发布osgi服务的同时，也将这个服务注册到jndi registry上，外部应用系统就可以通过jndi来查找并调用这些osgi服务。

后面两种方式都脱离了DI的方式，不能确保服务在被调用时是可用的。而第一种方式则依然在DI的框架内，如果它调用服务，服务就是可用的，如果服务不可用，那么它也没机会去调用下层服务——因为那时连它自已也还没组装起来。