OSGi规范中文版（第5版 core R6.0.0）-第1章OSGi概述[译]

译者：陈旭东  原文： http://www.osgi.org/Specifications/HomePage

1.介绍

        OSGI（Open Service Gateway Initiative）联盟成立于1999年。它的目的是建立一个向本地网络和设备提供服务的规范。OSGi组织主导下一代家居、汽车、手机、桌面系统、移动办公和其他环境下的互联网服务标准。

        OSGi服务规范为服务提供商、开发人员、软件开发商、网关运营商和设备供应商提供了一个开放的通用体系结构，用于协同开发、发布和管理服务。它使得灵活的智能设备和服务管理部署进入到一个全新领域。OSGi规范的目标群体为机顶盒、服务网关、有线电视Modem、电子消费品、PC、工业领域计算机、汽车、手机等等。实现OSGi规范的设备能够在本地设备网络中提供差异化发布重要服务的功能。

​        这个OSGi规范的第五版本由OSGi成员公司代表提供。OSGi R5将现有大部分api扩展到新应用领域。已有的API没有任何变化，使用R4版本的应用仍然可以在R5版本下运行，API仍然向前兼容。内部版本管理在必要情况下还是会允许Bundle能够在旧框架下运行。

​

​1.1 OSGi Framework 概述

​        Framework是OSGi规范的核心组成部分。它提供了通用、安全可管理的Java Framework，这个Framework可用来部署可扩展、可下载的一类应用（这类应用也被称为Bundle）。

​        OSGi兼容设备能够下载安装OSGi Bundle，当他们不在需要的时候还可以删除Bundle。在动态可扩展的OSGi环境中，Framework管理Bundle的安装和更新。同时Framework也管理着Bundle和Service的之间依赖关系。

​        Framework给Bundle开发者提供必要的资源在Java平台上进行开发，另外为开发的Bundles提供了代码动态加载的功能, 这也使得开发者在开发和部署一个大规模Services时变的很容易。

​        Framework的功能分为以下几层：

• 安全层（Security Layer）
• 模块层（Module Layer）
• 生命周期层（Life Cycle Layer）
• 服务层（Service Layer）
• 真实Services（Actual Services）

 

      Framework分层图 1.1

​

​        安全层基于java2 security，但是在这基础上添加了大量的限制，并补充了相应的Java标准。在这个层次中定义了安全包格式，以及运行时如何与java2 security层进行交互的方式。Framework Security层将会在第2章中详细描述。

​        Module层为Java定义了模块化模型，并且克服了java部署模型中的一些缺点。在模块化模型中为Bundle间的Java package共享和隔离定义了严格的规则。这个Module层能够独立于Life Cycle层和Service层使用，在Life Cycle层中提供了管理模块化Bundle的API，另外Service层提供了Bundle间的通信模型。Module层的详细描述在第3章。

​        Life Cycle层提供了管理Bundle生命周期的API，而且这个API为Bundle提供了运行期模型，定义了Bundle如何被启动、停止、安装、更新以及卸载。另外，还提供了一个完善的事件驱动API，用于在OSGi framework中管理和控制Bundle。Life Cycle层强依赖于Module层，但是不一定需要Security层依赖。在第4章对Life Cycle有更细的描述。

​         Service层为Bundle的java开发者提供了一个动态、简单的编程一致性模型，并使得Bundle服务开发和部署简化，而且Bundle服务接口与Bundle服务实现无耦合。这个模型允许开发者使用Bundle服务接口来绑定具体的服务，具体的服务实现将会在运行期获得。

​        Framework使用的服务层提供了一种可扩展机制(hook)，这种hook机制是指可由Framkework提供额外功能的一种服务。

​        编程一致性模型帮助开发人员很好处理不同问题的可扩展性，而且framework希望服务实现能够运行在各种有不同硬件特性的设备中。另外一致性接口也会确保多种组合的服务组件能够在系统中稳定运行。

​         Bundle能够在运行期时通过Framework，从service注册中选择一个合适的实现，Bundle则依据当前设备的功能来注册新服务、接受服务或者查询服务。Framework从而使得一个安装后的Bundle在部署之后仍然能够被扩展：在不重启系统的情况下安装新Bundle来增加新功能、或者对已存在的Bundle进行更新。Service层会在第5章详细描述。

​

​Framework各层次之间的交互图 1.2

​

​1.2 读者层次

