WBXML 与 SyncML 服务器的基本需求

2003 年 10 月 01 日

Edd Dumbill 一直在探求如何通过使用 SyncML,使他的数据在他需要的时候随时随地都可以访问，本文是这个系列的第二篇文章。文章介绍了 Wireless Binary XML（无线二进制 XML，WBXML），并探讨了 SyncML 服务器的最小功能需求。
在我的 前一篇专栏文章中，我介绍了对 SyncML 的研究与部署的情况。随着时间的流逝，人们在不同的地点，出于不同的需要，使用越来越多的设备。当人们出去旅行，或者是更换设备时，就会想，要是还能够访问自己的数据就好了。这就是 SyncML XML 协议的核心功能，它也迅速成为当前移动电话的功能选项。

上一次，我从很高的角度简要介绍了 SyncMl，并向您展示了从我的 Ericsson R520m 型移动电话向我的 Web 服务器发送的第一条 SyncML 消息。这条消息最让人吃惊的地方在于，它的编码不是用 XML，而是用 Wireless Binary XML（WBXML）。WBXML 是一项由 WAP 论坛开发的标准，意在提供一种能有效利用存储空间和 CPU 资源的 XML 表现形式。

虽然 WBXML 已经广泛应用于私有蜂窝电话网络，但是很多 XML 开发人员还是没有见过 WBXML。然而，要支持 SyncML，就要求同时具有处理这种编码和普通 XML 编码的能力。在这篇文章里，我将介绍 WBXML 编码的概要情况，将 SyncML 的 WBXML 编码处理成 XML 的步骤，以及从反方向将 XML 转换成 WBXML 的要求。我还将介绍 SyncML 协议的主要内容，以便能够为创建 SyncML 服务器搭好舞台。

WBXML 概述

XML 的二进制符号这个问题经久不衰，在这五年左右的时候中 XML 开发人员一直在讨论它。从上层看来，主要的观点分为两大阵营：第一大阵营倾向于定制新的编码，WBXML 使用的就是这种方法；第二大阵营坚持对普通的 XML 进行压缩，也可以达到类似的节省空间的效果。对于我来说，第二种方法似乎更加可取，因为这种方法能够重用一些通用的知名的软件组件。

然而，WAP Forum 却决定定制新的编码方案—— WBXML。随着 WAP 论坛后来制订的另外几种技术规范，先前这个规范也逐渐遭到批评。（有关对这些规范的批评的链接，请参阅 参考资料）

本专栏前一篇文章中的 图 1 显示，WBXML 用标记（token）的方法对 XML 进行编码。XML 中最常用的结构，如标签、属性、以及属性值等等，都缩减成只占一个字节的标记，其他一些文字可保留为原文。WBXML 也可以将普通的字符串缩减为标记，标记表则作为文档头部中的一部分传送。

WBXML 通过 代码页（ code pages）实现与 XML 命名空间等价。由于元素的标记只有27种——共占用5位，其中值从0到4为保留标记——复杂名词则需要进行复合，将标记集组织到不同的代码页中。代码页切换与切换缺省命名空间类似。SyncML 的 WBXML 编码对协议中用到的每一个 DTD 都使用一个代码页，它们分别是：SyncMl、SyncML Meta Information、以及 SyncML Device Information。

对 WBXML 的处理是相当简单的，即：读取文档头部，选择一组适当的标记表（这与应用程序的特定 DTD 有关），然后将文档中的标记处理掉。标记可能有下面几种：元素的开始/结束、切换代码页、实体、处理指令、经过标记处理的字符串、文字字符串、各种不同的扩展标记、以及 opaque 数据。最后一个， opaque，是 WBXML 中与 XML 的

CDATA

等价的元素。不同的 WBXML 应用程序按照不同的方式使用扩展标记。这些在 SyncML 编码中根本没有使用，但是文档头部中发来一个字符串表，WML 用上面那些元素处理经过标记的主体文本字符串。现在看来， WBXML 很显然不是一种通用的 XML 二进制编码。每个应用程序都需要一张标记表来进行查找，通常还需要编若干代码来解释扩展标记。

在对 SyncML 进行了这番研究之后，我决定将输入的用来表示 SyncML 的 WBXML 转换成相应的 XML，这样调试和划分模块会更加方便。这样，就只剩下相反方向的转换问题。

