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 會議的議程主席。您可以通過 [email protected] 與 Edd 聯繫。