JP2006509281A - 同期方法 - Google Patents

Abstract

【課題】データ同期モデルとｎ層モデルの利点を備えたモデルを、ｎ層モデルに大掛かりな変更を施す必要なく提供すること。
【解決手段】マスタ版のデータを保存する手段を有するレガシー・コンピュータと、アプリケーション・サーバと、マスタ版のデータのコピーを保存するシン・クライアント・コンピュータとを含む分散データ処理システムで使用される同期方法。第１に、シン・クライアントが、コピーに対してローカルに操作を実行する。操作は、リストにして、アプリケーション・サーバに送信される。アプリケーション・サーバは、シン・クライアントに代わって、マスタ・データに対して操作を実行する。マスタ版に対する操作が正常に実行された場合、正常な操作がマスタ版に適用されたという点において、同期が達成される。

Description

本発明は、同期の分野に関し、より詳細には、ｎ層アーキテクチャにおける同期に関する。

インターネットは、我々の生活の多くの局面に変化をもたらしているが、インターネットによって事業を運営する方法ほど急速かつ著しい変化をこうむった分野はない。今日の事業にとって、インターネット技術は、事業戦略が形成された後で考慮する事柄ではなく、戦略形成の推進力になっている。多くの組織は、ｅビジネスのことを、インターネット技術の利用による主要事業プロセスの転換であると定義づけている。ｅビジネスは、中枢的な事業システムを、顧客、従業員、納入業者、および流通業者にインターネットを介して直接結びつけて、商品の市場投入期間、ならびにより広範な顧客および納入業者へのアクセスに要する時間を改善し、能率を向上させ、コストを削減する。

ｅビジネス・モデルを実施する企業の例として、オンライン・サプライ・チェーン管理、または取引にかかる高いコストを削減する一方で、顧客口座への改善されたアクセスを提供する電子金融サービス組織と一体化された、オンライン購入を提供する小売り業者がある。ｅビジネスは、一定の事業機能を自動化する手段から、競争力のある事業にとっての必須要素になるまで発展してきた。

フレームワークとは、１組の抽象パターン、およびそれらのインタフェースが協力する方法として表現された再利用可能な設計のことである。フレームワークは、ソフトウェア・システムの全部または一部のための再利用可能な設計であり、ユーザ・インタフェース・フレームワークは、システムのユーザ・インタフェース用の設計だけを提供し、一方、アプリケーション・フレームワークは、アプリケーション全般用の設計を提供する。

アプリケーション・フレームワークは、複雑なアプリケーションを開発する上で、その重要性をますます増してきている。アプリケーション・フレームワークは、アプリケーションが利用可能な１組の対話コンポーネントおよびサービス、コンポーネントおよびサービスの担当範囲、ならびにそれらの間の対話について記述する。開発者は、アプリケーション・フレームワーク内で利用可能なようにコンポーネントおよびサービスを構成し、拡張することによって、アプリケーションを作成する。アプリケーション・フレームワークは一般に、製造または財務など、特定の事業領域に対応している。

オブジェクト指向（ＯＯ）設計フレームワークなど初期のフレームワークは、プログラミング言語を中心に展開した。アプリケーション・フレームワークは、オブジェクト指向言語で実施する必要はないが、フレームワークの各コンポーネントが、定義されたインタフェースおよび挙動を有するという点で、オブジェクト指向設計と類似する特性を有している。アプリケーション・フレームワークは、複雑なｅビジネス・アプリケーションを作成し、配備し、管理する必要があるソフトウェア、サーバ、およびサービスに、コンテキストを提供する。

ｅビジネス用にインターナショナル・ビジネス・マシーンズ・コーポレーションによって使用されるアプリケーション・フレームワークは、ｅビジネス・ソリューションを設計するためのモデルを提供する。このモデルは、従来のクライアント／サーバ・コンピューティング・モデルから進化したものであり、アプリケーション・ロジックおよびビジネス・サービスの階層が、ネットワークを介して互いに通信を行うコンポーネントから構成される、「ｎ層」分散環境に基づいている。

その最も基本的な形態において、フレームワークは、必ずしも物理的でなくてもよい、論理的なプロセスの分離が存在することを意味する、論理的な３層コンピューティング・モデルとして表すことができる。図１を参照すると、クライアント層（１０５）、中間層（１１０）、および第３層（１１５）を含む、３層モデル（１００）の例が示されている。

