專利名稱：一種保持兼容的移動(dòng)數(shù)據(jù)同步方法
技術(shù)領(lǐng)域：
本發(fā)明涉及移動(dòng)通信領(lǐng)域，更具體地說，涉及一種保持兼容的移動(dòng)數(shù)據(jù)同 步方法。
背景技術(shù)：
同步標(biāo)記語言(Syncronization Markup Language, SyncML)是唯一一禾中 行業(yè)通用的移動(dòng)數(shù)據(jù)同步化協(xié)議，由SyncML行動(dòng)(SyncML initiative)發(fā)行， 是一種開放性協(xié)議。SyncML initiative由行業(yè)先鋒愛立信、IBM、 Lotus、摩 托羅拉、諾基亞、Palm Inc.、 Psion及Starfish軟件初創(chuàng)，Matsushita也于最 近加入，使其會(huì)員達(dá)到9家。另外還有555家支持公司。SyncML initiative的 目的就在于與客戶端用戶、設(shè)備開發(fā)商、數(shù)據(jù)提供商、基礎(chǔ)構(gòu)件開發(fā)商、應(yīng) 用軟件開發(fā)商及服務(wù)提供商協(xié)同工作，發(fā)行SyncML，以真正實(shí)現(xiàn)使用任何客 戶端設(shè)備均可隨時(shí)隨地訪問任何網(wǎng)絡(luò)數(shù)據(jù)。SyncML可以表示通過任意網(wǎng)絡(luò)同 步化所有設(shè)備及應(yīng)用軟件。借助可擴(kuò)展標(biāo)記語言(EXtensible Markup Language, XML)， SyncML將成為真正的同步化平臺(tái)。
如圖l所示，SyncML的主要目的有兩方面通過任何移動(dòng)設(shè)備將網(wǎng)絡(luò)數(shù) 據(jù)同步化；移動(dòng)設(shè)備中的數(shù)據(jù)也可以用任何網(wǎng)絡(luò)數(shù)據(jù)同步化。
目前幾個(gè)主要的手機(jī)生產(chǎn)公司如諾基亞、索尼愛立信、摩托羅拉等公司 已經(jīng)在他們的產(chǎn)品中支持SyncML。 一些服務(wù)商己經(jīng)開始提供基于SyncML 的手機(jī)通訊錄同步服務(wù)，歐美的一些網(wǎng)站己經(jīng)擁有20多萬的用戶，發(fā)展勢頭 非常好。中國移動(dòng)也即將開始大規(guī)模推廣SyncML業(yè)務(wù)。
SyncML協(xié)議基于XML，通過XML數(shù)據(jù)包的形式在服務(wù)器端和客戶端(如 手機(jī))之間交換數(shù)據(jù)并進(jìn)行同步，SyncML協(xié)議定義了 XML包格式及同步的 流程，并未規(guī)定底層的通信協(xié)議，所以SyncML不但可用于手機(jī)地址本同步，
也可用于任何需要數(shù)據(jù)同步的場合，比如兩臺(tái)PC之間的數(shù)據(jù)同步。 SyncML協(xié)議定義了下面7種同步方式
1) 快同步，客戶端和服務(wù)器端互相交換最近的修改，客戶端先發(fā)送修改。
2) 慢同步，客戶端發(fā)送所有數(shù)據(jù)到服務(wù)器端，服務(wù)器端對比兩端的數(shù)據(jù)， 做相應(yīng)修改，并分析出客戶端需要進(jìn)行的修改。
3) 客戶端單向同步，客戶端把最新的修改發(fā)送到服務(wù)器端，但服務(wù)器端 不發(fā)送修改到客戶端。
4) 客戶端刷新同步，客戶端把所有數(shù)據(jù)發(fā)送到服務(wù)器端，服務(wù)器端簡單 地用客戶端數(shù)據(jù)覆蓋服務(wù)器端數(shù)據(jù)。
5) 服務(wù)器端單向同步，與客戶端單向同步相反，服務(wù)把最新的修改發(fā)送 到客戶端，但客戶端不發(fā)送修改到服務(wù)器端。
6) 服務(wù)器端刷新同步，服務(wù)器端把所有數(shù)據(jù)發(fā)送到客戶端，客戶端簡單 地用服務(wù)器端數(shù)據(jù)覆蓋客戶端數(shù)據(jù)。
7) 服務(wù)器端通知同步，這種方式用于服務(wù)器端發(fā)起的同步。服務(wù)器端發(fā) 送通知給客戶端，告訴它下面進(jìn)行哪種同步。
其中，快同步和慢同步是常用的同步方式，其他的方式絕大多數(shù)手機(jī)都不 支持。手機(jī)第一次與服務(wù)器端進(jìn)行同步都是慢同步，之后的同步默認(rèn)都是快同 步。
申請人的IPI同步服務(wù)器(IPI Sync Server)是基于Java開源項(xiàng)目Sync4J 開發(fā)的。Sync4J應(yīng)用了 Java2平臺(tái)企業(yè)版(Java 2 Enterprise Edition, J2EE) 技術(shù)，同步邏輯封裝在企業(yè)Java組件(Enterprise JavaBeans， EJB)中，多個(gè) EJB組成一個(gè)池，共同處理大量的并發(fā)用戶同步請求。IPI Sync Server自2005 年初就在河南、山東、江蘇試運(yùn)行，在實(shí)際使用過程中，證明Sync4J是個(gè)結(jié) 構(gòu)優(yōu)良，運(yùn)行穩(wěn)定的系統(tǒng)。但隨著新的客戶端型號(hào)的不斷推出，也出現(xiàn)過不少 比較嚴(yán)重的問題，這是因?yàn)椴煌瑥S商對SyncML協(xié)議的某些方面存在理解上的 差異，同一廠商對協(xié)議的理解或?qū)崿F(xiàn)方式也可能隨著時(shí)間推移而發(fā)生變化，產(chǎn) 生了如下關(guān)于系統(tǒng)兼容性的問題。
第一，先前SyncML同步服務(wù)器的實(shí)現(xiàn)是一個(gè)通用的實(shí)現(xiàn)，它假定了所
有客戶端都嚴(yán)格遵守SyncML協(xié)議。但因?yàn)椴煌瑥S商對SyncML協(xié)議的某些方 面存在理解上的差異，同一廠商對協(xié)議的理解或?qū)崿F(xiàn)方式也可能隨著時(shí)間推移 而發(fā)生變化，不同客戶端的同步功能是有差異的。當(dāng)我們?yōu)槟晨钚驴蛻舳说奶?性而修改系統(tǒng)時(shí)，常常導(dǎo)致以前同步正常的客戶端無法正常同步了，因此每次 因?yàn)榭蛻舳颂匦孕薷牧顺绦?，都必須把以前測試過的手機(jī)重新測試一遍，非常 麻煩，而且容易造成錯(cuò)誤。之前，因?yàn)楫?dāng)時(shí)支持的客戶端較少，通過對系統(tǒng)的 不斷修補(bǔ)也能夠解決問題，但隨著新客戶端的不斷推出，這種顧此失彼的方法 帶來了巨大的維護(hù)工作量，降低了對市場上新加入的客戶端的響應(yīng)速度，也增 加了系統(tǒng)出現(xiàn)問題的風(fēng)險(xiǎn)。
第二， SyncML協(xié)議沒有規(guī)定如何保證聯(lián)系人的唯一性，即為聯(lián)系人確定 主鍵的問題。在Sync4J開源項(xiàng)目中，慢同步是根據(jù)全等條件來匹配聯(lián)系人的 (即兩個(gè)聯(lián)系人的所有字段均相同，才認(rèn)為是同一個(gè)聯(lián)系人)，如果手機(jī)和服 務(wù)器器上都有一個(gè)聯(lián)系人張三，他們的大部分字段(比如姓名，手機(jī)，固定電 話等)都相同，只有Email字段不同，則同步后在服務(wù)器端和手機(jī)上都會(huì)出現(xiàn) 兩個(gè)張三，盡管這兩個(gè)張三的Email字段不同，但根據(jù)常識(shí)，這兩個(gè)張三其實(shí) 是重復(fù)的條目。由于較老型號(hào)的手機(jī)一般不允許用戶選擇慢同步方式，除了第 一次是慢同步之外，以后的同步都是快同步，所以系統(tǒng)在運(yùn)營的早期并未出現(xiàn) 此問題，但在某些新推出的手機(jī)型號(hào)上，用戶可以選擇主動(dòng)進(jìn)行慢同步，很容 易出現(xiàn)重復(fù)條目的問題。這對系統(tǒng)的實(shí)用性有很大的負(fù)面影響。雖然以姓名+ 手機(jī)作為主鍵，只要姓名+手機(jī)號(hào)碼相同，就認(rèn)為是同一個(gè)人。但是，該方法 雖然在服務(wù)器端不可能出現(xiàn)重復(fù)的聯(lián)系人。但手機(jī)一般并沒有這個(gè)限制，所以 手機(jī)上可能存在重復(fù)的聯(lián)系人。這樣同步之后的結(jié)果就是重復(fù)的聯(lián)系人只能有 一個(gè)同步到服務(wù)器上，造成兩端的聯(lián)系人數(shù)目不一致(手機(jī)上多)。
第三，SyncML協(xié)議沒有規(guī)定如何處理那些為空的聯(lián)系人字段。客戶端向 服務(wù)器端放松同步信息時(shí)，對于某個(gè)字段為空可以采取說明該字段為空或者不 發(fā)送該字段。例如，如果手機(jī)上某個(gè)聯(lián)系人的Email為空，向服務(wù)器端發(fā)送這 個(gè)聯(lián)系人的電子名片格式(BusinessCard， Vcard時(shí)就可能會(huì)有兩種形式(與手 機(jī)的型號(hào)有關(guān))EmailSCRLF〉或根本不發(fā)送Email信息。對于第一種形式，
服務(wù)器端知道手機(jī)上的Email是個(gè)空值，把服務(wù)器端的Email也更新為空值即 可。但對于第二種形式，服務(wù)器端就無法確定Email的值了，因?yàn)樵揈mail可 能是空值，也可能該乎機(jī)根本就不支持Email字段。如果是乎機(jī)不支持Email 字段，服務(wù)器端的Email就不應(yīng)該更新。
第四，SyncML協(xié)議無法保證ID映射表(ID Mapping)中數(shù)據(jù)的正確性 及清潔性。ID Mapping是保存于服務(wù)器端的一張映射表，用于保存客戶端和 服務(wù)器端相應(yīng)條目的對應(yīng)關(guān)系。例如，客戶端和服務(wù)器端都有個(gè)聯(lián)系人張三(手 機(jī)號(hào)碼也一樣)，手機(jī)上的張三的紀(jì)錄ID是123，服務(wù)器端的張三的紀(jì)錄ID 是789，則慢同步后ID Mapping表中會(huì)增加一條記錄(123， 789)。在第一 次慢同步時(shí)，同步服務(wù)器會(huì)對比服務(wù)器端和客戶端的所有聯(lián)系人，并生成對應(yīng) 關(guān)系。對于此后快同步的添加/刪除操作，添加/刪除對應(yīng)關(guān)系。對于那些允許 用戶主動(dòng)選擇進(jìn)行慢同步的手機(jī)型號(hào)，ID Mapping的某些記錄可能會(huì)被多次 修改。這可能會(huì)帶來嚴(yán)重問題。因?yàn)椋琁D Mapping具有非常關(guān)鍵的作用，因 為隨后進(jìn)行的修改/刪除操作都需要利用到其中的對應(yīng)關(guān)系。根據(jù)SyncML協(xié) 議，ID Mapping中的對應(yīng)關(guān)系一旦建立，就會(huì)一直存在下去(除非發(fā)生了聯(lián) 系人的刪除操作)，這種幾乎是無限的生命周期對ID Mapping的數(shù)據(jù)正確性及 清潔性(沒有垃圾數(shù)據(jù))提出了非常高的要求， 一旦出現(xiàn)錯(cuò)誤數(shù)據(jù)，同步就會(huì) 出現(xiàn)難以預(yù)料的錯(cuò)誤，而要修正錯(cuò)誤的數(shù)據(jù)，幾乎是不可能的(因?yàn)樾枰脩?手機(jī)的配合，而且數(shù)據(jù)對比的工作量很大)。實(shí)際上，要保持ID Mapping的數(shù) 據(jù)的正確性和清潔性確實(shí)很困難，根本原因是數(shù)據(jù)的正確性和清潔性無法驗(yàn) 證，因?yàn)楸仨氁玫绞謾C(jī)上的所有聯(lián)系人信息才能夠驗(yàn)證。在這種無法驗(yàn)證數(shù) 據(jù)正確性的情況下，如果程序邏輯存在問題，或者是發(fā)生了某些意料之外的異 常情況，都會(huì)產(chǎn)生難以恢復(fù)的錯(cuò)誤數(shù)據(jù)。而在系統(tǒng)不斷修改、演進(jìn)及長期運(yùn)營 的過程中，發(fā)生錯(cuò)誤或意外情況幾乎是不可避免的。所以這種對永久性的ID Mapping的依賴，是系統(tǒng)的一大隱患。
第五，SyncML協(xié)議沒有規(guī)定慢同步時(shí)的沖突解決策略。在同步過程中， 如果發(fā)現(xiàn)某聯(lián)系人在服務(wù)器端和客戶端都發(fā)生了修改，則認(rèn)為發(fā)生了沖突。 SyncML協(xié)議定義了下列沖突策略
以服務(wù)器端的數(shù)據(jù)為準(zhǔn)，手機(jī)上的數(shù)據(jù)被覆蓋 以手機(jī)的數(shù)據(jù)為準(zhǔn)，服務(wù)器端的數(shù)據(jù)被覆蓋
相互忽略，兩端數(shù)據(jù)均保持不變(這種策略一般不用，因?yàn)闀?huì)導(dǎo)致兩端數(shù) 據(jù)不一致)
但在開源項(xiàng)目Sync4j中，僅對快同步應(yīng)用沖突策略，而對于慢同步，手 機(jī)和服務(wù)器端的對應(yīng)條目數(shù)據(jù)的不一致，會(huì)被忽略。Sync4j的這種處理方式， 是因?yàn)閟yncML協(xié)議對沖突的定義，syncML協(xié)議對沖突的定義如下"沖突， 發(fā)生在客戶端和服務(wù)器端都修改了同一條目的情況下，......"。從沖突的定義
可見，沖突發(fā)生的條件是兩端對同一個(gè)條目發(fā)生修改，這的確暗示了沖突是在 快同步時(shí)發(fā)生的，因?yàn)橹挥锌焱讲艜?huì)同步自上次同步之后兩端發(fā)生了修改的 條目，而對于慢同步，是對兩端的所有條目進(jìn)行同步，沒有什么修改的概念。 對于那些允許用戶主動(dòng)選擇慢同步的手機(jī)型號(hào)，Sync4j這種處理方式導(dǎo)致在慢 同步后很容易出現(xiàn)兩端數(shù)據(jù)不一致的情況，這對用戶來說是不可理解的，用戶 希望看到的結(jié)果是同步之后兩端數(shù)據(jù)一致。所以這種處理方式會(huì)使用戶迷惑， 甚至?xí)挥脩粽J(rèn)為是系統(tǒng)的錯(cuò)誤。

