OSGi 开放式服务平台技术(一)

OSGi 开放式服务平台技术

―家用网关器与智能型车辆之应用

 

黄永顺 李坤敏 吴文玲 林文玮

工业技术研究院 计算机与通讯工业研究所

 

摘要

由于网际网路的快速发展，使得个人对网际网路的需求日益增加，并不只局限在工作环境中所需求，而是慢慢与家庭生活互相结合，因而数位家庭的生活随之展开。在数位家庭中，为内外网路环境搭起了沟通桥梁的家用网关器即扮演了一个关键性的角色，家庭中各种装置将透过家用网关器而彼此互相沟通。OSGi 技术为Open Service Gateway Initiative 协会所制定，目的在于制定一个整合性的信息服务平台，并将其整合至家用网关器里，并使远程软件服务供货商所提供之应用程序及加值服务，能视使用者所需求，透过网际网路动态地下载至用户的家用网关器上，且能够地自动安装执行。本文将就OSGi 的架构、技术及开发工具做简单之介绍，并就以OSGi服务平台为基础之家用网关器与智能型车辆之相关领域应用进行介绍。

一、前言

自1968年起，美国国防部接受公司与大学的建议，开始发展ARPANET网路，着手进行实验性的封包交换网路计划，连接分散于全美各地的计算机系统，使科学家与研究人员能分享资源，共享计算机设备，从此开始网际网路的新世界。从实验性的网路，到操作性网路，发展到TCP/IP通讯协议，一路走来，为往后的网际网路奠定了良好的基础。

随着网际网路的蓬勃发展，网路对于人们，不再局限于工作场所的搜寻工具，人们开始将它与生活结合。根据 TWNIC 台湾网路信息中心公布2004 年「台湾宽带网路使用调查」年中报告中显示，至 2004 年 7 月中为止，台湾地区上网人口已达 1,274 万人，上网率高达 56.49%，其中宽带网路使用人数就达 936万人，约占总人口数的五成，宽带网路的发展以稳定的速度持续成长。这意味着，有越来越多的人正在将网际网路连结到家中，「后 PC 时代」即将来临。

后 PC 时代，意味着信息家电将进入家庭中。对家庭环境的一般使用者而言，功能强大的计算机还是过于复杂。他们期待能有一种装置，在操作上方便、简单，功能明确，且同样具有连网的能力，信息家电就是因应这样的需求而产生的。当家中的客厅摆上连接内外网路的家用网关器（Residential Gateway，RG），厨房里有了自动提供食谱的网路冰箱，阳台的洗衣机会连网通知经销商它的马达出了问题，数位家庭生活于焉展开。

数位家庭的概念持续延烧，至今在产业界仍未止尽，家庭中最具代表性的场所便是客厅，「决战客厅」的口号于是喊出。在家庭网路的应用中，客厅里的家用网关器扮演了一个关键性的角色，为内外网路环境搭起了沟通的桥梁。对外，信息服务透过宽带网路进入客厅中的家用网关器，再由家用网关器过滤，分配给家庭中其它适当的装置；对内，家用网关器用以连结各式不同的网路环境，如WLAN、802.15.4/Zigbee、HomePNA、ECHONET、LonWorks、UPnP、1394… 等，使各种装置能透过家用网关器而彼此沟通。

1999 年3 月，一些营利与非营利公司及机构组织了 OSGi（Open ServiceGateway Initiative）协会，期望能制定一个整合性的信息服务平台，并将之整合至家用网关器里。OSGi 协会发展至今会员遍及欧美日，主要厂商有系统设备商、消费性电子厂商、汽车厂商，共一百多余家，包括了IBM、Motorola、Nokia、Philips、Panasonic、Sony、Toshiba、Echelon 等。 OSGi 制定标准的最主要目的，是为了提供远程的软件服务供货商与本地端的设备，一个点对点的服务传送方案。使得远程软件服务供货商能视使用者需求，将应用程序或加值性服务，动态的透过网际网路下载至客户端的家用网关器上，并且自动执行安装服务。

