OSGi（开放服务网关协议）技术是Java动态化模块化系统的一系列规范。OSGi一方面指维护OSGi规范的OSGI官方联盟，另一方面指的是该组织维护的基于Java语言的服务（业务）规范
OSGi（开放服务网关协议，Open Service Gateway Initiative）技术是 Java 动态化模块化系统的一系列规范。OSGi 一方面指维护 OSGi 规范的 OSGI 官方联盟，另一方面指的是该组织维护的基于 Java 语言的服务（业务）规范。简单来说，OSGi 可以认为是 Java 平台的模块层。OSGi 服务平台向 Java 提供服务，这些服务使 Java 成为软件集成和软件开发的首选环境。OSGi 技术提供允许应用程序使用精炼、可重用和可协作的组件构建的标准化原语，这些组件能够组装进一个应用和部署中。
简介
开放服务网关协议有双重含义。一方面它指 OSGi Alliance 组织；另一方面指该组织制定的一个基于 Java 语言的服务规范——OSGi 服务平台。 OSGi Alliance 是一个由 Sun Microsystems、IBM、爱立信等于 1999 年 3 月成立的开放的标准化组织，最初名为 Connected Alliance。该组织及其标准原本主要目的在于使服务提供商通过住宅网关，为各种家庭智能设备提供各种服务。该平台逐渐成为一个为室内、交通工具、移动电话和其他环境下的所有类型的网络设备的应用程序和服务进行传递和远程管理的开放式服务平台。
该规范和核心部分是一个框架，其中定义了应用程序的生命周期模式和服务注册。基于这个框架定义了大量的 OSGi 服务：日志、配置管理、偏好，HTTP（运行 servlet）、XML 分析、设备访问、软件包管理、许可管理、星级、用户管理、IO 连接、连线管理、Jini 和 UPnP。
这个框架实现了一个优雅、完整和动态的组件模型。应用程序（称为 bundle）无需重新引导可以被远程安装、启动、升级和卸载（其中 Java 包/类的管理被详细定义）。API 中还定义了运行远程下载管理政策的生命周期管理。服务注册允许 bundles 去检测新服务和取消的服务，然后相应配合。OSGI 框架一般具备的基础功能：
支持模块化的动态部署。基于 OSGI 而构建的系统可以以模块化的方式动态地部署至框架中，从而增加、扩展或改变系统的功能。支持模块化的封装和交互。每个工程（模块）可通过声明 Export-Package 对外提供访问此工程的类和接口。
支持模块的动态扩展。基于 OSGI 提供的面相服务的组件模型的设计方法，以及 OSGI 实现框架提供的扩展点方法可实现模块的动态扩展。模块化的设计。在 OSGI 中模块由一个或多个 bundle 构成，模块之间的交互通过 Import-Package、Export-Package 以及 OSGI Service 的方式实现。
动态化的设计。动态化的设计是指系统中所有的模块必须支持动态的插拔和修改，“即插即用，即删即无”。
可扩展的设计。通常使用定义扩展点的方式。按照 Eclipse 推荐的扩展点插件的标准格式定义 bundle 中的扩展点，其它要扩展的 bundle 可通过实现相应的扩展点来扩展该 bundle 的功能。每个 bundle 拥有独立的 class loader，通过它来完成本 bundle 类的加载。
稳定、高效的系统。基于 OSGI 的系统采用的是微核机制，微核机制保证了系统的稳定性，微核机制的系统只要微核是稳定运行的，那么系统就不会崩溃，也就是说基于 OSGI 的系统不会受到运行在其中的 bundle 的影响，不会因为 bundle 的崩溃而导致整个系统的崩溃。
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 网络。这是发布版本 3 中的推荐规范。
DMT 管理(DMTAdmin)开放移动联盟(OMA)基于设备管理树为移动设备管理提供了一个完整规定。DMT 管理服务定义该树如何被访问和/或者在 OSGi 服务平台中被扩充。
框架结构
OSGI 规范的核心组件是 OSGI 框架。这个框架为应用程序（被叫做组件（bundle））提供了一个标准环境。整个框架可以划分为一些层次：
L0：运行环境
L1：模块
L2：生命周期管理
L3：服务注册
还有一个无处不在的安全系统渗透到所有层。
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 服务平台发行版本 4 手册或者 PDF 下载中找到。需要注意的是每一种服务都是抽象定义的，与不同计算机服务商的实现相独立。
框架服务
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 模型不同于依赖于启动和关闭形式的典型的桌面或者移动电话应用程序模型。该应用程序管理服务提供了传统应用程序模型和它所要求的管理设施。