​        这个规范适合以下读者阅读：

• 应用开发人员
• 框架和系统服务开发人员（系统开发人员）
• 架构师

        OSGi规范希望读者有1年以上Java编程经验，如果有嵌入式系统或者服务器环境开发经历更好。应用开发人员需要了解OSGi环境相对传统桌面系统或者服务器环境具有更明显的动态性。

​        系统开发人员要求对Java有深入的理解，在任何一种系统环境中有至少3年的Java编码经历。Framework用Java实现和在传统应用中实现通常是不一样的，需要深入理解类加载、垃圾回收、java2安全、java native库的加载。

        架构师需要关注每个专题的介绍，这些介绍包含了专题概述、影响设计的需求、简短的操作描述和实体描述。在介绍章节中有java类和接口的概念，这些内容不要求有编码经历。

这些规范大部分适用于应用开发人员和系统开发人员。

 

1.3规则与术语

        1.3.1排版

        用无衬线字体表示这个类型是java package，class，interface或者成员变量，通常用这个做java编码字体。

        当一行文字必须被强制分隔成2行时，用<<符号代替，如：

http://www.acme.com/sp/«

file?abc=12

等价于

http://www.acme.com/sp/file?abc=12

 

        1.3.2 通用语法定义

​        在标准中的多数例子，需要有些符号语法描述，符号语法：

*重复0次或者多次如( ’,’ element ) *

+重复1次或者多次

?重复0次或者1次

( ... )分组

’...’文字

|或

[...]Set

..列表,如1..5表示列表1 2 3 4 5

<...>外部定义的符号

~非

 

        在本规范中预定义了以下符号:

ws ::= <参考Character.isWhitespace>

digit ::= [0..9]

alpha ::= [a..zA..Z]

alphanum ::= alpha | digit

token ::= ( alphanum | ’_’ | ’-’ )+

number ::= digit+

jletter ::= <参考[1]Java Language Specification Third EditionforJavaLetter>

jletterordigit::= <参考[1]Java Language Specification Third EditionforJavaLetterOrDigit >

qname ::= /*参考[1]Java Language Specification Third Editionforfully qualified class names */

identifier ::= jletter jletterordigit *

extended ::= ( alphanum | ’_’ | ’-’ | ’.’ )+

quoted-string ::= ’"’ ( ~["\#x0D#x0A#x00] | ’\"’|’\\’)* ’"’

argument ::= extended | quoted-string

parameter ::= directive | attribute

directive ::= extended ’:=’ argument

attribute ::= extended ’=’ argument

unique-name ::= identifier ( ’.’ identifier )*

symbolic-name ::= token('.'token)*

package-name ::= unique-name

path ::= special-chars+ | quoted-string

