OSGi（Open Service Gateway Initiative）

[quote]OSGi规范之所以应用如此广泛，是因为该平台是一个轻量级层，允许多个基于Java的组件在单个Java虚拟机（JVM）之中有效协作。它提供一个扩展的安全模型，以至于组件能够运行在一个可保护的环境之中。但是，同其它Java应用环境不同，在该平台上只要拥有合适的权限，组件就可以重用和协作。OSGi框架提供一组可扩展的机制，它们使该协作成为可能并且是安全的。基于中间件的OSGi技术的出现，在很多不同行业，建立了一个非常大的面向OSGi软件组件的软件市场。OSGi服务平台的严谨定义使组件能够运行在多种设备上，从非常小的设备到非常大的设备。因此OSGi规范的适应性能够降低软件开发成本，同时也产生了新的商业机会。[/quote]

OSGi 技术是面向Java的动态模型系统。OSGi服务平台向Java提供服务，这些服务使Java成为软件集成和软件开发的首选环境。 Java提供在多个平台支持产品的可移植性。OSGi技术提供允许应用程序使用精炼、可重用和可协作的组件构建的标准化原语。 这些组件能够组装进一个应用和部署中。

OSGi服务平台提供在多种网络设备上无需重启的动态改变构造的功能。为了最小化耦合度和促使这些耦合度可管理，OSGi技术提供一种面向服务的架构，它能使这些组件动态地发现对方。OSGi联盟已经开发了为例如象HTTP服务器、配置、日志、安全、用户管理、XML等很多公共功能标准组件接口。这些组件的兼容性插件实现可以从进行了不同优化和使用代价的不同计算机服务提供商得到。然而，服务接口能够基于专有权基础上开发。

因为OSGi技术为集成提供了预建立和预测试的组件子系统，所以OSGi技术使你从改善产品上市时间和降低开发成本上获益。因为这些组件能够动态发布到设备上，所以OSGi技术也能降低维护成本和拥有独一无二的新的配件市场机会。

[b]OSGi规范的体系结构[/b]
在OSGi规范中提供了一个参考的体系架构[1]，也基本上体现了OSGi的设计初衷。
OSGi的体系架构是基于这样一个模型的：经营者管理着一个潜在的巨大的服务网络平台。OSGi规范假设这个服务平台是完全被这个经营者控制，并且经营者使用该服务平台去运行来自不同服务提供者提供的服务。然而这只是一个场景，还有其他模型，例如PC机的部署，工业应用（如，移动电话基站是一个管理中心完全控制着各个方面），中间件模型等。OSGi最广泛的应用是在网络化的服务。除了参考模型之外，规范之中还提到了其他的一些模型。请参考OSGi 3.0规范[1]。
1.1.1 OSGi参考体系架构的特点
1． 商业驱动：经营者的观点驱动OSGi的体系架构。
2． 完美：体系架构必须是足够完善和详细的，以致允许开发商生产出健壮的产品。
3． 不受限的：由于经营者所操作的服务平台在性能和网络环境的变化是非常大的。
4． 开放：标准不是为一个具体的系统而设计的，OSGi参考体系架构必须考虑和支持许多不同的场景。
1.1.2 OSGi参考体系架构所涉及到实体
1. 服务平台：一个JAVA虚拟机的实例，一个OSGi框架结构，和运行着的服务包的集合。
2. 服务平台服务器(SPS)：驻留一个或多个服务平台的硬件。
3. 运营商：掌控许多服务平台的组织。
4. 服务应用：一套软件包，文档和支撑软件所组合起来的应用，这些应用向终端用户提供服务。
5. 服务用户：获取服务应用服务的用户。
6. 服务提供者：开发服务应用并且通过服务部署管理器部署到服务平台上。
7. 服务部署管理器：部署和部分管理一个或多个服务提供者提供的服务应用。
8. 服务运行支持：支撑软件和硬件，它们并不驻留在服务平台服务器上，但是在运行服务应用时需要它们。
9. 服务集成者：负责确保来自不同服务提供者的服务应用的集成。
10. 服务开发者：开发服务应用。
11. 制造商：制造服务平台服务器
12. 拥有者：服务平台服务器拥有者。
13. 收费提供者：接受帐户信息，并且提供统一的帐单给服务消费者。
14. 网络提供者：提供服务平台的网络链接。
15. 证书授权：管理证书的组织，这些证书被用来鉴别系统，个人和组织。

[b]框架服务[/b]

[quote]OSGi框架提供一个权限管理服务，一个包管理服务和一个开始级别服务。这些服务是一个可选部分，指示框架的操作。框架服务如下：[/quote]


