隨著信息社會的迅速發(fā)展，需求的不斷增長，人們對設備的功能性要求也不斷地提高。

設備的多樣性導致傳輸協(xié)議的多樣性，數據同步建立在私有協(xié)議上，每種協(xié)議只能支持有限種類的設備、系統(tǒng)及數據類型。這些不兼容的協(xié)議技術，增加了用戶、生產商、服務提供商、開發(fā)商工作的復雜度，同時也限制了移動設備的使用、數據的訪問和發(fā)行。為此通信行業(yè)巨頭們制定了一個業(yè)界標準的數據同步協(xié)議，稱為SyncML（Synchronization Markup Language，同步標注性語言）協(xié)議，該協(xié)議已經得到大多數廠商的廣泛支持。

在筆者研發(fā)的一款藍牙車載免提設備中，采用SyncML協(xié)議實現了藍牙手機和車載設備之間的電話本同步，在接聽來電時進行人名提示、對電話簿條目進行導航、選擇電話號碼撥打電話，極大地方便了用戶使用。該設備采用雙處理器，結構如圖1所示：

圖1 車載免提設備結構圖

系統(tǒng)采用CSR公司的BC5( BlueCore5-Multimedia External )藍牙芯片，實現SyncML的OBEX綁定協(xié)議，連接手機的同步通道進行數據收發(fā)，主處理器采用飛思卡爾公司的MCF5251芯片，實現SyncML的表示協(xié)議、同步協(xié)議和應用程序，進行SyncML文檔的處理、電話本保存和SyncML文檔生成，其中手機為SyncML客戶端，車載設備為服務器端。

1 SyncML 同步協(xié)議

1.1 協(xié)議概述

SyncML是一種行業(yè)通用的移動數據同步協(xié)議，采用統(tǒng)一格式的XML（extensible markuplanguage）語言進行設備間的消息傳遞，XML類似于HTML，而且用戶可以自定義自己的標記，便于推廣普及。

SyncML協(xié)議基于XML而定義，因而繼承了其語言簡單、開放、可擴展的特點，使得整個協(xié)議具有高度的靈活性和擴展性，可以適用于各種終端設備和網絡設備，簡單靈活且易于實現，按照該協(xié)議實現的產品又能在最大程度上保證互操作性。SyncML協(xié)議從發(fā)布至今，國際上已經有近700家公司宣布支持，3GPP也決定采SyncML作為其數據同步的標準，2001年發(fā)布的WAP2.0也將SyncML作為數據同步的解決方案。

1.2 SyncML協(xié)議體系

SyncML是一套協(xié)議集，包括數據同步協(xié)議、表示協(xié)議和傳輸方式綁定協(xié)議。

（1）數據同步協(xié)議：同步協(xié)議定義了客戶端和服務器端之間消息的交互過程，同時定義了七種同步類型：雙向同步、慢同步、客戶端單向同步、客戶端刷新同步、服務器端單向同步和服務器端刷新同步、服務器通知同步。其中雙向同步和慢同步是兼容性規(guī)范要求必須支持的，其他同步模式未作硬性規(guī)定。在筆者研制的設備中實現了雙向同步和慢同步。

（2）表示協(xié)議：定義了SyncML文檔的表示方式，一個SyncML文檔就是一個遵循XML規(guī)范的XML文件，它可能被拆分為多條SyncML消息。一條SyncML消息包括兩部分：消息頭、消息體。SyncML消息頭中包含有消息的路由、版本、認證、會話等信息，由SyncHdr元素說明。消息體包含一個或者多個SyncML命令，也包含需要同步的數據，由SyncBody元素說明。

（3）傳輸方式綁定協(xié)議：為了實現不同設備之間傳輸協(xié)議的兼容性，SyncML協(xié)議底層綁定了HTTP（hypertext transfer protocol）超文本傳輸協(xié)議、WSP（wireless sessionprotocol）無線會話協(xié)議和OBEX（IrDA object exchange protocol）對象交換協(xié)議，這3種傳輸協(xié)議基本上覆蓋了所有設備的傳輸。在筆者研制的設備中實現了OBEX綁定協(xié)議。