在底下的章节里，我们将简单介绍 OSGi 的架构，介绍架构中三个主要的组件：Framework、 Bundle 与 Service。接着说明 OSGi 厂商根据规格书所实作出来的参考实作与开发工具有哪些；还有规格书目前订定的状况，并简介 3.0版的规格书中所定义的服务有哪些。第三章则描述何谓家用网关器，并介绍OSGi 的实际应用场景。在这样的场景里，我们将可发现，这「网网相连，装置互通」的信息环境，其实已经奠定了无所不在的泛在运算（Pervasive Computing）基础。

二、OSGi 服务平台技术及开发工具介绍

OSGi 成立的目的在于定义一个开放性的平台，使远程软件服务供货商所提供的应用程序及加值服务，能视使用者需求，透过网际网路动态地下载至用户的家用网关器上，且能够自动安装执行。「开放性」意味 OSGi 的会员皆可参与标准之制定，并遵循此标准开发符合规格的产品。在此开放性的架构下，不同厂商所开发出来的服务软件、设备就能彼此沟通或搭配使用。

‧(一) OSGi 服务平台技术介绍

    如图一所示， OSGi 架构主要由三种组件所组成： Framework、Bundle 和Service。Framework 架构在 Java VM（Java Virtual Machine）上，Bundle 则是执行于 Framework 上的应用程序，而 Service 是 Bundle 所提供（Export）或所需（Import）的接口服务。 从远程下载的Bundle 会在OSGi Framework 上自动安装、执行，并跟 OSGi平台注册 Bundle 所提供分享或所需要的服务（Service）。 以下段落将就OSGi Framework、Bundle 和Service 详细说明。

图一 OSGi 服务平台架构《 OSGi Alliance》

OSGi Framework 为一整合性的信息服务平台，主要的功能是提供 Bundle

的执行环境与动态地调整 Bundle 挂载的生命周期（Bundle life cycle）。OSGi

Framework 也提供管理机制让执行其上的Bundles 可以（Export）或使用（Import）

Service。 Bundle 之间可透过 Service 的分享，以节省程序的开发时间或增加程

式之功能。

如图二所示，OSGi Framework 管理的Bundle 生命周期可分为六个状态：己安装（INSTALLED）、等待启动（RESOLVED）、启动（STARTING）、执行（ACTIVE）、停止（STOPPING）以及取消安装（UNINSTALLED）。当Bundle被停止时，Framework 会将Bundle 所注册（Register）的Service 动态地移除（Unregisters），在同一时间内，也会通知有使用该Service 的其它Bundle，让其他的Bundle 得知该事件。

图二 Bundle 生命周期《 OSGi Alliance》

Bundle 的中文名称是服务包，由OSGi Framework负责启动与执行。就实作的角度而言，Bundle 是一个Java Archive（JAR）档案，该 JAR 檔包含 Java类别（Class）、启动类别（Activator Class）、清单文件文件（Manifest Header）和一些资源檔（如HTML 网页或JPG 图檔等）。清单文件文件主要描述该Bundle 所附加的信息， 并订定一些规则， 如Import-Package 、Export-Package 、Bundle-Activator、Import-Service 与 Export-Service 等。

Bundle 可将其所要提供（Export）的功能，以 Service 的方式来表示。Service是一个定义清楚的接口服务，其它需要此（Import）功能的 Bundle 可透过此介面来存取。当 Bundle 提供Service 时，Framework 会保留了一个相对应的ServiceReference，需要此 Service 的 Bundle 可透过 Framework 所提供的查询机制（基于LDAP 的语法），请求并取得所要的Service。在Framework 里，一个有效的应用是由一系列的Service 相辅相成所互相搭配而成。

如图三所示， OSGi 规格中所定义的 Service 包括 Standard Services 与Custom Services 两种：Standard Services 是由OSGi Framework 本身所提供 ;Custom Services 则较为弹性，主要由服务厂商定义开发，目的在于区隔产品服务市场。

