OSGi简介
这两天在研究Kotlin时，看到Kotlin和和OSGi的完美融合，就有必要介绍下OSGi。
OSGi是什么
OSGi是Open Services Gateway initiative的缩写，叫做开放服务网关协议。我们说到OSGi时，根据上下文不同，通常可能指OSGi联盟、OSGi标准或者OSGi框架。OSGi联盟成立于1999年，当时是为了建立一套将可管理的服务（Managed Service）通过网络交付到设备中的开放标准。可见，OSGi最开始面向的是从嵌入式和移动设备，这也不难理解OSGi名称的由来了。不过现在OSGi已经不作为开放服务网关协议的缩写了，OSGi联盟官方网站的介绍中，OSGi只是作为一种技术的名称，而不是一种缩写了。因为时至今日，OSGi已经逐渐扩展到了企业应用领域，在JAVA企业级开发中扮演越来越重要的角色。
OSGi联盟现在将OSGi定义为一种技术：
OSGi技术是指一系列用于定义Java动态化组件系统的标准。这些标准通过为大型分布式系统以及嵌入式系统提供一种模块化架构减少了软件的复杂度。
这一系列的标准由OSGi联盟维护，标准的实现通常则称为OSGi容器或者OSGi服务平台。下面我们就分别简单介绍OSGi标准、OSGi的特点、业务主流的OSGi实现与扩展和OSGi联盟。
OSGi标准
既然OSGi技术是指一系列标准，那么我们从对OSGi标准的了解开始。OSGi R1于2000年发布，现在最新的标准版本是R5，到现在为止应用最广泛的当属是2005年发布的R4。2003年Eclipse开始基于OSGi对Eclipse进行了重构，IBM的加入也影响了R4的制定，作为Eclipse内核的Equinox也成为OSGi标准的参考实现。OSGi各个版本的标准可以从osgi.org中下载。最新标准分为两个部分，OSGi Core和OSGi Enterpise。
OSGi Core顾名思义，就是OSGi的核心标准，正是这个标准定义了一种动态化模块化的应用架构，其中主要定义了OSGi框架。OSGi框架提供了一个通用安全可管理的Java框架，能够支持可扩展可下载的应用（即bundles）的部署。OSGi框架是OSGi技术最基础也是最核心的部分。OSGi框架分为以下几层，如下图所示：
由上图可知，OSGi主要分为：安全层、模块层、生命周期层、服务层、服务层。
安全层
安全层基于Java2的安全机制增加了一些限制，并且弥补了Java标准的一些不足。
模块层
模块层定义了一个模块化Java模型，对Java部署模式的一些缺点进行了改进，并对bundle（bundle为OSGi中的组件模型，可以简单认为是增加了元数据的Jar包） 之间包的共享有严格的规定。模块层独立于生命周期层和服务层，使用时可以不需要生命周期层和服务层。生命周期层提供了对模块层的bundle 进行管理的API，而服务层提供了bundle之间的通信模型。
生命周期层
生命周期层为bundle 提供了生命周期管理API，为bundle提供了一个运行时模型，定义了一个bundle 如何启动、停止、安装和卸载。另外，生命周期层也提供全面的事件API，允许bundle去控制和操作服务平台。
服务层
服务层 为bundle开发者提供了一个动态、简明且并且统一的编程模型，通过解耦服务标准（即Java接口）和它的实现，能够简化服务bundle的开发和部署。这个模型允许bundle 开发者只使用他们自己的接口规范来绑定服务。这样接口的实现可以根据实际情况延迟到运行时来选择。框架通过使用服务层，为系统提供了一种扩展机制，成为hooks。Hooks是一种框架用来扩展功能的服务。
OSGi中统一的编程模型可以帮助bundle开发者应对很多情况下的扩展的问题，这一点非常重要，因为框架需要运行在各种硬件设备上，设备的不同硬件特性可能影响服务实现的许多方面。统一的接口使得软件组件能够匹配和组合，同时保证稳定的运行。
OSGi框架中bundle 可以在运行时通过服务注册中心选择一个可用的实现，bundle 可以注册新服务、接收关于服务状态的通知或者查找服务区以适配当前的设备。这使得一个bundle在部署后仍然具有可扩展性，新的bundle可被安装，已存在的bundle可修改和更新，而无需重新启动系统。
OSGi Enterprise由OSGi联盟的EEG(Enterprise Expert Group ) 制定，主要通过裁剪或者扩展OSGi框架（即OSGi Core）来定义技术需求与标准，以满足企业环境下IT软件基础设施的用况。OSGi Enterprise主要包括组件模型、分布式服务、Web应用于HTTP Servlet、事件模型、管理与配置服务、名称与目录服务、数据访问、事务支持以及其它一些支持服务。OSGi Enterprise在这里不详细展开，后面我们将会有详细的介绍。
OSGi的特点
OSGi已经被用于构建很多非常复杂的系统，比如IDE（Eclipse），应用服务器（GlassFish, IBM Websphere, Oracle/BEA Weblogic, Jonas, JBoss），应用框架（Spring，Guice），工业自动化等等。是什么特点使得OSGi称为这些系统的选择呢？
不妨从几个角度来说一说OSGi的特点。从开发的角度来说，OSGi具有以下特点： ● 复杂性的降低：基于OSGi的组件模型bundle能够隐藏内部实现，bundle基于服务进行交互。 ● 复用：很多第三方的组件可以以bundle的形式进行复用。 ● 简单：核心的API总过包括不超过30个类和接口。 ● 小巧：OSGi R4框架的实现仅需要300KB的JAR file就足够。在系统中引入OSGi几乎没有什么开销。 ● 非侵入式：服务可以以POJO的形式实现，不需要关注特定的接口。
从部署和运行的角度来说，OSGi的特点就更多了，OSGi的动态化很大程度体现在系统的部署和运行时。这些特点包括： ● 切合真实运行环境：OSGi框架是动态的，bundle能够进行即时的更新，服务可以根据需要动态增加或者删除。比如一个服务可以是一个网络中的设备，如果一个设备被监测到，则服务可以动态注册；如果设备被移除，则服务能够动态注销。在这样的运行环境中编程将需要耗费大量的开销来处理动态性，但是OSGi帮助开发者处理了绝大多数动态性方面的工作。 ● 易于部署：OSGi定义了组件是如何安装和管理的，标准化的管理API使得OSGi能够和现有和将来的各种系统有机的集成。 ● 动态更新：这是OSGi被最经常提起的一个特性，即所谓的“热插拔”特性，bundle能够动态的安装、启动、停止、更新和卸载，而整个系统无需重启。 ● 适配性：这主要得益于OSGi提供的服务机制、组件可以动态的注册、获取和监听服务，使得系统能够在OSGi环境调整自己的功能。 ● 透明：提供了管理API来访问内部状态，因此通常无需去查看日志，能够通过命令行进行调试。 ● 版本化：bundle可以版本化，多版本能够共存而不会影响系统功能，解决了JAR hell的问题。（这在开发时也提供了很大的帮助） ● 快速：这得益于OSGi的类加载机制，和JAR包的线性加载不同，bundle委托式的类加载机制，使得类的加载无需进行搜索，这又能有效的加快系统的启动速度。 ● 懒加载：OSGi技术采用了很多懒加载机制。比如服务可以被注册，但是直到被使用时才创建。
此外OSGi还有一些其他的优势，比如： ● 安全：OSGi提供了一个安全层，基于Java的安全模型增加了可用性。 ● 大公司的支持：OSGi联盟的成员里包含了很多业界有名的IT公司，比如Oracle, IBM, Samsung, Nokia, Progress, Motorola, NTT, Siemens, Hitachi, Deutsche Telekom, Redhat, Ericsson等。
OSGi的实现与扩展
OSGi框架最著名的三个实现包括Apache Felix, Equinox和Knopflerfish，这三个实现也是R4的认证实现。伴随OSGi框架的实现，通常会有相关的扩展，以进一步提供OSGi开发的工具或平台。
Apache Felix :
Felix项目包含了一个OSGi R4服务平台（Service Platform）标准的实现，以及大量相关的OSGi功能与技术的实现。Felix下的子项目有二十多个。除了核心框架的实现，也对主要的OSGi服务进行了实现，同时还提供了iPojo这样的OSGi编程模型（后面我们将会详细介绍）。Felix还提供了一个强大的Shell，名叫Gogo, 用以与OSGi的交互。还记得OSGi易于部署的特点吗？基于OSGi提供的管理API，你也可以实现一个于OSGi平台的交互控制台，甚至是图形化或者Web形式的交互方式。Gogo也被接下来要介绍的Virgo所采用。当然，Felix也提供了支持OSGi开发的SDK，同时还提供了一个bundle的中央仓库。
Apache还有另外一个项目Aries，这个项目里主要基于Felix，对OSGi企业标准进行了实现。
Equinox:
Equinox是Eclipse 社区开发的 OSGi 框架，也是 Eclipse 强大的插件体系的基础，是Eclipse著名的PDE开发环境的底层。在Equinox的基础上，Eclipse社区还有其它一些针对企业级开发的扩展项目。2008年开始Spring社区开始将Spring的编程模型引入到OSGi中，那时项目叫做Spring-OSGi，后来改名变成Spring DM，之后成为OSGi企业应用的标准，即Blueprint。可见，Gemini Blueprint是从Spring DM发展而来。使用Gemini Blueprint编写的代码更易于测试，同时与OSGi API是松耦合的。Gemini Web是OSGi Web Application Specification的一个参考实现，目的在于在OSGi环境下更好的支持Java EE中的Servlet模型。Virgo 项目EclipseRT项目的一部分，是一个完全模块化的Java运行时。Virgo自身就是设计为在Equinox之上的一个OSGi bundle集合。Virgo可以运行企业级Java应用以及基于Spring的应用。
值得一提的是，Spring社区的OSGi相关项目大多捐献给了Eclipse社区，这些项目也很大程度上影响了OSGi在企业级应用上的发展，从标准和工具支持上，都为OSGi走向企业级应用做出了很大的贡献。Spring Source现在也维护着最大也是最全面的一个bundle仓库，叫做Enterprise Bundle Respository，将绝大多数Java企业级开发的Package转换为了OSGi bundle。当你真正将OSGi应用到实际开发中时，你就能体会到这样一个仓库给我们带来了多大的方便。
Knopflerfish :
Knopflerfish也是一个大名鼎鼎的开源OSGi服务平台实现，由Markwave公司实现。除了提供运行环境外，Knopflerfish也提供了一套Eclipse的SDK，帮助开发者开发OSGi应用。
OSGi联盟
最后再说一说维护着OSGi标准，推动OSGi一直向前发展的OSGi联盟。OSGi联盟的主要目标是促进OSGi技术在应用，同时提升OSGi技术的市场价值，形成一个跨行业的生态系统。OSGi联盟现在主要做着以下几件事情：提供标准、提供标准的参考实现、提供OSGi的测试套件以及OSGi的认证。
OSGi的成员的架构组织形式于2011年11月进行了重新组织，现在盈利或者非营利性的公司、政府机构、科研院所一起其他符合OSGi联盟目标的组织都可以申请成为成员。OSGi联盟的成员遍布全球。其中半数来自欧洲，三分之一来自北美，其他的基本来自亚太地区。这些成员中，包括业务领先的服务于内容提供商、基础设施和网络的运营商、软件开发商、网关提供商、电子设备提供商以及研究机构。
OSGi联盟的正式成员分为三类：Strategic Members，Principal Members，Contributing Associates，成为这些成员都是要交年费的。同时OSGi联盟还提供一种免费的Supporter成员资格，希望推广联盟或者OSGi技术的组织都可以申请。
Strategic成员是最高级别的成员，管理整个联盟和标准的开发。Strategic成员有资格成为OSGi董事会成员、officer（干事）。Strategic成员可以进行OSGi的认证测试。所谓认证测试，就是实现了OSGi标准的产品如果通过OSGi联盟的测试，那就是通过认证了，跟什么ISO认证CMMI认证是类似的。OSGi联盟通过认证了，你的产品自然有公信力了。任何任务组织都可以申请成为Strategic 成员，不过年费也很高，一年得上交25000刀。像IBM、Oracle和Adobe这样的大公司都是strategic成员。
比Strategic成员更低一级别的是Principal 成员。Principal 成员可以领导专家组和社区，可以免费进行OSGi联盟的认证兼容性测试。250人以上的组织年费是20000刀，少于250人的组织年费是10000刀。
再下来就是Contributing Associates成员了。这一级别的成员主要关注技术，主要参与OSGi标准和技术的相关工作。Contributing Associates成员的年费是5000刀。大名鼎鼎的Eclipse基金会就是这一级别的成员。
Supporter成员那就很多了，毕竟是免费的，这里还能看到很多中国公司的身影了。Supporter成员有权在自己的站点使用OSGi的官方Logo，能够提出RFP，此外还有享受OSGi相关会议的折扣，接收OSGi的最新信息等。
刚刚说到strategic成员有资格成为OSGi董事成员和干事。董事会成员和干事都是来自strategic成员公司的个人，这些人构成OSGi联盟的日常管理和决策人员。OSGi技术的开展的推广是通过专家组来进行的。现在OSGi社区有三个专家组，分别是核心平台专家组、企业专家组和Residential专家组。为OSGi技术做出卓越贡献的人有机会被董事会授予终身OSGi Fellow，对OSGi技术的应用与推广做出卓越贡献的人则有机会被授予OSGi Laureates。不过OSGi Fellow和OSGi Laureates的人数是很少的，基本是大公司里的大牛。