嵌入式SyncML 服務(wù)器的設(shè)計(jì)與實(shí)現(xiàn)

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

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

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

圖1 車載免提設(shè)備結(jié)構(gòu)圖

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

1 SyncML 同步協(xié)議

1.1 協(xié)議概述

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

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

1.2 SyncML協(xié)議體系

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

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

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

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

1.3 SyncML協(xié)議框架結(jié)構(gòu)

基于SyncML的同步應(yīng)用框架可分為三層：最底層為通訊協(xié)議層，如HTTP、WSP、OBEX等網(wǎng)絡(luò)傳輸協(xié)議；中間層為SyncML協(xié)議實(shí)現(xiàn)及接口層，是架構(gòu)的核心層，提供了SyncML的實(shí)現(xiàn)并向同步應(yīng)用層提供統(tǒng)一的開發(fā)接口，SyncML接口是SyncML適配器的應(yīng)用編程接口，同樣也是框架實(shí)體與網(wǎng)絡(luò)傳輸?shù)慕涌冢⒇?fù)責(zé)在應(yīng)用A和應(yīng)用B之間發(fā)起和維護(hù)一個(gè)網(wǎng)絡(luò)連接；上層為同步應(yīng)用層。

2 SyncML 服務(wù)器設(shè)計(jì)

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

2.1 SRTK

SRTK 分為三層：

第一層：核心層，實(shí)現(xiàn)SyncML 應(yīng)用，主要包括SyncML 管理、命令生成和命令處理三部分，該層具有平臺(tái)無關(guān)性。管理部分對(duì)SyncML 實(shí)例、工作區(qū)進(jìn)行管理，控制緩沖區(qū)，并且在發(fā)送和接收模式間轉(zhuǎn)換；命令生成部分構(gòu)造同步數(shù)據(jù)包和命令序列，生成同步的文檔，僅用于“發(fā)送”模式；命令處理部分解析收到的數(shù)據(jù)包，提取命令，轉(zhuǎn)交給已注冊(cè)的事件響應(yīng)函數(shù)或回調(diào)函數(shù)，僅用于“接收”模式。

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

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

2.2 系統(tǒng)設(shè)計(jì)

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

2.2.1 同步的流程

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

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

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

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

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

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

SRTK 的移植工作主要體現(xiàn)在內(nèi)存管理上，由于在SyncML 應(yīng)用中大多情況下都需要?jiǎng)討B(tài)分配內(nèi)存，而MCF5251 不容許動(dòng)態(tài)分配內(nèi)存，為此在將SRTK 移植到MCF5251 中時(shí)，本文設(shè)計(jì)了函數(shù)MyMalloc 來靜態(tài)分配內(nèi)存，其C 語言描述如下所示：

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

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

2.2.3 應(yīng)用程序的關(guān)鍵技術(shù)

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

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

3 結(jié)論

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