1.3 SyncML協(xié)議框架結構

基于SyncML的同步應用框架可分為三層：最底層為通訊協(xié)議層，如HTTP、WSP、OBEX等網絡傳輸協(xié)議；中間層為SyncML協(xié)議實現及接口層，是架構的核心層，提供了SyncML的實現并向同步應用層提供統(tǒng)一的開發(fā)接口，SyncML接口是SyncML適配器的應用編程接口，同樣也是框架實體與網絡傳輸的接口，并負責在應用A和應用B之間發(fā)起和維護一個網絡連接；上層為同步應用層。

2 SyncML 服務器設計

在藍牙車載免提系統(tǒng)中，以SRTK 為基礎進行SyncML 服務器系統(tǒng)的設計。SRTK（SyncMLReference Toolkit）是SyncML 組織提供的一個實現工具包，不僅被國內學者研究探討，也作為很多企業(yè)級同步功能的實現基礎，SRTK 提供了一個接口統(tǒng)一的實現方式和命令解析方式，但并沒有提供所有的細節(jié)實現，而且沒有提供針對任何具體應用的應用程序。例如當服務器接收到手機端的SyncML 文檔后，如何對該文檔進行命令處理，產生什么樣的SyncML文檔，需要開發(fā)人員自己實現，而且SRTK 只提供了在Windows、Palma、Linux 環(huán)境下的實現，在MCF5251 上需要進行移植。

2.1 SRTK

SRTK 分為三層：

第一層：核心層，實現SyncML 應用，主要包括SyncML 管理、命令生成和命令處理三部分，該層具有平臺無關性。管理部分對SyncML 實例、工作區(qū)進行管理，控制緩沖區(qū)，并且在發(fā)送和接收模式間轉換；命令生成部分構造同步數據包和命令序列，生成同步的文檔，僅用于“發(fā)送”模式；命令處理部分解析收到的數據包，提取命令，轉交給已注冊的事件響應函數或回調函數，僅用于“接收”模式。

第二層：插件層，為核心層提供服務，分為SyncML 工作區(qū)管理和文檔編解碼兩部分，該層具有平臺相關性。工作區(qū)管理為發(fā)送、接收的數據包托管內存，處理發(fā)送和接收的數據緩沖區(qū)，允許并發(fā)執(zhí)行；文檔編解碼部分實現XML 和WBXML 文檔的編碼與解碼，壓縮或解析XML 和WBXML 的數據包。

第三層，系統(tǒng)數據庫層，封裝了一些系統(tǒng)相關的庫函數，比如內存分配和字符串處理等，把這一層單獨劃分出來是為了使整個模塊與平臺無關。

2.2 系統(tǒng)設計

SyncML 主應用程序在飛思卡爾為其32 位嵌入式處理器提供的操作系統(tǒng)FlexOS 上實現，對SRTK 進行了移植，在此基礎上以回調函數的形式進行同步命令的處理和SyncML 文檔的解析，實現客戶端對服務器端電話薄的“添加”、“更新”、“刪除”等操作，從而實現了藍牙手機與車載藍牙免提設備間的電話簿同步。OBEX 綁定協(xié)議由BC5 在其GOEP 應用剖面上實現，完成了SyncML 文檔在藍牙上的數據傳輸。

2.2.1 同步的流程

（1）建立 OBEX 連接：這部分由BC5 實現，BC5 通過SDP（服務發(fā)現協(xié)議）查詢手機為其SyncML 服務注冊藍牙通道，與該通道建立藍牙連接，這是進行電話簿同步的前提。

（2）同步初始化：連接成功后，要進行同步初始化的工作，在該過程中，服務器端和客戶端設備首先交換信息，主要包括能力描述、請求訪問的數據庫和同步類型、認證信息、同步錨等，然后服務器主動發(fā)送命令通知手機開始同步，MCF5251將包含有代碼為206的Alert命令的文檔經由BC5轉發(fā)給手機，手機在成功接收并解析該文檔后，將向SyncML服務器發(fā)出同步請求。

（3）同步處理和數據映射：BC5將從手機端接收到的SyncML文檔轉發(fā)給MCF5251，MCF5251解析該文檔，保存電話簿VCARD列表、建立ID映射表，同時生成回應的SyncML文檔，由BC5發(fā)送給手機，繼續(xù)同步過程。

