OSGI规范为网络服务定义了一个标准的、面向组件的计算环境。将OSGI服务平台添加到一个网络设备中,可以为其增加在网络的任何地方管理组件的生命周期的能力。软件组件可以从运行中被安装、升级或者移除而不需要中断设备的操作。软件组件可以动态的发现和使用其他库或者应用程序。通过这个平台,软件组件可以作为商品在柜台中出售以及在家里开发。OSGI联盟已经开发出很多标准组件接口,从普通的功能如:HTTP server、configuration、 logging、security、user administration、XML等等很多。一致的插件机制可以使这些组件满足不同买主的不同需求。
软件组件架构致力于一个软件开发中越来越大的问题:大量的基础配置需要开发和维护。标准化的OSGI组件架构显然可以简化这个配置过程。
安全是基于java和java2的安全模块。语言的设计限制了许多可能的结构。比如在病毒中常用的buffer溢出是不可能出现的。语言中的访问控制限制了其他开发者对代码的可见度。OSGI通过允许在标准的java中不可见的私有类来扩展这个模型。Java2的安全模块提供了一个全面的模型来检查代码对资源的访问权限。OSGI也添加了全面的动态权限管理。
在框架的上层,OSGI联盟定义了很多services。Services通过java接口定义。Bundles可以实现这些接口并注册到service注册器上。这些service的客户端可以通过注册器找到它们,或者当它出现/消失时对它作出反应。
下面的章节描述了OSGi Release 3 services的概况。更多的信息可以在OSGi Release 3 services的book或PDF中得到。注意每个service都被定义为抽象的,并且独立于不同提供者的实现。
OSGI框架提供一个权限管理服务,一个包管理服务和一个启动级别服务。这些服务是框架的一部分(可选)并指向操作的。
框架服务如下:
• Permission Admin:通过本服务现在或将来能够操作的bundles。权限在它们被设置时即时生效。
• Package Admin :Bundles同Classes和resources共享包。Bundles的升级可能需要系统重新计算依赖关系。这个Package Admin服务提供实际包在系统中的共享情况的信息,并且能够刷新已共享的包。I.e.打破依赖和重新计算依赖。
• Start Level :启动级别是一组应该一起运行或在其他服务之前初始化的bundles。启动级别服务设置当前启动级别,指定一个bundle的启动级别并且查看当前设置。
系统服务提供每个实际系统所需要的底层功能。例如: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的属性类。
OSGI联盟还定义了一组服务,每个OSGI服务对应一个外部协议:
• Http Service:Http service是一个servlet运行环境。Bundles能够提供可通过http协议访问的servlets。OSGI平台的动态更新工具使