OSGi规范介绍
第一章 引言
OSGi（Open Service Gateway Initiative）最初的目的就是为各种嵌入式设备提供通用的软件运行平台，即可以屏蔽设备操作系统与硬件区别的中间件平台。PC基本上被 Wintel架构垄断，运行在PC上的应用程序完全可以在另一台PC上运行；但对于其他设备来说就不同，它们的硬件平台可能完全不同，其操作系统也是来自不同厂商，所以任何设备上的应用程序都需要定制，于是就产生了对中间件平台的需求。
OSGi并不是专为家庭网络而制定的，除了住宅网关，像车载电脑等其他移动嵌入式设备也都可以通过OSGi接入Internet，获取不同的应用服务。它为服务供应商、软件供应商、网关开发人员以及设备供应商提供了一个开放、通用的架构，使它们能互动地开发、部署和管理服务。其软件环境基于Sun的 JAVA虚拟机，并不涉及具体的连接协议。对于任何新设备，它都能够灵活地将其纳入现有网络。可以使用OSGi的对象包括各种数字和模拟的机顶盒、服务网关、有线电视电缆调制解调器、消费类电子产品、PC、工业计算机、汽车等。
因为OSGi基于JAVA技术，而JAVA最大的好处就是平台无关性。在不同类型的住宅网关设备上都可以实现OSGi软件。而且OSGi规范可以与各种设备访问标准桥接（如图1所示），比如遵循OSGi的系统可以很好地部署和管理Jini服务，它可以提供Jini设备与服务提供商之间的交互。对于像 HAVi、UPnP等基于非JAVA技术的标准和规范，OSGi也可以提供与它们沟通的桥梁。
第二章 OSGi规范介绍
2.1 OSGi规范的体系结构
在OSGi规范中提供了一个参考的体系架构[1]，也基本上体现了OSGi的设计初衷。
OSGi的体系架构是基于这样一个模型的：经营者管理着一个潜在的巨大的服务网络平台。OSGi规范假设这个服务平台是完全被这个经营者控制，并且经营者使用该服务平台去运行来自不同服务提供者提供的服务。然而这只是一个场景，还有其他模型，例如PC机的部署，工业应用（如，移动电话基站是一个管理中心完全控制着各个方面），中间件模型等。OSGi最广泛的应用是在网络化的服务。除了参考模型之外，规范之中还提到了其他的一些模型。请参考OSGi 3.0规范[1]。
2.1.1 OSGi参考体系架构的特点
1． 商业驱动：经营者的观点驱动OSGi的体系架构。
2． 完美：体系架构必须是足够完善和详细的，以致允许开发商生产出健壮的产品。
3． 不受限的：由于经营者所操作的服务平台在性能和网络环境的变化是非常大的。
4． 开放：标准不是为一个具体的系统而设计的，OSGi参考体系架构必须考虑和支持许多不同的场景。
2.1.2 OSGi参考体系架构所涉及到实体
1. 服务平台：一个JAVA虚拟机的实例，一个OSGi框架结构，和运行着的服务包的集合。
2. 服务平台服务器(SPS)：驻留一个或多个服务平台的硬件。
3. 运营商：掌控许多服务平台的组织。
4. 服务应用：一套软件包，文档和支撑软件所组合起来的应用，这些应用向终端用户提供服务。
5. 服务用户：获取服务应用服务的用户。
6. 服务提供者：开发服务应用并且通过服务部署管理器部署到服务平台上。
7. 服务部署管理器：部署和部分管理一个或多个服务提供者提供的服务应用。
8. 服务运行支持：支撑软件和硬件，它们并不驻留在服务平台服务器上，但是在运行服务应用时需要它们。
9. 服务集成者：负责确保来自不同服务提供者的服务应用的集成。
10. 服务开发者：开发服务应用。
11. 制造商：制造服务平台服务器
12. 拥有者：服务平台服务器拥有者。
13. 收费提供者：接受帐户信息，并且提供统一的帐单给服务消费者。
14. 网络提供者：提供服务平台的网络链接。
15. 证书授权：管理证书的组织，这些证书被用来鉴别系统，个人和组织。
首先是制造商制造服务平台服务器，拥有者从制造商处购买服务平台服务器，网络提供商提供服务平台服务器和互联网的接入。服务平台的运营商使用网路提供者的接入基础件接入服务平台服务器，同时服务平台经营者控制着一个或多个运行在服务平台服务器的服务平台。另一方面，服务平台经营者许可服务部署管理器去部署服务应用到服务平台上。
其次服务开发者开发服务应用，一个服务应用可能包含多个服务包而这些服务包是真正运行在服务平台上的。服务提供者从服务开发者处得到服务应用并且可能会委托服务运行支撑系统去支撑该服务应用在服务平台上的运行。服务集成者将服务提供者获取的服务应用和支持系统集成起来由服务部署管理器部署到服务平台上。
最后服务消费者订阅服务提供者提供的服务。
更有意思的是这里还有一个服务用户实体，从图中可以看出服务消费者可以包含多个服务用户，服务用户是真正接受服务的实体。也就是说服务消费者是一个虚的实体，多个服务用户可以消费同一个服务消费者订阅的服务。这好比不同的人可以通过同一个电话打电话一样。这无疑提高了OSGi规范灵活性。
OSGi基本概念初探
1、OSGi是什么
OSGi是什么，OSGi是一种松散耦合的组件管理和服务运行平台规范。简单的说，用户只需要修改通用的Java类库打包档案JAR文件中META-INF下的元数据文件MANIFEST.MF，添加必要的标签信息，放置到OSGi框架的Bundle Repository中，用户的类库就成了OSGi环境的一部分。
成为OSGi环境的组件为其他标准的OSGi组件提供代码功能是最直接的一种。用户也可以将提供组件中的某种功能的接口和实现实例发布到OSGi服务注册表中，供其他组件直接查找使用。同样，用户可以查找OSGi环境中其他组件提供的接口服务，调用该服务完成必要的处理。
OSGi组件提供的服务具有两个层面的含义：系统层面，即一个组件为其他组件提供服务，这些服务体现为Java接口的实现；业务层面，即一个组件为外部系统或用户提供某种业务服务实现。
2、OSGi提供的功能
OSGi能够提供什么功能呢？我们将OSGi运行平台与常用的Web应用服务服务器做一个比较，来看OSGi提供的功能。首先，以tomcat为例，在tomcat容器中可以运行多个Web应用，假设存在两个Web应用A和Web应用B，一般说来，Web应用A和B具有各自的运行空间，两者之间不存在任何关联，A和B具有自己独立的生命周期，如部署、启动、停止和卸载等。
那么，是如何做到这一点的呢？很明显，这是通过JVM的类加载机制决定的。当tomcat运行并启动Web应用A和B时，tomcat为Web应用A和B各自构建了一个类空间，也可以看作是一个类域（Class Domain），Web应用A的类域包括JRE中的类，tomcat启动类路径上的类和Web应用A中WEB-INF目录下classes目录下的类和lib中的jar包；同样，Web应用B也有自己独立的类域，其范围除了JRE中的类，tomcat启动类路径上的类之外就是自己内部WEB-INF目录下classes目录下的类和lib中的jar包。如下图所示：
现在提出一个问题，如果Web应用A需要使用Web应用B提供的Java类，怎么办？实现方式有多种，一种是将B提供的类打包，放置到应用A的WEB-INF/classes或WEB-INF/lib中；也可以将B提供的类放置到tomcat的类路径上，甚至是JRE的扩展目录下，但这样做在实际使用中或多或少存在一些问题。能不能在运行时Web应用A可以直接使用Web应用B提供的类呢？在运行时Web应用B能不能提供一个接口的实现，即类实例，由Web应用A使用呢？能不能提供一个应用C为应用A和应用B提供服务呢？显然，这些对于Web容器是不行的。
带着上述问题我们回到OSGi运行平台。可以将OSGi看作是Web容器的泛化，是更高级别的抽象。运行在OSGi环境中的类似于Web容器中的Web应用的组件即Bundle，不再仅仅局限于一个业务应用的概念，它的粒度更加精细，即可以看作是一个Jar包，为其他Bundle提供帮助类；也可以是一个HTTP服务组件，为其他Bundle提供http服务；还可以是一个Web容器，为其他Bundle提供Web应用服务。
那么，能不能解决上述提到的问题呢？我们假设在OSGi运行平台中包含了3个Bundle：A、B和C。
· 对于问题一：Bundle A需要使用Bundle B中的某些实现类，如何实现？
可以将Bundle B中的这些类通过Bundle B的元数据描述信息公开（Export）出去，使得这些类对OSGi平台中的所有Bundle可见，这些类资源仍然位于Bundle B中。Bundle A在其元数据描述信息中将Bundle B公开的类引入（Import）进来。在运行时，Bundle A就可以使用Bundle B提供的这些类，而不是需要将这些类拷贝到Bundle A中或其他位置。
· 对于问题二：Bundle A可不可以直接使用Bundle B在运行时构建了类实例？
Bundle B在运行时可以将Bundle A需要的类实例注册到OSGi运行平台的服务注册表中，类实例实现的接口可以通过上述问题一的方式使得Bundle A可见，那么，在运行时，Bundle A就可以通过该接口到OSGi平台服务注册表中查找Bundle B中提供的接口实现类实例，并调用该接口上的方法。
· 现在来看问题三：Bundle C能不能为Bundle A和Bundle B共享呢？
可以将上述问题二的解决方案中的Bundle B提供的接口定义提取到Bundle C中，并在Bundle C的元数据中公开，通过在Bundle A和Bundle B中同时引入Bundle C中发布的接口，Bundle B提供该接口的实现，Bundle A使用该接口实现提供的功能。这一切看上去是不是解决的非常完美呢？！
3、OSGi的实现机制
OSGi是如何实现的呢？从本质上说，OSGi是充分使用了Java的类加载机制，对模块和应用进行了更加精细粒度的控制，然后在类域上建立一系列松耦合应用。OSGi为每一个Bundle组件定义了一些元数据信息，通过这些元数据，OSGi在运行时为每一个Bundle构建了一个独立的类域（即类空间），详细描述参考OSGi之Bundle小节。
4、OSGi的组成
OSGi在R4种将功能分为几层，包括：安全层、模块层、生命周期层、服务层和实际的服务。OSGi的核心实现即为OSGi框架，它本身也是一个OSGi Bundle。
· OSGi的安全层（Security Layer）是一个可选的实现，该层基于Java2 安全架构，位于OSGi服务平台的底层对OSGi环境中应用的部署和管理提供更好的安全控制。
· OSGi的模块层（Module Layer）为基于Java的应用、组件的打包，部署和校验提供了一个通用的标准化的解决方案。其他类似的解决方案如JBoss、NetBeans。
· 生命周期层（Life Cycle Layer）为Bundle组件的安全和生命周期操作提供了API定义，该层位于安全层和模块层之上。
· 服务层（Service Layer）定义了一个与生命周期层紧密结合的组件动态交互模型。OSGi中的服务是实现了一个或多个Java接口的Java对象，通过将这些对象依据其实现的接口注册到服务注册表中，Bundle组件可以发布自己的服务，查找使用服务，注册监听处理服务的状态变更等。
· 实际的服务（Actual Services）是OSGi定义的一些标准的服务接口如日志服务（Log Service），包管理服务（Package Admin Service）、启动级别服务（Start Level Service）、HTTP服务（Http Service）、配置服务（Config Admin Service）、用户管理服务(User Admin Service)等等，详细的服务定义参考OSGi规范。
5、OSGi之Bundle
OSGi中的重要元素就是Bundle 和Service，Bundle提供了一种静态资源边界，类似于Web容器中的Web应用的概念。
每一个Bundle通过一个元数据文件（MANIFEST.MF）描述。OSGi框架（即SystemBundle）通过解析这个元数据文件对该Bundle进行加载和管理。Bundle通过元数据中的"Export-Package"属性将内部的类包发布给OSGi系统中其他Bundle使用，通过"Import-Package"，"Requie-Bundle"属性引用OSGi系统中其他Bundle发布的类包。
每一个Bundle有自己独立的类加载器（Fragment Bundle例外，其资源通过其Host Bundle加载），Bundle内部的资源（类，文件等）通过该类加载器查找和加载。Bundle的类加载器能够控制的类加载边界包括：启动类路径上的类资源，OSGi框架即SystemBundle上的类资源和Bundle内部的类资源。该类资源边界即形成该Bundle的类域。
每一个Bundle在OSGi框架中具有自己的生命周期，其生命周期内的状态包括：INSTALLED、RESOLVED、STARTING、ACTIVE、STOPPING和UNINSTALLED。
INSTALLED状态是Bundle的初始状态，当该Bundle部署到OSGi系统的Bundle Repository中时，Bundle的状态标记为INSTALLED。
Bundle内部的资源在加载之前，首先由OSGi框架对其进行解析（Resolve），解析的过程就是分析Bundle的元数据的过程，详细过程参考OSGi规范。解析后的Bundle进入RESOLVED状态，解析失败时，仍然处于INSTALLED状态。
Bundle内的资源被其它Bundle使用时，该Bundle被启动，也可以通过设定让OSGi框架在加载该Bundle时直接启动。
Bundle内的资源通过BundleContext与其他Bundle进行交互。元数据中的"Bundle-Activator"属性指定了实现BundleActivator接口的实现类，Bundle通过该类得到BundleContext，通过BundleContext可以查找其他的Bundle，查找注册在OSGi中的服务（Service）与OSGi环境进行交互等等。Bundle可以在其提供的BundleActivator实现类中进行初始化的工作，也可以注册服务到OSGi的服务注册表中，供其他Bundle查找使用。
6、开源的OSGi实现
Knopflerfish：http://www.knopflerfish.org
Oscar：http://oscar.objectweb.org
Equinox：http://www.eclipse.org/equinox