(57)【要約】複数のコンピューティングノード間でレポジトリのデータを同期する方法、および同期データレポジトリプロバイダが開示される。各ノードは、複数のレポジトリのデータを同期するために、他のノードの同期プロバイダと通信する同期プロバイダを含む。この通信はデータ同期メッセージによるものであり、これは、他のノードのすべてに対してマルチキャスト通信リンクを介して送信ノードによりマルチキャストされる。同期範囲ならびにクラスは、レポジトリのデータを制限する。レポジトリは、別のノードとのポイントツーポイント通信リンクを介して初期設定される。この方法および同期プロバイダは、応答ストーム、消失メッセージ、および複製メッセージを処理する機能を含む。
2005531856.tif 000002
【特許請求の範囲】
【請求項１】
データを同期するために、コンピューティングシステムにおけるローカルノードと複数の遠隔ノードとの間の通信の方法において、レポジトリのデータに関するデータ同期メッセージを、前記ノードのすべてを相互接続するマルチキャスト通信リンクを介してマルチキャストモードで通信する方法。
【請求項２】
前記データ同期メッセージの少なくとも１つは、前記レポジトリの同期範囲のＩＤを含む、請求項１に記載の方法。
【請求項３】
前記ＩＤは、前記データのクラスをさらに特定する、請求項２に記載の方法。
【請求項４】
前記データ同期メッセージの少なくとも１つは、イベントインスタンス通知である、請求項１に記載の方法。
【請求項５】
前記ローカルノードは、前記少なくとも１つのデータ同期メッセージを受信し、前記レポジトリは遠隔レポジトリであり、前記ローカルノードはローカルレポジトリを含み、前記イベントインスタンス通知のイベントデータで、前記ローカルレポジトリのデータを更新するステップをさらに含む、請求項４に記載の方法。
【請求項６】
前記ローカルノードは、ローカルクライアントから前記イベントインスタンス通知を獲得し、前記伝達するステップは、前記ローカルノードから前記遠隔ノードに、前記マルチキャスト通信リンクを介して、前記少なくとも１つのデータ同期メッセージを送信する、請求項４に記載の方法。
【請求項７】
一連の前記データ同期メッセージが前記ローカルノードにより受信され、前記一連のデータ同期メッセージの少なくとも１つのメッセージが消失したことを検出するステップと、前記消失メッセージを回復するステップとをさらに含む、請求項１に記載の方法。
【請求項８】
前記データ同期メッセージのそれぞれは、最後の更新の連続番号とソースとのＩＤを含み、前記検出するステップは、前記消失メッセージに対応する不明の連続番号を検出し、前記回復するステップは、データ同期メッセージを、前記消失メッセージを要求する前記マルチキャスト通信リンクを介して送信する、請求項７に記載の方法。
【請求項９】
前記データ同期メッセージのそれぞれは、最後の更新の連続番号とソースとのＩＤを含み、前記複数のデータ同期メッセージのうちの受信した１つのデータ同期メッセージが、最後の更新のソースが異なることを除いて、既に受信されたデータ同期メッセージの複製であることを検出するステップと、その複製メッセージを最後の更新の前記複数の異なるソースの１つから再送することを要求するデータ同期メッセージを、前記マルチキャスト通信リンクを介して送信するステップとをさらに含む、請求項１に記載の方法。
【請求項１０】
受信されたデータ同期メッセージが応答データ同期メッセージを要求し、前記通信するステップが、応答ストームを回避するために、前記応答データ同期メッセージの送信を所定期間まで任意に延期する、請求項１に記載の方法。
【請求項１１】
前記所定期間は、前記受信されたデータ同期メッセージで指定される、請求項１０に記載の方法。
【請求項１２】
有効な応答データ同期メッセージが別の遠隔ノードから最初に受信された場合、前記伝達するステップは前記応答メッセージの送信を取り消す、請求項１１に記載の方法。
【請求項１３】
前記ローカルノードは、応答を要求する前記複数のデータ同期メッセージの１つを送信し、前記１つのデータ同期メッセージは、前記応答を送信することができる所定期間を指定する、請求項１に記載の方法。
【請求項１４】
前記ローカルノードと前記複数の遠隔ノードの１つとの間のポイントツーポイント通信リンクを介して、レポジトリのデータのコピーを伝達するステップをさらに含む、請求項１に記載の方法。
【請求項１５】
レポジトリのデータに関するデータ同期メッセージを、前記ノードのすべてを相互接続するマルチキャスト通信リンクを介してマルチキャストモードで伝達することにより、前記レポジトリのデータを同期するデータ通信デバイスを含む、コンピューティングシステムのローカルノードと複数の遠隔ノードとの間で通信する同期レポジトリプロバイダ。
【請求項１６】
前記データ同期メッセージの少なくとも１つは、前記レポジトリの同期範囲のＩＤを含む、請求項１５に記載の同期レポジトリプロバイダ。
【請求項１７】
前記ＩＤは、前記データのクラスをさらに特定する、請求項１６に記載の同期レポジトリプロバイダ。
【請求項１８】
前記データ同期メッセージの少なくとも１つは、イベントインスタンス通知である、請求項１５に記載の同期レポジトリプロバイダ。
【請求項１９】
前記ローカルノードは、前記少なくとも１つのデータ同期メッセージを受信し、前記レポジトリは遠隔レポジトリであり、前記ローカルノードはローカルレポジトリを含み、前記イベントインスタンス通知のイベントデータで前記ローカルレポジトリのデータが更新される、請求項１８に記載の同期レポジトリプロバイダ。
【請求項２０】
前記通信デバイスはローカルクライアントから前記イベントインスタンス通知を獲得し、前記通信デバイスは、前記ローカルノードから前記遠隔ノードに、前記マルチキャスト通信リンクを介し、前記少なくとも１つのデータ同期メッセージを送信する、請求項１８に記載の同期レポジトリプロバイダ。
【請求項２１】
一連の前記データ同期メッセージは前記ローカルノードにより受信され、前記通信デバイスは、前記一連のデータ同期メッセージの少なくとも１つのメッセージが消失したことを検出し、前記消失メッセージを回復するプロセスを実行する、請求項１５に記載の同期レポジトリプロバイダ。
【請求項２２】
前記データ同期メッセージのそれぞれは、最後の更新の連続番号とソースとのＩＤを含み、前記通信デバイスは、前記消失メッセージに対応する不明の連続番号を検出し、前記プロセスは、データ同期メッセージを、前記消失メッセージを要求する前記マルチキャスト通信リンクを介して送信する、請求項２１に記載の同期レポジトリプロバイダ。
【請求項２３】
前記データ同期メッセージのそれぞれは、最後の更新の連続番号とソースとのＩＤを含み、前記通信デバイスが、前記複数のデータ同期メッセージのうちの受信した１つのデータ同期メッセージは、最後の更新のソースが異なることを除いて、既に受信されたデータ同期メッセージの複製であることを検出し、前記通信デバイスが、その複製メッセージを最後の更新の前記複数の異なるソースの１つから再送することを要求するデータ同期メッセージを、前記マルチキャスト通信リンクを介して送信する、請求項１５に記載の同期レポジトリプロバイダ。
【請求項２４】
受信されたデータ同期メッセージが応答データ同期メッセージを要求し、前記通信デバイスが、応答ストームを回避するために、前記応答データ同期メッセージの送信を所定期間まで任意に延期する、請求項１５に記載の同期レポジトリプロバイダ。
【請求項２５】
前記所定期間は、前記受信されたデータ同期メッセージで指定される、請求項２４に記載の同期レポジトリプロバイダ。
【請求項２６】
有効な応答データ同期メッセージが別の遠隔ノードから最初に受信された場合、前記伝達するステップが前記応答メッセージの送信を取り消す、請求項２５に記載の同期レポジトリプロバイダ。
【請求項２７】
前記通信デバイスは、応答を要求する前記複数のデータ同期メッセージの１つを送信し、前記１つのデータ同期メッセージは、前記応答を送信することができる所定期間を指定する、請求項１５に記載の同期プロバイダ。
【請求項２８】
前記通信デバイスは、前記レポジトリのデータのコピーも、前記ローカルノードと前記複数の遠隔ノードのうちの１つとの間のポイントツーポイントリンクを介して送受信する、請求項１５に記載の同期レポジトリプロバイダ。
【請求項２９】
前記通信デバイスは、前記データ同期メッセージの発信データ同期メッセージを送信する送信スレッドと、前記データ同期メッセージの着信データ同期メッセージを受信する受信スレッドとを含む、請求項１５に記載の同期プロバイダ。
【請求項３０】
前記通信デバイスは、（ａ）前記発信データ同期メッセージの１つまたは複数を送信するためのクライアント要求、および（ｂ）前記着信メッセージの１つまたは複数を処理するための、クライアントプロセスをさらに含む、請求項２９に記載の同期プロバイダ。
【請求項３１】
前記データ同期メッセージの少なくとも１つは、イベント通知、消失メッセージ、および複製メッセージからなるグループの一要素である、請求項３０に記載の同期プロバイダ。
【請求項３２】
前記通信デバイスは、送信メッセージマップと受信メッセージマップをさらに含み、前記送信スレッドは、送信されたメッセージを前記送信メッセージマップに保存し、前記受信スレッドは、消失メッセージを処理する際に、前記送信メッセージマップと前記受信メッセージマップの少なくとも１つにアクセスする、請求項３１に記載の同期プロバイダ。
【請求項３３】
前記通信デバイスは、送信メッセージマップと受信メッセージマップをさらに含み、前記送信スレッドは、送信されたメッセージを前記送信メッセージマップに保存し、前記受信スレッドは、複製メッセージを処理する際に、前記送信メッセージマップと前記受信メッセージマップの少なくとも１つにアクセスする、請求項３１に記載の同期プロバイダ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、ネットワーク内で接続された複数のコンピューティングノード間におけるデータレポジトリの同期に関し、より詳細には、ウインドウズ管理計測（ＷＭＩ）環境で同期を達成する方法およびデバイスに関する。
【背景技術】
【０００２】
本願は、２００２年６月２８日出願の米国仮出願番号６０／３９２，７２４号の特典を請求する。
ウェブベースの企業管理（ＷＢＥＭ：Ｗｅｂ−Ｂａｓｅｄ  Ｅｎｔｅｒｐｒｉｓｅ  Ｍａｎａｇｅｍｅｎｔ）は、企業のシステムマネージャにその管理の必要性に応じた標準的な低価格の解決策を提供するために、分散マネージメントタスクフォース（ＤＭＴＦ：Ｄｉｓｔｒｉｂｕｔｅｄ  Ｍａｎａｇｅｍｅｎｔ  Ｔａｓｋ  Ｆｏｒｃｅ）によって企画された構想である。ＷＢＥＭ構想は、単純なワークステーション構成から複数のプラットフォームにわたるフルスケール企業管理に至る、多数のタスクを包含する。この構想の要としては、典型的な管理環境に存在するオブジェクトを表すための拡張可能なデータモデルである、共通情報モデル（ＣＩＭ：Ｃｏｍｍｏｎ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｍｏｄｅｌ）がある。
【０００３】
ＷＭＩは、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｗｉｎｄｏｗｓ（登録商標）プラットフォーム用のＷＢＥＭ構想の一実施態様である。ＷＭＩ環境に存在するオブジェクトを表すためにＣＩＭを拡張し、管理オブジェクト形式（ＭＯＦ：Ｍａｎａｇｅｄ  Ｏｂｊｅｃｔ  Ｆｏｒｍａｔ）言語と共通プログラミングインターフェースの両方をサポートするために管理基盤を実施することにより、ＷＭＩは、種々のアプリケーションが様々な企業の構成要素を透過的に管理することを可能にする。
【０００４】
ＷＭＩ基盤は、次に示すコンポーネントを含む。
・実際のＷＭＩソフトウェア（Ｗｉｎｍｇｍｔ．ｅｘｅ）、すなわち管理データへの均等なアクセスをアプリケーションに提供するコンポーネント。
【０００５】
・共通情報モデル（ＣＩＭ）レポジトリ、すなわち管理データの中央記憶域。
ＣＩＭレポジトリは、新しいオブジェクトクラスの定義により拡張される。ＣＩＭレポジトリは、静的に定義されたクラスインスタンスにより、または動的インスタンスプロバイダを介してポピュレートすることができる。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
ＷＭＩ基盤は、イベントの保証された配信をサポートせず、配信されたデータの同期した表示を獲得するための機構を提供しない。クライアントは、インスタンス目録およびイベント通知の登録のために、各データソースに明確に接続する必要がある。データサーバの終了のような接続問題またはネットワーク問題は、クライアント通知および切断されたデータソースに対する再接続における長い遅延の原因となる。これらの問題は、その問題をクライアントに指摘せずに、切断されたコールバック接続を生じさせる可能性がある。これらの問題に対する解決策は、各クライアントによる複数接続のオーバーヘッドを回避し、かつ接続を確立することができない場合のイベントデータの消失を回避する必要がある。単一接続に障害が生じた場合はデータの配信に割り込むことができず、切断されたサーバに対するメソッドコールに関連付けられたタイムアウトを最低限に抑える必要がある。変更通知の配信は、データソースの周期的なポーリングを要求せずに保証する必要がある。
【０００７】
管理データの複合表示を提供するための１つの方法は、共通コレクタサーバを開発することである。しかし、共通サーバの実施態様は、１つの障害点に対する解決策を提供するものであり、遠隔ソースに接続したすべてのクライアントに依然として依存する。高可用性サーバ実現および冗長サーバ同期は複雑化する可能性があり、クライアント／サーバ接続管理は依然として主要な問題である。
【０００８】
本発明は、以下の記述から明らかになる多くのさらなる利点も提供する。
【課題を解決するための手段】
【０００９】
本発明の同期レポジトリプロバイダ（ＳＲＰ）は、配信された管理データの同期されたＷＢＥＭレポジトリを維持するために、信頼性のあるＩＰマルチキャストベースの技術を実現する、動的ＷＭＩ外部イベントプロバイダである。ＳＲＰは、同期プロバイダの実現に対する共通コンポーネントである。ＳＲＰは、動的インスタンスプロバイダまたはインスタンスクライアントが、配信されたデータの複合表示を収集するよう複数の遠隔接続を行う必要性を解消する。ＳＲＰは、登録された同期プロバイダレポジトリデータの同期された表示の状態を維持する。ＳＲＰは、レポジトリ内容の分散した表示をまず同期し、次いでデータ変更イベントの配信を保証する。コネクションレス型通信プロトコルは、接続されたクライアントおよびサーバに対するネットワーク／コンピュータの停止による影響を最低限に抑える。ＩＰマルチキャストを使用することにより、ネットワーク帯域幅に対する影響が低減され、構成は単純化される。ＳＲＰは、標準ＷＭＩ外部イベントと、公開されたオープンインターフェースを同期プロバイダ開発に提供するメソッドプロバイダインターフェースとを実現する。ＳＲＰ、同期プロバイダ、またはクライアントを実施し、またはインストールするために、カスタムライブラリまたはプロキシファイルは必要とされない。
【００１０】
本発明の方法は、データを同期するために、コンピューティングシステムにおけるローカルノードと複数の遠隔ノードとの間の通信を提供する。この方法は、レポジトリのデータに関するデータ同期メッセージを、ノードのすべてを相互接続するマルチキャスト通信リンクを介してマルチキャストモードで伝達する。
【００１１】
本発明の方法の一実施形態によれば、データ同期メッセージの少なくとも１つは、レポジトリの同期範囲のＩＤを含む。このＩＤは、データのクラスをさらに特定することができる。
【００１２】
本発明の方法の別の実施形態によれば、ローカルノードは、遠隔レポジトリのイベントインスタンス通知を含むデータ同期メッセージを受信する。ローカルノードは、イベントインスタンス通知のイベントデータで更新されたローカルレポジトリを含む。ローカルノードがローカルクライアントからイベントインスタンス通知を獲得した場合、これはデータ同期メッセージにパッケージされ、ローカルノードから複数の遠隔ノードにマルチキャスト通信リンクを介して伝達される。
【００１３】
本発明の方法の別の実施形態によれば、一連の受信メッセージの消失メッセージが検出され、回復される。データ同期メッセージのそれぞれは、最後の更新の連続番号とソースとのＩＤを含む。検出するステップは、消失メッセージに対応する不明の連続番号を検出する。回復するステップは、データ同期メッセージを、その消失メッセージを要求するマルチキャスト通信リンクを介して送信する。
【００１４】
本発明の方法の別の実施形態によれば、複製メッセージ機能が提供される。データ同期メッセージのそれぞれは、最後の更新の連続番号とソースとのＩＤを含む。この方法は、複数のデータ同期メッセージのうちの受信した１つのデータ同期メッセージが、最後の更新のソースが異なることを除いて、既に受信されたデータ同期メッセージの複製であることを検出する。その複製メッセージを最終更新の複数の異なるソースの１つから再送することを要求するデータ同期メッセージが、次いでマルチキャスト通信リンクを介して送信される。
【００１５】
本発明の方法の別の実施形態によれば、応答ストーム機能が提供される。受信されたデータ同期メッセージが応答データ同期メッセージを要求する場合、応答ストームを回避するために、その応答データ同期メッセージの送信が所定期間まで任意に延期される。その所定期間は、受信されたデータ同期メッセージで指定される。有効な応答データ同期メッセージが別の遠隔ノードから最初に受信された場合、その応答メッセージは取り消される。
【００１６】
本発明の方法の別の実施形態によれば、ローカルレポジトリは、ローカルノードと複数の遠隔ノードの１つとの間のポイントツーポイント通信リンクを介して、別のレポジトリのデータのコピーを伝達することにより初期設定される。
【００１７】
本発明の同期レポジトリプロバイダは、そのデータに関するデータ同期メッセージを、ノードのすべてを相互接続するマルチキャスト通信リンクを介してマルチキャストモードで伝達することによりレポジトリのデータを同期する、データ通信デバイスを含む。この通信デバイスは、本発明の方法の上記実施形態の１つまたは複数を実行する能力を含む。
【００１８】
本発明の同期プロバイダの別の実施形態によれば、通信デバイスは、データ同期メッセージの発信データ同期メッセージを送信する送信スレッドと、データ同期メッセージの着信データ同期メッセージを受信する受信スレッドとを含む。
【００１９】
本発明の同期プロバイダの別の実施形態によれば、通信デバイスは、（ａ）発信データ同期メッセージの１つまたは複数を送信するためのクライアント要求、および（ｂ）着信メッセージの１つまたは複数を処理するためのクライアントプロセスをさらに含む。
【００２０】
本発明の同期プロバイダの別の実施形態によれば、データ同期メッセージの少なくとも１つは、イベント通知、消失メッセージ、および複製メッセージからなるグループの一要素である。
【００２１】
本発明の同期プロバイダの別の実施形態によれば、通信デバイスは、送信メッセージマップと受信メッセージマップをさらに含む。送信スレッドは、送信されたメッセージを送信メッセージマップに保存する。受信スレッドは、消失メッセージを処理する際に、送信メッセージマップと受信メッセージマップの少なくとも１つにアクセスする。
【００２２】
本発明の同期プロバイダの別の実施形態によれば、受信スレッドは、複製メッセージを処理する際に、送信メッセージマップと受信メッセージマップの少なくとも１つにアクセスする。
【００２３】
本発明のその他およびさらなる目的、利点、および特徴は、類似の部分を所与の類似の番号で示した添付の図面と共に以下の明細書を参照することにより理解されよう。
【発明を実施するための最良の形態】
【００２４】
本発明のその他およびさらなる目的、利点、および特徴は、添付の図面と共に以下の明細書を参照することにより理解されよう。添付の図面では、構成の類似の要素は類似の参照記号で示す。
【００２５】
図１を参照すると、システム２０は、１つのネットワーク３０を介して相互接続される複数のコンピューティングノード２２、２４、２６および２８を含む。ネットワーク３０は、いかなる適切な有線、無線、および／または光学ネットワークであってもよく、インターネット、イントラネット、公衆電話網、ローカルエリアネットワークおよび／または広域ネットワーク、および／または他の通信網を含むことができる。４つのコンピューティングノードが示されているが、コンピューティングノード２６と２８の間の破線は、これ以上またはこれ以下の数のコンピューティングノードを使用することが出来ることを示している。
【００２６】
システム２０は、複数のコンピューティングノード内で発生するか、または複数のコンピューティングノードの１つまたは複数によって追跡されるイベントを追跡する、いかなるアプリケーション用にでも構成することができる。一例として、また説明を完全にするために、システム２０は、本明細書ではプロセス３２の制御用として記述する。この目的のために、コンピューティングノード２２および２４は、プロセス３２を制御し、監視し、かつ／または管理するように割り付けられる。コンピューティングノード２２および２４は、プロセス３２への接続と共に示される。これらの接続は、様々なセンサおよび／または制御デバイスが接続されるバスに対する接続であってよい。例えば、コンピューティングノード２２および２４の１つまたは複数に対するローカルバスは、フィールドバス・ファンデーション・（Ｆｉｅｌｄｂｕｓ  Ｆｏｕｎｄａｔｉｏｎ；ＦＦ）ローカルエリアネットワークであってよい。コンピューティングノード２６および２８は、プロセス３２への直接接続を有さず、コンピューティングノードの管理、監視および他の目的のために使用することができる。
【００２７】
図２を参照すると、コンピューティングノード２２、２４、２６および２８は、それぞれに本発明のノードコンピュータ３４を含む。ノードコンピュータ３４は、複数の実行時システムコンポーネント、すなわちＷＭＩプラットフォーム３６、リダイレクタサーバ３８、システムイベントサーバ（ＳＥＳ）４０、ＨＣＩクライアントユーティリティマネージャ４２、コンポーネントマネージャ４４、およびシステムディスプレイ４６を含む。ＷＭＩプラットフォーム３６は、ローカルコンポーネント管理サービスプロバイダ４８、遠隔コンポーネント管理プロバイダ５０、システムイベントプロバイダ（ＳＥＰ：Ｓｙｓｔｅｍ  Ｅｖｅｎｔ  Ｐｒｏｖｉｄｅｒ）５２、ネームサービスプロバイダ（ＮＳＰ：Ｎａｍｅ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｄｅｒ）５４、同期レポジトリプロバイダ（ＳＲＰ：Ｓｙｎｃｈｒｏｎｉｚｅｄ  Ｒｅｐｏｓｉｔｏｒｙ  Ｐｒｏｖｉｄｅｒ）５６、およびハートビートプロバイダ５８を含む。図２中の線は、様々な実行時システム管理コンポーネント間の通信経路を表す。
【００２８】
本発明によれば、ＳＲＰ  ５６は、そのコンピューティングノードのレポジトリのデータを、システム２０の他のコンピューティングノードに配置されたレポジトリのデータと同期するよう動作可能である。例えば、ＳＥＳ  ４０、ＳＥＰ  ５０、ＮＳＰ  ５４、およびハートビートプロバイダ５８のような、コンピューティングノードの同期プロバイダのそれぞれは、関連付けられたデータレポジトリを有しており、ＳＲＰ  ５６のクライアントである。
【００２９】
システムディスプレイ４６は、システム状況ディスプレイであり、ユーザがコンピューティングノード２２、２４、２６、または２８およびそれらが管理するコンポーネントを構成し、監視することを可能にするツール、例えばプロセス３２を監視し制御するセンサおよび／またはトランスデューサとして働く。システムディスプレイ４６は、遠隔ＴＰＳノードおよびコンポーネント構成を実行する能力を提供する。システムディスプレイ４６は、ノードおよびシステム状況をそのローカルハートビートプロバイダ５８およびＳＥＰ  ５２から受信する。システムディスプレイ４６は、管理されたコンポーネント状況を受信するために、それぞれの監視されたノードのローカルコンポーネント管理サービスプロバイダ４８に接続する。
【００３０】
ＮＳＰ  ５４は、ＷＭＩクライアントに別名および関連付けられたコンポーネント情報の部分集合を提供する。コンピューティングノードのＮＳＰ  ５４は、異なるコンピューティングノードの別の設定済みＮＳＰ  ５４（１つあれば）のデータベースから関連付けられたデータベースを初期設定し、次いでその関連付けられたデータベースをそのコンピューティングノードのＳＲＰ  ５６を使用して同期化された状態に保つ。
【００３１】
ＳＥＰ  ５２は、ローカルイベントをシステムイベントとして発行し、システムイベントの同期化されたローカルコピーを所定範囲内に維持する。ＳＥＰ  ５２は、そのシステムイベントをＷＭＩクライアントに公開する。図２に示すように、システムディスプレイ４６とＳＥＳ  ４０は、どちらもＳＥＰ  ５２に対するクライアントである。
【００３２】
コンポーネントマネージャ４４は、ローカルに管理されたコンポーネントを監視し管理する。コンポーネントマネージャ４４は、管理されたコンポーネント状況を標準ＷＭＩクライアントに公開するＷＭＩプロバイダインターフェースを実現する。
【００３３】
ハートビートプロバイダ５８は、接続されたＷＭＩクライアントに、ハートビートプロバイダ５８のマルチキャスト範囲内でコンピューティングノードのハートビートと追加または削除のイベント通知とを現在報告中の、すべてのコンピューティングノードのリストを提供する。
【００３４】
ＳＲＰ  ５６は、情報を同期化した状態に保つために必須の低レベルのノード間通信を実行する。ＳＥＰ  ５２およびＮＳＰ  ５４は、ＳＲＰ  ５６の能力に基づいて構築される。これにより、ＳＥＰ  ５２およびＮＳＰ  ５４は、システムイベントおよび別名の同期化されたデータベースをそれぞれに維持することができる。
【００３５】
図３および５を参照すると、ＳＲＰ  ５６およびハートビートプロバイダ５８は、ノード間通信用にマルチキャストを使用する。一方、システムディスプレイ４６は、そのローカルハートビートプロバイダ５８およびＳＥＰ  ５２と通信するためにＷＭＩサービスを使用する。システムディスプレイ４６も、ローカルで管理されたノードおよび遠隔で管理されたノードのローカルコンポーネント管理サービスプロバイダ４８および遠隔コンポーネント管理サービスプロバイダ５０と通信するためにＷＭＩサービスを使用する。
【００３６】
図４を参照すると、システム２０は、コンピューティングノード６２、コンピューティングノード６４（組織ユニット＃１）、およびコンピューティングノード６６（組織ユニット＃２）を含む、複数のコンピューティングノードのドメイン６０を含む。ＮＳＰ  ５４のような同期プロバイダは、ドメイン６０のすべてを含む同期範囲Ａ（すなわち、コンピューティングノード６２、６４、および６６）、またはコンピューティングノード６４または６６だけを含む範囲Ｂを有することができる。
【００３７】
図３および５を参照すると、ノード間の通信リンクは、マルチキャストリンク７０およびポイントツーポイントリンク７２として示される。マルチキャストリンク７０およびポイントツーポイントリンク７２は、システム２０のｎ個のノードのうちの複数のノードを相互接続するように示されている。例えば、コンピューティングノード２２および２４は、データ同期のために相互に接続されるように示されている。システム２０の他のアクティブコンピューティングノードはマルチキャストリンク７０と相互接続されており、それによってポイントツーポイントリンク７２を設定することができることが理解されよう。コンピューティングノード２２のＳＲＰ  ５６は、システム２０のドメイン内のすべてのコンピューティングノード（コンピューティングノード２４を含めて）のＳＲＰ  ５６とマルチキャストリンク７０を介して通信する。
【００３８】
システム２０にあるコンピューティングノードは、それぞれ実質的に同じなので、コンピューティングノード２２だけを詳細に説明する。コンピューティングノード２２は、ＳＲＰ  ５６、同期プロバイダ登録設備７４、およびＮＳＰ  ５４とＳＥＰ  ５２で例示されるような複数の同期プロバイダを含む。コンピューティングノード２２は、この他のプロバイダに加え、図２に示す他の同期プロバイダも含むことができることが理解されよう。
【００３９】
ＮＳＰ  ５４は、関連付けられたＮＳＰデータレポジトリ７６を有し、ＳＥＰ  ５２は、関連付けられたＳＥＰデータレポジトリ７８を有する。ＮＳＰ  ５４およびＮＳＰデータレポジトリ７６には、それぞれに同期範囲Ａを示すＡがラベリングされる（図４）。ＳＥＰ  ５２およびＳＥＰデータレポジトリ７８には、それぞれに同期範囲Ｂを示すＢがラベリングされる（図４）。起動時または構成時に、ＮＳＰ  ５４の同期範囲Ａと、ＳＥＰ  ５２のＢが、同期プロバイダ設備７４に登録される。さらに、同期範囲内のデータのクラスもまた、ＮＳＰ  ５４およびＳＥＰ  ５２に関して登録される。すなわち、例えばＳＥＰ  ５２は、システム２０の他のノードにあるＳＥＰデータレポジトリ７８から入手可能なイベントデータ全体の限定されたクラスだけを必要とする場合がある。
【００４０】
ＳＲＰ  ５６と、同期プロバイダＮＳＰ  ５４およびＳＥＰ  ５２とは、コンピューティングノード２２のＷＭＩ設備３６を介して相互に通信する。例えば、ＳＥＰ  ５２は、プロセス３２（図１）の新しいイベントインスタンスをＳＥＰデータレポジトリ７８に記録し、ＳＲＰ  ５６にその新しいイベントインスタンスを通知する。ＳＲＰ  ５６は、この新しいイベントインスタンスをパッケージし、マルチキャストリンク７０を介してそのパッケージをシステム２０の他のコンピューティングノード（コンピューティングノード２４を含めて）にマルチキャストする。受信側ノードのそれぞれのＳＲＰ  ５６は、そのパッケージを解き、パッケージされたイベントインスタンスが、関連付けられたＳＥＰ  ５２およびＳＥＰデータレポジトリ７８の範囲およびクラスと一致するか否かを決定する。一致する場合、イベントインスタンスは、関連付けられたＳＥＰ  ５２にローカルＷＭＩ設備を介して提供される。
【００４１】
イベント通知に加え、ＳＲＰ  ５６は、システム２０にある他のコンピューティングノードのＳＲＰ  ５６との、様々なタイプの制御メッセージの交換においても、マルチキャストリンク７０を使用する。例えば、起動時に、ＳＥＰデータレポジトリ７８には、その登録された範囲およびクラスのイベントデータをポピュレートする必要がある。コンピューティングノード２２のＳＲＰ  ５６は、マルチキャストリンク７０を介して、必要とされるデータのダウンロードを要求する制御メッセージを送信する。受信側ノード、例えばコンピューティングノード２４は、その制御メッセージを検査し、それが入手可能なデータを有する場合には、制御メッセージで返答する。次いでコンピューティングノード２２のＳＲＰ  ５６は、ＷＭＩ設備３６に、コンピューティングノード２４のＳＲＰ  ５６とのポイントツーポイントリンク７２を設定させ、要求されたデータが、ＴＣＰ／ＩＰストリームとしてダウンロードされ、コンピューティングノード２２のＳＥＰ  ５２に提供される。
【００４２】
図６を参照すると、ＳＲＰ  ５６は、クライアントプロセス８０、ＳＲＰ  ＷＭＩの実現８２、送信スレッド９０、および受信スレッド９２を含む。エラー送信待ち行列８４、インスタンス送信待ち行列８６、および遅延送信待ち行列８８は、送信スレッド９０への入力待ち行列として割り付けられる。送信メッセージマップ９４は、送信スレッド９０および受信スレッド９２により共通に使用される。受信メッセージマップ９６および消失メッセージマップ９８は、受信スレッド９２と関連付けられる。
【００４３】
イベントインスタンスを送信するために、クライアントプロセス８０は、イベントインスタンスを獲得し、それをＳＲＰ  ＷＭＩの実現８２に提供するよう、ＷＭＩ設備３６を介してクライアント（例えば、ＳＥＰ  ５２）と通信する。ＷＭＩの実現８２は、イベントインスタンスをインスタンス通知としてパッケージし、それをインスタンス送信待ち行列８６に入れる。次いで送信スレッド９０は、マルチキャストリンク７０を介してそのインスタンス通知をシステム２０の他のコンピューティングノードに送信する。送信スレッド９０は、送信インスタンス通知を送信メッセージマップ９４にも入れる。
【００４４】
遠隔コンピューティングノードからの制御メッセージは、マルチキャストリンク７０を介して受信スレッド９２により受信される。受信スレッド９２は、着信メッセージを検査し、それらの性質を特定し、それらを受信メッセージマップ９６に入れる、状態分析プロセスを含む。着信メッセージが、ローカル同期プロバイダ（例えば、ＳＥＰ  ５２）の同期範囲およびクラスと一致するインスタンス通知である場合、それは受信待ち行列１００に入れられる。外部スレッド１０２は、その着信インスタンス通知をクライアントプロセス８０に提供し、クライアントプロセス８０は、その着信インスタンス通知を適切な同期プロバイダ（例えば、ＳＥＰ  ５２）に提供する。
【００４５】
受信スレッド９２の状態分析プロセスが、着信メッセージが消失したか、または所在不明であることを検出した場合、送信スレッド９０がマルチキャストリンク７０でマルチキャストするよう、エラーメッセージが送信側のためにパッケージされ、消失メッセージマップ９８に格納され、エラー送信待ち行列８４に入れられる。エラーメッセージを受信した際、元のメッセージの送信側の受信スレッド９２は、それが送信側であることを確認するためにその送信メッセージマップをチェックする。次いで元のメッセージが再送される。受信の際、受信スレッド９２は、この着信メッセージを送信エラーメッセージと照合するために送信メッセージマップ９４をチェックする。確認された場合、受信スレッド９２は、消失メッセージマップ９８に既に書き込まれたエラーメッセージを除去するか、または非活動化する。
【００４６】
本発明のＳＲＰ  ５６の上記および他の特徴を、以下でさらに説明する。
同期レポジトリプロバイダ
ＳＲＰ  ５６は、ＳＥＰ  ５２およびＮＳＰ  ５４の基礎的なコンポーネントである。ＳＥＰ  ５２およびＮＳＰ  ５４は、登録済みインスタンスクラスの複合表示を提供する。ＳＥＰ  ５２およびＮＳＰ  ５４は、ＳＲＰ  ５６により実現されるコネクションレス型の信頼性のあるプロトコルにより、それぞれのレポジトリデータを取得する。
【００４７】
ＳＲＰ  ５６は、分散型管理データの同期ＷＢＥＭレポジトリを維持するために、信頼性のあるインターネットプロトコル（ＩＰ）マルチキャストベースの技術を実現する、ＷＭＩ外部イベントプロバイダである。ＳＲＰ  ５６は、動的インスタンスプロバイダまたはインスタンスクライアントが、分散型データの複合表示を収集するために複数の遠隔接続を行う必要性を解消する。ＳＲＰ  ５６は、データ変更イベントの配信を保証するために、同期された表示の状態を維持する。コネクションレス型プロトコル（ＵＤＰ）が使用されるが、これは、接続されたクライアントおよびサーバに対するネットワーク／コンピュータ停止の影響を最小限に抑える。ＩＰマルチキャストを使用することにより、ネットワーク帯域幅に対する影響が低減され、構成は単純化される。
【００４８】
ＳＲＰ  ５６は、標準ＷＭＩ外部イベントおよびメソッドプロバイダインターフェースを実現する。ＳＲＰ  ５６に対して、ＩＷｂｅｍＳｅｒｖｉｃｅｓ：：ＥｘｅｃＭｅｔｈｏｄ［Ａｓｙｎｃ］（）メソッドを使用する同期プロバイダ（例えば、ＳＥＰ  ５２またはＮＳＰ  ５４）からすべてのメソッド呼び出しが行われる。ＳＲＰ  ５６からの外部イベントデータに対する登録は、ＩＷｂｅｍＳｅｒｖｉｃｅｓ：：ＥｘｅｃＮｏｔｉｆｉｃａｔｉｏｎＱｕｅｒｙ［Ａｓｙｎｃ］（）のＳＲＰ実施態様への呼び出しによる。ＳＲＰ  ５６は、外部イベント通知および接続状態更新を、ＩＷｂｅｍＯｂｊｅｃｔＳｉｎｋ：：Ｉｎｄｉｃａｔｅ（）およびＩＷｂｅｍｂＯｂｊｅｃｔＳｉｎｋ：：ＳｅｔＳｔａｔｕｓ（）のクライアントの実施に対するコールバックにより、ＳＥＰ  ５２およびＮＳＰ  ５４にそれぞれ提供する。標準ＷＭＩインターフェースしか使用されないので、（すべてのＷｉｎ２Ｋコンピュータに導入された）カスタムライブラリまたはプロキシファイルには、ＳＲＰ  ５６を実現またはインストールすることが要求されない。
【００４９】
構成の複雑さを低減し、融通性を最適化するために、すべての登録済みクライアント（同期プロバイダ）に対して単一ＩＰマルチキャストアドレスが使用される。受信したマルチキャストはＷＢＥＭクラスおよびソースコンピュータのアクティブディレクトリ経路によりフィルタリングされ、次に適切な同期プロバイダに配信される。各クライアントはＷＢＥＭクラスによりＳＲＰ  ５６に登録する。それぞれの登録されたクラスは、個別に構成可能なアクティブディレクトリ範囲を有する。
【００５０】
ＳＲＰ  ５６は、同期制御メッセージとレポジトリ更新の両方を渡すためにＩＰマルチキャストを使用するが、これにより通知配信のオーバーヘッドが低減され、ネットワーク帯域幅が保たれる。同期中のノード間における伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）ストリーム接続を介してレポジトリ同期が行われる。同期にＴＣＰ／ＩＰストリームを使用することにより、複雑度マルチキャストトラフィック解釈が低減され、レポジトリデータの信頼性のあるポイントツーポイント配信が保証される。
【００５１】
同期プロバイダは、コンピュータの論理グループ全体の同期を要求するＷＢＥＭインスタンスプロバイダである。これらのプロバイダは、ＳＲＰ  ５６から外部イベント通知を受信するために、標準ＩＷｂｅｍＳｅｒｖｉｃｅｓ、ＩＷｂｅｍＰｒｏｖｉｄｅｒＩｎｉｔ、およびＩＷｂｅｍＥｖｅｎｔＰｒｏｖｉｄｅｒ、ならびにＩＷｂｅｍＯｂｊｅｃｔＳｉｎｋを実現する。クライアントは、ＩＷｂｅｍＳｅｒｖｉｃｅｓインターフェースを介して同期プロバイダに接続する。ＷＭＩサービス（ｗｉｎｍｇｍｔ．ｅｘｅ）は、ＩＷｂｅｍＰｒｏｖｉｄｅｒＩｎｉｔを介して同期プロバイダを初期設定し、ＩＷｂｅｍＥｖｅｎｔＰｒｏｖｉｄｅｒインターフェースを介してインスタンス通知のクライアントイントレストを登録する。
【００５２】
同期プロバイダは、インスタンス通知がクライアントに配信される方法が標準のインスタンスプロバイダと異なる。ｗｉｎｍｇｍｔサービスのＩＷｂｅｍＯｂｊｅｃｔＳｉｎｋにインスタンス通知を直接配信する代わりに、同期プロバイダは、ＳＲＰ  ５６に接続し、ＳＲＰ  ＳｅｎｄＩｎｓｔａｎｃｅＮｏｔｉｆｉｃａｔｉｏｎ（）メソッドを使用してインスタンス通知を配信する。次いでＳＲＰはそのインスタンス通知をマルチキャストにより、構成済み同期グループのすべてのプロバイダに送る。ＳＲＰ  ５６により受信されたインスタンス通知は、ｗｉｎｍｇｍｔサービスにより外部イベントを介して同期プロバイダに転送される。同期プロバイダはそのＳＲＰ外部イベントを受信し、その外部イベントからインスタンスイベントを抽出し、そのインスタンスイベントを必要に応じて内部データベースに適用し、次いでそのイベントを接続されたクライアントにｗｉｎｍｇｍｔにより転送する。
【００５３】
同期されたデータが、インスタンスの配列を含んだ外部イベントブジェクトにより同期プロバイダに配信される。このオブジェクトの配列は、現在同期した状態にある遠隔の同期プロバイダからＴＣＰ／ＩＰストリームにより同期中のノードに配信される。同期プロバイダＳＲＰクライアントは、この受信した配列と局所的に生成されたインスタンスとをマージし、遠隔の同期プロバイダに、ＳＲＰ  ５６を介してインスタンス通知を送ることにより、その違いを通知する必要がある。各同期プロバイダは、同期データをローカルレポジトリデータとマージする最善の方法を決定する必要がある。
【００５４】
クライアントアプリケーションは、いかなる他のＷＢＥＭインスタンスプロバイダ用でもあるので、同期プロバイダ（ＳＲＰのクライアントとして登録済みのプロバイダ）にアクセスする。レポジトリの同期された性質は、同期プロバイダのクライアントに透過的である。
【００５５】
ＳＲＰ  ５６は、指定された一群のコンピュータに対して登録設定を調整する、Ｍｉｃｒｏｓｏｆｔ管理コンソール（ＭＭＣ）プロパティページにより構成される。ＳＲＰ構成は、ＩＰマルチキャストおよびアクティブディレクトリ範囲のストリングの両方の構成を要求する。
【００５６】
デフォルトで、ＳＲＰ  ５６は、ＨＫＬＭ＼Ｓｏｆｔｗａｒｅ＼Ｈｏｎｅｙｗｅｌｌ＼ＦＴＥレジストリキーにあるハートビートプロバイダ５８への構成されたＩＰマルチキャスト（ＩＰＭＣ）アドレスを使用する。これにより、ＬＡＮ診断メッセージ（ハートビート）による、ＩＰマルチキャストグループの健康状態に関する肯定的な指示が提供される。ＳＲＰメッセージ用のＵＤＰ受信ポートは、固有である（ハートビートプロバイダ５８と共有されない）。マルチキャスト通信は、ルータによりしばしば制約を受ける。あるサイトがあるルータを介したデータの同期を要求した場合、マルチキャストメッセージがそのルータを通過するよう許可するために、ネットワーク構成ステップが必須となる場合がある。
【００５７】
アクティブディレクトリ範囲は、同期プロバイダごとに構成される（例えば、ＳＥＰ  ５２またはＮＳＰ  ５４）。それぞれのインストールされたクライアントは、サポートされるＷＭＩクラスの名前付きキーを、ＨＫＬＭ＼Ｓｏｆｔｗａｒｅ＼Ｈｏｎｅｙｗｅｌｌ＼ＳｙｓＭｇｍｔ＼ＳＲＰ＼Ｃｌｉｅｎｔｓキーに追加する。このキーに、クライアントは名前と範囲の値を追加する。名前の値は、構成インターフェース内に表示するためにユーザフレンドリーな名前を含んだＲＥＧ＿ＳＺ値である。範囲の値は、１つまたは複数のアクティブディレクトリ範囲のストリングを含んだＲＥＧ＿ＭＵＬＴＩ＿ＳＺ値である。
【００５８】
ＳＲＰ構成ページは、ユーザに、構成すべきインストール済みＳＲＰクライアントの選択を可能にするコンボボックスを提示する。このコンボボックスには、ＳＲＰ＼Ｃｌｉｅｎｔｓキーの基に列挙されたクライアントクラスごとに名前の値がポピュレートされる。クライアントプロバイダが一度選択されると、アクティブディレクトリツリーが、ユーザが更新の範囲を選択できるようにするためのチェックボックス項目と共に表示される。これは、現在のクライアント範囲の値と一致するようにチェックマークにより初期設定される。
【００５９】
インスタンス内容をＩＰマルチキャストにより渡すには、ＵＤＰ  ＩＰマルチキャストパケットを介してＩＷｂｅｍＣｌａｓｓＯｂｊｅｃｔプロパティを読み取り、マルチキャストグループに整理し、受信側で再構成する必要がある。各通知オブジェクトが検査され、その内容がＳＲＰメモリのストリームオブジェクトに書き込まれる。インスタンスプロパティの数が最初にストリームに書き込まれ、次にすべてのインスタンスプロパティが名前（ＢＳＴＲ）、データ（ＶＡＲＩＡＮＴ）対の形式で書き込まれる。次いでこのストリームは、１つのＩＰマルチキャストＵＤＰデータパケットにパッケージされ送信される。受信されると、プロパティの数が抽出され、名前／データ対がストリームから読み出される。クラスインスタンスが作成され、受信された値がそれにポピュレートされ、次いで登録済みクライアント（同期プロバイダ）に配信するために外部イベントによりｗｉｎｍｇｍｔサービスに送信される。異型は参照データを含めることができない。値の安全な配列を含む異型は、まず異型タイプを書き込み、次にその安全な配列に含まれるインスタンスの数、次いですべての含まれる要素に関するその異型タイプとデータを書き込むことにより整理される。
【００６０】
応答ストームを回避するために、マルチキャスト応答は、送信前にリクエスター指定の最大時間まで任意に延期される。ローカル応答が送信される前に応答側ノードが別のノードから有効な応答を受信した場合、その送信は取り消される。
【００６１】
ＳＲＰ  ５６は、ＳＥＰ  ５２とＮＳＰ  ５４の両方によって使用される基盤コンポーネントである。いかなるＷＭＩレポジトリのデータでもＩＰマルチキャストによって同期するために、ＳＲＰ  ５６を使用することができる。ＷＭＩレポジトリを複数のノード全体にわたり同期した状態で保つ必要がある場合なら如何なる場合でも、ＳＲＰ  ５６を使用することができる。ＷＭＩレポジトリの同期を実行するには、その同期に参加する各ノードが、他のすべての参加しているノードにマルチキャストメッセージを送受信できるように、ＩＰマルチキャストは使用可能である必要がある。ＷＭＩインターフェースを使用してこの動作を実行するには、そのプロバイダがすべての他のノードのプロバイダに接続することが必要になる。ＳＲＰ  ５６を使用すると、プロバイダは、すべての他のノードから更新を受信するために、ローカルＳＲＰ  ５６への接続だけあればよい。この機構はコネクションレス型であるが、信頼性はある。
【００６２】
ＳＲＰ  ５６のクライアントはＷＭＩプロバイダである。各クライアントプロバイダは、そのＷＢＥＭオブジェクトクラスとレポジトリ同期範囲とを特定することにより、起動時にＳＲＰ  ５６に登録する。
【００６３】
それらのレポジトリの同期を維持するために、ＳＲＰクライアントインターフェースを実施する同期プロバイダの例を次に示す。
システムイベントプロバイダ
ＳＥＰ  ５２は、管理コンポーネントの同期レポジトリおよび他のシステム関連イベントを維持する。ＳＲＰ  ５６は、イベント表示を、指定されたアクティブディレクトリ範囲内で同期された状態に保つために利用される。イベントは、マルチキャストグループ全体に書き込まれ、認知され、削除される。
【００６４】
このマルチキャストグループアドレスおよびポートならびにアクティブディレクトリ範囲は、同期レポジトリ標準構成ページから構成される。すべての他の標準構成ページと同様に、この選択肢も、システムディスプレイ４６によりコンピュータ構成コンテキストメニューに表示される。
【００６５】
デフォルトＳＥＰ  ５２クライアント構成が、ＳＲＰクライアント構成レジストリキーに書き込まれる。このキーは、名前および範囲の値を含む。名前は、ＳＥＰサービスに対するユーザフレンドリーな名前であり、範囲は、デフォルトで、それが含む活動状態にあるディレクトリオブジェクト（ＴＰＳドメイン組織ユニット）を示す「ＴＰＳＤｏｍａｉｎである。
ネームサービスプロバイダ
ネームサービスプロバイダ（ＮＳＰ  ５４）は、ＨＣＩ／ＯＰＣ別名の決定を担当する。ＨＣＩクライアントまたはサーバを含む各ノードは、障害耐性を達成するためにローカルＮＳＰ  ５４を有する必要がある。ＮＳＰ  ５４は、そのローカルマシン上の、定義されたマルチキャストグループの範囲内にある別名のレポジトリを作成し、維持する。
【００６６】
ＮＳＰ  ５４は、別名のレポジトリに対するＷＭＩクライアントのアクセスを提供するＷＭＩプロバイダとして実施される。ＮＳＰ  ５４は、マルチキャストグループの範囲内で別名の修正、作成、および削除のイベント通知を提供する、ＳＲＰ  ５６へのＷＭＩクライアントとしても実現される。ＨＣＩ−ＮＳＰは、ローカル別名に対する変更を監視するためにワーカースレッドを利用する。ローカル別名は、レジストリ内およびＨＣＩコンポーネント別名ファイル内にある。
【００６７】
マルチキャストグループアドレスおよびポートならびにアクティブディレクトリ範囲は、同期レポジトリ標準構成ページから構成される。すべての他の標準構成ページと同様に、この選択肢もコンピュータ構成．．．コンテキストメニューに表示される。デフォルトのＮＳＰ  ５４  ＳＲＰクライアント構成が、キーに書き込まれる。このキーは、「名前」および「範囲」の値を含む。「名前」は、ネームサービスのユーザフレンドリーな名前であり、「範囲」は、デフォルトで、濾過が実行されないことを示す「＊」である。
ネームサービスプロバイダ−ＳＲＰクライアントオブジェクト
ＳＲＰクライアントオブジェクトは、ＳＲＰ  ５６からのＩｎｓｔａｎｃｅＣｒｅａｔｉｏｎ、ＩｎｓｔａｎｃｅＭｏｄｉｆｉｃａｔｉｏｎ、ＩｎｓｔａｎｃｅＤｅｌｅｔｉｏｎ、および外部イベントを処理するコードを実施する。このオブジェクトは、遠隔ノードから、列挙された別名配列と共にＳｙｎｃＳｏｕｒｃｅＲｅｓｐｏｎｓｅメッセージを取得し、次いでそれをＳＲＰ  ５６から報告された変更と同期した状態に保つ。
【００６８】
ＳＲＰ論理設計シナリオ
ＳＲＰ  ５６を利用するプロバイダ（例えば、ＳＥＰ  ５２またはＮＳＰ  ５４）が起動すると、そのプロバイダはそのクラスおよび同期範囲をＳＲＰ  ５６に登録する。次いでＳＲＰ  ５６は、既存の同期レポジトリのソースを見つけ、このソース名をクライアントプロバイダに返す。次にクライアントプロバイダは、指定されたソースに対する一回限りのＷＭＩ接続を行い、そのローカルレポジトリをポピュレートして、すべての既存のインスタンスを列挙する。このノードは起動され、クライアントプロバイダサービスがオートスタートされる。表１は、このプロセスを示す。
【００６９】
表１
イベント                      イベントの説明                                  
１    クライアントプロバイダが起動し、初期設定中にＳＲＰ上のＲｅｇｉｓｔｅｒＣ        ｌｉｅｎｔ（）メソッドを呼び出す。
２    ＳＲＰは、指定されたクラスおよび範囲に対する同期メッセージを管理するため        に、クラスオブジェクトを作成する。
３    ＳＲＰは、他のノードに現在のレポジトリ状態を要求する、０という初期状態を        指定するＳｅｑｕｅｎｃｅＭｅｓｓａｇｅメッセージを発行する。
４    リスニングＳＲＰは、ＳｅｑｕｅｎｃｅＭｅｓｓａｇｅを受信し、所与のクラス        および範囲について、その着信した連続番号をそれらのローカルに維持される連        続番号と照合する。
５    そのローカル連続番号は着信した連続番号を超えているので、受信側ノードは、        送信のためにＳｅｑｕｅｎｃｅＭｅｓｓａｇｅ  ｍｓｇを待ち行列に入れる。
６    それらのノードの１つが、そのＳｅｑｕｅｎｃｅＭｅｓｓａｇｅメッセージを送        信する。すべての他のノードがそのメッセージを受信し、それをそれらのローカ        ルｓｅｑと照合し、それらが同じならば、応答ストームを回避するために、それ        らの応答メッセージ（ＳｅｑｕｅｎｃｅＭｅｓｓａｇｅ）をそれらのメッセージ        待ち行列から除去する。
７    起動中のノード上のＳＲＰは、ＳｅｑｕｅｎｃｅＭｅｓｓａｇｅメッセージを受        信し、そのメッセージを評価し、同期が要求されると評価する。
８    遅延した配信ＳｙｎｃＲｅｑｕｅｓｔＴｉｍｅｏｕｔメッセージがクライアント        受信待ち行列に入れられ、これで同期が完了するまでインスタンスの受信が防止        される。このメッセージ通知遅延が時間切れになった場合、イベントはロギング        され、そのクライアントはＳｙｎｃＳｏｕｒｃｅＴｉｍｅｏｕｔメッセージを受        信する。
９    ＲｅｑｕｅｓｔＳｙｎｃＳｏｕｒｃｅＭｅｓｓａｇｅメッセージが、エラーメッ        セージ送信待ち行列に入れられ、その連続番号は、評価されたＳｅｑｕｅｎｃｅ        Ｍｅｓｓａｇｅメッセージで指定された連続番号に設定される。
１０  ＲｅｑｕｅｓｔＳｙｎｃＳｏｕｒｃｅＭｅｓｓａｇｅを受信したノードは、その        メッセージ連続番号を評価し、それらが適格である場合は、ＳｙｎｃＳｏｕｒｃ        ｅＲｅｓｐｏｎｓｅＭｅｓｓａｇｅをＤｅｌａｙｅｄＭｓｇＱｕｅｕｅに書き込        む。ローカル応答の送信を待機中に別のノードからの応答が受信された場合、そ        のローカル応答は取り消される。応答がない場合、ＳｙｎｃＳｏｕｒｃｅＲｅｓ        ｐｏｎｓｅＭｅｓｓａｇｅが送信される。
１１  要求側ノード（起動中のノード）は、ＳｙｎｃＳｏｕｒｃｅＲｅｓｐｏｎｓｅＭ        ｅｓｓａｇｅを受信し、応答側ノードへのＴＣＰ／ＩＰストリーム接続を設定し        、クラスインスタンスの現在の目録をダウンロードする。現在のレポジトリ状態        に貢献した、受信メッセージの署名リストもダウンロードする。
１２  インスタンス目録で完了したＳｙｎｃＳｏｕｒｃｅＲｅｓｐｏｎｓｅＭｅｓｓａ        ｇｅは、待ち行列に入れられ、登録されたクライアントプロバイダに配信される        。
【００７０】
ＳＲＰ  ５６を利用するプロバイダ（例えば、ＮＳＰ  ５４）が起動する際、それはそのクラスおよび同期範囲をＳＲＰ  ５６に登録する。ＳＲＰ  ５６は、既存の同期レポジトリソースを見つけるよう試みる。これに失敗した場合、ＳＲＰ  ５６は、それが最初に起動するノードであると仮定し、ＮＳＰデータレポジトリ７６を初期設定する。このノードが起動され、クライアントプロバイダサービスがオートスタートされる。表２は、このプロセスを示す。
【００７１】
表２
イベント                      イベントの説明                                  
１    クライアントプロバイダが起動し、初期設定中にＳＲＰ上のＲｅｇｉｓｔｅｒＣ        ｌｉｅｎｔ（）メソッドを呼び出す。
２    ＳＲＰは、指定されたクラスおよび範囲に対する同期メッセージを管理するため        にクラスオブジェクトを作成する。
３    ＳＲＰは、他のノードに現在のレポジトリ状態を要求する、０という初期状態を        指定するＳｅｑｕｅｎｃｅＭｅｓｓａｇｅメッセージを発行する。
４    ＲｅｑｕｅｔＳｙｎｃＳｏｕｒｃｅＭｅｓｓａｇｅが送信され、ＳｙｎｃＳｏｕ        ｒｃｅＴｉｍｅｏｕｔメッセージが待ち行列に入れられる。
５    応答がなく、ＳｙｎｃＳｏｕｒｃｅＴｉｍｅｏｕｔ遅延期間が満了すると、イベ        ントがロギングされ、ＳｙｎｃＳｏｕｒｃｅＴｉｍｅｏｕｔが登録クライ              アントプロバイダに配信される。
【００７２】
ＷＭＩプロバイダは、接続されたクライアントにインスタンスの作成、削除、または修正を通知するために、ＷＭＩインスタンスイベントを生成する。これらのイベントは、システム２０内で接続された他のコンピューティングノードのＳＲＰ  ５６へのマルチキャストのために、そのクライアントプロバイダによりＳＲＰ  ５６に送信される。条件が変更され、そのクライアントプロバイダ（例えば、ＳＥＰ  ５２）にインスタンスイベントを生成させる。登録されたクライアントプロバイダに対するすべてのＳＲＰは、同期した状態にある。表３は、このプロセスを示す。
【００７３】
表３
イベント                      イベントの説明                                  
１    クライアントプロバイダが、オブジェクトインスタンスを含んでいるＷＢＥＭＣ        ｌａｓｓＯｂｊｅｃｔを渡す、ＳＲＰ  ＳｅｎｄＩｎｓｔａｎｃｅＮｏｔｉｆｉ        ｃａｔｉｏｎ（）メソッドを呼び出す。
２    ＳＲＰが、そのオブジェクトインスタンスをマルチキャストメッセージにパッケ        ージし、ＳＲＰマルチキャストグループに配信するためにそのメッセージを待ち        行列に入れる。
３    ＳＲＰは完了し、現在の連続番号の同期を保証する保留中の受信動作、次いで待        ち行列に入っているメッセージ連続番号を更新し、そのメッセージをマルチキャ        ストする。
４    リスニングＳＲＰは、インスタンスメッセージを受信し、指定されたクラスおよ        び範囲について、それらのローカル連続番号と照合する。
５    リスニングＳＲＰの連続番号が更新され、登録されたクライアントに着信メッセ        ージがＷＭＩイベントとして転送される。
【００７４】
ＳＲＰ  ５６は、オブジェクトクラス、同期範囲、連続番号、最後の更新のソース、および受信メッセージリストを使用して、同期レポジトリの現在の状態を維持する。メッセージが（遅れないが）不適切に受信された場合、１つまたは複数の「消失」メッセージがクライアントに対して待ち行列に入れられ、次いでその受信メッセージが待ち行列に入れられる。その消失メッセージを受信するための時間切れ期間が満了するまで、この「消失」メッセージは処理されない。ＳＲＰ  ５６は、その不明メッセージの再送を要求して、ＳＲＰマルチキャストグループにマルチキャストするために、ＬｏｓｔＭｅｓｓａｇｅメッセージを待ち行列に入れる。その不明メッセージが受信された場合、そのメッセージはクライアント受信待ち行列内の「消失」メッセージに取って代わり、その待ち行列は引き続き処理される。ＬｏｓｔＭｅｓｓａｇｅプレースホルダーが時間切れになった場合、ＳＲＰはｒｅｓｙｎｃを初期設定する。
【００７５】
条件が変更され、クライアントプロバイダにインスタンスイベントを生成させる。何らかの理由で、ノードがそのメッセージの受信に失敗する（バッファーの制約などにより転送中にドロップされる可能性がある（ＩＰマルチキャスト配信は保証されない））。表４は、このプロセスを示す。
【００７６】
表４
イベント                      イベントの説明                                  
１    クライアントプロバイダは、オブジェクトインスタンスを含むＩＷｂｅｍＣｌａ        ｓｓＯｂｊｅｃｔを渡す、ＳＲＰ  ＳｅｎｄＩｎｓｔａｎｃｅＮｏｔｉｆｉｃａ        ｔｉｏｎ（）メソッドを呼び出す。
２    ＳＲＰは、オブジェクトインスタンスをマルチキャストメッセージにパッケージ        し、ＳＲＰマルチキャストグループに配信するためにそのメッセージを待ち行列        に入れる。
３    ＳＲＰは、保留中の受信動作を完了して現在の連続番号の同期を保証し、次いで        その待ち行列に入っているメッセージの連続番号を更新し、そのメッセージをマ        ルチキャストする。
４    リスニングＳＲＰは、インスタンスメッセージを受信し、指定されたクラスおよ        び範囲について、それらのローカル連続番号と照合すると、そのメッセージが１        つの連続番号をスキップしたことが判明する。消失メッセージの最大数（デフォ        ルトで５）が消失していない限り、複数のメッセージが消失した可能性がある。
最大が消失している場合、レポジトリの再同期がトリガされる。待ち行列に入っ        ている送信メッセージが、再同期されたレポジトリに適用される。
５    ＳＲＰは、ＬｏｓｔＭｅｓｓａｇｅプレースホルダーメッセージを受信メッセー        ジ待ち行列に入れ、受信メッセージをそれに続ける。
６    ＳＲＰは、ＬｏｓｔＭｅｓｓａｇｅメッセージをＳＲＰマルチキャストグループ        にマルチキャストする。
７    リスニングＳＲＰは、ＬｏｓｔＭｅｓｓａｇｅメッセージを受信し、ＬｏｓｔＭ        ｅｓｓａｇｅがそれらのノードをソースとしている場合（かつ、その寿命に達し        ていない場合）、そのメッセージをインスタンス送信待ち行列の筆頭に置く。
８    消失メッセージが、（元の連続番号および再送フラグセットと共に）再送される        。
９    その消失メッセージを待つノードがそのメッセージを受信し、それをＬｏｓｔＭ        ｅｓｓａｇｅメッセージプレースホルダーに挿入し、登録したクライアントにそ        れを転送する。
１０  消失メッセージが再送される前に受信待ち行列内のＬｏｓｔＭｅｓｓａｇｅメッ        セージが時間切れになった場合、そのメッセージは既に存在せず、再送されない        と仮定することができる。登録されたクライアントプロバイダにこのＬｏｓｔＭ        ｅｓｓａｇｅイベントが送信され、レポジトリ再同期が要求される。
１１  応答する同期されたソースが指定されたメッセージに対する要件を満たすことが        できるよう保証するために、ＬｏｓｔＭｅｓｓａｇｅに対する署名（ｒｃｖｄメ        ッセージリスト評価により知られている場合は）がＲｅｑｕｅｓｔＳｙｎｃＳｏ        ｕｒｃｅＭｅｓｓａｇｅに添付される。
【００７７】
ＳＲＰ  ５６は、オブジェクトクラス、同期範囲、連続番号、および最後の更新のソースを使用して、同期レポジトリの現在の状態を維持する。以前に処理されたあるメッセージと連続番号が同じでソースの異なるメッセージが受信された場合、それは複製であると仮定され、送信側は有効な連続番号と共に再送する必要がある。条件が変更され、クライアントプロバイダは、複数のノードで同時に１つのインスタンスイベントを生成させられる。２つのノードは、現在の連続番号と共に粗同時に送信し、その結果、連続番号が同じソースの異なる２つのメッセージが受信されることになる。
【００７８】
表５
イベント                      イベントの説明                                  
１    ＳＲＰは、現在の連続番号より小さい連続番号と共にメッセージを受信する。
２    最近受信されたメッセージマップでこのメッセージが検索され、そのメッセージ        署名が異なることが判明する。
３    そのメッセージが再送される必要があることを送信側ノードに示すために、複製        エラーメッセージが、遅延メッセージ待ち行列に入れられる。
４    受信されたメッセージが処理される。
５    複製メッセージの遅延送信が行われる前に、別のノードから複製メッセージエラ        ーが受信された場合、その複製メッセージエラーは取り消される。
６    遅延イベント時間が満了した場合、その複製メッセージエラーが送信される。
７    元の送信側ノードは、複製メッセージエラーを受信し、送信メッセージに再送フ        ラグをセットし、送信するようにそのメッセージを再通知する。
【００７９】
ＳＲＰ  ５６は、オブジェクトクラス、同期範囲、連続番号、最後の更新のソースおよびタイムスタンプを使用して同期レポジトリの現在の状態を維持する。何らかの理由でマルチキャストグループが中断した場合（すなわち、そのマルチキャストを転送しているネットワーク途中のルータに障害が発生した場合）、２つの別個に同期化されたレポジトリイメージが存在する。このネットワーク問題が解決した場合、ＳＲＰ  ５６は、同期したレポジトリのその２つの表示をマージする必要がある。レポジトリはマージして１つの複合イメージを作るので、どちらの側がマスターとして選択されたかは問題でない。
【００８０】
ネットワークの異常により、２つの有効なＳＲＰイメージが存在することになった。ネットワークは回復し、ＳＲＰ  ５６は、その２つの有効なレポジトリイメージをマージする必要がある。受信メッセージの連続番号は、現在の連続番号より小さく、再送フラグはセットされていない。それは、消失メッセージではない。そのタイムスタンプは最後の受信メッセージのタイムスタンプより古い。表６は、このプロセスを示す。
【００８１】
表６
イベント                      イベントの説明                                  
１    ＳＲＰが、現在の連続番号より小さい受信メッセージの連続番号と共にメッセー        ジを受信し、その受信メッセージには再送フラグがセットされていない。
２    ＳＲＰは、連続メッセージに連結された受信メッセージのリストを検査する。受        信リストをローカル受信メッセージリストと照合することにより、消失メッセー        ジのリストが作成される。
３    消失メッセージが特定された場合、特定された第１のメッセージに対する１つの        消失メッセージプレースホルダーが受信待ち行列に書き込まれ、消失メッセージ        エラーが遅延送信待ち行列に書き込まれる。
４    その要求が送信される前に、同じ要求された消失メッセージに対する別の消失メ        ッセージ要求が受信された場合、その要求は取り消される。
５    消失メッセージが受信された場合、消失リストにある次のメッセージが要求され        る。
６    消失メッセージのプレースホルダーが時間切れになると、同期が要求された消失        メッセージのリストを示す同期要求が書き込まれる。
【００８２】
ステップ＃３で消失メッセージが特定されない場合、表７に示す後続代替経路を辿る。
【００８３】
表７
イベント                      イベントの説明                                  
３    遠隔ノードがメッセージを見失っていないか否かを決定するために、メッセージ        の受信リストがローカル受信メッセージリストと照合される。
４    遠隔ノードが受信していない追加メッセージがローカルノードで特定された場合        、遠隔ノードが同期されることを保証するために、連続メッセージが遅延送信待        ち行列に入れられる。
５    追加メッセージがない場合、その連続番号が検査される。受信された連続番号が        ローカル番号より大きい場合、要求される連続番号を示して、再同期が要求され        る。
６    受信された連続番号がローカル番号より小さい場合、遠隔ノードが同期要件を評        価することを保証するように、１つの連続番号が送信される。
【００８４】
以上、本発明者は、本発明者の発明に従い数点の実施形態を図示し説明したが、上記実施形態は、当業者には明らかな多数の変更を受けることが理解されよう。したがって、本発明者らは、図示し説明した詳細に限定することを欲せず、首記の特許請求の範囲内に含まれるすべての変更および修正を示すことを意図する。
【図面の簡単な説明】
【００８５】
【図１】本発明のデータ同期デバイスを含むシステムのブロック図である。
【図２】本発明によるデータ同期デバイスの様々な実行時システム管理コンポーネント間における通信経路を示すブロック図である。
【図３】本発明のデータ同期デバイスにより使用される様々なコンピューティングノード間における通信リンクを示すブロック図である。
【図４】本発明のデータ同期デバイスの同期範囲を示すブロック図である。
【図５】本発明のデータ同期デバイスにより使用される様々なコンピューティングノード間における通信リンクをさらに示すブロック図である。
【図６】本発明のデータシンクロナイザーのブロック図である。
【図１】
2005531856.tif 000003
【図２】
2005531856.tif 000004
【図３】
2005531856.tif 000005
【図４】
2005531856.tif 000006
【図５】
2005531856.tif 000007
【図６】
2005531856.tif 000008
【国際調査報告】
2005531856.tif 000009
2005531856.tif 000010
2005531856.tif 000011