图三 OSGi Standard Services与Custom Services《OSGi Alliance》

 

如图四所示， 在 2000 年 5 月所发表的OSGi SPR1 (OSGi Service Platform Release 1)，定义 Device Access、Http 和 Log 等服务，提供基本的服务架构;2001 年10 月OSGi SPR2 发表时， 新增了 User Administration、Configuration Management 等服务，着重于安全性能与管理配置功能的增强; 2003 年3 月发展至OSGi SPR3，除了与 1.0 及 2.0 版本兼容外，更新增一些工具、管理、网路等相关服务，如 UPnP Device 、 Jini Driver 与 XML Parser 等服务。

图四 OSGi 规格《 OSGi Alliance》

(二) OSGi Standard Services 介绍

OSGi SPR3 将其所提供的Standard Services 分为以下四类：Framework Service、System Service、Protocol Service 和Miscellaneous Service。在此我们将针对 SPR3 所定义的 Standard Services 做一个简单的介绍，更详细的资料请参阅 OSGi 的官方网站（http：//www.osgi.org）。

Framework Service

提供Permission Admin、Package Admin 和Start Level 等服务。

u      Permission Admin：提供管理代理人（Management Agent）来管理Bundle 的

Permission（允许权）。主要提供一PermissionAdmin 接口，透过该接口可对Bundle 的Permission（允许权）资料贮存器进行存取控制。

u      Package Admin：该服务除了能提供 Framework 上 Packages 分享的状态外，还可处理Packages 之间的依赖关系（Dependencies），即Bundle 所提供（Export）及使用（Import） Service 的情形。

u      Start Level：可决定启动或停止 Bundle 时的顺序。它会指定Framework 一个有效启动等级（Active Start Level），并给予每个Bundle 一个启动等级（Start Level）。当要有效地启动Bundle 时，其启动等级（Start Level）必须等于或小于Framework 的有效启动等级（Active Start Level）。

System Service

u      Log Service：提供 Log Service 和 Log Reader Service 两种服务接口。Log Service 是用来记录有关事件、警告和除错等信息，而 Log Reader Service 则用来读取 Log 所记录的信息。

u      Configuration Admin：该服务提供弹性（Flexible）及动态（Dynamic）的模型（Model），可用来提供一些组态的设定与管理，如Port Number、Log Bundle等等。

u      Device Access Service：可自动侦测新加入的装置（Device），并动态的下载该装置的驱动程序（Bundle），使该装置能正常地运作。

u      User Admin Service：提供使用者认证及授权的服务。

u      IO Connector Service：根据 J2ME Connector Framework 的设计理念，参照javax.microedition.io 定义一个弹性且具延伸性的 Communication APIs。也可允许自行定义其它的 Communication APIs。

u      Preference Service：允许 Bundle 存取永久性的资料。这些资料可能属于特定使用者（User Specific）或是系统（System Specific）。资料以 key/value 的方式储存在远程的机器。类似于Windows 系统的 Registry 或 Java 的Preferences 类别。该服务与 java.util.Properties 不同的地方在于它支持分级制度（Hierarchical）的命名模型（Model）。

Protocol Service

u      Http Service：可将该服务视为一个Web Server，可执行 Bundle 所注册的Servlets 或相关的 Resources（例如：HTML、JPG 和.wav 等）。又，因为 OSGiFramework 具有动态更新 Bundle 的功能，所以 Web Server 不需重新启动便能够更新旧有的 Servlets 或是执行新加载的 Servlets。

u      UPnP Service：可将UPnP 的服务转换为OSGi 的服务或将OSGi 服务转换为UPnP 的服务。

u      Jini Service：在OSGi 与Jini 之间定义一个桥接（Bridge）的方式。更明确的说，它针对Jini-to-OSGi 和OSGi-to-Jini 定义一个转换接口。

Miscellaneous Service