（4）同步結束：當手機發(fā)送的文檔中只有Status命令時,這標志著同步結束，這時MCF5251解析VCARD列表并通知BC5同步結束，BC5斷開與手機的OBEX連接。

2.2.2 工作區(qū)管理和內存管理

工作區(qū)管理和內存管理是整個 SyncML 應用系統(tǒng)的核心。在系統(tǒng)初始化時，首先設置所有工作區(qū)最大的字節(jié)個數，然后在SyncML 例程初始化時，為當前工作區(qū)分配內存。該最大字節(jié)數需要通知手機，在消息頭（SyncHdr）中的Meta 屬性中設置，描述如下：10000這樣便定義了SyncML 文檔的最大字節(jié)數為10000。

SRTK 的移植工作主要體現在內存管理上，由于在SyncML 應用中大多情況下都需要動態(tài)分配內存，而MCF5251 不容許動態(tài)分配內存，為此在將SRTK 移植到MCF5251 中時，本文設計了函數MyMalloc 來靜態(tài)分配內存，其C 語言描述如下所示：

void * MyMalloc(unsigned int Number)
{
unsigned char * temp;
temp = (unsigned char *) AllMemSFS + SysDFC;
SysDFC += Number;
return temp;
}

其中AllMemSFS 是系統(tǒng)內存數組，該數組足夠大，可以滿足所有應用，SysDFC 是系統(tǒng)已經分配的內存字節(jié)個數，Number 是申請的字節(jié)個數。函數返回一個指針，該指針的起始地址等于AllMemSFS 首地址與SysDFC 的和。

2.2.3 應用程序的關鍵技術

根據近幾年手機銷售量，筆者選擇了6 部手機進行同步測試，包括索愛W908c、索愛K530c、索愛W700c、諾基亞N72、諾基亞6230、諾基亞6500c。發(fā)現這些藍牙手機在SyncML同步上存在一定的兼容性問題，實驗結果表明索愛W908c、索愛K530c、索愛W700c 不容許強制慢同步，也就是說當手機請求與服務器進行電話薄更新（Alert 命令代碼為200）時，如果服務器要強制慢同步（Alert 命令代碼為201）并且服務器對Alert 命令的回應命令Status 的代碼為200（表示SyncML 命令成功完成）時，手機將取消此次同步。在這種情況下服務器對Alert 命令的回應命令Status 的代碼必須為508（表示服務器與客戶端同步狀態(tài)不一致時的刷新請求），這樣方可使得同步正常完成。

電話簿同步速度對用戶體驗來說是個關鍵的指標，所以筆者在保證對藍牙手機同步兼容性的基礎上，做了如下處理以提高同步速度：（1）增大OBEX 每包字節(jié)長度，該操作對大部分手機有效；（2）增大服務器能接收的最大消息字節(jié)數，該操作只對部分手機有效。在同步過程中，下列情況下同步將失?。海?）同步過程中藍牙連接斷開，SyncML 同步服務便中止，同步失??；（2）如果服務器接收到的SyncML 文檔超過了設定的能夠接收到的最大消息的字節(jié)數或者存在語法錯誤，服務器將中止同步，命令BC5 斷開與手機的連接，同步失敗。斷開連接一定要遵守OBEX 協(xié)議，對于正在進行的數據傳輸必須調用Abort 中止本次數據傳輸，然后才能正確斷開連接，否則下次進行同步時將無法正確同步。

3 結論

實驗結果表明，應用SyncML 協(xié)議能夠很好地實現藍牙手機和車載免提設備間的電話簿同步，給用戶接打電話提供了很多便利。同理，采用SyncML 協(xié)議可以在任何支持SyncML的移動設備間實現個人數據同步化，它的商業(yè)實現對于移動計算來說將是革命性的。本文作者創(chuàng)新點：采用CSR 公司的BC5 芯片和飛思卡爾公司的MCF5251 芯片，設計了嵌入式SyncML 服務器系統(tǒng)，實現了藍牙手機和車載設備之間的電話本同步。