转换回 XML

如果您觉得解释 WBXML 很别扭，那么我恐怕不得不告诉你，创建 WBXML 会更加难受。并且，尽管有通用的算法可以将 XML 转换成 WBXML，应用程序相关的扩展机制也使问题变得复杂。为使您能够很好的理解其中的问题，请您阅读从 WAP Forum 的 WBXML 规范中（WAP-192-WBXML-20010725-a Version 1.3）摘录出来的这段话（有关该规范的链接，请参阅 参考资料）：

在用标记处理 XML 文档的过程中，我们 必须将所有的标志（markup）和 XML 语法（比如实体、标签、属性等等）转换为标记格式。所有的注释、XML 声明、以及文档类型声明，都 必须删除。为实现标记转换而设置的处理指令也 可以删除；但 必须保留所有其他的处理指令。所有的文本和字符实体都 必须转换成字符串（如

STR_I

）或实体（

ENTITY

）标记。文本标志（textual markup）中的所有字符实体（如 &），如果可以用目标字符编码中表示出来的， 必须在进行标记处理的时候转换成字符串格式。其他的（如那些无法在目标字符编码表示的）则 必须全部用

ENTITY

标记来编码。XML 解析过的实体（包括内部和外部的）必须在进行标记化之前处理掉。XML 符号以及未经解析的实体可在某个应用程序的基础上进行处理（比如说，用内嵌的 opaque 数据）。属性名 必须转换成属性的起始标记（这个标记如果这样定义的话，也将指定全部或者部分的属性值）或者 必须只用一个

LITERAL

标记来表示。属性值 绝对不能用

LITERAL

标记进行编码。

在 SyncML 的 WBXML 编码问题上有一个重大问题需要考虑，这个问题就是每一份文档的长度。无线设备的内存容量相对较小，显然不可能处理任意长度的响应。有个最常见的例子可以说明这一限制，即，WAP 页面中使用的 WML。在 WML 中，每一张页面都不能超过约 1500 字节。因为只有应用程序知道最适合进行分割的位置，所以显然需要在应用程序和编码模块之间进行协商，才能将输出分割成适当的大小。

SyncML 没有任由设备凭空猜测消息的大小，而是允许每一种设备都指明它能够处理多大的消息。Meta Information DTD 中的

MaxMsgSize

元素就是用于这一目的的。让我们来举个例子。我们从本文附带的资料（请参阅 参考资料）中的 example.xml文件里节选了一段内容，如清单 1 所示：

清单 1. 某个有效的 SyncML 文档的头部，其中显示了元信息

<SyncHdr><VerDTD>1.0</VerDTD> <VerProto>SyncML/1.0</VerProto> <SessionID>10</SessionID> <MsgID>1</MsgID> <Target><LocURI>sync.example.com</LocURI> </Target> <Source><LocURI>520327511080721</LocURI> </Source> <Cred><Meta><Format xmlns='syncml:metinf'>b64</Format> <Type xmlns='syncml:metinf'>syncml:auth-basic</Type> </Meta> <Data>ZDpk</Data> </Cred> <Meta><MaxMsgSize xmlns='syncml:metinf'>2700</MaxMsgSize> </Meta> </SyncHdr><dl>

SyncML 服务器的基本需求

我们已经掌握了足够的基本知识。现在让我们来总结一下 SyncML 服务器都要求实现哪些基本特性才能够提供可用的数据同步功能。

服务器至少要能够理解基本 SyncML 词汇表。此外，如果它要实现通讯簿、日历、任务安排以及电子邮件，则必须分别支持 vCard、vCalendar、vTodo、以及 RFC2822/RFC2045规范。（有关这些规范的链接，请参阅 参考资料）

然而，服务器并不必实现 SyncML 协议的全部功能。SyncML Representation Protocol 规范的第七部分定义了所有必须满足的要求及其细节信息（有关 SyncML 规范的链接，请参阅 参考资料）。表 1 中描述了基本 SyncML 操作的语义，并对基本功能进行了总结。

表 1: SyncML 对服务器命令的最小需求描述