クライアント層（１０５）は、リクエストを（例えば、ブラウザまたはＪａｖａアプレットを介して）アプリケーションに送信し、アプリケーションによって生成された情報および結果を（グラフィカル・ユーザ・インタフェースを介して）ユーザに提示することに関するロジックを有する、クライアント（例えば、スマートカード、デジタル無線電話、携帯情報端末（ＰＤＡ））を含む。クライアントは、「シン（thin）」クライアントと呼ばれることがあるが、これは、そのクライアント上では、アプリケーション・ロジックが僅かしか、または全く実行されず、そのため、そのクライアントには、比較的僅かなソフトウェアしかインストールする必要がないことを意味する。一般に、そのようなクライアント上では、ユーザ対話および入力検査機能だけが実行される。クライアントは、ユーザとの対話、中間層との通信、ならびに標準データ形式の送信および受信を可能にする、業界標準技術および業界標準プロトコル（例えば、ＴＣＰ／ＩＰ、ＨＴＴＰ、ＨＴＭＬ／ＤＨＴＭＬ／ＸＭＬ、およびＪａｖａ（ＪａｖａおよびすべてのＪａｖａベースの商標は、米国、その他の国、またはその両方に所在するサン・マイクロシステムズ・インコーポレイテッドの商標である））を用いて実装される。

シン・クライアントの利用は、管理容易性、柔軟性、および商品の売買に要する時間を改善する。有利な点としては、装置性能に対する依存性が低下するので、より広範囲なクライアント装置をサポートすることができる。さらに、ユーザ・アプリケーション環境を集中的に管理しながら、異なる場所にある異なるタイプのクライアント装置に分散させて、移動ユーザに対してサポートを提供することができる。

中間層（１１０）は、シングル・アプリケーションまたはマルチ・アプリケーション・サーバであるアプリケーション・サーバを含む。ｅビジネス環境では、サーバは、インターネット・アプリケーション用に最適化されたウェブ・アプリケーション・サーバである。アプリケーション・サーバは、アプリケーションのビジネス・ロジックにランタイム環境を提供するプラットフォームである。ビジネス・ロジックは、クライアント・タイプおよびユーザ・インタフェース・スタイルとは無関係に実行される。提示ロジックをアプリケーション・ロジックから分離することによって、数々の異なるスタイルのユーザ・インタフェースから利用できる再利用可能なアプリケーション・コンポーネントの作成が可能になる。

中間層サーバは、他の層のアプリケーション、データ、およびサービスと通信を行うための複数のアプリケーション統合技術を含んでいる。オンライン・トランザクションの数が激しい増加を見せているので、ウェブ・アプリケーション・トランザクション・サーバは、ｅビジネス基盤に欠かすことができない。顧客は、基幹アプリケーションの高速トランザクション処理、堅牢なシステム信頼性、バックアップ、および速やかな復旧を必要とする。ウェブ・アプリケーション・サーバは、他のシステムとの包括的な統合機能も提供しなければならない。ウェブ・アプリケーション・サーバは、これらの新しい事業プロセスを可能にするため、バックエンドの第３層ばかりでなく、相互にも接続しなければならない。

ウェブ・アプリケーション・サーバは、ＨＴＴＰサーバおよびプラットフォーム独立のエンタープライズＪａｖａプログラミング環境を含む、様々なインターネットおよびＪａｖａ技術を利用して実装される。エンタープライズＪａｖａプログラミング環境は、下層のハードウェア、オペレーティング・システム、およびネットワーク基盤に対するビジネス・ロジックの依存性をなくし、それによって、移植性を高め、開発および保守コストを低下させる。中間層は、分散ネットワーク環境におけるアプリケーションの速やかな開発および配備を可能にする、ネットワーク基盤および基礎サービスを含む。アプリケーション（１２０）は、ウェブ・アプリケーション・サーバおよびＪａｖａ仮想マシンにおいて、サーブレット、サーバサイド・スクリプト、およびエンタープライズＪａｖａＢｅａｎｓ（ＥＪＢ）の組み合わせとして動作する。ＥＪＢは、アプリケーションの多くのビジネス・ロジック、特にデータベースおよびトランザクション・サービスへのアクセスを提供する。ＥＪＢは、下層のデータベースおよびトランザクション・サービスの独特な特性から開発者を隔離し、プラットフォーム独立のビジネス・ロジックの開発を簡単にする。