special-chars ::= ~["\#x0D#x0A#x00:=;,<参考[1]Java Language Specification Third Editionforwhitespace>]

 

        空格在终端中是被忽略的，除非是被特殊引用。任何包含空白、逗号、小分号、分号、等号或者任何不是语法字符的也都是可被引用的.

​

​        1.3.3面向对象术语

        类、接口、对象和服务的概念不一样但是也不好区分，如“LogService”可以表示成LogService类的实例，也可以表示成LogSevice类，甚至可以表示成Log服务。专家们通常通过上下文来理解具体的含义，故使用以下规则来突出这些概念。

        使用类的时候，类名需要与Java类文件名一致，如“HttpService类”、“HttpContext类的一个方法”、“javax.servle.Servlet对象”。在上下文中无法确定这个类所在的package时，那就应该使用带package路径的类名（如javax.servle.Servlet），当然有些package下的类可以省略包名（如java.lang, java.io, java.util and java.net），java.lang.String可以直接写成String。

​        在多数情况，一个类型可以是Collection类型或者数组类型，这些情况下，类型后面可以带上+符号，如String+（表示只有一个String、一个String[],Collection<String>）。

​        Exception类或者Permission类不允许名称成“object”，为了提高可读性避免使用“object”后缀。如“throw a Security Exception”或者“File Permission”。

​        Permission可以进一步限定一些行为。 ServicePermission[com.acme.*,GET|REGISTER] 表示 ServicePermission 允许对com.acme.*的类执行GET 或者REGISTER行为。ServicePermission[Producer|Consumer, REGISTER]表示ServicePermission允许对Producer类或者Consumer类执行REGISTER注册行为。

​        当服务要注册到OSGi Framework时，服务注册需要包含Service接口类、属性集合、Service接口的实现类等信息，这个注册的服务类和接口必须是类型安全、命名规范的。因此，服务对象是以类/接口维度进行注册的，如将PermissionAdmin类做为服务注册到OSGi Framework。

​

​        1.3.4图表

         在规范文档中使用图表，目的是为了在页面中提供一个更高层次的概述。以下段落中描述图标符号和规则：

        类和接口用矩形表示,如图1.3。

        接口在第一行用<<interface>>表示，规范的类或者接口使用粗体，但是可能会用普通字体来表示实现类。有些时候类名会用省略号表示。如果接口作为服务使用，则右下角会有一个黑色的三角形，如图1.4

​

​图1.3类和接口

​

​

​图1.4

​

        ​Service在服务交互图中会出现多次，因此这种交互行为用一个三角形代替，这个三角形不同位置的连接关联不同的服务含义：

​点：与三角形箭头点的连接位置。表示接收服务提供方方法的回调。

直边：表示连接了客户端服务，客户端调用Service方法

直角边：Service Listener

​

​

​图1.5

​

​        

​         继承、实现或者扩展关系用实心箭头表示，如图1.6

​

​图1.6

 

          用直线表示关联关系，如图1.7显示了BundleContex类与BundleListener是一对多的关系。

​

​图1.7关联关系​

​        

​        类之间的关系用虚线描述则表示类之间存在关系，但并不一定有强依赖。如“每一个ServiceRegistration类有一个ServiceReference类关联，但是这个关联不是强依赖关系，而是从其他方式上推断出来。

​        当一个关系使用了名称或者对象标识，还是用点垂线描述的。这样的关系通常是Map类型的对象实现。如图1.8 显示了使用name来标识UserAdmin类和Role类的1对多关系。

​

​图1.8

​

​        Bundle是应用中编写的一系列可见实例。例如，当一个Bundle停止运行时，对应的服务将会被卸载，这些被卸载一组类/接口是指图1.9里灰色矩形内容.

​

图1.9 Bundle

​

        ​1.3.5关键词

​在OSGi R5版本中，对may,should和must的描述如下：

•must–绝对.Framework实现和Bundle必须遵守的规范。

•should–推荐。建议遵守的规范描述内容，但是也可以不遵守。

•mayorcan–可选.

 

1.4版本信息

         这个文档是OSGI的第5个版本。他向后兼容以前的4个版本。Security、Module、Life Cycle和Service层是Framework的重要组成部分。组件也有自己的规范版本，与OSGI R5版本独立。下表总结了package版本和规范版本的区别，当一个组件成为一个Bundle时，必须在Bundle manifest头文件里的Import-Package和Export-Package中指定package版本。

 

表1.1 Packages和OSGi Core Release 5版本

项目	Package	版本
Framework 规范核心	org.osgi.framework	V1.8
Framework 启动	org.osgi.framework.launch	V1.2
资源文件管理API规范	org.osgi.resource	V1.0
Bundle Wiring Api规范	org.osgi.framework.wiring	V1.2
Framework命名空间规范	org.osgi.framework.namespace	V1.1
启动级别API规范	org.osgi.framework.startlevel	V1.0
ConditionalPermission Admin Service规范	org.osgi.service.condpermadmin	V1.1
Permission Admin Service 规范	org.osgi.service.permissionadmin	V1.2
URL Handlers Service规范	org.osgi.service.url	V1.0
Resolver Hook Service规范	org.osgi.framework.hooks.resolver	V1.0
Bundle Hook Service规范	org.osgi.framework.hooks.bundle	V1.1
Service Hook Service规范	org.osgi.framework.hooks.service	V1.1
Weaving Hook Service规范	org.osgi.framework.hooks.weaving	V1.1
数据传输对象规范	org.osgi.dto	V1.0
Tracker规范	org.osgi.util.tracker	V1.5
注解版本	org.osgi.annotation.versioning	V1.0

 

1.5修改记录

• 删除了远程服务部分
• 将Tracker加入到核心规范中
• 增加了资源文件相关API规范，这个也是框架所应具备的能力。
• 增加了一些命名空间（Namespaces），具体后面会详细介绍。
• 增加语义版本类型角色
• 增加数据传输对象
• 增加服务作用域和原型服务工厂

1.6引用

[1]Java Language Specification Third Edition http://docs.oracle.com/javase/specs/