u      Wire Admin：以生产者（Producer）和顾客（Customer）的方式来表示 Bundle之间的关系，顾客可向生产者订阅它所感兴趣的讯息，生产者将定期的将讯息传送给顾客。此服务以wire 来连结 Bundle 之间的关系。

u      XML Parser Service：定义XML、SAX 和DOM Parser 在OSGi 服务平台里要如何的提供及使用。

u      Position：利用WGS-84 GPS code 来处理地理位置及移动相关信息。Position对象包含了纬度、经度、海拔、轨迹和速度等领域。

‧(三) OSGi 参考实作与发展工具

本节将介绍关于 IBM、ProSyst、Gatespace、Microsystems 等厂商，依据OSGi规格所开发出来的参考实作与应用开发工具，如表一所示。

表一 OSGi 相关应用开发工具列表

 

IBM, Service Management Framework （SMF）

IBM Websphere Device Developer 为一个整合式的开发环境平台。Websphere 提供手机、PDA 等嵌入式装置的程序开发环境，软件开发厂商可在其上开发相关的行动应用程序，例如J2ME 的应用程序。Websphpere 同时也整合了SMF—IBM 自行开发的 OSGi 参考实作。软件开发厂商可藉由Websphere所整合的Bundle Developer Plug-in 功能，快速开发OSGi Bundle、ManifestHeaders，并对其进行测试。SMF Framework 目前虽己符合OSGi 3.0 的规格，但还未将OSGi 3.0 所有的规格给加入，如Start Level、I/O Connector、Wire Admin、Jini Driver 与UPnP Device 等服务都尚未被加入SMF Framework。 相关参考网址：http：//www-306.ibm.com/software/wireless/smf/

ProSyst, mBedded Server

ProSyst 针对 OSGi 提供一系列完整的产品：mBedded Server, mBedded Remote Manager 与 mBedded Builder。其中，mBedded Server 为ProSyst 自行开发的 OSGi 3.0 参考实作。mBedded Remote Manager 提供 OSGi 一个远程控管的简单接口程序。而 mBedded Builder 则提供软件开发厂商 OSGi 程序撰写的开发平台。 相关参考网址：http：//www.prosyst.com/solutions_html/mbeddedserver.html

Gatespace Telematics, Ubiserv

Gatespace Telematics 所提供的 OSGi 3.0 参考实作—Ubiserv 目前隶属于Knopflerfish 开放原始码项目。该项目于1999 年开始，原来分成两个部分：GDSP（Gatespace Distributed Service Platform）与SGADK（Service Gatespace Development Kit）。GDSP为OSGi 的参考实作，SGADK则是相关的工具与应用程序。GDSP 与 SGADK 后来都被 Ubiserv 所替代。Gatespace 的Ubiserv着重于无线数据通讯和多频率方面。 相关参考网址：http：//www.knopflerfish.org/

Sun Microsystems, Java Embedded Server （JES）

JES 为 Sun 所开发的 OSGi 1.0 参考实作，亦为开放软件，可在 Sun 的官方网站上下载使用。目前的版本支持Solaris、Linux 与 Windows 等操作系统平台。 参考网址：http：//wwws.sun.com/software/embeddedserver/

这些 OSGi 的参考实作（IBM 的SMF, ProSyst 的mBedded Server, Gatespace的Ubiserv, Sim 的JES），已经被应用在家用网关器中。市面上可见的家用网关器已使用 OSGi 平台的产品有Cisco 的Internet Home Gateway（iHG）使用Gatespace Ubiserv 平台、撼讯（Tul）的SG 2100+使用IBM SMF 平台。此外，这些OSGi 的参考实作亦被运用于智能型车辆之应用上，如：知名汽车大厂BMW的iDRIVE 与iWALK 系统，与Volvo 车厂的RTL 系统，即分别使用ProSyst 的mBedded Server 与Gatespace 的Ubiserv 平台；另外，亦有一些相关计划也是应用于此智能型车辆之相关领域，如：Politfish 组织所提出之B2B 汽车分享式系统（B2B Car-Sharing System）。

