SyncML在藍(lán)牙車載免提裝置中的應(yīng)用

為了保證電話簿數(shù)據(jù)的一致性，當(dāng)用戶在手機(jī)上更新了電話簿時(shí)，免提裝置上的電話簿數(shù)據(jù)庫也應(yīng)該同步更新，藍(lán)牙SIG組織沒有單獨(dú)定義同步協(xié)議，本文在分析通用的數(shù)據(jù)同步協(xié)議SyncML的基礎(chǔ)上，將SyncML與藍(lán)牙OBEX綁定，實(shí)現(xiàn)了免提裝置和手機(jī)間電話簿的同步。

SyncML簡介

SyncML是同步標(biāo)記語言(Synchronous Markup Language)的縮寫，旨在提供一種終端用戶、設(shè)備開發(fā)商、數(shù)據(jù)提供商、基礎(chǔ)構(gòu)件開發(fā)商、應(yīng)用軟件開發(fā)商及服務(wù)提供商協(xié)同工作的機(jī)制，使得任何終端設(shè)備均可隨時(shí)隨地進(jìn)行數(shù)據(jù)同步。它包括同步協(xié)議、表示協(xié)議和傳輸綁定協(xié)議三個(gè)部分。

同步協(xié)議

同步協(xié)議指定了如何使用表示協(xié)議以滿足客戶端和服務(wù)器SyncML的互操作性，以消息序列表(message sequence chart)的形式定義了七種同步類型的會(huì)話流程，以請求／響應(yīng)的形式定義了會(huì)話中的數(shù)據(jù)交互過程等。同步協(xié)議采用客戶端／服務(wù)器模式定義了同步框架，劃分了客戶端和服務(wù)器的任務(wù)模塊。

其中，服務(wù)器的同步引擎負(fù)責(zé)整個(gè)數(shù)據(jù)同步操作，同步服務(wù)器代理和同步客戶端代理實(shí)現(xiàn)同步協(xié)議，SyncML接口實(shí)現(xiàn)表示協(xié)議，SyncML適配器實(shí)現(xiàn)傳輸協(xié)議的綁定，用于收發(fā)XMI語言格式的object。下面通過同步協(xié)議定義的幾個(gè)重要概念來描述一下同步機(jī)制。

客戶端和服務(wù)器端都要建立自己的數(shù)據(jù)庫，每個(gè)數(shù)據(jù)條目都由一個(gè)UID(唯一標(biāo)識符)進(jìn)行標(biāo)識，客戶端UID稱為LUID，服務(wù)器UID稱為GUID。服務(wù)器建立一個(gè)ID映射表，使得LUID可以和GUID一一映射，當(dāng)數(shù)據(jù)條目發(fā)生更改時(shí)，建立記錄更改信息的變更日志。當(dāng)同步開始后，通過UID映射和變更日志指定是哪個(gè)數(shù)據(jù)條目發(fā)生了怎樣的改變。

為了檢查同步效果，服務(wù)器端和客戶端各有兩個(gè)同步錨last和next，一般情況是用ISO8601格式的日歷時(shí)間，也可以用一個(gè)序列號，在初始化同步時(shí)客戶端和服務(wù)器端互換同步錨，它的用法如下：

設(shè)本次同步客戶端同步錨為last_c、next_c，服務(wù)器端同步錨為last_s、next_s，同步成功，則更新next_c=next_s，同步不成功則不更新next_c。

下次同步時(shí)，客戶端同步錨為last_c'=next_c、next_c'，服務(wù)器端同步錨為last_s'=next_s、next_s'，客戶端發(fā)送last_c'和next_c'到服務(wù)器端，服務(wù)器端比較last_c'與last_s'，相等則說明上次同步是成功的，不相等則說明上次同步失敗。檢查出上次同步失敗后就要初始化慢同步(雙向同步所有數(shù)據(jù))下載所有的電話簿數(shù)據(jù)。

表示協(xié)議

表示協(xié)議定義了SyncML同步應(yīng)用中XML(Extensible MarkupLanguage)的語法和語義，是一種與平臺(tái)無關(guān)并被廣泛采用的標(biāo)準(zhǔn)。SyncML以XML文檔的形式定義了SyncML消息的格式，每條消息就是一個(gè)單獨(dú)的XML文檔。該文檔包括一個(gè)Header和Body，Header以SyncHdr類型定義，指定了該SyncML消息的路由和版本信息；Body以SyncBody類型定義，包含了一條或多條SyncML操作，一個(gè)操作的語義由命令和被操作數(shù)據(jù)的類型共同確定。SyncMLDTD定義了SyncML消息中通用元素的類型，根據(jù)這些通用元素類型可以指定特定的元素類型，從而滿足各種數(shù)據(jù)同步的擴(kuò)展需要。