第３層（１１５）は、新規および既存の内部アプリケーション、サービス、およびデータ、ならびに新規および既存の事業パートナからの外部アプリケーション、サービス、およびデータをサポートする、長年にわたって使用されてきた（故に「レガシー（遺産）」という語を冠する）レガシー・システムを含む。これらのサービスに接続することで、顧客、事業パートナ、および従業員にとっての価値が高まる。外部サービスおよびレガシー・システムは、企業の長年にわたる情報技術投資の結果であるので、ウェブ・アプリケーション・モデルの出現の基礎をなしている。これらは、皆が日々頼っている基幹アプリケーションおよびデータであり、企業がイントラネットおよびエクストラネット内の顧客、従業員、および納入業者にとっての企業価値を高めることができるよう、安全かつ統制された方法によってウェブから利用可能にする必要がある事業資産である。この層のサーバは、ウェブ・アプリケーション・サーバ・プロセスによって使用されるデータ記憶およびトランザクション・アプリケーションを提供する。

これら３つの論理層に存在するアプリケーション要素は、業界標準プロトコル、サービス、およびソフトウェア・コネクタの組によって接続される。コネクタ（１２５、１２６、１２７）は、中間層に存在する新しい付加価値を有する事業ロジックを、バックエンド層に存在する企業の既存のアプリケーションおよびデータ・システムの莫大な蓄積資産に結びつける。中間層で動作するビジネス・ロジックは、クライアントからリクエスト（例えば、ＨＴＴＰリクエスト）を受け取ると、コネクタを起動して、クライアントの代わりに、バックエンド層のサービスと安全に通信を行う。

代替モデルに、「データ同期」モデルがある。図２の分散システム（２００）を参照すると、アプリケーションが、サーバ（２１５）（例えば、記憶装置（２２０）内など）に存在し、同じアプリケーションの複製が、（例えば、パーソナル・コンピュータなどの）「ファット(fat)・クライアント」（２０５）（例えば、記憶装置（２１０）内など）に存在する。ファット・クライアントは自ら、アプリケーションの大部分またはすべての処理を実行する。ユーザがオフラインにある場合、ファット・クライアントは、複製データ上でローカルに作業を行うことができ、周期的に、ユーザがネットワーク（２２５）を介してサーバ（２１５）に接続すると、複製データとサーバ（２１５）に存在するマスタ・データとの同期がとられる。このモデルは、カレンダ、ｅメールなどの個人情報管理（ＰＩＭ）アプリケーション用にしばしば使用され、断続的にのみネットワークに接続される移動クライアントにとって特に有用である。

現在、多くの組織が、ｅビジネス・アプリケーションを配布する方法として、データ同期を取り入れることを望んでいる。例えば、銀行は、ＰＤＡ上のローカル・データとバックエンド層のマスタ・データとの同期を定期的に維持し、顧客がＰＤＡアプリケーションで自分の口座を調べ、操作できるようにすることを望んでいる。しかし、データ同期モデルは、ｅビジネスの３層モデルとはうまく適合しない。具体的には、組織は、複雑な高度に保護されたバックエンド・データベースを、クライアントと直接的に同期させることを望んでおらず、または同期させることができない。別の複雑さは、ウェブ・アプリケーション・サーバ上で動作するアプリケーションのビジネス・ロジックが、ＨＴＴＰリクエストによって駆動され、ＨＴＴＰレスポンスを生成する点にある。また、クライアントとバックエンド層との間で必要とされる同期プロトコルを、ビジネス・ロジックは理解しない。

可能な解決策の１つは、データのコピーをバックエンド層から中間層に抽出することである。その場合、クライアントは、中間層に接続し、データを更新することができる。更新したデータは、その後、中間層を介して、バックエンド層に保存されているデータと同期させることができる。