發(fā)明內(nèi)容
本發(fā)明要解決的技術(shù)問題在于，針對現(xiàn)有技術(shù)的上述系統(tǒng)不穩(wěn)定、實(shí)用性 差、兼容性不好等缺陷，提供一種保持兼容的移動(dòng)數(shù)據(jù)同步方法。
本發(fā)明解決其技術(shù)問題所采用的技術(shù)方案是:提供一種保持兼容的移動(dòng)數(shù) 據(jù)同步方法，服務(wù)器端和客戶端之間通過XML數(shù)據(jù)包的形式交換數(shù)據(jù)并進(jìn)行同 步，其特征在于，當(dāng)客戶端新加入服務(wù)器端時(shí)，服務(wù)器端采取下述方法處理所 述新加入的客戶端(a)、獲取客戶端設(shè)備的型號(hào)信息，得到客戶端設(shè)備的特 性；(b)、根據(jù)所述客戶端設(shè)備的特性，采用與該特性相對應(yīng)的、獨(dú)立的程序 進(jìn)行分支處理。
在本發(fā)明所述的數(shù)據(jù)同步方法中，所述步驟(a)中，進(jìn)一步包括以下步 驟(al)、服務(wù)器在數(shù)據(jù)庫中建立設(shè)備型號(hào)表，用于保存系統(tǒng)支持的所有設(shè)備 型號(hào)和每個(gè)型號(hào)的特性，所述設(shè)備型號(hào)表中用于確定設(shè)備型號(hào)的字段有制造商、型號(hào)和IMEI前位；(a2)、從客戶端在第一次同步時(shí)發(fā)送的設(shè)備信息中獲 取型號(hào)信息，并與設(shè)備型號(hào)表中的制造商字段和型號(hào)字段分別進(jìn)行匹配，如果
匹配上了則獲取型號(hào)成功；(a3)、如果步驟(a2)中獲取型號(hào)不成功，則從用 戶代理中獲取型號(hào)信息，并與設(shè)備型號(hào)表中的制造商字段和型號(hào)字段分別進(jìn)行 匹配，如果匹配上了則獲取型號(hào)成功；(a4)、如果步驟(a3)中獲取型號(hào)不成 功，則從IMEI中獲取型號(hào)信息，取IMEI的前6位與設(shè)備型號(hào)表中的IMEI 前位字段進(jìn)行匹配，如果匹配上了則獲取型號(hào)成功；(a5)、如果步驟(a4)中 獲取型號(hào)仍不成功，則匹配到設(shè)備型號(hào)表中的缺省型號(hào)。
在本發(fā)明所述的數(shù)據(jù)同步方法中，客戶端與服務(wù)器端同步后，當(dāng)服務(wù)器端 發(fā)現(xiàn)有重復(fù)條目時(shí)，則對其中一個(gè)條目進(jìn)行重新命名。
在本發(fā)明所述的數(shù)據(jù)同步方法中，服務(wù)器端通過下述步驟判斷是否為重復(fù) 條目確定條目的主鍵；判斷條目間的主鍵是否相同，如果是則確定為重復(fù)條 目。
在本發(fā)明所述的數(shù)據(jù)同步方法中，當(dāng)所述條目為手機(jī)聯(lián)系人時(shí)，所述主鍵 為姓名和手機(jī)號(hào)碼。
在本發(fā)明所述的數(shù)據(jù)同步方法中，當(dāng)客戶端向服務(wù)器發(fā)送的信息中的某些 字段為空時(shí)，通過下述步驟處理該空字段(Sl)服務(wù)器端在數(shù)據(jù)庫中對客戶 端進(jìn)行配置，即配置各客戶端的支持字段；(S2)客戶端向服務(wù)器發(fā)送其中帶 有空字段的信息；(S3)服務(wù)器端根據(jù)配置信息，判斷該客戶端是否支持所述 空字段，如果是則轉(zhuǎn)到步驟(S4)中，否則轉(zhuǎn)到步驟(S5)中；(S4)將服務(wù) 器端的與所述空字段對應(yīng)的字段更新為空；(S5)不更新服務(wù)器端的與所述空 字段對應(yīng)的字段。
在本發(fā)明所述的數(shù)據(jù)同步方法中，在同步異常中斷時(shí)，服務(wù)器端強(qiáng)制客戶 端采用慢同步的方式進(jìn)行同步；在慢同步時(shí)重新生成ID映射表，所述ID映射 表用于保存客戶端和服務(wù)器端相應(yīng)條目的對應(yīng)關(guān)系。
在本發(fā)明所述的數(shù)據(jù)同步方法中，所述同步異常中斷包括網(wǎng)絡(luò)中斷和/或 客戶端取消同步。
在本發(fā)明所述的數(shù)據(jù)同步方法中，當(dāng)采用的同步方式為慢同步時(shí)，如果發(fā)
現(xiàn)客戶端和服務(wù)器端的對應(yīng)條目的數(shù)據(jù)不完全一致時(shí)，則采用沖突策略解決。 在本發(fā)明所述的數(shù)據(jù)同步方法中，所述的沖突策略包括用服務(wù)器端的數(shù) 據(jù)覆蓋客戶端數(shù)據(jù)；用客戶端數(shù)據(jù)覆蓋服務(wù)器端的數(shù)據(jù)；服務(wù)器端和客戶端數(shù) 據(jù)均保持不變。
實(shí)施本發(fā)明的移動(dòng)數(shù)據(jù)同步方法，具有以下有益效果本發(fā)明的方法解決
了現(xiàn)有系統(tǒng)中諸多不兼容的問題，成為一個(gè)穩(wěn)定、實(shí)用、兼容性好的系統(tǒng)。有 利于快速響應(yīng)市場變化，盡快提供對新客戶端型號(hào)的支持。同時(shí)使同步系統(tǒng)更 簡單，更易理解。