三、以OSGi 服务平台为基础的家用网关器设计

网际网路日益普及，间接带动信息家电与家庭网路的蓬勃发展。在需求、技术、市场一切浑沌未明的情况下，软硬件厂商百家争鸣，家庭网路的相关应用也随之复杂了起来。为整合家庭网路中各式不同的通讯技术与连结接口，并藉此提供一致性而多样化的服务，我们需要一个整合型的网路接取设备，即家用网关器。它也是「决战客厅」中的关键角色。家用网关器除可作为网路接取的设备外，它还有一个重要的功能，就是开放性的服务平台。远程的服务供货商（Service Providers）可透过家用网关器，将客户端所需的各式生活信息与服务，透过网际网路，动态的下载至客户端的家中，提高人们生活的便利性。本节我们将简述，一个植基于 OSGi 服务平台的家用网关器，在实际生活中可扮演什么角色，而我们透过它，又可得到什么样的服务。

如图五所示，在家庭网路环境中，OSGi 组织所定义的OSG（Open Service Gateway，开放性服务网关器） 对外可与远程的服务供货商连结，对内则与家庭网路相连接。当使用者购买一个符合OSGi规格的新产品，并将之连接到家庭网路时，OSG 会自动侦测到此装置，并透过 WAN Port 与远程的服务供货商连结，认证了使用者的注册资料后，OSG 便会从远程下载适当的服务包（Bundle），自动执行安装，连接到家庭网路中的新装置，便可正常使用。而使用者也可透过OSG所提供的远程遥控功能，从外地透过网路与OSG，远程遥控连接到家用网路上的新装置。当装置发生错误时，OSG 会自动将这些错误讯息以 E-mail 或用简讯的方式通知远程的服务人员，服务人员亦可透过 OSG 对设备进行诊断，并根据结果来决定下一步该怎么做。

图五 OSG 与服务供货商及家庭网路之关系图《取自 OSGi Alliance》

一般来说，家用网关器的系统架构，需从硬件、软件两方面来分析、考量。硬件方面，CPU 的选择就是一门重要的学问。为应付日益复杂的家庭网路架构，家用网关器所使用的 CPU 性能不能太差，如X86，ARM Xscale，PowerPC，MIPS..等都是常见的选择。但因其设计理念的不同，使用需求的差异，CPU 的选择也要有所斟酌。以OSG 来说，我们会建议功能强、连网能力好、扩充性强的CPU，如 X86 或是ARM Xscale。

软件方面，包括操作系统及其上面各种 Protocol 的选定，也是需要斟酌。我们选择 Linux 当我们的操作系统，主要原因是 Linux 的网路支持完整，系统安全与稳定。您也可以视自己的需求，而选择 WinRiver vxWorks、PSOS、Nucleus…等操作系统。操作系统架设完后，就要提供 OSG 各式网路的Protocol支援。图七为软件系统架构图：图中的 TCP/IP、ARP、ICMP、Firewall、NAT、DHCP、HTTP…等 Protocol，皆已内建在新版的 Linux 核心中，所以我们就不需另外安装。至于一些需求比较特殊的Protocol，如 Routing Protocol、Security（包含无线与有线的）…等，就需额外加灌软件进去。至于操作系统上要安装哪些 Protocol，就要看系统分析、使用需求分析与 OSG 的规格书而定。

网路功能与安全机制建置完成后，紧接着就是要把 OSGi Framework 架构到家用网关器上去。因 OSGi Framework 是 Java-based 的服务性平台，所以需要在 Java VM 上执行。见图六，我们在操作系统上加装 JVM，其地位与其它Protocol 平行。当软硬件的架构都完成后，我们就可以开始设计并撰写一些符合OSGi 规范的服务包（Bundle），提供给使用者使用。

图六 OSG 软件系统架构

接下来，我们会针对一些未来家庭生活中可能会使用到的应用程序，并在