しかし、この解決策には不都合な点がある。第１に、クライアントが作業するデータは、いつも最新ではなく、データが夜間バッチで抽出されたものである場合は特にそうである。さらに、バックエンド層で一貫性のあるデータを維持するためには、更新したデータをバックエンド層のデータと同期させる新しいアプリケーション機能を開発しなければならない。その結果、分散トランザクション処理が必要になるが、これにはよく知られた短所が存在する。例えば、トランザクション・コーディネータが、（例えば、銀行Ａがある金額を口座Ａの借方に記帳し、銀行Ｂが同じ金額を口座Ｂの貸方に記帳する）トランザクションを、そのトランザクションに関与するすべてのリソース・マネージャに「コミット」したが、その時、ネットワークが停止中であったとすると、トランザクションの状態の一貫性を期待することはできない。いくつかのリソース・マネージャは、そのトランザクションを完了として登録するが、他のリソース・マネージャは、そうすることができない。一般に、トランザクションの結果を明確にする必要があるリソース・マネージャは、トランザクション・コーディネータに照会する必要がある。しかし、ネットワークが再び稼動を始めるまで、それは不可能であり、その間、口座ＡおよびＢは、しばらくの間、ロックされる場合がある。別の不都合は、この解決策を複数のシン・クライアントに拡大するには、中間層は一般に、複数のウェブ・アプリケーション・サーバを含まなければならない点にある。したがって、一貫性を維持する問題は、動的にその難しさを増す。

米国特許第６０２３６８４号は、クライアント・プログラムとの論理セッションの開始時に、アプリケーション・サービスが、バックエンド処理システムからホスト・インタフェースを介して取得したデータを使用して、クライアント・プログラムに関連づけられた顧客用のデータをリフレッシュする、３層モデルを開示している。データは、アプリケーション・サービスに関連づけられたローカル・データ・メモリに保存され、その後、このデータは、論理セッション中、クライアント・リクエストを処理するために、アプリケーション・サービスによって使用される。ローカル・データ・メモリは、クライアント・リクエストの処理を、バックエンド処理システムの更新から切り離すことを可能にする。
米国特許第６０２３６８４号

したがって、「ｎ層」モデルに大掛かりな変更を施す必要なく、データ同期モデルと「ｎ層」モデルの利点を提供するモデルが必要とされている。

本発明の第１の態様によれば、マスタ版のデータを保存する手段を有する少なくとも１つのレガシー・コンピュータと、同期をサポートする手段を有する第１の非レガシー・コンピュータと、前記マスタ版のデータのコピーを保存する手段、および前記コピーに対して少なくとも１つの操作を実行する手段を有する第２の非レガシー・コンピュータとを含む分散データ処理システムで利用される同期方法が提供され、前記方法は、前記第２の非レガシー・コンピュータによって、前記コピーに対して前記少なくとも１つの操作を実行するステップと、前記第２の非レガシー・コンピュータによって、前記少なくとも１つの操作を前記第１の非レガシー・コンピュータに送信するステップと、前記第１の非レガシー・コンピュータによって、前記少なくとも１つのレガシー・コンピュータの前記マスタ版に対して前記少なくとも１つの操作を実行するステップと、前記実行ステップが成功したかどうかを決定するステップと、実行ステップの成功に応答して、前記少なくとも１つの操作を適用することによって、前記マスタ版を同期させるステップとを含む。

一例として、レガシー・コンピュータは、メインフレーム・コンピュータであり、第１の非レガシー・コンピュータは、ウェブ・アプリケーション・サーバであり、第２の非レガシー・コンピュータは、ＰＤＡである。好ましくは、前記方法はさらに、第２の非レガシー・コンピュータによって、同期プロトコルを第１の非レガシー・コンピュータに送信するステップを含む。前記プロトコルは一般に、第２の非レガシー・コンピュータのタイプに特有なものである。本発明の好ましい一実施形態では、レガシー・コンピュータ上で実行される操作が２以上存在する場合、それらの操作は、順々に実行される。

適切には、レガシー・コンピュータ上で少なくとも１つの操作が実行された後、第１の非レガシー・コンピュータは、結果（すなわち、成功／失敗の通知と、結果データ自体）と、マスタ版のデータの新しいコピーとを、第２の非レガシー・コンピュータに送信する。好ましくは、少なくとも１つの操作が、（例えば、同時発生した操作と競合したために）マスタ版に対して実行できない場合は、マスタ版を同期させない。