下面將結(jié)合附圖及實(shí)施例對本發(fā)明作進(jìn)一步說明，附圖中
圖1是SyncML同步示意圖2是本發(fā)明中獲取手機(jī)型號(hào)的流程圖3是本發(fā)明中處理空字段的流程圖。
具體實(shí)施例方式
1、系統(tǒng)不易修改的問題
本發(fā)明中，當(dāng)客戶端新加入服務(wù)器端時(shí)，服務(wù)器端采取下述方法處理所述 新加入的客戶端:首先獲取客戶端設(shè)備的型號(hào)信息，得到該客戶端設(shè)備的特性; 然后根據(jù)所述客戶端設(shè)備的特性，采用獨(dú)立的程序進(jìn)行分支處理。如前面背景 技術(shù)中所述，現(xiàn)有解決方案是對整個(gè)系統(tǒng)進(jìn)行修改。而在本發(fā)明中，對于各客 戶端的通用部分可以用一個(gè)公有模塊實(shí)現(xiàn)，對于各客戶端的獨(dú)有特性，即與其 它客戶端的差異部分，可以采用獨(dú)有的子模塊進(jìn)行單獨(dú)處理。這樣就新加入的 客戶端可以進(jìn)行單獨(dú)處理，不需修改系統(tǒng)的公有模塊，也不會(huì)影響原有客戶端 的同步操作。
如圖2所示，獲取客戶端設(shè)備的型號(hào)信息包括以下步驟。在步驟201中，
服務(wù)器在數(shù)據(jù)庫中建立設(shè)備型號(hào)表，保存系統(tǒng)支持的所有設(shè)備型號(hào)和每個(gè)型號(hào)
的特性，表中用于確定設(shè)備型號(hào)的字段有制造商，型號(hào)，IMEI前位；在步
驟202中，從客戶端在第一次同步時(shí)發(fā)送的設(shè)備信息中獲取型號(hào)信息；在步驟 203中，將步驟202中獲得的型號(hào)信息與設(shè)備型號(hào)表中的制造商字段和型號(hào)字 段分別進(jìn)行匹配，如果匹配上了則轉(zhuǎn)到步驟209中，說明獲取型號(hào)成功，否則 轉(zhuǎn)到步驟204中；在步驟204中，從user-agent中獲取型號(hào)信息；在步驟205 中，將在步驟204中獲得的型號(hào)信息與設(shè)備型號(hào)表中的制造商字段和型號(hào)字段 分別進(jìn)行匹配，如果匹配上了則轉(zhuǎn)到步驟209中，說明獲取型號(hào)成功，否則轉(zhuǎn) 到步驟206中；在步驟206中，從IMEI中獲取型號(hào)信息；在步驟207中，將 步驟206中從IMEI獲得的前6位與設(shè)備型號(hào)表中的IMEI前位字段進(jìn)行匹配， 如果匹配上了則轉(zhuǎn)到步驟209中，說明獲取型號(hào)成功，否則轉(zhuǎn)到步驟208中； 在步驟208中，將其匹配到設(shè)備型號(hào)表中的缺省型號(hào)。 在本發(fā)明第一實(shí)施例中，假設(shè)該客戶端為手機(jī)。
比如，Nokia6108手機(jī)Vcard的漢字編碼是UTF-8，但并未進(jìn)行傳輸編碼 (BASE64/QP)，對這種情況，程序進(jìn)行了處理，后來又發(fā)現(xiàn)有些其它型號(hào)的手 機(jī)也是這樣的編碼方式，程序?qū)@些這些型號(hào)的處理也是正常的。但后來發(fā)現(xiàn) MOTO A768也是UTF-8，并且未進(jìn)行傳輸編碼，可是同步之后卻發(fā)生了亂碼。 這種情況下，就需要針對M0T0A768增加獨(dú)立的程序分支進(jìn)行特殊處理，避免 修改對其它型號(hào)的處理。
確定手機(jī)型號(hào)的方案基于以下事實(shí)
手機(jī)第一次同步時(shí)會(huì)送上設(shè)備信息，其中可能含有型號(hào)信息，例如
〈Man〉NOKI A</Man>(制造商)
〈Mod〉6681〈/Mod〉 (型號(hào)) 手機(jī)送上來的HTTP包頭中的user-agent屬性可能含有型號(hào)信息，例如 user-agent=LG-G828/V090CT1/WAP2. 0 (LG-G828是手機(jī)型號(hào)) 手機(jī)送上來的SyncML包中，含有IMEI，而IMEI的前6位是型號(hào)信息。 例如
〈LocURI〉IMEI:355660004221570〈/LocURI〉 (355660是Nokia 6681)
但是該些信息可能存在以下問題:手機(jī)第一次同步時(shí)送上來的設(shè)備信息中 可能并不含有型號(hào)信息；HTTP包頭中的user-agent屬性可能并不含有型號(hào)信
息；雖然手機(jī)送上來SyncML包中一定含有IMEI，可這個(gè)IMEI可能是錯(cuò)誤的 (某些型號(hào)的手機(jī)送上來的IMEI并不是真實(shí)的IMEI，只是隨便送了個(gè)字符串 而已)。
雖然這3種獲取手機(jī)型號(hào)的方法的途徑都有缺陷，不過綜合使用還是確定 絕大多數(shù)的手機(jī)型號(hào)。
2、 重復(fù)條目問題
對于重復(fù)條目，本發(fā)明提出的方法為，同步服務(wù)器在發(fā)現(xiàn)客戶端上有重復(fù) 的聯(lián)系人時(shí)，對其中一個(gè)聯(lián)系人重新命名，如果有兩個(gè)張三，就把其中一個(gè)改 名為張三2 (服務(wù)器端添加張三2，手機(jī)上的一個(gè)張三更改為張三2)，這樣就 保證服務(wù)器端和客戶端不會(huì)出現(xiàn)重復(fù)條目且兩端聯(lián)系人數(shù)量一致。
當(dāng)然，聯(lián)系人改名還要考慮姓名沖突問題，該細(xì)節(jié)問題在本發(fā)明中不再詳述。
3、 空字段的處理問題
對于同步信息中的空字段，本發(fā)明采用在數(shù)據(jù)庫中對每個(gè)客戶端進(jìn)行配置 的方法，即配置每個(gè)客戶端都支持哪些字段，同步時(shí)只對客戶端支持的字段同 步。如圖3所示，在步驟301中，服務(wù)器端在數(shù)據(jù)庫中對客戶端進(jìn)行配置，即 配置各客戶端支持的字段為哪些；在步驟302中，客戶端向服務(wù)器發(fā)送其中帶 有空字段的信息；在步驟303中，服務(wù)器端根據(jù)配置信息，判斷該客戶端是否 支持其中為空的字段，如果是則轉(zhuǎn)到步驟304中，否則轉(zhuǎn)到步驟305中；在步 驟304中，將服務(wù)器端的相應(yīng)字段更新為空；在步驟305中，不更新服務(wù)器端 的相應(yīng)字段。
例如，假設(shè)數(shù)據(jù)庫中對手機(jī)型號(hào)A和型號(hào)B作了如下配置 手機(jī)型號(hào)A支持字段姓名，手機(jī)號(hào)碼，Email;
手機(jī)型號(hào)B支持字段姓名，手機(jī)號(hào)碼。
假設(shè)型號(hào)A采用第二種形式發(fā)送發(fā)送聯(lián)系人的Vcard。 當(dāng)手機(jī)型號(hào)A同步時(shí)，假設(shè)某聯(lián)系人的Vcard沒有Email信息，服務(wù)器端 通過配置知道型號(hào)A是支持Email字段的，所以可斷定Email是個(gè)空值，并把
服務(wù)器端的Email也更新為空值。
當(dāng)手機(jī)型號(hào)B同步時(shí)，聯(lián)系人的Vcard都沒有Email信息，服務(wù)器端通過 配置知道這是因?yàn)槭謾C(jī)不支持Email字段，所以并不會(huì)更新服務(wù)器端的Email 字段。
4、 ID Mapping導(dǎo)致的健壯性問題
為了保證ID Mapping的數(shù)據(jù)的正確性和清潔性，本發(fā)明提出了的方法為 在上次同步異常中斷(網(wǎng)絡(luò)中斷或用戶取消同步)的情況下，如果再次同步， 服務(wù)器端強(qiáng)制手機(jī)進(jìn)行慢同步；用戶每次慢同步都重新生成該用戶的ID Mapping數(shù)據(jù)。
因?yàn)檫M(jìn)行了第一次慢同步之后，在正常情況下，以后的同步都應(yīng)是快同步。 如果又要進(jìn)行慢同步，則一般是因?yàn)榘l(fā)生了某些異常情況，而在異常情況下， ID Mapping出錯(cuò)的可能也較大，這時(shí)重新建立ID Mapping數(shù)據(jù)是一種預(yù)防措 施。在上次同步異常中斷(網(wǎng)絡(luò)中斷或用戶取消同步)的情況下，通過慢同步 重建ID Mapping數(shù)據(jù)，可以不定期的清除以前積累的錯(cuò)誤數(shù)據(jù)和垃圾數(shù)據(jù)。 通過在慢同步時(shí)重建ID Mapping數(shù)據(jù)，使得慢同步自然成為一種故障恢復(fù)手 段，只要向用戶提供主動(dòng)進(jìn)行慢同步的方法，用戶自己就可以把系統(tǒng)恢復(fù)到正 常狀態(tài)。
5、 沖突策略的使用范圍問題
在慢同步時(shí),如果發(fā)現(xiàn)對應(yīng)條目的數(shù)據(jù)不完全一致，也認(rèn)為是發(fā)生了沖突， 并用原先只應(yīng)用于快同步的沖突策略來解決該沖突。確保了慢同步后兩端數(shù)據(jù) 一致，并且由于慢同步沿用了快同步的處理方式，使系統(tǒng)更簡單，更易理解。
本發(fā)明的移動(dòng)數(shù)據(jù)同步方法解決了現(xiàn)有系統(tǒng)中諸多不兼容的問題，成為一 個(gè)穩(wěn)定、實(shí)用、兼容性好的系統(tǒng)。有利于快速響應(yīng)市場變化，盡快提供對新客 戶端型號(hào)的支持。同時(shí)使同步系統(tǒng)更簡單，更易理解。
權(quán)利要求
1、一種保持兼容的移動(dòng)數(shù)據(jù)同步方法，服務(wù)器端和客戶端之間通過XML數(shù)據(jù)包的形式交換數(shù)據(jù)并進(jìn)行同步，其特征在于，當(dāng)客戶端新加入服務(wù)器端時(shí)，服務(wù)器端處理所述新加入的客戶端包括以下步驟(a)、獲取客戶端設(shè)備的型號(hào)信息，得到客戶端設(shè)備的特性；(b)、根據(jù)所述客戶端設(shè)備的特性，采用與該特性相對應(yīng)的、獨(dú)立的程序進(jìn)行分支處理。
2、 根據(jù)權(quán)利要求1所述的數(shù)據(jù)同步方法，其特征在于，所述步驟(a)中， 進(jìn)一步包括以下步驟(al)、服務(wù)器在數(shù)據(jù)庫中建立設(shè)備型號(hào)表，用于保存系統(tǒng)支持的所有設(shè) 備型號(hào)和每個(gè)型號(hào)的特性，所述設(shè)備型號(hào)表中用于確定設(shè)備型號(hào)的字段有制 造商、型號(hào)和IMEI前位；(a2)、從客戶端在第一次同步時(shí)發(fā)送的設(shè)備信息中獲取型號(hào)信息，并與 設(shè)備型號(hào)表中的制造商字段和型號(hào)字段分別進(jìn)行匹配，如果匹配上了則獲取型 號(hào)成功；(a3)、如果步驟(a2)中獲取型號(hào)不成功，則從用戶代理中獲取型號(hào)信 息，并與設(shè)備型號(hào)表中的制造商字段和型號(hào)字段分別進(jìn)行匹配，如果匹配上了 則獲取型號(hào)成功；(a4)、如果步驟(a3)中獲取型號(hào)不成功，則從IMEI中獲取型號(hào)信息， 取IMEI的前6位與設(shè)備型號(hào)表中的IMEI前位字段進(jìn)行匹配，如果匹配上了 則獲取型號(hào)成功；(a5)、如果步驟(a4)中獲取型號(hào)仍不成功，則匹配到設(shè)備型號(hào)表中的 缺省型號(hào)。
3、 根據(jù)權(quán)利要求1所述的數(shù)據(jù)同步方法，其特征在于，客戶端與服務(wù)器 端同步后，當(dāng)服務(wù)器端發(fā)現(xiàn)有重復(fù)條目時(shí)，則對其中一個(gè)條目進(jìn)行重新命名。
4、 根據(jù)權(quán)利要求3所述的數(shù)據(jù)同步方法，其特征在于，服務(wù)器端通過下 述步驟判斷是否為重復(fù)條目判斷條目間的主鍵是否相同，如果是則確定為重復(fù)條目。
5、 根據(jù)權(quán)利要求4所述的數(shù)據(jù)同步方法，其特征在于，當(dāng)所述條目為手 機(jī)聯(lián)系人時(shí)，所述主鍵為姓名和手機(jī)號(hào)碼。
6、 根據(jù)權(quán)利要求1所述的數(shù)據(jù)同步方法，其特征在于，當(dāng)客戶端向服務(wù) 器發(fā)送的信息中的某些字段為空時(shí)，通過下述步驟處理該空字段-(51) 服務(wù)器端在數(shù)據(jù)庫中對客戶端進(jìn)行配置，即配置各客戶端的支持字段；(52) 客戶端向服務(wù)器發(fā)送其中帶有空字段的信息；(53) 服務(wù)器端根據(jù)配置信息，判斷該客戶端是否支持所述空字段，如果 是則轉(zhuǎn)到步驟(S4)中，否則轉(zhuǎn)到步驟(S5)中;(54) 將服務(wù)器端的與所述空字段對應(yīng)的字段更新為空；(55) 不更新服務(wù)器端的與所述空字段對應(yīng)的字段。
7、 根據(jù)權(quán)利要求1所述的數(shù)據(jù)同步方法，其特征在于，在同步異常中斷 時(shí)，服務(wù)器端強(qiáng)制客戶端采用慢同步的方式進(jìn)行同步；在慢同步時(shí)重新生成 ID映射表，所述ID映射表用于保存客戶端和服務(wù)器端相應(yīng)條目的對應(yīng)關(guān)系。
8、 根據(jù)權(quán)利要求7所述的數(shù)據(jù)同步方法，其特征在于，所述同步異常中 斷包括網(wǎng)絡(luò)中斷和/或客戶端取消同步。
9、 根據(jù)權(quán)利要求1所述的數(shù)據(jù)同步方法，其特征在于，當(dāng)采用的同步方 式為慢同步時(shí)，如果發(fā)現(xiàn)客戶端和服務(wù)器端的對應(yīng)條目的數(shù)據(jù)不完全一致時(shí)， 則采用沖突策略解決。
10、 根據(jù)權(quán)利要求9所述的數(shù)據(jù)同步方法，其特征在于，所述的沖突策略包括:用服務(wù)器端的數(shù)據(jù)覆蓋客戶端數(shù)據(jù);用客戶端數(shù)據(jù)覆蓋服務(wù)器端的數(shù)據(jù)； 服務(wù)器端和客戶端數(shù)據(jù)均保持不變。
全文摘要
本發(fā)明涉及一種保持兼容的移動(dòng)數(shù)據(jù)同步方法，服務(wù)器端和客戶端之間通過XML數(shù)據(jù)包的形式交換數(shù)據(jù)并進(jìn)行同步，當(dāng)客戶端新加入服務(wù)器端時(shí)，服務(wù)器端采取下述方法處理所述新加入的客戶端獲取客戶端設(shè)備的型號(hào)信息，得到客戶端設(shè)備的特性；根據(jù)所述客戶端設(shè)備的特性，采用與該特性相對應(yīng)的、獨(dú)立的程序進(jìn)行分支處理。當(dāng)客戶端和服務(wù)器端出現(xiàn)重復(fù)條目時(shí)，可采用重新命名的方法解決。當(dāng)客戶端發(fā)送空字段時(shí)，服務(wù)器端可根據(jù)事先配置的客戶端的支持字段確定該空字段的意義進(jìn)而判斷是否更新服務(wù)器端的相應(yīng)條目。在慢同步時(shí)重新生成ID映射表以盡可能保證映射數(shù)據(jù)的正確性和清潔性，進(jìn)而構(gòu)成一個(gè)穩(wěn)定、實(shí)用、兼容性好的數(shù)據(jù)同步系統(tǒng)。
文檔編號(hào)H04L7/00GK101110813SQ20061006171
公開日2008年1月23日 申請日期2006年7月17日 優(yōu)先權(quán)日2006年7月17日
發(fā)明者剛 張, 馬育兵 申請人:深圳市艾派應(yīng)用系統(tǒng)有限公司