OSGi模块之间的通信机制

OSGi在9012年，一直有鸡肋的说法。主要是其依赖JVM，导致硬件资源隔离困难，另外故障的跨模块影响也是问题。而在这个微服务的时代，使用分离的bundle来实现微服务，颇有杀鸡用牛刀的问题。但是也不可否认，对于中型要求高性能高吞吐量的架构，OSGi还是非常重要的。

OSGi的bundle通信有三种方式

Export-Package

根据OSGi规范，每个工程可以通过声明Exprot-Package对外提供访问此工程中的类和接口，可以先把bundle导出，再导入到需要调用的bundle中

OSGi服务

通过将要对外提供功能声明为OSGi的服务实现面向接口、面向服务式的设计；

package osgitut.movies.impl;
 
import org.osgi.framework.*;
 
import osgitut.movies.*;
import java.util.Properties;
import java.util.Dictionary;
 
public class BasicMovieFinderActivator implements BundleActivator {
    private ServiceRegistration registration;
 
    public void start(BundleContext context) {
        MovieFinder finder = new BasicMovieFinderImpl();
 
        Dictionary props = new Properties();
        props.put("category", "misc");
 
        registration = context.registerService(
                               MovieFinder.class.getName(),
                               finder, props);
    }
 
    public void stop(BundleContext context) {
        registration.unregister();
    }
}

下面转载自
https://www.iteye.com/blog/superseven-1758359

Life Cycle(生命周期管理)：用于动态管理Bundle的生命周期，可以动态安装、启动、停止、更新和卸载这些Bundle。Bundle依赖于模块层的CLASS载入但是添加了为运行时管理的API。生命周期管理层引入了应用程序通常不具有的动态性。有扩展的依赖机制用来保证环境的正确运行。

Service Registery(服务注册)：服务注册表为bundles的动态特征提供了协作模型。Bundles之间可以使用传统的类共享机制实现协作，但是类共享机制对于动态安装和卸载的模块来说无法提供一致性，因此服务注册表为bundles之间共享对象提供了一致的模型。许多服务与服务器端对象相似，如Http服务器，其他的服务代表这真是世界中的一个对象，例如身边的蓝牙电话。这个服务模块提供了完整安全保障。该服务安全模块使用了一个很聪明的方式来保障bundles之间通信安全。

Service(规范服务)：服务层定义了一个动态的协作模型，服务模型是定义在模块（bundle）的基础上的。Bundle可以动态的发布，查找service，并且当该服务的状态（生命周期）改变时，更够发出通知，这样所有对该service关心的bundle，可以通过注册监听器的方式，接收消息，做后续的处理。

在OSGi平台中，各个模块（bundle）可以提供服务，并且可以引用其他的服务，而这些服务都有统一的管理注册中心（ServiceRegistry），该注册中心由框架提供，运行在框架之上的。

这样的一些服务都是归bundle所有并且运行在它的bundle上的；所以可以通过bundle的bundlecontext把这些服务注册在ServiceRegistry中，以便能够由框架统一管理，并且能够被其他的bundle所引用。这样当bundle的生命周期发生变化的时候，如stop，那么就能够通过框架，来自动的卸载提供的服务，并且解决好bundle之间的服务引用依赖关系。

服务对象serviceobject，类似与pojo，调用它的接口，可以提供服务。这样的一个serviceobject可以实现ServiceFactory接口，也可以实现其他的接口。如果实现了ServiceFactory，那么对于每一个bundle对服务的引用来说，都是一个通过ServiceFactory创建新的实例。否则所引用的服务对象就是通过bundlecontext注册的绑定在ServiceRegistration 的原始对象。

ServiceReference类似于服务对象的句柄，通过它可以查找到真实的服务对象。其实它只是包含了对对象的描述，如该服务是位于哪一个bundle上的，该服务的bundle是否已经停 止，以及服务的描述等等。

对于引用该服务的bundle来说，只是保存的service的句柄，真实的service对象可以不存在，这样的模式被广泛应用在动态的环境中。
ServiceListener可以通过BundleContext注册在框价ServiceRegistry中，这样在服务的生命周期改变时候，可以接收消息，每个bundle可以在自己的lisitener里，做出相应的处理，如释放响应的资源等等。
BundleContext提供了注册服务，注册服务，框架，bundle的监听器，查找服务的统一入口。

Security(安全层)：安全机制是基于Java 和Java2的安全模型，这个语言的设计减少很多可能的安全漏洞，比如，病毒使用缓冲区溢出就不可能了。访问限制使得对其他程序员代码的可视性受到了限制。OSGi通过私有的class扩从了这个模型。一个在标准Java环境里面无法达到的机制。Java2 安全模型提供了一种合理的模型来检查代码和资源的访问。OSGi 添加了完整的动态管理权限的机制。

Event

基于OSGi的Event服务也是实现模块交互的一种可选方法，模块对外发布事件，订阅了此事件的模块就会相应地接收到消息，从而做出反应，以达到交互的目的。