SyncML在藍(lán)牙車載免提裝置中的實(shí)現(xiàn)

SyncML OBEX綁定協(xié)議

OBEX(Object Exchange)是紅外數(shù)據(jù)標(biāo)準(zhǔn)協(xié)會(huì)(IrDA)定義的用于對象交換的一種協(xié)議，后被藍(lán)牙SIG組織采納，定義了GOEP(General Object ExchangeProfile)與其適配。在GOEP的基礎(chǔ)上，藍(lán)牙SIG定義了FTP、OPP、PBAP剖面應(yīng)用，其中PBAP是專為電話簿數(shù)據(jù)的自動(dòng)下載定義的剖面，可以下載手機(jī)和SIM卡上存儲(chǔ)的電話簿，還可以下載呼叫日志、呼入、呼出和未接來電。OPP可以用于電話簿的手動(dòng)下載。SyncML針對OBEX定義的綁定協(xié)議分別定義了SyncML在紅外OBEX和藍(lán)牙OBEX上的實(shí)現(xiàn)方式，跟藍(lán)牙OBEX的綁定如圖2所示。

圖2中的SyncML Client層實(shí)現(xiàn)客戶端代理的功能，SYncMLServer層實(shí)現(xiàn)同步引擎和服務(wù)器端代理的功能。OBEX定義了"對象模型"來描述對象，使用"PUT" 和"GET"命令在不同設(shè)備、不同平臺(tái)之間方便高效地交換信息。為了統(tǒng)一地描述各種對象，OBEX定義了Header的概念，每個(gè)Header描述對象的一個(gè)方面。OBEX定義了一系列常用的Header，其中SyncML應(yīng)用到的header為Connection ID、Type、length、Body／EndofBody、Target。

SyncML應(yīng)用所綁定的OBEX操作符包括Connect、Disconnect、Put、Get和Abort。綁定協(xié)議規(guī)定每條SyncML消息必須以MIME類型在OBEX請求或響應(yīng)主體內(nèi)傳輸，定義了OBEX連接、對象交換、斷開連接過程中的請求／響應(yīng)必須包括哪些Filed和Header，比如在一次OBEX Connect操作中，必須包括的Field為連接操作符0x80+包長度+OBEX版本號+標(biāo)志位+最大OBEX包長度，包含的Header為Target。

SyncML的軟件實(shí)現(xiàn)

SyncML的軟件實(shí)現(xiàn)包括應(yīng)用程序、SyncML協(xié)議的實(shí)現(xiàn)和通信程序三個(gè)部分，軟件結(jié)構(gòu)如圖3所示。應(yīng)用程序包括同步管理器、變更日志管理和數(shù)據(jù)庫管理三個(gè)部分。同步管理器按照SyncML同步協(xié)議為每個(gè)同步類型定義的消息序列表管理同步流程，通過調(diào)用SyncML協(xié)議實(shí)現(xiàn)的API，實(shí)現(xiàn)錯(cuò)誤處理、命令處理等操作；變更日志管理程序記錄數(shù)據(jù)更改情況，同時(shí)維護(hù)多個(gè)變更日志，數(shù)據(jù)庫管理程序?qū)崿F(xiàn)對電話簿數(shù)據(jù)庫的增刪和修改。SyncML協(xié)議的實(shí)現(xiàn)主要完成創(chuàng)建、發(fā)送、接收和解析SyncML消息，該部分在SyncML協(xié)會(huì)提供的開放性實(shí)現(xiàn)樣本--SyncML C Toolkit的基礎(chǔ)上實(shí)現(xiàn)。通信程序即SyncML與OBEX的綁定，將SyncML消息封裝為OBEX的object，通過藍(lán)牙鏈路進(jìn)行傳輸。

電話簿數(shù)據(jù)的處理

電話簿數(shù)據(jù)對象符合vCard2.1和vCard3.0規(guī)范，該規(guī)范被SyncML使用，用于電話簿數(shù)據(jù)類型的定義。vCard定義了一種個(gè)人信息的組織方法，主要用于個(gè)人信息的傳輸和交換。符合vCard規(guī)范的電話簿數(shù)據(jù)如下所示：