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

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


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