移动微件技术及标准进展

【摘要】移动微件(Mobile Widget)技术被业界认为是开展移动互联网业务的良好载体。移动微件最大的问题是缺乏标准化,导致各厂家微件的实现不尽相同,运营商采用微件部署业务因而存在困难。文章对移动微件技术的现状进行总结,并对标准化过程存在的困难进行了分析。

【关键字】移动微件 移动互联网 Web2.0 移动业务

1 微件及移动微件概述

Widget是指利用Web技术,通过XML和JavaScript等来实现的小应用,可以分为桌面Widget和Web Widget。随着移动互联网和嵌入式设备的发展,Widget逐步在手机和其它终端上得到应用,继而延伸出移动Widget、TV Widget等嵌入式终端的表现形式。截至2008年3月,全球各大Widget平台上的应用已经超过20万个,用户累计下载量超过50亿次。按照使用设备的不同,这些Widget可分为 移动Widget和PC Widget;按照使用资源的不同,则可分为本地Widget、Web Widget以及混合Widget;按照实现业务种类又可以分为信息资讯类、媒体娱乐类、生活工具类、社区交友类等。

后来,Widget这个概念被引进到网页内部,形成Web Widget,典型的代表有Facebook Widget、Google Widget等。Web Widget并不需要一个专门的Widget Engine,只是网页中的组件,需要通过浏览器来运行。

移动Widget是将Widget引进手机以支撑移动业务而形成的一个概念。什么是移动 Widget?目前并没有一致的看法,也没有形成统一规范,但是Widget的技术思路和展现形式,使其成为手机应用的主要展现形式。

Widget是典型的自治应用,可以显示和更新远端数据,允许单一下载和安装在客户机或者移动设备。如同开发者的HTML文件,开发者的Widget依赖于各种文件格式和规格,以建造一个用户接口、脚本、封装、数字签名以及部署其应用。

2 移动微件主要方案对比

虽然移动微件的实现方案很多,但是从标准化的角度来说,真正具有标准化前景的方案有四种:W3C方案、OMTP BONDI方案、诺基亚的WRT方案、中国移动的JIL Widget方案。

2.1 W3C Widget

自2006年起,W3C开始制定Widget草案,目前由Web Applications(WebApps) Working Group负责。

图1是一个典型的Widget架构(源于W3C),最下一层称为主机运行时环境,通常是一个软件引擎,或提供功能的网页浏览器。大部分的环境主机运行时,通常会支持HTTP、IRIs、Unicode、HTTP,以及ECMAScript/JavaScript、CSS、DOM,其中还包括为了展现多媒体资源需要的支撑技术。

目前,此草案系列公开了以下几个规范,表1列出了各规范的时间规划。以目前来看,其推进计划明显滞后。

各规范的内容大致如下:

(1)《Widgets 1.0: Requirements》:针对打包、配置文件、程序语言接口、用户体验、安全与数字签名等内容提出Widget总体需求。

(2)《Widgets 1.0: Packaging and Configuration》: 涉及到资源文件的文件类型、内容、路径,打包方式,描述文件元数据等;规定Widget需用ZIP算法打包,并使用wgt作为文件扩展名;配置文件需用统一的文件名:config.xml,放在Widget包的根目录下;并进一步规范了配置文件所应使用的源数据及其语义:Widget,name,description,author,license,icon,content,feature,param,preference。

(3)《Widgets 1.0: Digital Signatures》:数字签名用于验证Widget包的完整性,需使用signature1.xml作为文件名,放在Widget包根目录下;并同时规范用户对签名文件的处理流程。

(4)《Widgets 1.0: APIs and Events》:定义Widget对象提供给应用程序(如jacascript脚本)调用的接口,具体包括一个Widget接口,其中包含如下属性:viewMode,locale,identifier, authorName,authorEmail,authorHref,name,description,version,width,height,preferences。如下方法:onmodechange,hasFeature,openURL,getAttention,showNotification。

(5)《Widgets 1.0: Access Requests Policy》:定义默认情况下的安全策略、安全声明格式以及对安全事件的处理流程。目前尚无实质内容。

(6)《Widgets 1.0: Updates》:定义了Widget更新需使用统一命名的update.xml文件名,并规范了此文件中需使用的元数据和更新处理流程。

(7)《Widgets 1.0: URI Scheme》:规范化Widget内部所使用的URI的语法和模式,目前尚无实质内容。

2009年7月3日,W3C DAP工作组(Device APIs and Policy Working Group)成立。DAP制定终端侧API,通过这些API,互联网应用和微件(Widget)能与终端提供的服务交互,如日程、地址本、摄像头等。同时,该工作组还研究制定安全框架,该框架管理对API的安全访问/调用。

应该说,由于W3C在互联网领域以及Web标准制定上的权威性,W3C的标准是最具有指导价值的。但是,由于W3C标准需要广泛征求各方建议,充分吸纳各种输入文稿,所以其制定速度较慢。因为草案较多,制定的内容也比较全面,因此至今仍未关于Widget标准的正式国际规范。

此外,对运营商采用Widget开展业务来说,由于W3C并未规定相关的平台侧技术要求,可能会造成具体运营时的困难。在具体的API定义上,W3C也处于起步阶段,这是影响Widget可移植性的主要因素,如果W3C标准要进入实际运营环节,还有很多工作要做。

2.2 OMTP BONDI

OMTP是由国外8家具有影响力的移动运营商组成的联盟,致力于移动应用的编程接口的标准化工作,针对Widget成立了BONDI项目,包含如下两项规范:

(1)《BONDI:Interfaces》:移动设备底层能力调用接口的标准化。

(2)《BONDI:Architecture_Security》:移动设备底层能力调用的安全架构。

OMTP将来打算将BONDI项目形成的规范推向W3C Widget,已于2008年8月与W3C签订了备忘录。因此可以认为OMTP BONDI与W3C Widget是相互兼容的。

BONDI由几个相关的规范组成。

API规范――一组生成HTML页的BONDI APIs的语法和语义定义。

安全策略规范――安全策略的一个互操作的XML描述,定义访问一个特定Web应用和Widget所需的BONDI APIs。