Introduction
OSGI规范为网络服务定义了一个标准的、面向组件的计算环境。将OSGI服务平台添加到一个网络设备中，可以为其增加在网络的任何地方管理组件的生命周期的能力。软件组件可以从运行中被安装、升级或者移除而不需要中断设备的操作。软件组件可以动态的发现和使用其他库或者应用程序。通过这个平台，软件组件可以作为商品在柜台中出售以及在家里开发。OSGI联盟已经开发出很多标准组件接口，从普通的功能如：HTTP server、configuration、 logging、security、user administration、XML等等很多。一致的插件机制可以使这些组件满足不同买主的不同需求。
软件组件架构致力于一个软件开发中越来越大的问题：大量的基础配置需要开发和维护。标准化的OSGI组件架构显然可以简化这个配置过程。
The Framework
|
OSGI规范的核心组件使OSGI框架。该框架为应用程序（被成为bundles）提供一个标准化的环境。这个框架被分为以下几个层次：
· L0: 执行环境
· L1: 组件模块
· L2: 组件生命周期管理
· L3: 服务注册
另外，还有一个安全机制深深的缠绕在所有的层中。 |
|
|
 L0:执行环境就是java环境的规范。Java2配置和profiles，如j2se、CDC、MIDP等等都是可用的执行环境。OSGI还标准化了一个基于基本profile的执行环境和一个可用于OSGI bundles的最小执行环境的规范。
|
|
 L1:模块层定义了类加载策略。OSGI框架是一个健壮而严格定义的类加载模型。它基于java但是更加模块化。在java中，通常只有一个单独的classpath包含所有的class和resource。OSGI模块层为一个模块添加私有的类并控制模块之间的关联。
|
|
 L2：生命周期层添加能够动态的安装、启动、停止、升级和卸载的bundles。Bundles加载class时依赖于模块层，但也一个API在运行期管理模块。生命周期层引入了通常不属于应用一部分的动态性。广泛的依赖机制过去常用于确认环境的当前操作。
|
|
 L3层添加了一个服务注册器。服务注册器为bundles提供了一个协作模块用于动态注册。Bundles可以通过传统的class共享来协作，但是class共享与动态安装和卸载的代码不太协调。服务注册器提供了一个全面的模块似的bundles可以共享对象。一些事件被定义来处理服务的加载和卸载。服务只是一些能够代表任何东西的java对象。很多服务的活动象一个HTTP服务器，其他服务代表了真实世界中的一个对象，比如：附近的一个蓝牙电话。
|
安全是基于java和java2的安全模块。语言的设计限制了许多可能的结构。比如在病毒中常用的buffer溢出是不可能出现的。语言中的访问控制限制了其他开发者对代码的可见度。OSGI通过允许在标准的java中不可见的私有类来扩展这个模型。Java2的安全模块提供了一个全面的模型来检查代码对资源的访问权限。OSGI也添加了全面的动态权限管理。
Standard Services
在框架的上层，OSGI联盟定义了很多services。Services通过java接口定义。Bundles可以实现这些接口并注册到service注册器上。这些service的客户端可以通过注册器找到它们，或者当它出现/消失时对它作出反应。
下面的章节描述了OSGi Release 3 services的概况。更多的信息可以在OSGi Release 3 services的book或PDF中得到。注意每个service都被定义为抽象的，并且独立于不同提供者的实现。
Framework Services
OSGI框架提供一个权限管理服务，一个包管理服务和一个启动级别服务。这些服务是框架的一部分（可选）并指向操作的。
框架服务如下：
• Permission Admin：通过本服务现在或将来能够操作的bundles。权限在它们被设置时即时生效。
• Package Admin ：Bundles同Classes和resources共享包。Bundles的升级可能需要系统重新计算依赖关系。这个Package Admin服务提供实际包在系统中的共享情况的信息，并且能够刷新已共享的包。I.e.打破依赖和重新计算依赖。
• Start Level ：启动级别是一组应该一起运行或在其他服务之前初始化的bundles。启动级别服务设置当前启动级别，指定一个bundle的启动级别并且查看当前设置。
System Services
系统服务提供每个实际系统所需要的底层功能。例如：Log Service, Configuration Admin Service, Device Access Service, User Admin Service, IO Connector Service和Preferences Service。
• Log Service：记录通过log service处理的information, warnings, debug 信息或者error。它获得log实体然后分派这些消息实体到订阅该消息的bundles。
• Configuration Admin Service：该service提供一个灵活和动态的模型来设置和访问配置信息。
• Device Access Service：设备访问是一个OSGI机制，当有新的设备添加时，它为新设备匹配驱动，并下载一个bundle来实现该驱动。这对即插即用的情形非常有用。
• User Admin Service：这个服务使用一个用户信息的数据库（私有或共有）来达到授权和认证的目的。
• IO Connector Service：IO Connector Service实现CDC/ CLDC javax.microedition.io包作为一个service.这个service允许bundles实现新的、可选的协议。
• Preferences Service：这个service提供分层的属性数据库的访问。类似于windows的注册表或者java的属性类。
Protocol Services
OSGI联盟还定义了一组服务，每个OSGI服务对应一个外部协议：
• Http Service：Http service是一个servlet运行环境。Bundles能够提供可通过http协议访问的servlets。OSGI平台的动态更新工具使http service变成了一个非常吸引人的web server，因为它可以远程动态更新servlet而不需要重启
• UPnP Service：统一即插即用（UPnP）是一个对用户电器暴露的统一接口。OSGI UPnP Service通过service注册器对应一个设备到一个UPnP网络。可选的，它也能够对应一个OSGI service到一个UPnP网络。这在release3规范中是被推荐的做法。
• Jini Service：Jini是一个网络协议用来发现网上的Jini服务并从该服务器上下载这些服务的java代码并执行它们。这在release3规范中是被推荐的做法。
Miscellaneous Services
• Wire Admin Service ：通常bundles建立寻找它们想要与之合作的service的规则。然而，通常这应该在部署时决定。Wire Admin service将一个配置文件中定义的不同service连接到一起。Wire Admin service使用生产者消费者模式在service之间交换对象。
• XML Parser Service： XML Parser service允许一个bundle通过指定的属性定位一个解析器并同JAXP兼容。
Conclusion
OSGI规范有广泛的适用性，是因为它是在一个单独的JVM中的一个很小的层，并允许多样的、基于java的、组件的高效合作。它提供一个可扩展的安全机制以便组件可以运行在一个受保护的环境。而且，通过适当的权限，组件可以重用和合作，而不像其他java应用环境。OSGI框架提供一个可扩展排队机制使得这种合作变得可能和安全。
基于OSGI的中间件的存在为OSGI组件提供了广阔的市场。OSGI平台严格的定义似的组件能够运行在各种各样的设备上，从手持设备到大型主机。
采用OSGI规范还可以降低提供新业务的软件开发成本。
Further Reading
OSGi Service Platform, Release 3 download or buy the book at reduced cost.
OSGI联盟撰写了一个技术白皮书 和一个白板模式白皮书 来深入的解释该项技术。