本発明の第２の態様によれば、マスタ版のデータを保存する手段を有する少なくとも１つのレガシー・コンピュータと、同期をサポートする手段を有する第１の非レガシー・コンピュータと、前記マスタ版のデータのコピーを保存する手段、および前記コピーに対して少なくとも１つの操作を実行する手段を有する第２の非レガシー・コンピュータとを含む同期用の分散データ処理システムが提供され、前記システムはさらに、前記第２の非レガシー・コンピュータによって、前記コピーに対して前記少なくとも１つの操作を実行する手段と、前記第２の非レガシー・コンピュータによって、前記少なくとも１つの操作を前記第１の非レガシー・コンピュータに送信する手段と、前記第１の非レガシー・コンピュータによって、前記少なくとも１つのレガシー・コンピュータの前記マスタ版に対して前記少なくとも１つの操作を実行する手段と、前記実行ステップが成功したかどうかを決定する手段と、成功したとの決定に応答して、前記少なくとも１つの操作を適用することによって、前記マスタ版を同期させる手段とを含む。

本発明の第３の態様によれば、コンピュータ・プログラム・コード手段を含むコンピュータ・プログラムが提供され、コンピュータ・プログラム・コード手段は、前記プログラムがコンピュータ上で実行される時に上記の方法のすべてのステップを実行するように適合される。

次に、添付の図面に示される本発明の好ましい実施形態を参照しながら、本発明を例としてのみ説明する。

図３に、本発明を実施できる３層モデル（３００）の絵図を示す。関連する記憶手段（それぞれ、３１０、３２０、３３０）を有する、クライアント層（３０５）、中間層（３１５）、およびバックエンド層（３２５）が示されている。クライアント層（３０５）と中間層（３１５）は、ソフトウェア・コネクタ（３３１）によって接続され、中間層（３１５）とバックエンド層（３２５）は、ソフトウェア・コネクタ（３３２、３３３）によって接続される。バックエンド層（３２５）のアプリケーションおよびサービスは、ファイアウォール（３３５）によって保護される。

次に、本発明の一実施形態を、図３、図４、および図５を参照しながら説明する。シン・クライアント（３０５）をＰＤＡ、中間層（３１５）をウェブ・アプリケーション・サーバ、バックエンド層（３２５）を銀行口座データのマスタ版を保存するデータ・リポジトリとするバンキング・アプリケーションを例にして説明する。

好ましくは、シン・クライアント（３０５）は、実行すると、バックエンド層（３２５）の記憶手段（３３０）からユーザの銀行口座データのコピーを取得する機能を含む。好ましくは、前記コピーは、シン・クライアント（３０５）に関連づけられた記憶手段（３１０）にローカルに保存される。この例では、残高が£３００の銀行口座データが、ローカルに保存される。ユーザは、ローカル・データに対して操作（例えば、変更／更新）を実行する（ステップ４００、ステップ５００）。この実施形態では、操作は以下のようになる。
・口座に£５０を入金する。
・口座からの£１００の自動振替を設定する。
・口座から£７５の１回限りの支払いを行う。

しかし、ローカル・データは、バックエンド層（３２５）に存在するマスタ版に関して最新ではなくなりやすい。これは、ユーザが開始した操作のいくつかが、バックエンド層（３２５）のユーザの銀行口座のマスタ版に適用される同時発生した操作と衝突を起こすことがあるためである。例えば、自動振替の支払い、貯蓄口座への振替、ローンの支払いなどがある。この実施形態では、同時発生した操作が、ユーザの銀行口座のマスタ版に適用される。この例では、£２００の１回限りの支払いが、ユーザの銀行口座から引き落とされ、その結果、実際の残高は、£１００（すなわち、£３００−£２００＝£１００）になっている。

ユーザが開始した操作は、マスタ版に適用された同時発生した操作とまだ矛盾なく調整されていないので、好ましくは、ユーザの操作は、リスト内に保持される。したがって、シン・クライアント（３０５）は、２つのタイプのデータ、すなわち、（おそらく、僅かにマスタ版とは異なっている）「現在の」データのコピー（すなわち、ユーザの銀行口座データ）と、保留中の操作のリスト（すなわち、上記の操作１、２、３のリスト）とを保存する。

次に、シン・クライアント（３０５）のユーザは、更新したローカル・データをマスタ版と同期させるためのリクエスト（リクエストＡ）を、ＨＴＴＰリクエストによって中間層（３１５）に送信する（ステップ４０５、ステップ５０５）。中間層（３１５）は、同期に着手するようシン・クライアント（３０５）に指示するＨＴＴＰレスポンス（レスポンスＡ’）を返信することによって（ステップ４１０、ステップ５１０）、「リクエストＡ」を正常に受信したことを通知する。このリクエスト／レスポンス交換は、任意選択ステージであることを理解されたい。次に、シン・クライアント（３０５）のユーザは、同期を開始するため、ＨＴＴＰリクエスト（リクエストＢ）を中間層（３１５）に送信する（ステップ４１５、ステップ５１５）。シン・クライアントの標準的な同期プロトコルも、中間層（３１５）に送信される。有利には、ビジネス・アプリケーション・ロジックをＨＴＴＰリクエスト／レスポンス・モデルを使用することによって中間層で利用するのに加えて、ネイティブなシン・クライアント同期プロトコルを実行できる中間層の機能も利用される。

