(57)【要約】本願は、データベースのための遠隔データ同期方法及び装置を提供し、当該方法は：データ更新イベントで更新されたサービスデータを取得し、データ更新イベントに対応するイベントバージョンを生成し、サービスデータとイベントバージョンとをイベントオブジェクト内にカプセル化するステップと；ピアエンドのサービスアプリケーションが、イベントバージョンに従って、データ更新イベントが有効であると判定した際に、ピアエンドのデータベースがサービスデータに従って更新されるようにするために、イベントオブジェクトをピアエンドのサービスアプリケーションに伝送するステップと；を備える。本願は、高速で信頼性の高いデータ同期を実現する。【選択図】図３
2018510430.tif 000002
【特許請求の範囲】
【請求項１】
データベースのための遠隔データ同期方法であって、前記方法はサービスアプリケーションによって実行され、前記データベースは前記サービスアプリケーションのデータを記憶するために用いられることを特徴とする前記方法は：
データ更新イベントで更新されたサービスデータを取得し、前記データ更新イベントに対応するイベントバージョンを生成し、前記サービスデータと前記イベントバージョンとをイベントオブジェクト内にカプセル化するステップと；
ピアエンドのサービスアプリケーションが、前記イベントバージョンに従って、前記データ更新イベントが有効であると判定した際に、ピアエンドのデータベースが前記サービスデータに従って更新されるようにするために、前記イベントオブジェクトを前記ピアエンドのサービスアプリケーションへ伝送するステップと；を備える、
遠隔データ同期方法。
【請求項２】
前記イベントオブジェクトは、サービスメインキーをさらに備え、前記サービスメインキーは異なるサービスデータを区別するために用いられることを特徴とする、
請求項１に記載の方法。
【請求項３】
前記方法は、前記サービスデータと前記イベントバージョンとをイベントオブジェクト内にカプセル化するステップの後に、前記イベントオブジェクトを記録するステップをさらに備えることを特徴とする、
請求項１に記載の方法。
【請求項４】
データベースのための遠隔データ同期方法であって、前記方法はサービスアプリケーションによって実行され、前記データベースは前記サービスアプリケーションのデータを記憶するために用いられることを特徴とする、前記方法は：
ピアエンドのサービスアプリケーションが送信したイベントオブジェクトを受信するステップであって、前記イベントオブジェクトがデータ更新イベントで更新されたサービスデータと、前記データ更新イベントに対応したイベントバージョンとを含む、ステップと；
前記イベントバージョンに従い前記ピアエンドのデータ更新イベントが有効であると判定した際に、前記データ更新イベントで更新された前記サービスデータに従って、ローカルデータベースを更新するステップ；を備えることを特徴とする、
遠隔データ同期方法。
【請求項５】
前記イベントバージョンに従い、前記ピアエンドのデータ更新イベントが有効であると判定する前記ステップは：
前記イベントバージョンに従い、前記ピアエンドのデータ更新イベントが、経時上、ローカルに記録されているデータ更新イベントの後に発生していると判定するステップ；を備えることを特徴とする、
請求項４に記載の方法。
【請求項６】
前記イベントバージョンに従い、前記ピアエンドのデータ更新イベントが、経時上、ローカルに記録されているデータ更新イベントの後に発生していると判定するステップは：
前記イベントオブジェクトに含まれるサービスメインキーに従って、前記サービスメインキーに対応する、ローカルに記録されているデータ更新イベントのイベントバージョンを取得するステップであって、前記サービスメインキーは異なるサービスデータを区別するために使用される、ステップと；
前記ローカルのイベントバージョンをピアエンドのイベントバージョンと比較し、前記ピアエンドのデータ更新イベントが、経時上、前記ローカルに記録されているデータ更新イベントの後に発生していると判定するステップと；を備えることを特徴とする、
請求項５に記載の方法。
【請求項７】
前記方法は、前記イベントバージョンに従い、前記ピアエンドのデータ更新イベントが有効であると判定した後に、前記イベントオブジェクトを記録するステップをさらに備えることを特徴とする、
請求項４に記載の方法。
【請求項８】
データベースのための遠隔データ同期装置であって、前記装置はサービスアプリケーション内に配設されており、前記データベースは前記サービスアプリケーションのデータを記憶するために用いられることを特徴とする、前記装置は：
データ更新イベントで更新されたサービスデータを取得し、前記データ更新イベントに対応するイベントバージョンを生成し、前記サービスデータと前記イベントバージョンとをイベントオブジェクト内にカプセル化するように構成されたイベントカプセル化モジュールと；
ピアエンドのサービスアプリケーションが、前記イベントバージョンに従って、前記データ更新イベントが有効であると判定した際に、ピアエンドのデータベースが前記サービスデータに従って更新されるようにするために、前記イベントオブジェクトを前記ピアエンドのサービスアプリケーションへ伝送するように構成されたイベント送信モジュールと；を備えることを特徴とする、
遠隔データ同期装置。
【請求項９】
前記イベントオブジェクトは、サービスメインキーをさらに備え、前記サービスメインキーは異なるサービスデータを区別するために用いられることを特徴とする、
請求項８に記載の装置。
【請求項１０】
データベースのための遠隔データ同期装置であって、前記装置はサービスアプリケーション内に配設されており、前記データベースは前記サービスアプリケーションのデータを記憶するために用いられることを特徴とする、前記装置は：
ピアエンドのサービスアプリケーションが送信したイベントオブジェクトを受信するように構成されたイベント受信モジュールであって、前記イベントオブジェクトがデータ更新イベントで更新されたサービスデータと、前記データ更新イベントに対応したイベントバージョンとを含む、イベント受信モジュールと；
前記イベントバージョンに従い前記ピアエンドのデータ更新イベントが有効であると判定した際に、前記データ更新イベントで更新された前記サービスデータに従って、ローカルデータベースを更新するように構成されたデータ更新モジュールと；を備えることを特徴とする、
遠隔データ同期装置。
【請求項１１】
前記データ更新モジュールは：
前記イベントオブジェクト内のサービスメインキーに従い、前記サービスメインキーに対応する、ローカルに記録されているデータ更新イベントのイベントバージョンを取得するように構成された記録取得ユニットであって、前記サービスメインキーは異なるサービスデータを区別するために用いられる、記録取得ユニットと；
前記ローカルイベントバージョンをピアエンドのイベントバージョンと比較し、経時上、前記ピアエンドのデータ更新イベントが、前記ローカルに記録されているデータ更新イベントよりも後に発生していることを判定するように構成されたイベント判断ユニットと；を備えることを特徴とする、
請求項１０に記載の装置。
【請求項１２】
前記装置は、前記イベントバージョンに従い、前記ピアエンドのデータ更新イベントが有効であると判定した後に、又は、前記サービスデータ及び前記イベントバージョンが前記イベントオブジェクト内にカプセル化された後に、前記イベントオブジェクトを記録するように構成されたイベント記録モジュールをさらに備えることを特徴とする、
請求項１０に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本願はデータベース技術に関し、特にデータベースのための遠隔データ同期方法及び装置に関する。
【背景技術】
【０００２】
各所に展開されるデータベース間におけるデータの同期には、普通、データベース関連アプリケーションが関与する。データの同期を必要とするツーエンドでのデータベースが比較的互いに遠く離れていると、従来のデータベース同期技術では同期遅延が拡大し、同期効率は低下してしまう。また、ツーエンドで同一のオブジェクトを変更すると、大幅な遅延によってデータベース側でデータ衝突を生じる可能性があり、それによって、正確なデータ修正をデータベースが拒否し、ツーエンドでのデータベースのデータに不整合が生じ、信頼性は低下する。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
上記に鑑み、本願は、高速で信頼性の高いデータ同期を実現するために、データベースのための遠隔データ同期方法及び装置を提供する。
【課題を解決するための手段】
【０００４】
具体的に、本発明は以下の技術的解決により実施される。
【０００５】
第１の態様では、データベースのための遠隔データ同期方法が提供され、当該方法はサービスアプリケーションによって実行され、データベースはサービスアプリケーションのデータを記憶するために用いられ、当該方法は：
データ更新イベントで更新されたサービスデータを取得し、データ更新イベントに対応するイベントバージョンを生成し、サービスデータとイベントバージョンとをイベントオブジェクト内にカプセル化するステップと；
ピアエンドのサービスアプリケーションが、イベントバージョンに従って、データ更新イベントが有効であると判定する際に、ピアエンドのデータベースがサービスデータに従って更新されるようにするために、イベントオブジェクトをピアエンドのサービスアプリケーションに伝送するステップと；を備える。
【０００６】
第２の態様では、データベースのための遠隔データ同期方法が提供され、当該方法はサービスアプリケーションによって実行され、データベースは前記サービスアプリケーションのデータを記憶するために用いられ、当該方法は：
ピアエンドのサービスアプリケーションが送信したイベントオブジェクトを受信するステップであって、イベントオブジェクトはデータ更新イベントで更新されたサービスデータと、データ更新イベントに対応するイベントバージョンとを含み；
イベントバージョンに従いピアエンドのデータ更新イベントが有効であると判定する際に、データ更新イベントで更新されたサービスデータに従って、ローカルデータベースを更新するステップ；を備える。
【０００７】
第３の態様では、データベースのための遠隔データ同期装置が提供され、当該装置はサービスアプリケーション内に配設され、データベースはサービスアプリケーションのデータを記憶するために用いられ、当該装置は：
データ更新イベントで更新されたサービスデータを取得し、データ更新イベントに対応するイベントバージョンを生成し、サービスデータとイベントバージョンとをイベントオブジェクト内にカプセル化するように構成されたイベントカプセル化モジュールと；
ピアエンドのサービスアプリケーションが、イベントバージョンに従って、データ更新イベントが有効であると判定した際に、ピアエンドのデータベースがサービスデータに従って更新されるようにするために、イベントオブジェクトをピアエンドのサービスアプリケーションへ伝送するように構成されたイベント送信モジュールと；を備える。
【０００８】
第４の態様では、データベースのための遠隔データ同期装置が提供され、当該装置はサービスアプリケーション内に配設され、データベースはサービスアプリケーションのデータを記憶するために用いられ、当該装置は：
ピアエンドのサービスアプリケーションが送信したイベントオブジェクトを受信するように構成されたイベント受信モジュールであって、イベントオブジェクトは、データ更新イベントにて更新されたサービスデータと、データ更新イベントに対応したイベントバージョンとを備える、イベント受信モジュールと；
イベントバージョンに従いピアエンドのデータ更新イベントが有効であると判定された際に、データ更新イベントにて更新されたサービスデータに従って、ローカルデータベースを更新するように構成されたデータ更新モジュールと；を備える。
【０００９】
本願で提供されるデータベースのための遠隔データ同期方法及び装置によれば、データ更新情報の高速伝送は、サービスアプリケーションが更新済みデータとイベントバージョンとをイベントオブジェクト中へカプセル化した後、このイベントオブジェクトをピアエンドアプリケーションへ伝送することにより実現され、さらに、データ更新イベントの発生順序をイベントバージョンにより特定することにより、高速で信頼性のあるデータ同期が保証される。
【図面の簡単な説明】
【００１０】
【図１】一の実施例におけるデータ同期のアプリケーションシナリオを示す。
【図２】一の実施例におけるデータ同期のプラットフォーム構造を示す。
【図３】一の実施例におけるデータ同期のイベント送信側エンドでの実行フローを示す。
【図４】一の実施例におけるサービスアプリケーションの概略構造図である。
【図５】一の実施例におけるデータ同期のイベント受信側エンドでの実行フローを示す。
【図６】一の実施例における遠隔データ同期装置の構造図である。
【発明を実施するための形態】
【００１１】
ここでは、例示の実施の形態を、図に示すその実施例を用いて詳細に説明する。特に記載のない限り、以下の説明で図を参照する場合、各図を通じ同一の符号は同一又は類似の要素を示す。以下の例示の実施の形態で述べる実施は、本願と一致する全ての実施を表すものではない。むしろ、これらの実施は、添付の特許請求の範囲で詳述され、本発明のいくつかの態様と一致する、装置及び方法の単なる例に過ぎない。
【００１２】
図１はデータ同期のアプリケーションシナリオを示す。図１に示すように、「サービスアプリケーション」とは、ユーザ情報を取得及び記憶すること、例えば、アリペイ（Ａｌｉｐａｙ（商標））ユーザの、アカウント、電話番号、その他のユーザ情報を記憶することを目的としたアプリケーションであると仮定する。このサービスアプリケーションは、場所Ａと場所Ｂの両方で展開され、この２つの場所は、中国とアメリカ、河北省と江蘇省などのように互いに遠く離れている。サービスアプリケーションのユーザ情報はデータベースに記憶される。例えば、サービスアプリケーションが場所Ａで取得したユーザ情報（例えば、Ａｌｉｐａｙ（商標）のウェブサイト上のユーザ登録から導出したユーザ情報）はデータベースＡに記憶される一方、場所Ｂで取得したユーザ情報はデータベースＢに記憶される。サービス要求に基づき、これら２つの場所におけるデータベースのデータの整合性を取るために、場所Ａで取得したユーザ情報は場所Ｂと同期させる必要があり、同様に、場所Ｂで取得したユーザ情報は場所Ａと同期させる必要があるため、データベースＡとデータベースＢとの間の遠隔データの同期が必要となる。
【００１３】
この実施の形態の遠隔データの同期方法は、データの同期処理がアプリケーション層すなわちサービスアプリケーションにより実行される（図１の実線で示すように、データの同期が２つの場所のサービスアプリケーション間で生じる）という点で、データベース間でのデータの同期モード（図１の点線で示すように、データ同期は、データベースＡとデータベースＢとの間で直接実行される）とは異なる。以下、データベース層による同期とアプリケーション層による同期とを、遅延パフォーマンスと信頼性の視点から比較する。
【００１４】
遅延パフォーマンス：データベースは、標準同期モードをデータベース同期メカニズムとして採用しているのが普通である。例えば、データベースに記憶された情報が更新されたかどうかを一定の間隔でチェックし、更新された場合には、更新されたデータがその時間間隔内にピアエンドへ伝送される。さらに、伝送モードについては、一つのユーザデータ内のユーザ名の変更を例に挙げて示す。このユーザ名をデータベースが変更する場合、複数のデータベース指示（例えば、複数のＳＱＬ文）を実行してデータ更新を実現することができ、また、ピアエンドとの同期時に、これら複数のデータベース指示もピアエンドへ伝送されねばならず、さらに、複数のデータベース指示はその実行順序に従ってピアエンドへ送信されねばならない（例えば、これら指示の一つの受信に成功したピアエンドからのフィードバックを受信してから次の指示を送信する）。これらのすべての要因が原因で、ピアエンドのデータベースへのデータ伝送速度が相対的に遅くなる、特に、このデータ伝送速度は遠隔での（このような長距離の）データ同期では劇的に低下してしまうことになる。
【００１５】
引き続き、この実施の形態のデータ同期方法では、データ更新が発生する度に、サービスアプリケーションは更新済みデータをリアルタイムで即座にピアエンドへ送信する能力がある。そして、伝送モードになった場合、サービスアプリケーションは、このデータ更新に関する情報をサービスレベルで取得することができる。例えば、より具体的でオペレーショナルレベル（operational level）のＳＱＬ文ではなく、このデータ更新の結果の方が注視される。例えば、複数のデータベース指示を実行すると、一つのユーザデータのユーザ名が変更され、その他にも、サービスアプリケーションは、例えば変更されたユーザ名が属する一つのユーザデータなどのより多くの情報をサービスレベルで取得し、このデータ更新イベントの発生時間をマーク付けすることが可能である。すなわち、サービスアプリケーションがこのデータ更新全体を一つのイベントとみなし、ピアエンドへの伝送時に、このイベントのデータ更新結果をピアエンドへ一度に直接伝送することができるので、より簡潔で高速となる。
【００１６】
信頼性：データベース同期の従来のメカニズムには、データ同期を実行するツーエンドがデータベース文書を同時に修正しようとする間際に、ツーエンドでのデータ更新の発生順序をデータベース自体が判定することは非常に難しいという欠陥があり、この事実により、データベースが本来は正確なこれらのデータ更新をデータの衝突と見なして拒否してしまうという状況を引き起こす。この実施の形態では、サービスアプリケーション層は、ローカルエンドにおけるデータ更新のタイムマークを記録でき、さらに、様々なデータ更新の順序をタイムマークに応じて判断し、最新データを選択してこれをデータベースに更新することができる。すなわち、アプリケーション層はより多くの処理を実行する能力があり、データベースのデータ同期をより信頼性の高いものにすることができる。
【００１７】
上の説明に基づき、本願の実施の形態における遠隔データの同期方法はサービスアプリケーションによって実行される。図２は、このデータ同期方法の原理を例証する。ここで、場所ＡのデータベースＡにおいてデータ更新が発生し、次に、データを場所Ａから場所Ｂへ同期させる必要があると仮定する。このとき、場所Ａのサービスアプリケーションがデータ同期の送信側エンドとして機能し、場所Ｂにおけるサービスアプリケーションがデータ同期の受信側エンドとして利用される。図２は、送信側エンドとして機能するサービスアプリケーション及び受信側エンドとして機能するサービスアプリケーションのそれぞれが含む処理モジュールを示す。ここで留意すべきは、データを場所Ｂから場所Ａに同期させる場合、図２に示すように、場所Ｂのサービスアプリケーションは場所Ａのサービスアプリケーションの様々なモジュールを含み、同様に、場所Ａのサービスアプリケーションは場所Ｂのサービスアプリケーションの様々なモジュールを含む、すなわち逆方向への一貫したフローがあるということである。以下の実施の形態では、両方向のうちの一方向でのデータ同期の処理手順についてのみ説明する。
【００１８】
図３は、送信側エンドとして機能する場所Ａのサービスアプリケーションが実行する遠隔データの同期方法のフローを示す。この方法は、図２及び図３に示すように、以下のステップを含んでよい。
【００１９】
３０１．サービスアプリケーションが、サービスデータを変更するデータ更新イベントを実行する。
【００２０】
実施例として、サービスアプリケーションは、ユーザ名をＪｉｍ（ジム）からＴｏｍ（トム）に変更する要求を、アプリケーションサイトを介してユーザから受信すると、サービスアプリケーションはデータベースを修正することができるようになる。例えば、アプリケーションは、データベースインターフェースを介してデータベースを操作することで、上述のユーザ名の変更を終えることができる。このデータ変更は一の「データ更新イベント」と呼ぶことができる。
【００２１】
この実施の形態では、データベースにデータ文書が記憶されており、各データ文書はこれに記憶されたユーザ情報を含む。データベース内の多種多様なユーザ情報はそれぞれ異なる行に記憶でき、また、一つ一つの行情報はデータ記憶ユニットと呼ぶことができる。例えば、第１データ記憶ユニットは、ユーザＹ１の情報、例えばＵｓｅｒ：｛ｉｄ＝１，ｎａｍｅ＝Ｊｉｍ｝を記憶するために用いられる。当然ながら、このユニットはさらに多くの情報、例えばＵｓｅｒ：｛ｉｄ＝１，ｎａｍｅ＝Ｊｉｍ，ｐｈｏｎｅ＝１３２＊＊＊＊１１１２｝を含んでもよい。第２データ記憶ユニットは、ユーザＹ２の情報、例えばＵｓｅｒ：｛ｉｄ＝２，ｎａｍｅ＝Ｍａｒｙ｝を記憶するために用いられる。ここで、ユーザ情報中のｉｄは、異なるサービスデータを区別するために用いられる「サービスメインキー」と呼ぶことができ、この実施の形態では、異なるｉｄを用いて異なるユーザ情報を区別する。１人のユーザの情報しかない場合は、サービスメインキーを用いなくてよい。
【００２２】
このステップでは、データ更新イベントにて実行するサービスデータの変更を、一のユーザ情報中のデータの一部にすることもできる。例えば、ユーザ情報Ｕｓｅｒ：｛ｉｄ＝１，ｎａｍｅ＝Ｊｉｍ，ｐｈｏｎｅ＝１３２＊＊＊＊１１１２｝のうち名前だけを修正できる。しかし、ユーザ情報を記憶するために用いるこの実施の形態のアプリケーションサービスに関し、この実施の形態は、上で述べたユーザ情報の全体を一つのサービスデータとして参照できる。図２に示すように、サービスデータの変更は、サービスアプリケーション内のデータ変更モジュールによって実行できる。
【００２３】
３０２．サービスアプリケーションは、データ更新イベントで更新されたサービスデータを取得し、このデータ更新イベントに対応するイベントバージョンを生成し、サービスデータとイベントバージョンをイベントオブジェクト内にカプセル化する。
【００２４】
実施例として、サービスアプリケーションのデータ変更モジュールによってサービスデータの変更を実行した後、例えば、ユーザ名をＪｉｍからＴｏｍに変更した後に、サービスアプリケーションは、この変更に対応するサービスデータすなわちＵｓｅｒ：｛ｉｄ＝１，ｎａｍｅ＝Ｔｏｍ｝）も取得する必要がある。これはすなわち、このデータ変更はこのサービスデータの名前の変更ということである。
【００２５】
サービスアプリケーションは、このデータ更新イベントに対応するイベントバージョンも生成する。この実施の形態では、データベースデータのデータ更新、例えば一つの追加、削除、修正は、全て「一つのデータ更新イベント」と呼ぶことができる。また、イベントの経時的順序を表すために、イベントの発生順序に従って「イベントバージョン」を記録する。例えば、１回目に発生するイベントのバージョンは「１」つまりｖｅｒｓｉｏｎ＝１であってよく、２回目に発生するイベントのバージョンは段階１の累増つまりｖｅｒｓｉｏｎ＝２であってよい。当然ながら、イベントバージョンの累増段階は１である必要はなく、例えば２であってもよい。１回目に発生するイベントのバージョンが１で、２回目に発生する第２イベントのバージョンが３であってもよい、あるいはイベントバージョンを数字で表す必要はなく、代わりに、例えばイベント発生のタイムスタンプで表すこともできる。例えば、１回目に発生するイベントのバージョンが２０１４．１２．３１であり、２回目に発生するイベントのバージョンが２０１５．１．２０である場合には、イベント発生の経時的順序をこれらのタイムスタンプで識別することもできる。
【００２６】
このステップでは、図２に示すように、上述のサービスデータを取得する操作とイベントバージョンを生成する操作は、サービスアプリケーションのイベントカプセル化モジュールによって実行でき、さらに、イベントカプセル化モジュールは、サービスデータとイベントバージョンをイベントオブジェクト内にカプセル化することができる。例えば、カプセル化されたイベントオブジェクトは、Ｅｖｅｎｔ：｛ｕｓｅｒ＝｛ｉｄ＝１，ｎａｍｅ＝Ｔｏｍ｝，ｖｅｒｓｉｏｎ＝１｝で表すことができる。サービスアプリケーションに複数のユーザ情報が記憶されている場合には、上述のイベントオブジェクトは、このイベントオブジェクトがどのユーザに対応しているかを示すサービスメインキーを含むことができる。
【００２７】
３０３．サービスアプリケーションは、イベントオブジェクトをピアエンドのサービスアプリケーションへ伝送する。
【００２８】
実施例として、図２に示すように、サービスアプリケーションによってカプセル化されたイベントオブジェクトは、イベント送信モジュールによってピアエンドのサービスアプリケーション（つまり、データ同期を必要とする遠隔ピアエンド）へ送信され、次に、ピアエンドのサービスアプリケーションのイベント受信モジュールによって受信される。この実施の形態では、送信側エンドのイベント送信モジュールと受信側エンドのイベント受信モジュールを総称して「イベント通知プラットフォーム」と呼ぶことができ、このイベント通知プラットフォームは、サービスアプリケーションによってカプセル化されたイベントオブジェクトを伝送するように機能し、伝送はメッセージ形式で完了されてよい。
【００２９】
イベント通知プラットフォームを介してイベントを伝送することにより、リアルタイム伝送を達成できる。例えば、サービスアプリケーションは、データベースのデータの更新後に、リアルタイムでのイベントオブジェクトへのカプセル化を終え、このイベントオブジェクトを、イベント通知プラットフォームを介してピアエンドへ伝送することができ、これにより同期効率は従来の標準的なデータベース同期と比べて著しく向上する。さらに、一のデータ更新に関して、イベント通知プラットフォームは、一の「イベント」オブジェクトを介して、このデータ更新の情報をピアエンドにその都度伝送することができ、これにより、データベースが一のデータ更新に含まれる複数の指示情報を順次に伝送する従来のモードに対してデータ同期速度が増加する。例えば、国境をまたぐデータ同期において、このプラットフォームは、一のイベントの、ピアエンドへの国境をまたぐ伝送を約数ミリ秒付近でサポートする能力を有する。
【００３０】
この実施の形態では、サービスアプリケーションは、サービスデータとイベントバージョンとをイベントオブジェクト内にカプセル化した後に、イベントオブジェクトを記録することもできる。図４の実施例を参照すると、サービスアプリケーションはイベント記録モジュールをさらに含んでもよく、このモジュールはイベントオブジェクトを記録するように構成でき、またイベントオブジェクトはデータベースに記録でき、さらに各イベントオブジェクトは次のように記録することができる：
Ｅｖｅｎｔ：｛ｕｓｅｒ＝｛ｉｄ＝１，ｎａｍｅ＝Ｊｉｍ｝，ｖｅｒｓｉｏｎ＝０｝；
Ｅｖｅｎｔ：｛ｕｓｅｒ＝｛ｉｄ＝１，ｎａｍｅ＝Ｔｏｍ｝，ｖｅｒｓｉｏｎ＝１｝；
【００３１】
一方、イベントオブジェクトを記録することは、ピアエンド（すなわち、受信側エンド）から送信されたイベントオブジェクトを受信すると、イベントの有効性を判定するべく、イベントバージョンに関する情報を、記録されたイベントオブジェクトから抽出するために用いることができ、また、この処理を行うために、受信側エンドで実行される方法の下記説明を参照することができる。他方、全てのイベントオブジェクトを記録することはデータ変更手順のより優れた知見を促し、これにより履歴のトレーサビリティが得られる。
【００３２】
イベント記録モジュールによるイベントオブジェクトの記録は、イベントカプセル化モジュールがイベントオブジェクト内へのカプセル化を終え、このイベントオブジェクトを送信する前、又は、イベント送信モジュールがイベントオブジェクトを送信した後、のいずれかに実行できる。
【００３３】
図５は、受信側エンドとして機能する場所Ｂのサービスアプリケーションによって実行される遠隔データの同期方法のフローを示す。この方法は、図２及び図５に示すように、以下のステップを含んでもよい。
【００３４】
５０１．サービスアプリケーションは、ピアエンドのサービスアプリケーションが送信したイベントオブジェクトを受信し、イベントオブジェクトは、データ更新イベントにて更新されたサービスデータと、データ更新イベントに対応するイベントバージョンとを含む。
【００３５】
実施例として、受信側エンドのサービスアプリケーションは、イベント受信モジュールにより、ピアエンドが送信したイベントオブジェクトを受信することができ、このイベントオブジェクトはサービスデータとイベントバージョンとを含んでよく、例えば、イベントオブジェクトは上の実施例で述べたＥｖｅｎｔ：｛ｕｓｅｒ＝｛ｉｄ＝１，ｎａｍｅ＝Ｔｏｍ｝，ｖｅｒｓｉｏｎ＝１｝であり、また、２人以上のユーザの情報をデータベースに記憶する場合には、イベントオブジェクトのサービスデータは、サービスメインキーと更新対象のデータとを少なくとも含み、このサービスメインキーを用いて異なるユーザ情報を区別する。
【００３６】
５０２．サービスアプリケーションは、イベントオブジェクト内のサービスメインキーに従って、ローカルに記録されている、このサービスメインキーに対応するデータ更新イベントのイベントバージョンを取得する。
【００３７】
実施例として、図２に示すように、サービスアプリケーション内のデータ更新モジュールは、イベントオブジェクトのカプセル化解除を行うことで、イベントオブジェクト内のサービスメインキーとイベントバージョンとを取得することができ、例えば、上述のイベントでは、サービスメインキーはｉｄ＝１、イベントバージョンはｖｅｒｓｉｏｎ＝１である。
【００３８】
イベント記録モジュールを介することで、サービスアプリケーション自体が発生したイベントオブジェクトを記録できることは図３に示す実施例で述べた。このステップでは、受信したピアエンドのイベントオブジェクト内のサービスメインキーｉｄ＝１に従って、データ更新モジュールが、ローカルに記録されている、サービスメインキーに対応するデータ更新イベントのイベントバージョンを取得することができる。例えば、サービスメインキーとイベントバージョンとに関する情報、例えば｛ｉｄ＝１，ｖｅｒｓｉｏｎ＝０｝を、ローカルに記録されているイベント記録から抽出する。同一のｉｄに対応する複数のイベントバージョンがローカルに記録されている場合には、最後に発生したイベントのイベントバージョン、例えば、最新の時間のもの又はバージョン番号が最大のものを取得する。
【００３９】
５０３．サービスアプリケーションは、受信したデータ更新イベントが有効であるか否かをイベントバージョンに従って判断する。
【００４０】
実施例として、サービスアプリケーションのデータ更新モジュールは、ローカルに記録されているイベントバージョンを、同一のｉｄに対応している受信したピアエンドのイベントバージョンと比較する。ピアエンドのイベントの発生時間の方が遅い場合には、ピアエンドのイベントが有効である、つまり、これが最新のデータ更新イベントであることを意味し、また、ピアエンドのイベントの発生時間の方が早い場合には、最新のデータ更新イベントがローカルに記録されており、ピアエンドのイベントは無効であることを意味する。
【００４１】
データ更新イベントが有効であるか否かを具体的に判定する場合、上述の実施例にてイベントバージョンの数を比較することができる。ピアエンドイベントのイベントバージョンｖｅｒｓｉｏｎ＝１がローカルエンドのイベントバージョンｖｅｒｓｉｏｎ＝０よりも大きい場合には、ピアエンドのデータ更新イベントは有効と判定し、５０４を実行するように進み、それ以外の場合は、ピアエンドのイベントバージョンがローカルエンドのイベントバージョンよりも小さいと仮定し、ピアエンドのイベントは無効であると判定して、５０６を実行できる。加えて、イベントバージョンがタイムスタンプで表されている場合、これらのタイムスタンプ同士を同様に比較して、ローカルエンドとピアエンドのイベント発生の経時的順序を判断する。
【００４２】
５０４．サービスアプリケーションは、データ更新イベントで更新されたサービスデータに従って、ローカルデータベースを更新する。
【００４３】
実施例として、サービスアプリケーションは、ピアエンドのデータ更新イベントが有効であると判定した後、データベース内の対応するサービスデータを変更するためにデータベースインターフェースを呼び出す。つまり、ｕｓｅｒ＝｛ｉｄ＝１，ｎａｍｅ＝Ｔｏｍ｝に従って、ローカルサービスデータをｕｓｅｒ＝｛ｉｄ＝１，ｎａｍｅ＝Ｔｏｍ｝に更新する。
【００４４】
５０５．サービスアプリケーションによってイベントオブジェクトを記録する。
【００４５】
実施例として、サービスアプリケーションは、ピアエンドのデータ更新イベントに従ってローカルデータベース内のサービスデータを更新した後に、このイベントに従って、ローカルに記録されているイベントオブジェクトをさらに更新し、また、上の実施例で述べたように、サービスアプリケーションは、最新のイベントオブジェクトＥｖｅｎｔ：｛ｕｓｅｒ＝｛ｉｄ＝１，ｎａｍｅ＝Ｔｏｍ｝，ｖｅｒｓｉｏｎ＝１｝をイベント記録モジュールを介してローカルデータベースに記録し、追跡用に履歴イベント記録を確保する。実際には、イベントオブジェクトは、ピアエンドのイベントが有効と判定された後、又はローカルデータベースを更新した後、のいずれかに記録することができる。
【００４６】
５０６．サービスアプリケーションは、イベントオブジェクトを破棄し、イベントオブジェクトに従ったローカルデータベースの更新をしない。
【００４７】
この実施の形態のサービスアプリケーションは、イベントバージョンを用いて様々なデータ更新イベントの発生順序を識別する。これは最新イベントの正確な識別を支援し、データベースの正確な更新を確実に行えるようにする。例えば、ツーエンドが同じ対象のデータを同時に変更する間際であっても、イベントバージョン同士を比較することにより、最新のデータ更新を正確に識別できるようになる。
【００４８】
この実施の形態の遠隔データの同期方法によれば、このイベントベースのデータ同期は、データ更新に関する情報のリアルタイムの伝送、さらに比較的に高速なイベント伝送を可能にする。さらに、イベントバージョンによって異なるデータ更新の順序を区別することもでき、これにより、データベースのデータ更新の正確性と信頼性が保証される。
【００４９】
上述の説明から分かるように、送信側エンドと受信側エンド両方のサービスアプリケーションは、図２及び図４に示すような遠隔データ同期装置を含み、この遠隔データ同期装置は、各種内蔵モジュールを用いてこの実施の形態の遠隔データ同期方法を実行する。さらに、受信側エンドのサービスアプリケーションに関し、図６に見られるその遠隔データ同期装置の構造はデータ受信モジュール６１とデータ更新モジュール６２とを含み、ここで、データ更新モジュール６２は記録取得ユニット６２１とイベント判断ユニット６２２とを含んでいてもよい。
【００５０】
記録取得ユニット６２１は、イベントオブジェクト内のサービスメインキーに従い、このサービスメインキーに対応した、ローカルに記録されているデータ更新イベントのイベントバージョンを取得するように構成されており、サービスメインキーを用いて異なるサービスデータを区別する。
【００５１】
イベント判断ユニット６２２は、ローカルイベントバージョンをピアエンドのイベントバージョンと比較し、経時上、ローカルに記録されているデータ更新イベントよりも後にピアエンドデータ更新イベントが発生したことを判定するように構成されている。
【００５２】
上記は本願の好ましい実施の形態にすぎず、本願を限定するために用いられるものではない。本願の精神及び原理の範囲内において行われる任意の変形、同等物の置換、及び改良は、本願の範囲内に含まれるものである。
【図１】
2018510430.tif 000003
【図２】
2018510430.tif 000004
【図３】
2018510430.tif 000005
【図４】
2018510430.tif 000006
【図５】
2018510430.tif 000007
【図６】
2018510430.tif 000008
【国際調査報告】
2018510430.tif 000009
2018510430.tif 000010
2018510430.tif 000011
2018510430.tif 000012