OSGI （面向Java 的动态模型系统）
OSGi(Open Service Gateway Initiative)技术是Java 动态化模块化系统的一系列规范。OSGi 一方面指维护OSGi 规范的OSGI 官方联盟，另一方面指的是该组织维护的基于Java 语言的服务（业务）规范。简单来说，OSGi 可以认为是Java 平台的模块层。
OSGi 服务平台向Java 提供服务，这些服务使Java 成为软件集成和软件开发的首选环境。Java 提供在多个平台支持产品的可移植性。OSGi 技术提供允许应用程序使用精炼、可重用和可协作的组件构建的标准化原语，这些组件能够组装进一个应用和部署中。
背景
OSGi 给出了一套Java 模块化规范，这套规范给出了OSGi 框架的定义，而具体的OSGi 平台，如Felix 和Equinox 则分别是Apache 和Eclipse 开源社区给出的标准规范的实现。
OSGi 服务平台提供在多种网络设备上无需重启的动态改变构造的功能。为了最小化耦合度和促使这些耦合度可管理，OSGi 技术提供一种面向服务的架构，它能使这些组件动态地发现对方。OSGi 联盟已经开发了例如像HTTP 服务器、配置、日志、安全、用户管理、XML 等很多公共功能标准组件接口。这些组件的兼容性插件实现可以从进行了不同优化和使用代价的不同计算机服务提供商得到。然而，服务接口能够基于专有权基础上开发。
因为OSGi 技术为集成提供了预建立和预测试的组件子系统，所以OSGi 技术使你从改善产品上市时间和降低开发成本上获益。因为这些组件能够动态发布到设备上，所以OSGi 技术也能降低维护成本和拥有独一无二的新的配件市场机会。 安全协议
安全机制是建立在Java 和Java2安全模型基础之上。Java 语言的设计对很多结构进行了限制。例如病毒中经常遇到的缓存溢出是不可能发生的。Java 语言中的访问控制符限制了代码可见性。
OSGI 平台通过使用私有类（在Java 中不能用标准方式使用的机制）扩展了该模型。Java2安全模型提供了一个完整模块检查代码对于资源的可访问性。OSGI
增加了完全动态的权限管理，简化了操作者和系统管理员的工作。
OSGI 联盟已经定义了很多协议服务，这些服务将外部协议映射为OSGI 服务。HTTP 服务(HttpService)该HTTP 服务是servlet 运行器。bundles 提供servlets ，这些服务端小程序基于HTTP 协议成为可用的。OSGi 服务平台的动态更新功能使HTTP 服务成为一个非常具有吸引力的Web 服务器，它能伴随着新的servlet 被更新，如果需要可以远程更新而无需重启。
UPnP 服务(UPnPService)通用即插即用（UPnP ）是一个正在形成中的消费电子标准。OSGi 中的UPnP 服务在一个UPnP 网络上将设备映射到服务注册中。同样，它也可以将OSGi 服务映射到UPnP 网络。
DMT 管理(DMTAdmin)开放移动联盟(OMA)基于设备管理树为移动设备管理提供了一个完整规定。DMT 管理服务定义该树如何被访问和/或者在OSGi 服务平台中被扩充。
框架结构
OSGI 规范的核心组件是OSGI 框架。这个框架为应用程序（被叫做组件（bundle ））提供了一个标准环境。整个框架可以划分为一些层次：
L0：运行环境
L1：模块
L2：生命周期管理
L3：服务注册[2]
还有一个无处不在的安全系统渗透到所有层。
L0层执行环境是Java 环境的规范。Java2配置和子规范，像J2SE ，CDC ，CLDC ，MIDP 等等，都是有效的执行环境。OSGi 平台已经标准化了一个执行环境，它是基于基础轮廓和在一个执行环境上确定了最小需求的一个小一些的变种，该执行环境对OSGi 组件是有用的。
L1模块层定义类的装载策略。OSGi 框架是一个强大的具有严格定义的类装载模型。它基于Java 之上，但是增加了模块化。在Java 中，正常情况下有一个包含所有类和资源的类路径。OSGi 模块层为一个模块增加了私有类同时有可控模块间链接。模块层同安全架构完全集成，可以选择部署到部署封闭系统，防御系统，或者由厂商决定的完全由用户管理的系统。
L2生命周期层增加了能够被动态安装、开启、关闭、更新和卸载的bundles 。这些bundles 依赖于于具有类装载功能的模块层，但是增加了在运行时管理这些模块的API 。生命周期层引入了正常情况下不属于一个应用程序的动态性。扩展依赖机制用于确保环境的操作正确。生命周期操作在安全架构保护之下，使其不受到病毒的攻击。
L3层增加了服务注册。服务注册提供了一个面向bundles 的考虑到动态性的协作模型。bundles 能通过传统的类共享进行协作，但是类共享同动态安装和卸载代码不兼容。服务注册提供了一个在bundles 间分享对象的完整模型。定义了大量的事件来处理服务的注册和删除。这些服务仅仅是能代表任何事物的Java 对象。很多服务类似服务器对象，例如HTTP 服务器，而另一些服务表示的是一个真实世界的对象，例如附近的一个蓝牙手机。这个服务模块提供了完整安全保障。该服务安全模块使用了一个很聪明的方式来保障bundles 之间通信安全。 标准服务
在该框架之上，OSGi 联盟定义了很多服务。这些服务通过一个Java 接口指定。bundles 能够实现这个接口，并在注册服务层注册该服务。服务的客户端在注册库中找到它，或者当它出现或者消失时做出响应。这个同SOA 架构使用Web 服务进行发布的方式相似。
两者主要不同是Web 服务总是需要传输层，这个使它比采用直接方法调用的OSGi 服务慢几千倍。同时，OSGi 组件能够对这些服务的出现和消失做出响应。需要注意的是每一种服务都是抽象定义的，与不同计算机服务商的实现相独立。 框架服务
OSGi 框架提供一个权限管理服务，一个包管理服务和一个开始级别服务。这些服务是一个可选部分，指示框架的操作。框架服务如下：
权限管理(PermissionAdmin)目前或者将来的bundles 的权限通过这种服务进行维护。一旦设置了它们，权限服务立即激活。
包管理(PackageAdmin)bundles同类和资源分享包。bundles 的更新可能需要系统重新计算这些依赖。这个包管理服务提供关于系统的实际包分享状态和能够刷新已经共享的包。也就是，取消依赖和重新计算依赖。
启动级别(StartLevel)启动级别是一个bundles 集合，它们应该同时运行或者
应该在其它已经启动以前被初始化。启动级别服务设置当前的启动级别，为每个bundle 排一个启动级别和审核当前的设置。
URL 处理者(URLHandler)Java环境为URL 处理者支持一个提供者模型。然而，这是一个单件，不可能在一个象OSGi 可能有很多提供者的协作环境上使用它。此服务规范使任何组件提供额外的URL 处理者。
系统服务
系统服务提供水平功能，它在每个系统是必须的。日志服务，配置管理服务，设备访问服务，用户管理服务，IO 连接器服务和参数服务都是系统服务的一个方面。
日志服务(LogService)日志信息，警告，调试或者错误信息通过日志服务来处理的。它接受日志实体并分派这些实体到订阅了这个信息的其他bundles 。
配置管理服务(ConfigurationAdminService)该服务提供一个设置和获取配置信息的灵活、动态模型。
设备访问服务(DeviceAccessService)设备访问是OSGi 为一个新的设备匹配一个驱动，并自动下载一个实现该驱动的bundles 的机制。这个可用作即插即用方案。
用户管理服务(UserAdminService)该服务使用一个用于授权和验证目的的用户信息数据库。
IO 连接器服务(IOConnectorService)该IO 连接器服务实现了CDC/CLDCjavax包，并作为一个服务。该服务允许bundles 提供新的可交换协议模式。
参数服务(PreferencesService)该服务提供了参数层级数据库的可访问性，同Windows 注册表或者Java 参数类相似。
组件运行时服务(ComponentRuntime)服务的动态特性--它们能够在任何时间来去自由--使编写软件变得更难。组建运行时规范通过提供一个基于依赖声明的XML 文件来简化处理这些动态方面。
部署管理服务(DeploymentAdmin)OSGi的主要部署格式是bundle ，它是一个JAR/ZIP文件。部署管理提供第二种可选格式：部署包。部署包能够将bundles 和相应资源联接成可被安装和卸载的单个交付。完整的资源处理器模型允许用户代码扩充资源类型。
事件管理服务(EventAdmin)很多OSGi 事件有特定的类型化的接口，使其很难接收和过滤事件。事件服务提供一个泛化的基于主题的事件机制。这个规范包括为所有已存框架和服务事件的映射。
应用程序管理服务(ApplicationAdmin)OSGibundle模型不同于依赖于启动和关闭形式的典型的桌面或者移动电话应用程序模型。该应用程序管理服务提供了传统应用程序模型和它所要求的管理设施。
OSGi 的组成
通常，OSGi 框架从概念上可以分为三层：模块层、生命周期层和服务层。各层的主要功能如下：
Ø Module Layer ——模块层主要涉及包及共享的代码；
Ø Lifecycle Layer ——生命周期层主要涉及 Bundle 的运行时生命周期管理；
Ø Service Layer ——服务层主要涉及模块之间的交互和通信。
OSGI （面向Java 的动态模型系统）
OSGi(Open Service Gateway Initiative)技术是Java 动态化模块化系统的一系列规范。OSGi 一方面指维护OSGi 规范的OSGI 官方联盟，另一方面指的是该组织维护的基于Java 语言的服务（业务）规范。简单来说，OSGi 可以认为是Java 平台的模块层。
OSGi 服务平台向Java 提供服务，这些服务使Java 成为软件集成和软件开发的首选环境。Java 提供在多个平台支持产品的可移植性。OSGi 技术提供允许应用程序使用精炼、可重用和可协作的组件构建的标准化原语，这些组件能够组装进一个应用和部署中。
背景
OSGi 给出了一套Java 模块化规范，这套规范给出了OSGi 框架的定义，而具体的OSGi 平台，如Felix 和Equinox 则分别是Apache 和Eclipse 开源社区给出的标准规范的实现。
OSGi 服务平台提供在多种网络设备上无需重启的动态改变构造的功能。为了最小化耦合度和促使这些耦合度可管理，OSGi 技术提供一种面向服务的架构，它能使这些组件动态地发现对方。OSGi 联盟已经开发了例如像HTTP 服务器、配置、日志、安全、用户管理、XML 等很多公共功能标准组件接口。这些组件的兼容性插件实现可以从进行了不同优化和使用代价的不同计算机服务提供商得到。然而，服务接口能够基于专有权基础上开发。
因为OSGi 技术为集成提供了预建立和预测试的组件子系统，所以OSGi 技术使你从改善产品上市时间和降低开发成本上获益。因为这些组件能够动态发布到设备上，所以OSGi 技术也能降低维护成本和拥有独一无二的新的配件市场机会。 安全协议
安全机制是建立在Java 和Java2安全模型基础之上。Java 语言的设计对很多结构进行了限制。例如病毒中经常遇到的缓存溢出是不可能发生的。Java 语言中的访问控制符限制了代码可见性。
OSGI 平台通过使用私有类（在Java 中不能用标准方式使用的机制）扩展了该模型。Java2安全模型提供了一个完整模块检查代码对于资源的可访问性。OSGI
增加了完全动态的权限管理，简化了操作者和系统管理员的工作。
OSGI 联盟已经定义了很多协议服务，这些服务将外部协议映射为OSGI 服务。HTTP 服务(HttpService)该HTTP 服务是servlet 运行器。bundles 提供servlets ，这些服务端小程序基于HTTP 协议成为可用的。OSGi 服务平台的动态更新功能使HTTP 服务成为一个非常具有吸引力的Web 服务器，它能伴随着新的servlet 被更新，如果需要可以远程更新而无需重启。
UPnP 服务(UPnPService)通用即插即用（UPnP ）是一个正在形成中的消费电子标准。OSGi 中的UPnP 服务在一个UPnP 网络上将设备映射到服务注册中。同样，它也可以将OSGi 服务映射到UPnP 网络。
DMT 管理(DMTAdmin)开放移动联盟(OMA)基于设备管理树为移动设备管理提供了一个完整规定。DMT 管理服务定义该树如何被访问和/或者在OSGi 服务平台中被扩充。
框架结构
OSGI 规范的核心组件是OSGI 框架。这个框架为应用程序（被叫做组件（bundle ））提供了一个标准环境。整个框架可以划分为一些层次：
L0：运行环境
L1：模块
L2：生命周期管理
L3：服务注册[2]
还有一个无处不在的安全系统渗透到所有层。
L0层执行环境是Java 环境的规范。Java2配置和子规范，像J2SE ，CDC ，CLDC ，MIDP 等等，都是有效的执行环境。OSGi 平台已经标准化了一个执行环境，它是基于基础轮廓和在一个执行环境上确定了最小需求的一个小一些的变种，该执行环境对OSGi 组件是有用的。
L1模块层定义类的装载策略。OSGi 框架是一个强大的具有严格定义的类装载模型。它基于Java 之上，但是增加了模块化。在Java 中，正常情况下有一个包含所有类和资源的类路径。OSGi 模块层为一个模块增加了私有类同时有可控模块间链接。模块层同安全架构完全集成，可以选择部署到部署封闭系统，防御系统，或者由厂商决定的完全由用户管理的系统。
L2生命周期层增加了能够被动态安装、开启、关闭、更新和卸载的bundles 。这些bundles 依赖于于具有类装载功能的模块层，但是增加了在运行时管理这些模块的API 。生命周期层引入了正常情况下不属于一个应用程序的动态性。扩展依赖机制用于确保环境的操作正确。生命周期操作在安全架构保护之下，使其不受到病毒的攻击。
L3层增加了服务注册。服务注册提供了一个面向bundles 的考虑到动态性的协作模型。bundles 能通过传统的类共享进行协作，但是类共享同动态安装和卸载代码不兼容。服务注册提供了一个在bundles 间分享对象的完整模型。定义了大量的事件来处理服务的注册和删除。这些服务仅仅是能代表任何事物的Java 对象。很多服务类似服务器对象，例如HTTP 服务器，而另一些服务表示的是一个真实世界的对象，例如附近的一个蓝牙手机。这个服务模块提供了完整安全保障。该服务安全模块使用了一个很聪明的方式来保障bundles 之间通信安全。 标准服务
在该框架之上，OSGi 联盟定义了很多服务。这些服务通过一个Java 接口指定。bundles 能够实现这个接口，并在注册服务层注册该服务。服务的客户端在注册库中找到它，或者当它出现或者消失时做出响应。这个同SOA 架构使用Web 服务进行发布的方式相似。
两者主要不同是Web 服务总是需要传输层，这个使它比采用直接方法调用的OSGi 服务慢几千倍。同时，OSGi 组件能够对这些服务的出现和消失做出响应。需要注意的是每一种服务都是抽象定义的，与不同计算机服务商的实现相独立。 框架服务
OSGi 框架提供一个权限管理服务，一个包管理服务和一个开始级别服务。这些服务是一个可选部分，指示框架的操作。框架服务如下：
权限管理(PermissionAdmin)目前或者将来的bundles 的权限通过这种服务进行维护。一旦设置了它们，权限服务立即激活。
包管理(PackageAdmin)bundles同类和资源分享包。bundles 的更新可能需要系统重新计算这些依赖。这个包管理服务提供关于系统的实际包分享状态和能够刷新已经共享的包。也就是，取消依赖和重新计算依赖。
启动级别(StartLevel)启动级别是一个bundles 集合，它们应该同时运行或者
应该在其它已经启动以前被初始化。启动级别服务设置当前的启动级别，为每个bundle 排一个启动级别和审核当前的设置。
URL 处理者(URLHandler)Java环境为URL 处理者支持一个提供者模型。然而，这是一个单件，不可能在一个象OSGi 可能有很多提供者的协作环境上使用它。此服务规范使任何组件提供额外的URL 处理者。
系统服务
系统服务提供水平功能，它在每个系统是必须的。日志服务，配置管理服务，设备访问服务，用户管理服务，IO 连接器服务和参数服务都是系统服务的一个方面。
日志服务(LogService)日志信息，警告，调试或者错误信息通过日志服务来处理的。它接受日志实体并分派这些实体到订阅了这个信息的其他bundles 。
配置管理服务(ConfigurationAdminService)该服务提供一个设置和获取配置信息的灵活、动态模型。
设备访问服务(DeviceAccessService)设备访问是OSGi 为一个新的设备匹配一个驱动，并自动下载一个实现该驱动的bundles 的机制。这个可用作即插即用方案。
用户管理服务(UserAdminService)该服务使用一个用于授权和验证目的的用户信息数据库。
IO 连接器服务(IOConnectorService)该IO 连接器服务实现了CDC/CLDCjavax包，并作为一个服务。该服务允许bundles 提供新的可交换协议模式。
参数服务(PreferencesService)该服务提供了参数层级数据库的可访问性，同Windows 注册表或者Java 参数类相似。
组件运行时服务(ComponentRuntime)服务的动态特性--它们能够在任何时间来去自由--使编写软件变得更难。组建运行时规范通过提供一个基于依赖声明的XML 文件来简化处理这些动态方面。
部署管理服务(DeploymentAdmin)OSGi的主要部署格式是bundle ，它是一个JAR/ZIP文件。部署管理提供第二种可选格式：部署包。部署包能够将bundles 和相应资源联接成可被安装和卸载的单个交付。完整的资源处理器模型允许用户代码扩充资源类型。
事件管理服务(EventAdmin)很多OSGi 事件有特定的类型化的接口，使其很难接收和过滤事件。事件服务提供一个泛化的基于主题的事件机制。这个规范包括为所有已存框架和服务事件的映射。
应用程序管理服务(ApplicationAdmin)OSGibundle模型不同于依赖于启动和关闭形式的典型的桌面或者移动电话应用程序模型。该应用程序管理服务提供了传统应用程序模型和它所要求的管理设施。
OSGi 的组成
通常，OSGi 框架从概念上可以分为三层：模块层、生命周期层和服务层。各层的主要功能如下：
Ø Module Layer ——模块层主要涉及包及共享的代码；
Ø Lifecycle Layer ——生命周期层主要涉及 Bundle 的运行时生命周期管理；
Ø Service Layer ——服务层主要涉及模块之间的交互和通信。