次に、同期プロセスが開始される（ステップ４２０）。具体的には、同期させるデータは、シン・クライアント（３０５）のユーザが実行を求める操作（上記の１、２、３）のリストである。同期ステップにおいて、操作のリストは、シン・クライアント（３０５）から中間層（３１５）にロードされる。その後、中間層（３１５）は、リスト内の操作をバックエンド層（３２５）上で再現する（５２０）。すなわち、£５０を口座に入金し、口座からの£１００の自動振替を設定し、口座から£７５の１回限りの支払いを行う。競合の機会が減少するように、好ましくは、再現ステップは素早く行われることを理解されたい。また、好ましくは、操作のリストは、順を追って再現される。

競合する同時発生操作が、バックエンド層（３２５）に存在するマスタ版に適用されたかどうかに応じて、ユーザが開始した操作には、成功するものと失敗するものがあることを理解されたい。同時発生操作がマスタ版に適用されたならば、これらは、シン・クライアント（３０５）がデータの「現在の」コピーを受信した後で適用されたものである。ステップ４２５で、各操作について、それが成功したがどうかが決定される。肯定的な結果の場合は、成功したユーザ開始操作を反映するように、マスタ版のデータを同期させ（ステップ４３０）、否定的な結果の場合は、マスタ版のデータを同期させない（ステップ４３５）。この例では、実際の銀行口座残高は、£１００になっている。したがって、操作１は成功し（操作１の後、実際の銀行口座残高＝£１５０となり）、操作２も成功し（操作２の後、実際の銀行口座残高＝£５０となり）、操作３は失敗する（実際の銀行口座残高＝£−２５となるため）。

次に、バックエンド層（３２５）が、ユーザ開始操作の結果と、銀行口座の新しい（更新された）マスタ版のコピー（この例では、実際の銀行口座残高＝£５０）を、中間層（３１５）に送信する（５２５）。

中間層（３１５）は、これらの操作の結果を監視し（ステップ４４０）、結果と、さらに銀行口座の新しいマスタ版のコピーを、シン・クライアント（３０５）に送信する（ステップ４４５、ステップ５３０）。ステップ４００でユーザが使用したローカル・コピーは、銀行口座の新しいマスタ版のコピーで置き換えられる。

これで、同期プロセスは終了し、そのことが、中間層（３１５）からシン・クライアント（３０５）にＨＴＴＰレスポンス（レスポンスＢ’）を送信することによって（ステップ４５０、ステップ５３５）、ユーザに通知される。好ましくは、その後、銀行口座の更新状況を示すビュー、成功した操作のリスト、および失敗した操作のリストを、ユーザに提示することができる。図６に、ビュー（６００）の一例を示す。操作がもう実行されないのであれば、ステップ４５５で、プロセスは終了する。しかし、まだ操作を実行する場合は、プロセスはステップ４００に戻り、例えば、ユーザは、操作の取り消し、修正、延期などによって、失敗した操作に対処することができる。

有利な点として、中間層は、新しいマスタ版のデータの最新コピーをシン・クライアントに送信するには、同期がとられた後に、マスタ版のデータにアクセスしさえすればよい。さらに、本発明の好ましい実施形態は、同時発生操作がマスタ版のデータに適用された可能性にも対処することができる。このシナリオは、シン・クライアントとバックエンド層とで食い違いのないデータのコピーを必要とせずに実施することができる。

別の利点は、データ同期モデルの利点が、３層モデルに大掛かりな変更を施す必要なしに提供される点にある。したがって、本発明は、今日すでに多くの組織によって運営されているシステムで利用することができる。例えば、シン・クライアントと中間層の既存の関係、すなわち、現在利用可能なＨＴＴＰおよびＰＤＡ同期プロトコルを使用することができる。しかし、本発明は、その他のプロトコルを用いても実施できることを理解されたい。さらに、３層モデルについて説明してきたが、本発明は、「ｎ」層のモデルにおいても実施することができる。また、ＰＤＡ、ウェブ・アプリケーション・サーバ、およびバックエンド・ホストについて説明してきたが、各層は、その他の任意のコンピュータ・マシンを含み得ることを理解されたい。

