专利名称：在SyncML层实现数据同步的方法
技术领域：
本发明涉及开放移动联盟定义的数据同步规范(SyncML DataSynchronization)技术领域，特别是指在SyncML层实现数据同步的方法。
背景技术：
IBM、Nokia、Palm、Psion等公司为了制订可以在多个平台及网络之间实现个人信息及企业内数据同步的标准规格，于2000年2月份创建了业界团体SyncML iniative。开发SyncML的目的在于，使终端用户、设备开发商、基础构件开发商、数据提供商、使用软件开发商以及服务提供商协同工作，真正实现使用任何终端设备均可随时随地访问任何网络数据。SyncML数据同步的典型应用是移动设备或应用服务器、与网络服务器之间的数据同步。除此之外，SyncML还可用于对等的数据同步，如两台PC之间。
图1所示为实现同步的示意图。SyncML客户端与服务器经过同步初始化阶段的参数协商以后，终端和服务器互相发送各自改变的数据，以保证双方数据的同步。
同步客户端(DS Client)，它通常是一个PC软件、手机或PDA等智能终端。DS Client包含一个客户端数据库(Client Database)，用来存储用户所需的数据，这些数据包括通讯录、日程、便笺、短信、电子邮件等。这些数据均有标准规范定义其格式，客户端可以将数据转换成标准的格式发送给服务器，服务器处理后可保存入自己的数据库中。
同步服务器(DS Server)，可接收来自DS Client的数据同步消息和同步命令，并能向同步客户端发送同步消息。这个设备可以是一个网络服务器或是一个PC。DS Server包含了一个服务器端数据库(Server Database)，用来存放服务器上的数据。
客户端和服务器端都存储有用于标识数据的标识，在客户端用LUID(Local Unique Identifier)作为数据标识；在服务器端使用GUID(GlobalUnique Identifer)作为数据标识。
参见图2，图2所示为客户端和服务器端的数据存储示意。在客户端，只需维护LUID与具体实际数据的对应关系，在服务器端不仅需要维护GUID与具体实际数据的对应关系，还要维护GUID和LUID的对应关系。
同步类型分为多种，具体参见表1。
表1
SyncML规范中规定的同步流程通常分为三个阶段1、同步初始化阶段，其主要完成身份鉴权、需要同步的数据库的协商、同步能力的协商(支持同步哪些数据、支持哪些同步类型等)。该交互过程可能需要持续多次才能完成。
2、同步阶段，其主要用于客户端和服务器中的一端，根据数据的状态将发生改变的数据通过操作命令的方式发送到客户端和服务器中的另一端，由另一端按照这些命令进行相同的操作来达到同步的目的。
3、同步完成阶段，其主要用于客户端和服务器端互相确认同步完成。
现有技术中，为实际的数据定义了Folder和File两种格式，其主要是模拟PC机上的文件夹和文件那样的树状目录结构，并定义Folder和File有类似文件系统那样的属性，如是否隐藏(h)、是否为系统目录或文件(s)、是否压缩(a)、是否删除，如果为删除状态，目录或文件可以被删除(d)、是否可写(w)、是否可读(r)、文件是否可执行(x)等。而且，在执行同步操作时，只能用于同步文件系统那样的物理方式的目录结构。
同时，在现有技术中还提供了过滤(Filtering)功能，其作用主要是在初始化协商阶段指明过滤条件。例如在协商终端能力时，可以针对待同步数据指定过滤条件，如A、指定客户端不接收vCard中的PHOTO属性；B、指定客户端仅仅同步属于Business和Personal群组的联系人；其中的过滤条件B可以看做是客户端和服务器端协商仅同步指定目录的过程。
但是，即使是用于同步文件系统那样的物理方式的目录结构，在现有的规范中也没有明确说明具体的实现方法，即没有明确如何使用Folder和File进行递归同步，因而，当前各个厂商几乎都没有对某一目录进行同步的实现方法。
再有，即使采用这种方法，也只能实现对物理方式的目录结构实现同步，而不能对逻辑方式的目录结构实现同步，无法区分递归同步和非递归同步。例如，假设用户的手机内已存在通讯录、短信、电子邮件等几个以物理方式存在的目录结构，在现有技术中，用户只能同步短信这一大类，而不能将已存储的短信分为“笑话”和“祝福”两个逻辑类，更不能只同步“笑话”这一逻辑目录。同时也不支持一个数据项同时存在于两个分类中，例如对于用户通讯簿，张三既属于“同事组”，又属于“朋友组”的需求无法实现。
另外，在现有通讯录(vCard)规范中有group属性，可以用于分类，但是其与具体的同步内容绑定即同步指定的目录依赖于具体的数据格式，而且同一内容只能属于一个分类而不能同时属于多个分类，例如通讯录中张三的属性是“同事”，那么其就只能属于“同事”这一分类，而不能再属于“好友”这一分类。并且其他数据格式，如短信、日程等，并不支持基于group的属性。可见，该种分类并不通用。再有，基于vCard的group属性需要用户打开具体的数据格式来编辑群组名，这样可能由于误操作使得“好友”和“好友”被认为是不同的群组，且大小写敏感。而且group属性仅能够支持一级目录结构，对于多级目录是不支持的。
在现有技术中当客户端操作和服务器端操作发生冲突时，仅仅是采用以客户端数据为主、或者以服务器端数据为主的简单解决措施；当采用目录结构以后，冲突发生的情况就会变得复杂，例如用户在客户端上移动A目录使其成为B目录的子目录，而服务器端是在A目录中增加了一个条目，二者的操作发生了冲突，如果采用现有技术，最终只能是采用客户端的操作，服务器端新增条目被丢弃；或者客户端上A目录新增一个条目，A目录移动到B目录下的操作被丢弃；而实际用户希望的情况是A目录下新增了条目，并且A目录被移动到B目录下。
发明内容
有鉴于此，本发明的目的在于提供一种在SyncML层实现数据同步的方法，可以指定任意一目录进行同步，不但节省网络资源，而且增强用户体验。
为达到上述目的，本发明的技术方案是这样实现的
一种在SyncML层实现数据同步的方法，当SyncML客户端或服务器端中的一端接收到来自用户的同步请求时，客户端和服务器端协商待同步数据所属目录；该方法包括以下步骤a、SyncML客户端或服务器端中的一端首先确定接收到的请求同步命令中待同步数据的类型，如果是目录项，则执行步骤b，如果是数据项目，则执行步骤c；b、从已设置的目录表中获取该待同步数据的当前状态，如果当前状态指示为未变化，则不做处理，如果当前状态指示为变化，则根据该变化状态构建与之相对应的数据同步命令，将该数据同步命令发送给客户端或服务器端中的另一端；c、从已设置的数据条目-目录对应关系表中获取该待同步数据的变化状态，并根据该变化状态构建与之相对应的数据同步命令，将该数据同步命令发送给客户端或服务器端中的另一端；所述所构建的命令中至少包括待同步数据的数据类型和待同步数据编号；SyncML客户端或服务器中的另一端接收到来自对端的同步命令后，执行以下步骤d、根据接收到的数据同步命令，确定操作类型，更改相应表格的内容，实现数据同步。
较佳地，所述发起同步请求的为客户端，所述执行同步操作的为服务器端；所述该待同步数据的变化状态为新增N，所述与该变化状态相对应的数据同步命令为增加ADD同步命令；所述该命令中的待同步数据编号是该数据在客户端的编号，且该命令中进一步包括具体的待同步数据以及该数据所属父目录；所述服务器端确定操作类型为增加；所述更改相应表格的内容，实现数据同步的过程包括以下步骤
根据接收到的数据同步命令，在本地数据库保存接收到的待同步数据，为该待同步数据分配服务器本地编号，在已设置的SyncML客户端内的编号与服务器内的编号的对应关系列表中保存该同步数据在客户端的编号与该同步数据在服务器端的编号的对应关系；并且，根据同步命令中的待同步数据的数据类型，确定该同步数据的类型，如果数据类型是目录项，则在本地已设置的目录表中增加相应条目，如果数据类型是数据项目，则在本地已设置的数据条目表和数据条目-目录对应关系索引表中增加相应条目。
较佳地，所述发起同步请求的为服务器端，所述执行同步操作的为客户端；所述该待同步数据的变化状态为新增N，所述与该变化状态相对应的数据同步命令为增加ADD同步命令；所述该命令中的待同步数据编号是该数据在服务器端的编号，且该命令中进一步包括具体的待同步数据以及该数据所属父目录；所述客户端确定操作类型为增加；所述更改相应表格的内容，实现数据同步的过程包括以下步骤根据接收到的数据同步命令，在本地数据库保存接收到的待同步数据，为该待同步数据分配客户端本地编号，并且，根据同步命令中的待同步数据的数据类型，确定该同步数据的类型，如果数据类型是目录项，则在本地已设置的目录表中增加相应条目，如果数据类型是数据项目，则在本地已设置的数据条目表和数据条目-目录对应关系索引表中增加相应条目；之后，给服务器端返回该数据客户端内的编号与服务器内的编号的对应关系，由服务器端将接收到的对应关系保存在本地已设置的SyncML客户端内的编号与服务器内的编号的对应关系列表内。
较佳地，步骤b执行完毕之后，进一步包括e判断该新增加的目录项下是否有新增加的数据项目，如果有，则重复执行步骤c，直到将所有数据项目全部同步为止，之后执行步骤f；如果没有，则直接执行步骤f；f、判断该新增加的目录项下是否有新增加的子目录项，如果有，则重复执行步骤b，直到将所有目录项全部同步为止，之后执行步骤e，如果没有，则结束。
较佳地，步骤b执行完毕之后，进一步包括e判断该新增加的目录项下是否有新增加的数据项目，如果有，则重复执行步骤c，直到将所有数据项目全部同步为止。
较佳地，所述该待同步数据的变化状态为更新U，所述与该变化状态相对应的数据同步命令为替换Replace同步命令，且该命令中进一步包括具体的待同步数据，以及该数据所属父目录；所述另一端确定操作类型为更新；所述更改相应表格的内容，实现数据同步的过程包括以下步骤根据接收到的数据同步命令，确定该同步数据的类型，如果数据类型是目录项，则在本地已设置的目录表中更新待同步数据在本地的编号所对应的条目，如果数据类型是数据项目，则在本地已设置的数据条目表中更新待同步数据在本地的编号所对应的条目。
较佳地，步骤b执行完毕之后，进一步包括g判断该已更新的目录项下是否有更新的数据项目，如果有，则重复执行步骤c，直到将所有数据项目全部同步为止，之后执行步骤h；如果没有，则直接执行步骤h；h、判断该已更新的目录项下是否存在更新的子目录项，如果有，则重复执行步骤b，直到将所有目录项全部同步为止，之后执行步骤g，如果没有，则结束。
较佳地，步骤b执行完毕之后，进一步包括g判断该已更新的目录项下是否有更新的数据项目，如果有，则重复执行步骤c，直到将所有数据项目全部同步为止。
较佳地，所述该待同步数据的变化状态为移动M，所述与该变化状态相对应的数据同步命令为移动Move同步命令；且该命令中进一步包括变更后的该数据所属父目录；所述另一端确定操作类型为移动；所述更改相应表格的内容，实现数据同步的过程包括以下步骤根据接收到的数据同步命令，确定该同步数据的类型，如果数据类型是目录项，则在本地已设置的目录表中将该待同步数据在本地的编号所对应的条目所属父目录更改为接收到的同步命令中的父目录，如果数据类型是数据项目，则在本地已设置的数据条目-目录对应关系表中将待同步数据在本地的编号所对应的条目所属父目录更改为接收到的同步命令中的父目录。
较佳地，步骤b所述当前状态指示为删除D，所述与该变化状态相对应的数据同步命令为删除Delete同步命令；则所述发起同步请求的一端进一步包括判断该待删除目录下的数据项目以及该目录的子目录下的数据项目是否仅存在于该待删除目录下，如果是，则构建一条删除命令，且该删除命令中包含指示永久删除的信息；否则，针对每个数据项目和目录项分别构建一条删除命令，且仅存在于该待删除目录下的数据项目或目录项所对应的删除命令中包含指示永久删除的信息，并非仅存在于该待删除目录下的数据项目或目录项所对应的删除命令中包含指示非永久删除的信息；所述另一端确定操作类型为删除；所述更改相应表格的内容，实现数据同步的过程包括以下步骤根据接收到的数据同步命令确定删除类型，以及待同步数据的数据类型，如果数据类型是目录项，则无论是删除类型为永久删除还是非永久删除，都在本地已设置的目录表中删除待同步数据在本地的编号所对应的条目；如果数据类型是数据项目，且删除类型为永久删除，则在本地数据库内删除该数据，并在本地已设置的数据条目表和数据条目-目录对应关系表中，分别删除待同步数据在本地的编号所对应的条目；如果数据类型是数据项目，且删除类型为非永久删除，则在本地的数据条目-目录对应关系表中删除待同步数据在本地的编号所对应的条目。
较佳地，步骤b所述当前状态指示为删除D，所述与该变化状态相对应的数据同步命令为删除Delete同步命令；所述另一端确定操作类型为删除；所述更改相应表格的内容，实现数据同步的过程包括以下步骤根据接收到的数据同步命令确定删除类型，以及待同步数据的数据类型，如果数据类型是目录项，则再判断该待删除目录下的数据项目以及该目录的子目录及子目录下的数据项目是否仅存在于该待删除目录下，如果是，则确定该待删除目录以及该目录下的数据项目、和子目录及子目录下的数据项目均为永久删除，否则，确定针对该待删除目录以及仅存在于该待删除目录下的数据项目或目录项为永久删除，针对并非仅存在于该待删除目录下的数据项目或目录项为非永久删除；如果删除的是目录项，则无论是删除类型为永久删除还是非永久删除，都在本地已设置的目录表中删除待同步数据在本地的编号所对应的条目；如果删除的是数据项目，且删除类型为永久删除，则在本地数据库内删除该数据，并在本地已设置的数据条目表和数据条目-目录对应关系表中，分别删除待同步数据在本地的编号所对应的条目；如果数据类型是数据项目，且删除类型为非永久删除，则在本地的数据条目-目录对应关系表中删除待同步数据在本地的编号所对应的条目。
较佳地，步骤c所述变化状态为删除D，所述与该变化状态相对应的数据同步命令为删除Delete同步命令；则所述发起同步请求的一端进一步包括判断接收到的来自用户的删除命令中是否指示永久删除该数据项目，如果是，则所述删除命令中进一步包括永久删除的标识，否则，判断该待删除数据项目是否位于多个目录下，如果是，在所述删除命令中进一步包括非永久删除的标识，否则所述删除命令中进一步包括永久删除的标识；所述另一端确定操作类型为删除；所述更改相应表格的内容，实现数据同步的过程包括以下步骤根据接收到的数据同步命令确定数据类型为数据项目后，再确定删除类型，如果删除类型为永久删除，则在本地数据库内删除该数据，并在本地已设置的数据条目表和数据条目-目录对应关系表中，分别删除待同步数据在本地的编号所对应的条目；如果删除类型为非永久删除，则在本地的数据条目-目录对应关系表中删除待同步数据在本地的编号所对应的条目。
较佳地，在作为执行同步操作的客户端或服务器另一端执行完毕删除同步操作后，进一步包括发起同步请求的一端在本地已设置的相应数据表中删除相应数据项目。
较佳地，如果所述发起同步请求的为客户端，执行同步操作的为服务器端，则所述同步命令中的待同步数据编号是该数据在客户端的编号；所述服务器端接收到数据同步命令后，确定数据类型前进一步包括在已设置的SyncML客户端内的编号与服务器内的编号的对应关系列表中获取该更新的待同步数据在服务器本地的编号，之后再继续执行后续操作。
如果所述发起同步请求的为服务器端，执行同步操作的为客户端，则所述同步命令中的待同步数据编号是服务器端根据自身已设置的客户端内的编号与服务器内的编号的对应关系列表获取的该数据在客户端的编号。
较佳地，所述在SyncML客户端及服务器内分别设置的目录表中，至少包括目录项编号、目录名、该目录项名所属的父目录、以及该目录项状态的对应关系；所述在SyncML客户端及服务器内分别设置的数据条目-目录对应关系索引表中，至少包括数据项目编号、父目录、以及数据项目状态的对应关系。
较佳地，所述在SyncML客户端及服务器内分别设置的数据条目表中至少包括数据项目编号以及具体的数据内容的对应关系；所述在服务器端已设置的SyncML客户端内的编号与服务器内的编号的对应关系列表中至少包括数据在客户端内的编号与服务器内的编号的对应关系。
较佳地，所述协商待同步数据所属目录的操作在初始化阶段，包括以下步骤对URI的格式作预定义，在目标数据库元素中通过URI的含义指明待同步目录。
较佳地，所述协商待同步数据所属目录的操作在初始化阶段，包括以下步骤在过滤条件元素中通过过滤条件指明待同步目录。
较佳地，该方法进一步包括增设以服务器端和客户端合并处理(Win-Win)的仲裁结果；当服务器端和客户端的修改操作发生冲突时，客户端根据服务器端的修改执行同步操作，并且，服务器端根据客户端的修改执行同步操作；所述修改包括新增、更新、移动、删除、复制操作。
本发明所述方法，不但详细给出了实现数据分类同步的具体实现方式，使得针对某一目录进行同步能够得以实现，而且，还在具体实现的过程中，尽量传递编号、数据类型等信息，避免了过多的具体的数据内容进行传递，且同步数据实际占用的物理空间也较小(每个数据只有一份)，因而最大限度地减少了冗余数据的存在，节省了有限的设备资源和网络资源。同时用户可以按照自己的意愿创建物理或逻辑分类，可以通过拖拉操作等，将数据项目归入指定的目录，不需要手工去编辑数据项目；可以指定任一目录即分类进行递归或非递归同步，增强了用户体验感。
图1所示为实现同步的示意图；图2所示为客户端和服务器端的数据存储示意；图3a所示为应用本发明实施例一的用户定义的数据结构示意图；图3b所示为应用本发明实施例一的客户端的数据存储示意图；图4a所示为应用本发明实施例二的用户定义的数据结构示意图；图4b所示为应用本发明实施例二的客户端的数据存储示意图；图5a所示为应用本发明实施例三的用户定义的数据结构示意图；图5b所示为应用本发明实施例三的客户端的数据存储示意图；图6a所示为应用本发明实施例四的用户定义的数据结构示意图；图6b所示为应用本发明实施例四的客户端的数据存储示意图；图7a所示为应用本发明实施例五的用户定义的数据结构示意图；图7b所示为应用本发明实施例五的客户端的数据存储示意图；
图8a所示为应用本发明实施例六的用户定义的数据结构示意图；图8b所示为应用本发明实施例六的客户端的数据存储示意图。
具体实施例方式
下面结合附图及具体实施例，对本发明再做进一步地详细说明。
为了实现能够使用户按照自己的意愿创建物理或逻辑分类目录，并指定任意一分类目录进行递归同步或非递归同步，需要在客户端和服务器端分别设置以下三张数据表1、数据条目表(Data Item Table)该表用于保存所有的数据项目信息，其包括数据项目编号以及具体的数据内容(Data)的对应关系；其中，所述数据项目编号在客户端以Item LUID表示，在服务器端以Item GUID表示2、目录表(Folder Table)该表用于保存所有的目录项信息，其包括目录项编号、目录名(Name)、该目录项名所属的父目录(Parent Source)、以及该目录项状态(Folder Satus)的对应关系。其中的状态主要包括现存未修改Existing(E)、新增New(N)、更新Update(U)、删除Delete(D)、移动Move(M)以及复制Copy(C)状态；其中，Delete又可以分为永久删除Delete permanetly(P-D)和非永久删除Delete non-permanetly(P-ND)两种状态；所述目录项编号在客户端以Folder LUID表示，在服务器端以Folder GUID表示。
3、数据条目-目录对应关系索引表(Index Table)该表用于保存数据项目的归属关系，其包括数据项目编号、父目录(Parent Source)以及数据项目状态(Data Satus)的对应关系；其中所述数据项目编号在客户端以ItemLUID表示，在服务器端以Item GUID表示。
再有，在服务器端还需保存数据在SyncML客户端内的编号与服务器内的编号的对应关系列表，即GUID与LUID之间的对应关系。
众所周知，在SyncML中实现同步分为三个阶段同步初始化阶段、同步阶段和同步完成阶段。在本发明中同步完成阶段的处理与现有方式相同，因此，以下仅就同步初始化阶段和同步阶段进行描述。
在同步初始化阶段，除了象现有技术一样协商需要同步的数据库、终端能力之外，还要指明待同步目录，具体的可以有以下两种方式来实现方式一在目标数据库元素中指明待同步目录。具体为对统一资源标识符(URI，Uniform Resource Identifier)的格式作预定义，预先指定哪一级标识数据库地址，哪一级表示目录的地址，通过URI的标识指明待同步目录。当然，如果需要同步多个目录，可同时给出多个URI予以指明。
方式二在过滤条件元素中指明待同步目录。具体为扩展现有的过滤功能，在过滤条件(如Filter)中指明待同步目录。所述待同步目录是SyncML级别的目录，是不依赖于同步数据类型的。当然，如果需要同步多个目录，可同时指出多个目录。
下面结合具体实施例对同步阶段进行说明。由于客户端发起同步与服务器端发起同步的处理流程相类似，下面仅以客户端发起同步，服务器端执行数据同步操作为例进行说明。
实施例一用户在短信的根目录(./sms)下增加了一个新的目录“bless”，并且，在“bless”目录下又增加了两个子目录分别为“Spring Festival”和“Mid-autumn Festival”，同时，在每个目录下分别增加了一个数据，即在“bless”目录下增加了数据N1，在“Spring Festival”目录下增加了数据N2，在“Mid-autumn Festival”目录下增加了数据N3。
参见图3a和图3b，图3a所示为应用本发明实施例一的用户定义的数据结构示意图，其中，方框表示Folder，圆圈表示data Item；实线表示的状态为Existing，虚线表示的状态为New。图3b所示为应用本发明实施例一的客户端的数据存储示意图。在客户端保存有数据条目表Data Item Table、目录表Folder Table和“数据条目-目录”对应关系索引表Index Table。各个列表所增加数据的状态在图3b都有相应的反映。
当用户要求同步“bless”目录时，客户端顺序生成以下同步命令首先，客户端根据接收到的来自用户的同步bless目录的命令确定同步数据是一个目录项后，从Folder Table确定该bless的状态为N，之后，构建增加(ADD)的同步命令，并且，在该构建的命令中的Meta字段指明根据Folder Table确定的数据类型为目录项Folder，LUID字段指明待同步数据的编号1006，Data字段指明具体的数据为bless，SourceParent字段指明其所属父目录为根目录。
之后，客户端确定bless目录下数据项目状态，由于在Index Table中，数据项目2001所对应的状态为N，因此，构建ADD同步命令，并且从DataItem Table中确定2001所对应的具体数据内容为N1后，该所构建的ADD同步命令中的Meta字段指明数据类型为数据项目Item，LUID字段指明待同步数据的编号为2001，Data字段指明具体的数据为N1，SourceParent字段指明其所属父目录为1006。
之后，当客户端确定bless目录下没有新增加的数据项目后，索引该bless目录下子目录的状态，其具体方法与确定bless目录的方法相同，此处不再赘述。其确定的结果是构建两个ADD同步命令，其中一个命令中的Meta字段指明数据类型为目录项Folder，LUID字段指明待同步数据的编号1007，Data字段指明具体的数据为Spring Festival，SourceParent字段指明其所属父目录为1006；另一个命令中的Meta字段指明数据类型为目录项Folder，LUID字段指明待同步数据的编号1008，Data字段指明具体的数据为Mid-autumnFestival，SourceParent字段指明其所属父目录为1006。
之后，当客户端确定bless目录下没有新增加的子目录后，再确定SpringFestival目录和Mid-autumn Festival目录下的数据项目的状态，其具体方法与确定N1的方法相同，即客户端会分别再构造两条ADD同步命令，在此不再赘述。
以此类推，直到针对所有增加的数据均发出ADD同步命令为止，这样也就实现了递归同步。当然，如果只同步某一目录项，而不再同步该目录项下的数据项，实际就是实现了非递归同步。另外，还可以只同步某一目录项及该目录项下的数据项目，而不再同步该目录项下的子目录项。
之后，将所构造的ADD同步命令全部发送给服务器。如果每个ADD命令的数据量较少，可在一个消息中包含多个ADD命令，一次性交互即可；如果数据较多，需要多次交互。在实际应用中，还可以只发送一个ADD同步命令，但在一个ADD命令中包含多个目录和数据项目，即其逻辑上仍然是多个ADD命令。
下面说明服务器端接收到上述ADD命令后，执行同步操作的过程。该过程所涉及的表格与图3b所示表格类似，因此图未示。
当服务器端接收到增加bless目录项的同步命令后，通过接收到的同步命令中的Meta字段确定待同步数据的类型为目录项，根据LUID字段确定该待同步数据在客户端的编号为1006，根据Data字段确定其名称为bless，根据SourceParent字段确定其父目录为根目录。之后，为该待同步数据分配服务器本地编号Folder GUID，如100006。然后，在本地已设置的目录表中增加相应条目，即增加100006、bless、根目录以及该bless数据当前状态的对应关系条目。并且，在自身已设置的SyncML客户端内的编号与服务器内的编号的对应关系列表中保该同步数据在客户端的编号LUID与该同步数据在服务器端的编号GUID的对应关系，即保存1006和100006之间的对应关系。
当服务器端接收到增加N1数据项目的同步命令后，通过接收到的同步命令中的Meta字段确定待同步数据的类型为数据项目，根据LUID字段确定该待同步数据在客户端的编号为2001，根据Data字段确定其具体的数据内容为N1，根据SourceParent字段确定其父目录为1006。之后，在本地数据库中保存该N1数据，然后为该待同步数据分配服务器本地编号FolderGUID，如200001，并在本地已设置的数据条目表Data Item Table中增加相应条目，即增加200001和N1的对应关系条目；在Index Table中增加相应条目，即增加200001、100006以及该N1数据当前状态的对应关系条目，在自身已设置的SyncML客户端内的编号与服务器内的编号的对应关系列表中保该同步数据在客户端的编号与该同步数据在服务器端的编号的对应关系，即保存2001和200001之间的对应关系。
服务器端增加Spring Festival目录项和Mid-autumn Festival目录项的方式与增加bless目录项的方式相同，增加N2和N3数据项目的方法与增加N1数据项目的方式相同，在此不再赘述。
另外，有一点需要说明的是如果是服务器端发起同步请求，由客户端执行同步操作，则服务器端发送给客户端的同步请求中包含待同步数据在服务器端的编号，客户端执行完同步操作后，将给服务器端返回该数据客户端内的编号与服务器内的编号的对应关系即LUID与GUID的对应关系，由服务器端将接收到的对应关系保存在本地已设置的SyncML客户端内的编号与服务器内的编号的对应关系列表内。
至此，实现了增加数据的同步操作，而且该数据可以是一个具体的数据项目，也可以是根据用户的意愿而创建的目录项，且该目录项不受系统的数据物理结构的限制。可见，应用本发明的好处是相同的数据只需传递一份，而且，执行同步操作的一端，对相同数据也只需保存一份，大大节省了网络资源和设备本身的资源。例如，假设N1同时属于bless、Spring Festival和Mid-autumn Festival目录下，那么在服务器端的同步操作过程中，只需在Index Table中再增加两条相应条目，即增加200001、100007以及该N1数据当前状态的对应关系条目，和200001、100008以及该N1数据当前状态的对应关系条目即可。
实施例二用户在短信的根目录(./sms)下更新了目录“bless”的属性，并更新了“bless”目录下数据U1，仅更新了“Spring Festival”目录下的数据U2。本实施例中，U2同时属于Spring Festival和Mid-autumn Festival两个目录下。
参见图4a和图4b，图4a所示为应用本发明实施例二的用户定义的数据结构示意图，其中，方框表示Folder，圆圈表示data Item；实线表示的状态为Existing，点画线表示的状态为Updata。图4b所示为应用本发明实施例二的客户端的数据存储示意图。在客户端保存有数据条目表Data Item Table、目录表Folder Table和“数据条目-目录”对应关系索引表Index Table。各个列表所中数据的状态在图4b都有相应的反映。
当用户要求同步“bless”目录时，客户端顺序生成以下同步命令首先，客户端根据接收到的来自用户的同步bless目录的命令确定同步数据是一个目录项后，从Folder Table确定该bless的状态为U，之后，构建替换(Replace)的同步命令，并且，在该构建的命令中的Meta字段指明根据Folder Table确定的数据类型为目录项Folder，LUID字段指明待同步数据的编号1006，Data字段指明具体的数据为bless，SourceParent字段指明其所属父目录为根目录。
之后，客户端确定bless目录下数据项目状态，由于在Index Table中，1006所对应的数据项目为2001，且其状态为U，因此，构建Replace同步命令，并且从Data Item Table中确定2001所对应的具体数据内容为U1后，该所构建的Replace同步命令中的Meta字段指明数据类型为数据项目Item，LUID字段指明待同步数据的编号为2001，Data字段指明具体的数据为U1，SourceParent字段指明其所属父目录为1006。
之后，当客户端确定bless目录下没有更新的数据项目后，索引该bless目录下子目录的状态，其具体方法与确定bless目录的方法相同，本例中，该bless目录下子目录的状态未发生变化，不做处理。
之后，当客户端确定bless目录下没有更新的子目录后，再确定子目录Spring Festival下的数据项目的状态，其具体方法与确定U1的方法相同。即其最终的结果是构建Replace同步命令，并且从Data Item Table中确定2002所对应的具体数据内容为U2后，该所构建的Replace同步命令中的Meta字段指明数据类型为数据项目Item，LUID字段指明待同步数据的编号为2002，Data字段指明具体的数据为U2，SourceParent字段指明其所属父目录为1007。
以此类推，直到针对所有更新的数据均发出Replace同步命令为止，这样也就实现了递归同步。当然，如果只同步某一目录项，而不再同步该目录项下的数据项，实际就是实现了非递归同步。另外，还可以只同步某一目录项及该目录项下的数据项目，而不再同步该目录项下的子目录项。
之后，将所构造的Replace同步命令全部发送给服务器，具体发送方式与发送ADD同步命令的方式相同，在此不再赘述。
下面说明服务器端接收到上述Replace命令后，执行同步操作的过程。该过程所涉及的表格与图4b所示表格类似，因此图未示。
当服务器端接收到更新bless目录项的同步命令后，通过接收到的同步命令中的Meta字段确定待同步数据的类型为目录项，根据LUID字段确定该待同步数据在客户端的编号为1006，根据Data字段确定其名称为bless，根据SourceParent字段确定其父目录为根目录。之后，在已设置的SyncML客户端内的编号与服务器内的编号的对应关系列表中获取该更新的待同步数据在服务器本地的编号；如100006。然后，在本地已设置的目录表中更新相应条目，即更新100006、bless、根目录以及该bless数据当前状态的对应关系条目中的bless的属性信息。
当服务器端接收到更新U1数据项目的同步命令后，通过接收到的同步命令中的Meta字段确定待同步数据的类型为数据项目，根据LUID字段确定该待同步数据在客户端的编号为2001，根据Data字段确定其具体的数据内容为U1，根据SourceParent字段确定其父目录为1006。之后，在已设置的SyncML客户端内的编号与服务器内的编号的对应关系列表中获取该更新的待同步数据在服务器本地的编号，如200001，在本地已设置的数据条目表中更新待同步数据在本地的编号所对应的条目，即更新200001与U1的对应关系条目中的U1的信息。
服务器端更新U2的方法与更新U1的方法相同，在此不再赘述。
此处需要说明一点，本例中，U2既属于Spring Festival目录又Mid-autumn Festival目录，但更新U2时只需发送一次Replace命令，服务器端也只需更新一次U2，就可以使两个目录下的U2都得到更新。这是因为，在服务器端实际只保存了一份数据，该数据的隶属关系是通过Index Table表来体现的。可见，采用本发明的方法可最大限度地减少冗余数据的存在，进而最大限度地节省有限的资源。
实施例三用户将“music”目录下的数据项目“M1”移动到“favoriate”目录下；将“mp3”整个目录移动到“favorite”下。
参见图5a和图5b，图5a所示为应用本发明实施例三的用户定义的数据结构示意图，其中，方框表示Folder，圆圈表示data Item；实线表示的状态为Existing，双点画线表示的状态为Move。图5b所示为应用本发明实施例三的客户端的数据存储示意图。在客户端保存有数据条目表Data Item Table、目录表Folder Table和“数据条目-目录”对应关系索引表Index Table。各个列表中数据的状态在图5b都有相应的反映。
当用户要求同步根目录时，客户端顺序生成以下同步命令首先，客户端根据接收到的来自用户的同步根目录的命令后，索引该根目录下的所有子目录的状态，本例中，该根目录下所有子目录的状态未发生变化，因而不做处理。然后，客户端索引该根目录下的数据项目的状态是否发生变化，本例中，该根目录下的数据项目的状态也未发生变化，不做处理。
之后，客户端依次索引每个子目录中的子目录状态是否发生变化，本例中，客户端确定music目录下的“mp3”子目录的状态为M，之后，构建移动(Move)同步命令，并且，在该构建的命令中的Meta字段指明根据FolderTable确定的数据类型为目录项Folder，LUID字段指明待同步数据的编号1006，SourceParent字段指明其移动后所属父目录为1004。
之后，客户端确定music目录下数据项目的状态，由于在Index Table中，1006所对应的数据项目为2001，且其状态为M，因此构建Move同步命令，并且，在该构建的命令中的Meta字段指明数据类型为数据项目Item，LUID字段指明待同步数据的编号2001，SourceParent字段指明其移动后所属的父目录为1004。
以此类推，本例中没有其他发生移动的数据，因此不再处理。
之后，将所构造的MOVE同步命令全部发送给服务器，具体发送方式与发送ADD同步命令的方式相同，在此不再赘述。
下面说明服务器端接收到上述Move命令后，执行同步操作的过程。该过程所涉及的表格与图5b所示表格类似，因此图未示。
当服务器端接收到移动mp3目录项的同步命令后，通过接收到的同步命令中的Meta字段确定待同步数据的类型为目录项，LUID字段确定该待同步数据在客户端的编号为1006，SourceParent字段确定其移动后所属父目录为1004后，在已设置的SyncML客户端内的编号与服务器内的编号的对应关系列表中获取该待移动数据在服务器本地的编号，如100006，在本地已设置的Folder Table中将该待同步数据在本地的编号所对应的条目所属父目录更改为接收到的同步命令中的父目录，即将该表中的100006所对应的父目录由1005改为1004。
当服务器端接收到移动M1数据项目的同步命令后，通过接收到的同步命令中的Meta字段确定待同步数据的类型为Item，LUID字段确定该待同步数据在客户端的编号为2001，SourceParent字段确定其移动后所属父目录为1004后，在已设置的SyncML客户端内的编号与服务器内的编号的对应关系列表获取该更新的待同步数据在服务器本地的编号，如200001，在本地已设置的Index Table中将该待同步数据在本地的编号所对应的条目所属父目录更改为接收到的同步命令中的父目录，即将该表中的200001所对应的父目录由1005改为1004。
可见，采用本发明的方法进行移动的同步操作时，仅需修改相应数据表中的对应关系，不需要对实际数据进行移动，从而最大限度节省了有限的资源。
另外需要说明一点在移动某个目录及其下的子目录和数据项目时，比如移动mp3目录项时，只需针对mp3目录项只发送一条MOVE命令，而不需再针对mp3目录下的子目录和数据项目发送MOVE命令，因为其下的子目录和数据项目所属的父目录是未发生任何变化的。
实施例四用户删除了“bless”目录下的“D1”数据项目，对“SpringFestival”目录下的数据“U2”选择了永久删除，“D3”选择了非永久删除。本例中，仅是对删除数据项目的描述。
参见图6a和图6b，图6a所示为应用本发明实施例四的用户定义的数据结构示意图，其中，方框表示Folder，圆圈表示data Item；实线表示的状态为Existing，点线表示的状态为Delete。图6b所示为应用本发明实施例四的客户端的数据存储示意图。在客户端保存有数据条目表Data Item Table、目录表Folder Table和“数据条目-目录”对应关系索引表Index Table。各个列表中数据的状态在图6b都有相应的反映。
当用户要求同步“bless”目录时，客户端顺序生成以下同步命令客户端确定bless目录下数据项目状态，由于在Index Table中，数据项目为2001的状态为永久删除P-D，因此，构建删除Delete同步命令，该所构建的Delete同步命令中的Meta字段指明数据类型为数据项目Item，LUID字段指明待同步数据的编号为2001，并且在该命令中还需包括指明永久删除的标识。
之后，当客户端确定bless目录下没有删除的数据项目后，索引该bless目录下子目录的状态，本例中，该bless目录下子目录的状态未发生变化，不做处理。
当客户端确定bless目录下没有删除的子目录后，再确定子目录SpringFestival下的数据项目的状态，其具体方法与确定D1的方法相同。即其最终的结果是构建两条Delete同步命令，其中一条Delete同步命令中的Meta字段指明数据类型为数据项目Item，LUID字段指明待同步数据的编号为2002，并且在该命令中还需包括指明永久删除的标识。另一条Delete同步命令中的Meta字段指明数据类型为数据项目Item，LUID字段指明待同步数据的编号为2003，并且在该命令中还需包括指明非永久删除的标识。
所构建的Delete命令中，不需要包含要删除的数据，只需指明要删除数据的类型、编号、以及是永久删除还是非永久删除即可。以上是Delete命令的一种实现方式，即该命令中包含类型、编号、以及是永久删除还是非永久删除三种信息；当然，还可以有其他的实现方式，比如，将Delete分为两种命令，一种永久删除P-Delete命令，另一种是非永久删除NP-Delete命令，这样，每种删除命令中只需包含待删除数据的类型、编号即可。
之后，将所构造的用于指示删除的同步命令全部发送给服务器。
下面说明服务器端接收到上述Delete命令后，执行同步操作的过程。
当服务器端接收到删除D1数据项目的同步命令后，通过接收到的同步命令中的Meta字段确定待同步数据的类型为数据项目Item，根据LUID字段确定该待同步数据在客户端的编号为2001，并确定此次删除为永久删除，之后，在已设置的SyncML客户端内的编号与服务器内的编号的对应关系列表中获取该待删除数据在服务器本地的编号，如200001，在本地的数据条目表和数据条目-目录对应关系表，分别删除待同步数据在本地的编号所对应的条目，即删除编号为200001的整个条目。同时，在本地数据库中删除D1数据。
当服务器端接收到删除D2数据项目的同步命令后，即删除相应数据表中的整个条目，其删除D2的方法与删除D1的方法相同，在此不再赘述。
当服务器端接收到删除D3数据项目的同步命令后，通过接收到的同步命令中的Meta字段确定待同步数据的类型为数据项目Item，根据LUID字段确定该待同步数据在客户端的编号为2003，并确定此次删除为非永久删除，之后，在已设置的SyncML客户端内的编号与服务器内的编号的对应关系列表中获取该待删除数据在服务器本地的编号，如200003，只在本地的数据条目-目录对应关系表中删除待同步数据在本地的编号所对应的条目，即删除该表中编号为200003的整个条目。在本地数据库内不删除D3数据。
可见，采用本发明的方法进行删除的同步操作时，仅需在客户端与服务器端之间传递标识，不需要传输具体的数据内容，最大限度节省了有限的资源。
实施例五用户删除了整个“bless”目录。这相当于同时删除了其下的所有子目录以及其下的所有数据项目。本例中，D1和D2仅存在于bless目录下，D3存在于bless和joke目录下，且本例仅是对删除目录项的描述。
参见图7a和图7b，图7a所示为应用本发明实施例五的用户定义的数据结构示意图，其中，方框表示Folder，圆圈表示data Item；实线表示的状态为Existing，点线表示的状态为Delete。图7b所示为应用本发明实施例五的客户端的数据存储示意图。在客户端保存有数据条目表Data Item Table、目录表Folder Table和“数据条目-目录”对应关系索引表Index Table。各个列表中数据的状态在图7b都有相应的反映。
当用户要求同步根目录时，客户端顺序生成以下同步命令首先，客户端根据接收到的来自用户的同步根目录的命令后，索引该根目录下的所有子目录的状态，本例中，从Folder Table表中确定bless的状态为D，则客户端还要进一步包括判断该待删除目录下的数据项目以及该目录的子目录下的数据项目是否仅存在于该待删除目录下，如果是，则构建一条删除命令，且该删除命令中包含指示永久删除的信息；否则，针对每个数据项目和目录项分别构建一条删除命令，且仅存在于该待删除目录下的数据项目或目录项所对应的删除命令中包含指示永久删除的信息，并非仅存在于该待删除目录下的数据项目或目录项所对应的删除命令中包含指示非永久删除的信息。也就是说，如果某个数据项目或目录项，还存在于其他目录下(这里的其他目录不包括bless子目录)，则将这样的数据所对应的删除命令中包含非永久删除信息，如果不是这样的数据，则其所对应的删除命令中包含永久删除信息。之后，将所构建的所有删除Delete同步命令均发送给服务器。这里，针对每个数据项目和目录项分别构建一条删除命令，实际就是一种递归的同步。
下面说明服务器端接收到上述Delete命令后，执行同步操作的过程。
如果服务器接收到的是针对数据项目的删除命令，则与实施例四中所述的处理方式相同，不再赘述。
如果服务器接收到的是针对目录项的删除命令，则在已设置的SyncML客户端内的编号与服务器内的编号的对应关系列表中获取该待删除数据在服务器本地的编号，而无论是永久删除还是非永久删除都在本地已设置的目录表中删除待同步数据在本地的编号所对应的条目。
对于目录删除操作还有一点需要说明作为请求发起方的客户端，在删除某个目录项时，如删除bless目录项，其可以针对该目录项只构建一条删除命令，而其所执行的其他操作，如“判断该待删除目录下的数据项目以及该目录的子目录下的数据项目是否仅存在于该待删除目录下”等，均由服务器端来执行，这样可以简化客户端的操作。当然，反之也适用。
在实际应用中，实施例四、五通常会结合起来同时使用。
另外，对于删除操作，在服务器端完成同步操作后，客户端也会将自身相应数据表中的条目删除。
实施例六用户将“music”目录下的数据项目“M1”复制到“favoriate”目录下；将“mp3”目录复制到“favorite”目录下。
参见图8a和图8b，图8a所示为应用本发明实施例六的用户定义的数据结构示意图，其中，方框表示Folder，圆圈表示data Item；实线表示的状态为Existing，粗实线表示的状态为Copy。图8b所示为应用本发明实施例六的客户端的数据存储示意图。在客户端保存有数据条目表Data Item Table、目录表Folder Table和“数据条目-目录”对应关系索引表Index Table。各个列表所增加数据的状态在图3b都有相应的反映。
当用户要求同步根目录时，客户端与服务器端的操作与实施例一的操作基本一致。所不同之处在于，在实施例一中，客户端要针对每一个数据项目和目录项都发送一次ADD命令，而在本例中，如果客户端对一目录项发出Copy命令，则不需对该目录项下的子目录项和数据项目再发命令，从而进一步减少数据量的传输，节约网络资源。而本例中服务器端的处理过程与实施例一中的处理过程是相同的，其也是针对每一个目录项和数据项目逐一地进行处理。
再有，在执行Copy同步时，用户可根据需要决定，是否在再指令复制一份实际数据，如果是，则执行同步操作的一端实现数据同步的操作进一步包括在本地数据库内在复制一份数据，并在本地已设置的数据目录表中增加相应条目。
如果客户端和服务器端的修改操作存在冲突，如在被移动的目录中增加、更新或者删除了一些条目，通过扩展现有的冲突机制，确保客户端和服务器端的数据完全同步。具体实现为将现有的以客户端为主(Client-Win)和以服务器端为主(Server-Win)的仲裁结果加以扩展，增加一种以服务器端和客户端合并处理(Win-Win)的仲裁结果，通过双赢的方式来确保客户端和服务器端的数据完全一致。
例如，用户在客户端上移动A目录使其成为B目录的子目录，而服务器端是在A目录中增加了一个条目，此时，在服务器端将移动A目录使其成为B目录的子目录，并且，在客户端在A目录中也增加一个条目，从而确保客户端和服务器端的数据完全一致。
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
权利要求
1.一种在SyncML层实现数据同步的方法，其特征在于，当SyncML客户端或服务器端中的一端接收到来自用户的同步请求时，客户端和服务器端协商待同步数据所属目录；该方法包括以下步骤a、SyncML客户端或服务器端中的一端首先确定接收到的请求同步命令中待同步数据的类型，如果是目录项，则执行步骤b，如果是数据项目，则执行步骤c；b、从已设置的目录表中获取该待同步数据的当前状态，如果当前状态指示为未变化，则不做处理，如果当前状态指示为变化，则根据该变化状态构建与之相对应的数据同步命令，将该数据同步命令发送给客户端或服务器端中的另一端；c、从已设置的数据条目-目录对应关系表中获取该待同步数据的变化状态，并根据该变化状态构建与之相对应的数据同步命令，将该数据同步命令发送给客户端或服务器端中的另一端；所述所构建的命令中至少包括待同步数据的数据类型和待同步数据编号；SyncML客户端或服务器中的另一端接收到来自对端的同步命令后，执行以下步骤d、根据接收到的数据同步命令，确定操作类型，更改相应表格的内容，实现数据同步。
2.根据权利要求1所述的方法，其特征在于，所述发起同步请求的为客户端，所述执行同步操作的为服务器端；所述该待同步数据的变化状态为新增N，所述与该变化状态相对应的数据同步命令为增加ADD同步命令；所述该命令中的待同步数据编号是该数据在客户端的编号，且该命令中进一步包括具体的待同步数据以及该数据所属父目录；所述服务器端确定操作类型为增加；所述更改相应表格的内容，实现数据同步的过程包括以下步骤根据接收到的数据同步命令，在本地数据库保存接收到的待同步数据，为该待同步数据分配服务器本地编号，在已设置的SyncML客户端内的编号与服务器内的编号的对应关系列表中保存该同步数据在客户端的编号与该同步数据在服务器端的编号的对应关系；并且，根据同步命令中的待同步数据的数据类型，确定该同步数据的类型，如果数据类型是目录项，则在本地已设置的目录表中增加相应条目，如果数据类型是数据项目，则在本地已设置的数据条目表和数据条目-目录对应关系索引表中增加相应条目。
3.根据权利要求1所述的方法，其特征在于，所述发起同步请求的为服务器端，所述执行同步操作的为客户端；所述该待同步数据的变化状态为新增N，所述与该变化状态相对应的数据同步命令为增加ADD同步命令；所述该命令中的待同步数据编号是该数据在服务器端的编号，且该命令中进一步包括具体的待同步数据以及该数据所属父目录；所述客户端确定操作类型为增加；所述更改相应表格的内容，实现数据同步的过程包括以下步骤根据接收到的数据同步命令，在本地数据库保存接收到的待同步数据，为该待同步数据分配客户端本地编号，并且，根据同步命令中的待同步数据的数据类型，确定该同步数据的类型，如果数据类型是目录项，则在本地已设置的目录表中增加相应条目，如果数据类型是数据项目，则在本地已设置的数据条目表和数据条目-目录对应关系索引表中增加相应条目；之后，给服务器端返回该数据客户端内的编号与服务器内的编号的对应关系，由服务器端将接收到的对应关系保存在本地已设置的SyncML客户端内的编号与服务器内的编号的对应关系列表内。
4.根据权利要求2或3所述的方法，其特征在于，步骤b执行完毕之后，进一步包括e判断该新增加的目录项下是否有新增加的数据项目，如果有，则重复执行步骤c，直到将所有数据项目全部同步为止，之后执行步骤f；如果没有，则直接执行步骤f；f、判断该新增加的目录项下是否有新增加的子目录项，如果有，则重复执行步骤b，直到将所有目录项全部同步为止，之后执行步骤e，如果没有，则结束。
5.根据权利要求2或3所述的方法，其特征在于，步骤b执行完毕之后，进一步包括e判断该新增加的目录项下是否有新增加的数据项目，如果有，则重复执行步骤c，直到将所有数据项目全部同步为止。
6.根据权利要求1所述的方法，其特征在于，所述该待同步数据的变化状态为更新U，所述与该变化状态相对应的数据同步命令为替换Replace同步命令，且该命令中进一步包括具体的待同步数据，以及该数据所属父目录；所述另一端确定操作类型为更新；所述更改相应表格的内容，实现数据同步的过程包括以下步骤根据接收到的数据同步命令，确定该同步数据的类型，如果数据类型是目录项，则在本地已设置的目录表中更新待同步数据在本地的编号所对应的条目，如果数据类型是数据项目，则在本地已设置的数据条目表中更新待同步数据在本地的编号所对应的条目。
7.根据权利要求6所述的方法，其特征在于，步骤b执行完毕之后，进一步包括g判断该已更新的目录项下是否有更新的数据项目，如果有，则重复执行步骤c，直到将所有数据项目全部同步为止，之后执行步骤h；如果没有，则直接执行步骤h；h、判断该已更新的目录项下是否存在更新的子目录项，如果有，则重复执行步骤b，直到将所有目录项全部同步为止，之后执行步骤g，如果没有，则结束。
8.根据权利要求6所述的方法，其特征在于，步骤b执行完毕之后，进一步包括g判断该已更新的目录项下是否有更新的数据项目，如果有，则重复执行步骤c，直到将所有数据项目全部同步为止。
9.根据权利要求1所述的方法，其特征在于，所述该待同步数据的变化状态为移动M，所述与该变化状态相对应的数据同步命令为移动Move同步命令；且该命令中进一步包括变更后的该数据所属父目录；所述另一端确定操作类型为移动；所述更改相应表格的内容，实现数据同步的过程包括以下步骤根据接收到的数据同步命令，确定该同步数据的类型，如果数据类型是目录项，则在本地已设置的目录表中将该待同步数据在本地的编号所对应的条目所属父目录更改为接收到的同步命令中的父目录，如果数据类型是数据项目，则在本地已设置的数据条目-目录对应关系表中将待同步数据在本地的编号所对应的条目所属父目录更改为接收到的同步命令中的父目录。
10.根据权利要求1所述的方法，其特征在于，步骤b所述当前状态指示为删除D，所述与该变化状态相对应的数据同步命令为删除Delete同步命令；则所述发起同步请求的一端进一步包括判断该待删除目录下的数据项目以及该目录的子目录下的数据项目是否仅存在于该待删除目录下，如果是，则构建一条删除命令，且该删除命令中包含指示永久删除的信息；否则，针对每个数据项目和目录项分别构建一条删除命令，且仅存在于该待删除目录下的数据项目或目录项所对应的删除命令中包含指示永久删除的信息，并非仅存在于该待删除目录下的数据项目或目录项所对应的删除命令中包含指示非永久删除的信息；所述另一端确定操作类型为删除；所述更改相应表格的内容，实现数据同步的过程包括以下步骤根据接收到的数据同步命令确定删除类型，以及待同步数据的数据类型，如果数据类型是目录项，则无论是删除类型为永久删除还是非永久删除，都在本地已设置的目录表中删除待同步数据在本地的编号所对应的条目；如果数据类型是数据项目，且删除类型为永久删除，则在本地数据库内删除该数据，并在本地已设置的数据条目表和数据条目-目录对应关系表中，分别删除待同步数据在本地的编号所对应的条目；如果数据类型是数据项目，且删除类型为非永久删除，则在本地的数据条目-目录对应关系表中删除待同步数据在本地的编号所对应的条目。
11.根据权利要求1所述的方法，其特征在于，步骤b所述当前状态指示为删除D，所述与该变化状态相对应的数据同步命令为删除Delete同步命令；所述另一端确定操作类型为删除；所述更改相应表格的内容，实现数据同步的过程包括以下步骤根据接收到的数据同步命令确定删除类型，以及待同步数据的数据类型，如果数据类型是目录项，则再判断该待删除目录下的数据项目以及该目录的子目录及子目录下的数据项目是否仅存在于该待删除目录下，如果是，则确定该待删除目录以及该目录下的数据项目、和子目录及子目录下的数据项目均为永久删除，否则，确定针对该待删除目录以及仅存在于该待删除目录下的数据项目或目录项为永久删除，针对并非仅存在于该待删除目录下的数据项目或目录项为非永久删除；如果删除的是目录项，则无论是删除类型为永久删除还是非永久删除，都在本地已设置的目录表中删除待同步数据在本地的编号所对应的条目；如果删除的是数据项目，且删除类型为永久删除，则在本地数据库内删除该数据，并在本地已设置的数据条目表和数据条目-目录对应关系表中，分别删除待同步数据在本地的编号所对应的条目；如果数据类型是数据项目，且删除类型为非永久删除，则在本地的数据条目-目录对应关系表中删除待同步数据在本地的编号所对应的条目。
12.根据权利要求1所述的方法，其特征在于，步骤c所述变化状态为删除D，所述与该变化状态相对应的数据同步命令为删除Delete同步命令；则所述发起同步请求的一端进一步包括判断接收到的来自用户的删除命令中是否指示永久删除该数据项目，如果是，则所述删除命令中进一步包括永久删除的标识，否则，判断该待删除数据项目是否位于多个目录下，如果是，在所述删除命令中进一步包括非永久删除的标识，否则所述删除命令中进一步包括永久删除的标识；所述另一端确定操作类型为删除；所述更改相应表格的内容，实现数据同步的过程包括以下步骤根据接收到的数据同步命令确定数据类型为数据项目后，再确定删除类型，如果删除类型为永久删除，则在本地数据库内删除该数据，并在本地已设置的数据条目表和数据条目-目录对应关系表中，分别删除待同步数据在本地的编号所对应的条目；如果删除类型为非永久删除，则在本地的数据条目-目录对应关系表中删除待同步数据在本地的编号所对应的条目。
13.根据权利要求10、11或12所述的方法，其特征在于，在作为执行同步操作的客户端或服务器另一端执行完毕删除同步操作后，进一步包括发起同步请求的一端在本地已设置的相应数据表中删除相应数据项目。
14.根据权利要求6、9、10、11或12所述的方法，其特征在于，如果所述发起同步请求的为客户端，执行同步操作的为服务器端，则所述同步命令中的待同步数据编号是该数据在客户端的编号；所述服务器端接收到数据同步命令后，确定数据类型前进一步包括在已设置的SyncML客户端内的编号与服务器内的编号的对应关系列表中获取该更新的待同步数据在服务器本地的编号，之后再继续执行后续操作。如果所述发起同步请求的为服务器端，执行同步操作的为客户端，则所述同步命令中的待同步数据编号是服务器端根据自身已设置的客户端内的编号与服务器内的编号的对应关系列表获取的该数据在客户端的编号。
15.根据权利要求1所述的方法，其特征在于，所述在SyncML客户端及服务器内分别设置的目录表中，至少包括目录项编号、目录名、该目录项名所属的父目录、以及该目录项状态的对应关系；所述在SyncML客户端及服务器内分别设置的数据条目-目录对应关系索引表中，至少包括数据项目编号、父目录、以及数据项目状态的对应关系。
16.根据权利要求2、3任一所述的方法，其特征在于，所述在SyncML客户端及服务器内分别设置的数据条目表中至少包括数据项目编号以及具体的数据内容的对应关系；所述在服务器端已设置的SyncML客户端内的编号与服务器内的编号的对应关系列表中至少包括数据在客户端内的编号与服务器内的编号的对应关系。
17.根据权利要求1所述的方法，其特征在于，所述协商待同步数据所属目录的操作在初始化阶段，包括以下步骤对URI的格式作预定义，在目标数据库元素中通过URI的含义指明待同步目录。
18.根据权利要求1所述的方法，其特征在于，所述协商待同步数据所属目录的操作在初始化阶段，包括以下步骤在过滤条件元素中通过过滤条件指明待同步目录。
19.根据权利要求1所述的方法，其特征在于，该方法进一步包括增设以服务器端和客户端合并处理(Win-Win)的仲裁结果；当服务器端和客户端的修改操作发生冲突时，客户端根据服务器端的修改执行同步操作，并且，服务器端根据客户端的修改执行同步操作；所述修改包括新增、更新、移动、删除、复制操作。
全文摘要
本发明公开了一种在SyncML层实现数据同步的方法，其不但详细给出了实现数据分类同步的具体实现方式，使得针对某一目录进行同步能够得以实现，而且，还在具体实现的过程中，尽量传递编号、数据类型等信息，避免了过多的具体的数据内容进行传递，且同步数据实际占用的物理空间也较小(每个数据只有一份)，因而最大限度地减少了冗余数据的存在，节省了有限的设备资源和网络资源。同时用户可以按照自己的意愿创建物理或逻辑分类，可以指定任一目录即分类进行同步，增强了用户体验感。
文档编号H04L29/06GK1794724SQ20051011680
公开日2006年6月28日 申请日期2005年10月27日 优先权日2005年10月27日
发明者田林一 申请人:华为技术有限公司