OSGI框架初探

首先让我们来查看OSGI的框架图：

                                    

除去OS Hardware和JVM，还有Class Loading(类加载)、Life Cycle(生命周期管理)、Service Registery(服务注册)、Service(规范服务)、Security(安全层)。

     Class Loading(类加载机制)：Bundle的运行主要依靠于OSGi 框架为其创建的类加载器（Class Loader），加载器负责查找和加载 Bundle 自身或所依赖的类资源。Class Loader 能加载的所有类的集合构成了 Bundle 的类空间 (Class Space) 。类空间包含的类资源主要来自于以下几个方面：

1. 父 Class Loader 可加载的类集合；
2. Import-Package 定义的依赖的包；
3. Require-Bundle 定义的依赖的 Bundle 的类集合；
4. Bundle 自身的类集合，通常在 Bundle-Classpath 中定义；
5. 隶属于 Bundle 的 Fragment 类集合。

在实际运行环境中，Bundle 的 Class Loader 根据如下规则去搜索类资源。规则简要介绍如下：

1. 如类资源属于 java.* 包，则将加载请求委托给父加载器；
2. 如类资源定义在 OSGi 框架中启动委托列表（org.osgi.framework.bootdelegation）中，则将加载请求委托给父加载器；
3. 如类资源属于在 Import-Package 中定义的包，则框架通过 Class Loader 依赖关系图找到导出此包的 Bundle 的 Class Loader，并将加载请求委托给此 Class Loader ；
4. 如类资源属于在 Require-Bundle 中定义的 Bundle，则框架通过 Class Loader 依赖关系图找到此 Bundle 的 Class Loader，将加载请求委托给此 Class Loader ；
5. Bundle 搜索自己的类资源 ( 包括 Bundle-Classpath 里面定义的类路径和属于 Bundle 的 Fragment 的类资源）；
6. 若类在 DynamicImport-Package 中定义，则开始尝试在运行环境中寻找符合条件的 Bundle 。

如果在经过上面一系列步骤后，仍然没有正确地加载到类资源，则 OSGi 框架会向外抛出类未 发现异常。

  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 添加了完整的动态管理权限的机制。