[list=1]
[*]权限管理(Permission Admin) 目前或者将来的bundles的权限通过这种服务进行维护。 一旦设置了它们，权限服务立即激活。
[*]包管理(Package Admin) bundles同类和资源分享包。bundles的更新可能需要系统重新计算这些依赖。这个包管理服务提供关于系统的实际包分享状态和能够刷新已经共享的包。也就是，取消依赖和重新计算依赖。
[*]启动级别(Start Level) 启动级别是一个bundles集合，它们应该同时运行或者应该在其它已经启动以前被初始化。启动级别服务设置当前的启动级别，为每个bundle排一个启动级别和审核当前的设置。
[*]URL处理者(URL Handler) Java环境为URL处理者支持一个提供者模型。然而，这是一个单件，不可能在一个象OSGi可能有很多提供者的协作环境上使用它。此服务规范使任何组件提供额外的URL处理者。
[/list]

[b]系统服务[/b]

[quote]系统服务提供水平功能，它在每个系统是必须的。日志服务，配置管理服务，设备访问服务，用户管理服务，IO连接器服务和参数服务都是系统服务的一个方面。[/quote]


[list]
[*]日志服务(Log Service) 日志信息，警告，调试或者错误信息通过日志服务来处理的。它接受日志实体并分派这些实体到订阅了这个信息的其他bundles。
[*]配置管理服务(Configuration Admin Service) 该服务提供一个设置和获取配置信息的灵活、动态模型。
[*]设备访问服务(Device Access Service) 设备访问是OSGi为一个新的设备匹配一个驱动，并自动下载一个实现该驱动的bundles的机制。这个可用作即插即用方案。
[*]用户管理服务(User Admin Service) 该服务使用一个用于授权和验证目的的用户信息数据库。
[*]IO连接器服务(IO Connector Service) 该IO连接器服务实现了CDC/ CLDC javax. microedition.io 包，并作为一个服务。 该服务允许bundles提供新的可交换协议模式。
[*]参数服务(Preferences Service) 该服务提供了参数层级数据库的可访问性，同Windows注册表或者Java参数类相似。
[*]组件运行时服务(Component Runtime) 服务的动态特性 -- 它们能够在任何时间来去自由 -- 使编写软件变得更难。组建运行时规范通过提供一个基于依赖声明的XML文件来简化处理这些动态方面。
[*]部署管理服务(Deployment Admin) OSGi的主要部署格式是bundle，它是一个JAR/ZIP文件。部署管理提供第二种可选格式：部署包。部署包能够将bundles和相应资源联接成可被安装和卸载的单个交付。完整的资源处理器模型允许用户代码扩充资源类型。
[*]事件管理服务(Event Admin) 很多OSGi事件有特定的类型化的接口，使其很难接收和过滤事件。事件服务提供一个泛化的基于主题的事件机制。这个规范包括为所有已存框架和服务事件的映射。
[*]应用程序管理服务(Application Admin) OSGi bundle模型不同于依赖于启动和关闭形式的典型的桌面或者移动电话应用程序模型。该应用程序管理服务提供了传统应用程序模型和它所要求的管理设施。
[/list]


[b]协议服务[/b]

[quote]OSGi 联盟已经定义了很多协议服务，这些服务将外部协议映射为OSGi服务。[/quote]


[list]
[*]HTTP 服务(Http Service) 该HTTP服务是servlet运行器。bundles提供servlets，这些服务端小程序基于HTTP协议成为可用的。OSGi服务平台的动态更新功能使HTTP服务成为一个非常具有吸引力的Web服务器，它能伴随着新的servlet被更新，如果需要可以远程更新而无需重启。
[*]UPnP服务(UPnP Service) 通用即插即用（UPnP）是一个正在形成中的消费电子标准。OSGi中的UPnP服务在一个UPnP网络上将设备映射到服务注册中。同样，它也可以将OSGi服务映射到UPnP网络。这是发布版本3中的推荐规范。
[*]DMT管理(DMT Admin) 开放移动联盟 (OMA) 基于设备管理树为移动设备管理提供了一个完整规定。 DMT 管理服务定义该树如何被访问和/或者在OSGi服务平台中被扩充。
[/list]


[b]更多服务[/b]

[list]
[*]有线管理服务(Wire Admin Service) 正常情况下bundle建立发现与之共同协作的服务的规则。但是，在很多情况下，这是一个部署定义。因此有线管理服务连接在配置文件中共同定义的不同服务。该有线管理服务使用在对象间连线通信的生产者和消费者服务理念。
[*]XML解析服务(XML Parser Service) XML解析服务允许一个bundle定位一个具有所需要属性和同JAXP兼容的解析器。
[*]初始化提供(Initial Provisioning)
[*]外部应用访问(Foreign Application Access)
[/list]