命令名称	在 SyncML 服务器环境中的功能描述
Add	用于指示服务器在客户机的数据中建立了新的内容（比如说在电话本中新建一项）
Alert	用于通知服务器。所谓通知就是一些同步请求，其中携带了表示客户机数据库状态的数据。请参考 example.xml 中 CmdID2 和 3 的 Alert 命令，它们请求的是同步日历与电话本。 Data 元素所关联的代码指明了请求的类型，在这个例子中类型为 201 ，意思是“慢同步”（Slow Synchrionization）。在“SyncML Sync Representation 勘误信息”规范中可以找到这些代码的完整列表（请参阅 参考资料）。
Copy	请求在接收者数据库中的其他位置创建某个项的拷贝。
Delete	请求从服务器的数据库中永久删除某项。
Get	显式地请求根据所请求的 URI 从服务器数据库中获取数据项。
Map	用于维护将本地资源标识与远程资源对应的映射表。比如说，移动电话上的某项资源可能具有一个2字节的标识，而在服务器上，同一项资源的 ID 则用一个16个字符的字符串表示。
Put	用于将数据项上传到服务器指定的 URI 处。比如说 example.xml 中处理 CmdID 1 的 Put 命令。这一命令请求服务器将电话的容量（已经 SyncML Device Information DTD 编码）存储到相对 URI /devinf10 处。 Put 命令在设备同步之外使用。
Replace	请求将指定的对象替换成同步信息中的一部分。
Results	用于携带 Get 等请求返回的结果对象。
Status	用于返回与请求相关的状态代码。
Sync	用于将一组命令（如 Add、Replace 、及 Delete ）封装成一次同步。

对 SyncML 客户机的基本需求与服务器的相似。随着将来在 XML 观察专栏对协议实现的深入讨论，我将进一步介绍这些内容。

SyncML 用 URI 的语义来指示位于本地和远程数据库中的数据项。这意味着文件系统作为同步数据库的底层支持是合情合理的。有了这样的认识，下一篇专栏文章将着眼于构造一台基本的服务器，它即可以使用 WBXML 编码的 SyncML，也可以使用 XML 编码。

参考资料

您可以参阅本文在 developerWorks 全球站点上的 英文原文.

请在 讨论论坛上参与本文的讨论。（您也可以单击文章顶部或底部的 讨论来访问论坛。）

请回顾一下 XML Watch 专栏前一篇文章，其中概要介绍了 SyncML。里面的资料下载中包含了 清单 1和 表 1中引用的 example.xml。

在 WAP Forum 的 技术规范清单中可以找到 WBXML 的正式规范定义。

有关 WAP Forum 协议的批评意见，请参阅“ The Harm of the Wireless Application Protocol”。特别要指出，Rohit Khare 的 “ W* Effect Considered Harmful” 尤其值得阅读。

Bilal Siddiqui 有一篇精彩的 WBXML 编码过程概述文章，其中包含了一个 SyncML 的例子，请参阅“ Compressing XML -- Part 1, Writing WBXML”。

请访问 Robin Cover 的 SyncML 网站，上面有大量与 SyncML 相关的文章。

SyncML Web 站点是 SyncML 规范的主页。

SyncML 应用程序经常合并支持以下与个人信息相关的规范：vCard （ 2.1, 3.0）、vCalendar/vTodo （ 1.0）、 iCalendar、e-mail、以及MIME （RFC 822、 2822、和 2045）。

请阅读 Edd Dumbill 以往的 XML 观察专栏。

在 developerWorks XML 专区中可以找到更多的 XML 资料。有关移动通信技术的更多信息，请您参考 Wireless 专区。

IBM WebSphere Studio是 XML 自动化开发套件，不仅支持 Java，还支持其他语言。它与 WebSphere Application Server紧密集成，但是也可以用于其他的 J2EE 服务器。

请您关注如何才能成为 IBM 认证的 XML 及其相关技术开发人员。

关于作者

		Edd Dumbill 是 XML.com 网站的常务编辑，还是 XML 开发人员新闻网站 XMLhack 的编辑和发行人。他是 O'Reilly 的 Programming Web Services with XML-RPC一书的合著者，还是 Pharmalicensing 生命科学知识产权交易事务所的共同创始人和顾问。Edd 还是 XML Europe 2002 会议的议程主席。您可以通过 edd@xml.com 与 Edd 联系。