什么是移动微件

移动微件是在移动互联网领域对微件技术的提升和应用，同时受到运营商、终端厂商、平台厂商和应用软件提供商、内容提供商的重视，是因为它可以满足产业链上不同角色的需要。从运营商角度看，移动微件可以作为业务运营的一种良好方式；从终端厂商角度看，移动微件可以用于增加其终端的可定制性；从平台厂商角度看，移动微件可以作为其控制终端桌面，从而实现控制用户的一种方式；从应用软件提供商来看，移动微件易于开发、易于部署的特性使其成为应用开发的较好平台；从内容提供商角度看，移动微件是开展内容服务的较好通道。

移动微件的实现方案

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

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

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

各规范的内容大致如下：

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

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

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

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

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

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

(7)《Widgets 1．O：URI Scheme》：规范化Widget内部所使用的URI的语法和模式，目前尚无实质内容。

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

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

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

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

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

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

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

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

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

安全策略规范——安全策略的一个互操作的×ML描述，定义访问一个特定Web应用和Widget所需的BONDI APls。

开源的参考实现(Rl) -有关接口和安全规范应该实现的一个实际的、具体例子， Rl SDK包含API文档和代码。

BONDI工作组要确定的规范必须提交W3C和OpenAjax联盟审阅和修订。

OMTP BONDI已经正式提交给W3C作为Widget API的输入文稿，这表示BONDI和W3C的工作会逐步走向统一。

虽然BONDI的参与者众多，但是其产品化推进一直没有得到太多的重视，导致其接口定义虽然完整，但是真正实现BONDI的厂家较少，不利于其推广应用。

诺基亚于2007年8月24日发布了在S60平台上的Widget引擎并且宣布在其未来所有发布的S60手机都将支持自己的Widget产品。Widget的运行基于Web Run-time（以下简称WRT）。WRT是S60 SDK 3rd EditionFeature Pack 2中新增加的浏览器组件。它是一个Web应用开发环境。

Nokia Widget的使用方式与S60本地应用一样。作为Widget的运行平台，WRT设计目标之一就是使Widget与S60平台进行无缝集成，给用户一致的使用体验。例如，每个Widget都可以在应用程序菜单中显示图标；可被设置为待机状态下的快捷键和左右软键；能出现在活动应用列表中；具有与现有的S60应用一样的管理方式，如安装、卸载等等。由于功能简单，WRT占用资源较其他Widget引擎要小。同时，由于WRT是基于S60浏览器环境构建，技术相对较成熟，对资源的利用效率也较高。

从标准的角度来说，诺基亚提供了以下输入文稿到W3C，作为W3C DAP组的起草文件：Nokia´s calendarAPI, Nokia´s camera API, Nokia´s contacts API,Nokia´s messaging API, Nokia´s System Info API,Nokia´s DeviceException Interface。

整体上说，OMTP和Nokia都是W3C成员．OMTP正在将其BONDI规范，Nokia也正在将其JavaScript API规范提交W3C供讨论。

BAE是中国移动主导的，面向移动互联网的、开放的、跨终端操作系统平台应用运行环境。它基于开放的浏览器技术，为移动互联网应用提供了跨平台的运行环境，为开发者提供基于标准Web技术开发移动互联网应用的基础，降低了手机终端应用和业务的开发和部署难度；为终端用户在手机终端上提供移动互联网全新体验。目前，BAE支持JIL Widget格式（中国移动与沃达丰、软银、Verizon共同定义、遵循的Widget标准），同时兼容部分互联网上流行的Widget，如Apple Dashboard Widget等。

JIL Widget的特点是提供一套可产品化的参考实现。同时，JIL Widget项目也在与移动软件开发商、设备制造商的战略合作，推动丰富的产品开发工作。更进一步，JIL Widget也会提供相应兼容性测试工具。另一方面，JIL Widget标准化的工作重点是推动个人及第三方的Widget开发工作，构建一个开放的、全球化的开发者社区。JIL Widget希望通过以上这种方式来建设一个较为完整的、能够商业化运营的移动Widget产业环境。

从技术层面上来讲，JIL和BONDI的API定义各有特色，但是JIL更加重视产业化推进，配套开发工具和开发包等比较完备。

JIL Widget的主要特点是运营商主导，推进迅速，但是其并没有纳入W3C规范，即没有正式向W3C输入文稿，在具体的API定义方面也与W3C的路线有冲突，该方案能否在全球范围内取得成功，还需要时间的检验。

移动微件业务发展策略

从移动微件业务本身来说，支持何种形式的应用都有可行性，但是技术毕竟有其局限性，除去标准化的因素，结合运营商自身的需求，找准移动微件最适用的业务形式，是移动微件业务成功的关键因素之一。这里重点考虑两方面的问题：一是移动微件从技术角度来说适用的应用形式；二是移动微件如何与其它业务相结合。

从技术角度来说，移动微件对复杂逻辑的处理能力有限，因此难以用来开发较为复杂的本地应用，如大型游戏等，至少在现阶段仍是如此。从微件简单易移植的特性来说，更加适合信息类的应用，以及对现有应用进行UI优化或者集成的方面，除简单的天气预报、新闻类业务外，可以重点考虑话费查询、影音播放等逻辑较为简单的业务，以及开展广告等后向收费型的推送业务。从移动微件与其它业务的关系来说，移动微件可以成为其它业务的良好承载形式，如将运营商常见的手机音乐、手机电视、手机邮箱等业务用移动微件的形式来提供，即可提高应用的可移植性，加快部署速度，也可以有更优化的UI和更灵活的界面布局控制。从部署策略来说，移动微件常与应用商厦相结合，可以成为应用的一种形式。但是，移动微件在访问控制上有更高的要求，特别是终端本地能力访问控制上，比常见的应用有更好的控制力，因此移动微件也有自己的控制平台，除通过移动微件引擎进行控制外，部分功能还需要与平台联系来确定应用的访问权限。从发展的趋势来说，移动微件的策略应该是与本地应用相混合，从形式上不再让用户区分是微件应用还是本地应用，也就是类似Palm在发展WebOS时的技术途径，但是应用之间应该有相互调用的机制，以保证业务的一体化。