従来技術の「ｎ層」モデルの概略図である。 従来技術のデータ同期モデルの概略図である。 本発明による「ｎ層」モデルの概略図である。 図３に示すようなモデルにおいて実施されるデータ同期プロセスに含まれる操作ステップを示したフローチャートである。 図３に示すようなモデルのコンポーネント間でのデータ同期プロセスに含まれるフローのシーケンス図である。 データ同期の結果の図である。

Claims (11)

1. マスタ版のデータを保存する手段を有する少なくとも１つのレガシー・コンピュータと、同期をサポートする手段を有する第１の非レガシー・コンピュータと、前記マスタ版のデータのコピーを保存する手段、および前記コピーに対して少なくとも１つの操作を実行する手段を有する第２の非レガシー・コンピュータとを含む分散データ処理システムで利用される同期方法であって、
   前記第２の非レガシー・コンピュータによって、前記コピーに対して前記操作を実行する第１の実行ステップと、
   前記第２の非レガシー・コンピュータによって、前記操作を前記第１の非レガシー・コンピュータに送信するステップと、
   前記第１の非レガシー・コンピュータによって、前記レガシー・コンピュータの前記マスタ版に対して前記操作を実行する第２の実行ステップと、
   前記第２の実行ステップが成功したかどうかを決定するステップと、
   前記第２の実行ステップの成功に応答して、前記操作を適用することによって、前記マスタ版を同期させるステップとを含む方法。
2. 前記第２の非レガシー・コンピュータによって、同期プロトコルを前記第１の非レガシー・コンピュータに送信するステップをさらに含む、請求項１に記載の方法。
3. 前記操作が、２以上の操作を含み、各操作が、前記第１の非レガシー・コンピュータによって順々に実行される、請求項１または２に記載の方法。
4. 前記第１の非レガシー・コンピュータによって、前記マスタ版に対して前記操作を実行する前記第２の実行ステップの結果と、前記マスタ版のデータの新しいコピーとを送信するステップをさらに含む、請求項１ないし３のいずれかに記載の方法。
5. 第２の実行ステップの不成功に応答して、前記マスタ版を同期させない、請求項１に記載の方法。
6. マスタ版のデータを保存する手段を有する少なくとも１つのレガシー・コンピュータと、同期をサポートする手段を有する第１の非レガシー・コンピュータと、前記マスタ版のデータのコピーを保存する手段、および前記コピーに対して少なくとも１つの操作を実行する手段を有する第２の非レガシー・コンピュータとを含む同期用の分散データ処理システムであって、
   前記第２の非レガシー・コンピュータによって、前記コピーに対して前記少なくとも１つの操作を実行する第１の実行手段と、
   前記第２の非レガシー・コンピュータによって、前記操作を前記第１の非レガシー・コンピュータに送信する手段と、
   前記第１の非レガシー・コンピュータによって、前記レガシー・コンピュータの前記マスタ版に対して前記少なくとも１つの操作を実行する第２の実行手段と、
   前記操作の実行が成功したかどうかを決定する手段と、
   成功したとの決定に応答して、前記操作を適用することによって、前記マスタ版を同期させる手段とを含むシステム。
7. 前記第２の非レガシー・コンピュータによって、同期プロトコルを前記第１の非レガシー・コンピュータに送信する手段をさらに含む、請求項６に記載のシステム。
8. 前記操作が、２以上の操作を含み、各操作が、前記第１の非レガシー・コンピュータによって順々に実行される、請求項６または７に記載のシステム。
9. 前記第１の非レガシー・コンピュータによって、前記マスタ版に対して前記操作を実行する前記第２の実行手段の結果と、前記マスタ版のデータの新しいコピーとを送信する手段をさらに含む、請求項６ないし８のいずれかに記載のシステム。
10. 不成功との決定に応答して、前記マスタ版を同期させない、請求項６に記載のシステム。
11. コンピュータ・プログラムであって、前記プログラムがコンピュータ上で実行される時に、請求項１ないし５のいずれかに記載の方法を構成するすべてのステップを実行するように適合されたコンピュータ・プログラム・コード手段を含むコンピュータ・プログラム。

Images