JP2004518310A - 送信されたプロトコル・データ単位を解析する方法 - Google Patents

Abstract

本発明は、送信されたプロトコル・データ単位、特に一般ＯＲＢ間プロトコルの送信されたプロトコル・データ単位を解析する方法に関する。この方法は、一般ＯＲＢ間デコーダで、単一オブジェクトに関連して、初期化段階、学習段階、および復号段階の３つの段階を有し、それによって、含まれるメッセージを可能な限り完全に表すことができる。初期化段階では、すべての可能なインターフェース定義のリストを確立する。これらのリストは、具体的には、特定のホスト、特定のエージェント、またはエージェント特有の宛先アドレスに対して格納される。学習段階では、排他基準を使用して可能性の数を減らすが、評価したメッセージはまだ完全に復号することはできない。特定のオブジェクトの基礎を形成する可能性のある複数のインターフェース定義が依然として存在する。オブジェクトの基礎となるインターフェース定義を決定した後、オブジェクトと送受信されるメッセージは、復号段階で復号することができる。原理上、段階２と段階３との間に明確な境界はなく、段階３から段階２に部分的に戻ることが必要となる可能性がある。段階３にまだ到達していないために復号することができない任意のメッセージは、単に非復号形式で出力されるか、または復号プロセスを後の段階で完了しなければならない可能性がある。１つの特に単純な可能性は、始めにすべての記録されたプロトコル・データ単位と共に段階２を実行し、それに続いてこれらすべてを段階３で再復号することである。

Description

【０００１】
本発明は、請求項１の種概念の定義に従って送信されたプロトコル・データ単位（Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ：ＰＤＵ）を解析する方法に関する。
【０００２】
含まれるメッセージを可能な限り完全に表すために、オブジェクト・リクエスト・ブローカ（Ｏｂｊｅｃｔ Ｒｅｑｕｅｓｔ Ｂｒｏｋｅｒｓ：ＯＲＢ）間で通信するための一般的プロトコルの送信されたプロトコル・データ単位を解析する方法が一般に知られている。
【０００３】
ＣＯＲＢＡは、Ｕｗｅ Ｓｅｉｍｅｔによる「Ｗｉｓｓｅｎ」第１０８頁乃至第１１３頁の論文”ＣＯＲＢＡ，ｕｂｅｒｎｅｈｍｅｎ Ｓｉｅ”、Ｓｅｒｖｉｃｅｓ ： Ｂａｓｉｓｄｉｅｎｓｔｅ ｆｕｒ ｄｅｎ ＯＲＢ” に記載されている。ＣＯＲＢＡはまた、”ＮＯＭＳ ２０００，２０００ ＩＥＥＥ／ＩＦＩＰ、Ｎｅｔｗｏｒｋ ａｎｄ Ｍａｎａｇｅｍｅｎｔ Ｓｙｍｐｏｓｉｕｍ””Ｔｈｅ Ｎｅｔｗｏｒｋｅｄ Ｐｌａｎｅｔ：Ｍａｎａｇｅｍｅｎｔ Ｂｅｙｏｎｄ ２０００”のフレームワークにおけるＧｕｉｄｏ Ｃａｒｌｓ、Ｇｅｒｄ Ａｓｃｈｅｍａｎｎ、Ｙｉｎｇ Ｌｕの”Ｖａｌｉｄａｔｉｎｇ Ｉｎｔｅｒａｃｔｉｏｎ Ｐａｔｔｅｒｎｓ ｏｆ ＣＯＲＢＡ Ｂａｓｅｄ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍｓ”（２０００年４月１０日乃至１４日、Ｈｉｌｔｏｎ Ｈａｗａｉｉａｎ ｖｉｌｌａｇｅ、Ｈｏｎｏｌｕｌｕ、Ｈａｗａｉｉ）の文献にも記載されている。ＣＯＲＢＡは、いくつかのオペレーティング・システム・プロセスにわたってアプリケーションを分散するために使用される。ＣＯＲＢＡにより、分散アプリケーションの非独占ホスト間通信（ｎｏｎ−ｐｒｏｐｒｉｅｔａｒｙ， ｉｎｔｅｒｈｏｓｔ ｃｏｍｍｕｎｉｃａｔｉｏｎ）が可能となる。この状況では、クライアントの役割とサーバの役割とが区別される。クライアント役のアプリケーションは、サーバ役で動作する別のアプリケーションに要求を送信する。この要求は、サーバ役のアプリケーションで処理され、対応する応答がクライアントに返される。２つのオブジェクト・リクエスト・ブローカ間の通信用の一般的プロトコルは、これらのメッセージを搬送するためのプロトコルとして使用される。ＴＣＰ／ＩＰベースのネットワークでは、その特殊な形式、いわゆる「インターネットＯＲＢ間プロトコル（Ｉｎｔｅｒｎｅｔ Ｉｎｔｅｒ−ＯＲＢ Ｐｒｏｔｏｃｏｌ：ＩＩＯＰ）」が使用される。どの内容をクライアントとサーバとの間で交換することができるかについての情報が、オブジェクト指向インターフェース記述言語（ＩＤＬ）を使用して確立される。
【０００４】
分散アプリケーションが予期せぬ挙動をした場合、または分散アプリケーションの受諾テスト中、個々のアプリケーション・コンポーネントの挙動に関する結論を得ることができるように、クライアントとサーバとの間の通信を監視することが必要となることがある。例えば、上記で引用した参考文献では、以下の手順を記載している。
【０００５】
分散アプリケーションをクライアント側またはサーバ側で拡張し、それによって交換するＧＩＯＰメッセージも完全に、または部分的に記録用および評価用の分散アプリケーションのコンポーネントに経路指定するようにできる。
クライアントとサーバとの間で交換されるＰＤＵをトレース・ツールによって記録することができ、かつ交換するメッセージのタイプと、使用する製品とに関する追加の知識を使用して復号することができる。メッセージの復号は、手動または自動で行うことができる。
テスト目的専用に開発されたアプリケーションを、クライアントとサーバとの間の通信に組み込む。このアプリケーションは、サーバとしてクライアントからの要求を受け取り、クライアントとしてこの要求をサーバに経路指定する。応答がそれに応じて返される。この結果、このテスト・アプリケーションによって、すべてのＰＤＵを監視し、評価することができる。
【０００６】
これらの周知の方法は、クライアントとサーバとの間で交換される一般ＯＲＢ間プロトコル（Ｇｅｎｅｒａｌ Ｉｎｔｅｒ ＯＲＢ Ｐｒｏｔｏｃｏｌ：ＧＩＯＰ）ＰＤＵの受動記録だけでは、メッセージを完全に復号するのに十分ではないという欠点を有する。これはいくつかの理由のために生じるが、それを以下で示す。
【０００７】
規則として、値、例えば１２３だけしかＧＩＯＰ ＰＤＵで符号化されず、そのタイプ・コード、例えば整数は符号化されない。したがって、ＰＤＵだけでは、ＰＤＵ内に含まれるパラメータの数、または値のタイプを決定することができない。
起動されるメソッドの名前は、呼出しではそのフル・コンテキスト内に符号化されない。このメソッドが宣言されるインターフェース定義の固有の識別が欠けている。同一のメソッドを異なるシグニチャで異なるインターフェース定義内に定義すべき場合、同一の値符号化長が与えられると、実際に符号化されるメソッドを識別することができない。
サーバ側のエージェントが、自動生成し、発行した「ターゲット・アドレス」を介して着信要求を特定のＣＯＲＢＡオブジェクトと関連付けることができる間、ＣＯＲＢＡ標準によるトレース・ツールは実際に、索引に従ってターゲット・アドレスの内容が同等かをチェックすることができるが、具象オブジェクト、およびオブジェクトの下にあるインターフェース定義を関連付けることはできない。ＣＯＲＢＡ標準のプロプラエタリ拡張を用いた場合にのみ、トレース・ツールを使用してターゲット・アドレスの内容から情報を得ることが可能である。
ＣＯＲＢＡでは、サーバからクライアントに転送されるオブジェクト参照が提供され、例えばディスケット上のテキスト・ファイルのようなＧＩＯＰプロトコルが回避される。ＩＩＯＰプロトコルに基づいて一意的にＣＯＲＢＡオブジェクトをアドレス指定する働きをする相互運用オブジェクト参照（ＩＯＲ）として交換されるこのオブジェクト参照が、関連するインターフェース定義に関する情報も含むとき、この情報の項目は、一般に決して再度クライアントとサーバとの間で交換されない。したがって、通信に関係するアプリケーション・コンポーネントに能動的に照会せずに、ＣＯＲＢＡトレース・ツールがこの情報を得る方法はない。しかし、これは、トレース・ツールは受動的に監視することしか可能ではないという枠組みと相容れない。
【０００８】
したがって、クライアントとサーバとに周知の状況で単一のＧＩＯＰ ＰＤＵを一意的に相関させ、復号することは確かに可能であるが、記録されたＰＤＵをこの周知の状況の外部で固有かつ標準に準拠して復号する可能性はないという問題が存在する。
【０００９】
したがって、本発明の目的は、ＣＯＲＢＡクライアントとＣＯＲＢＡサーバとの間の通信を制御し、またはそれを可能にする２つのオブジェクト・リクエスト・ブローカ間で通信するため、すなわち含まれるメッセージを可能な限り完全に表すための一般的プロトコルの送信されたプロトコル・データ単位を解析する方法であって、交換するＧＩＯＰ ＰＤＵを十分な期間受動的に監視するだけで、送信されたメッセージをクライアントおよびサーバの実装を変更することなく完全に復号することを可能にするように意図した方法を提供することである。
【００１０】
本発明の目的を達成する手段は、請求項１に記載されている。
【００１１】
本発明の別の設計手法または実施例は、請求項２から１１に記載されている。
【００１２】
本発明による方法により、交換するＧＩＯＰ ＰＤＵを十分な期間の間、受動的に監視するだけで、クライアントおよびサーバの実装を変更することなく送信されたメッセージを完全に復号することが可能となるので有利である。
これは、一種の学習段階で、交換したメッセージを系統的に評価し、相関させ、その結果個々のメッセージの復号中に発生する可能性のあるあいまいさを除外することによって達成される。
【００１３】
このようにして、記録されたプロトコル・データ単位をこの周知の状況の外部で復号することを可能にする、固有かつ標準準拠の解決策が生成される。
【００１４】
含まれるメッセージを可能な限り完全に表す目的で送信されたＧＩＯＰ ＰＤＵを解析するためのこの方法の別の利点、特徴、および可能な使用法を、図面に示す例示的実施例と共に以下で説明する。
【００１５】
以下では、図面に示す例示的実施例に照らして、本発明をより詳細に説明する。最後に示した参照符号のリストで使用される用語および関連する参照符号を、特許請求の範囲、要約、および図面中で使用する。
【００１６】
以下は、この後で使用する用語の簡単な説明または定義である。
ＣＯＲＢＡ：共通オブジェクト・リクエスト・ブローカ・アーキテクチャ。各ホストにアプリケーションを分散するためのフレームワークの定義。
ＧＩＯＰ：一般ＯＲＢ間プロトコル。２つのＯＲＢ間通信用一般プロトコル。
ＯＲＢ：オブジェクト・リクエスト・ブローカ。ＣＯＲＢＡクライアントとＣＯＲＢＡサーバとの間の通信を許可する。
ＩＩＯＰ：インターネットＯＲＢ間プロトコル。ＴＣＰ／ＩＰベースのネットワーク用のＧＩＯＰのアプリケーション。
ＩＩＯＰ ＰＤＵ：インターネットＯＲＢ間プロトコル・データ単位。
ＰＤＵ：プロトコル・データ単位。送信機と受信機との間で交換されるバイナリ・コード・メッセージ。
メッセージ：ＰＤＵとして送られる情報の項目。符号化方式ではなく、情報の意味が先頭にある。
ＴＣＰ／ＩＰ：伝送制御プロトコル／インターネット・プロトコル（一般に使用されるインターネット・プロトコル）。
ＵＭＬ：統合モデル化言語。
ホスト：分散アプリケーションの一部が動作し、固有アドレスによってアクセスすることができるコンピュータ。
ポート：ホスト内の複数の異なるエージェントに対する接続を確立することが可能なアドレスの論理サブディビジョン。
エージェント：ＧＩＯＰメッセージを送受信することを担当するエンティティ。
オブジェクト・キー：エージェントにより供給され、ＩＯＲを生成するために使用される特定の値。
ＩＯＲ：相互運用オブジェクト参照。ＩＩＯＰプロトコルに基づいてＣＯＲＢＡオブジェクトを一意的にアドレス指定するために使用される。
ターゲット・アドレス：ＧＩＯＰリリース１．２現在、オブジェクトに関する複数の異なるアドレス指定モードを記述する用語「ターゲット・アドレス」が導入されている。基本機能に関しては、以前は排他的に使用されていた「ターゲット・アドレス」とオブジェクト・キーは、ほぼ同一と見なすことができる。
タイプ・コード：ＯＲＢ内のデータ構造の記述。
クライアント：プロセスが分散アプリケーション内で請け負うことができる役割。クライアントは、サーバに対する接続をオープンするエージェントである。
サーバ：プロセスが分散アプリケーション内で請け負うことができる役割。サーバは、クライアントがそれに対する接続を確立するエージェントである。
アドレス：例示的な実施例でのホストの固有識別。
分散ＣＯＲＢＡアプリケーション：異なるホスト上に分散し、ＩＤＬ内で定義されたインターフェースを介してＧＩＯＰメッセージを交換する複数のプロセスから構成される。
ＩＤＬ：オブジェクト指向インターフェース記述言語。
ＣＤＲ：共通データ表現。
要求：クライアントからサーバにメソッド呼出しを送る特定のＧＩＯＰメッセージ。
応答：先行する要求に応答して、サーバからクライアントに送られる特定のＧＩＯＰメッセージ。
プロセス：ホスト上のプログラムの記憶エンティティ。
インターフェース：メソッド呼出しの形でサーバ内のエージェントを介してそのエンティティにアクセスすることができるＣＯＲＢＡオブジェクトの、ＩＤＬ内に定義される記述。
デコーダ：ＰＤＵ中に符号化される情報を、含まれるメッセージの可読表現に変換するシステム。この例示的実施例の状況では、これは、本発明による方法を使用するシステムである。
シグニチャ：プログラミング言語によって作り出された用語。同名のメソッドは、パラメータが異なるために相異なる可能性がある。この識別基準がシグニチャと呼ばれる。ＩＤＬは、同じコンテキスト内の同名のメソッドの定義を除外し、それによってメソッドのシグニチャも符号化する必要がなくなる。
ＩＦＲ：インターフェース・リポジトリ。後にアクセスする目的で、ＩＤＬ定義を介して情報を利用可能にするために、ＣＯＲＢＡ標準で定義されるオプション。
【００１７】
図１に、本発明による方法の基本的実施例、具体的には、その実用的な応用例の基本的実施例を示す。分散ＣＯＲＢＡアプリケーション１４の２つのコンポーネント１および１’が通信し、一方のコンポーネント１または１’がクライアント役として動作し、他方がサーバ役として動作する。この２つのコンポーネント１および１’は、異なるホスト・システム上で動作し、その結果インターネットＯＲＢ間プロトコルＩＩＯＰ ２を介してメッセージを送らなければならないと仮定する。このプロセスでは、２つの関係するオブジェクト・リクエスト・ブローカ６間にＴＣＰ／ＩＰ接続１３が確立され、この接続を介して、インターネットＯＲＢ間プロトコル８データ単位（ＩＩＯＰ−ＰＤＵ）が送られる。インターフェース８によって値６の厳密な記述がＯＲＢ ４内のデータ構造の記述を表すいわゆる「タイプ・コード」５の形でオブジェクト・リクエスト・ブローカ４内に存在する間、プロトコル・データ単位の場合にタイプ・コード５の伝送が不要となる。それぞれの他のオブジェクト・リクエスト・ブローカ４中の値が、インターフェース８のＣＤＲデコーダ７を介して復号される。すべての必要な情報、例えば、Ｒｅｑｕｅｓｔ＿ｉｄ、「ターゲット・アドレス」、および呼び出されるメソッドの名前がそこで利用可能であるからである。この情報により、プロトコル・データ単位（ＰＤＵ）をオブジェクトに関連付けることが可能となる。ＧＩＯＰデコーダ３で復号するのに必要なタイプ・コード５は、オブジェクトに関連するインターフェース定義によって決定することができる。ＧＩＯＰデコーダ３は、受動ＣＯＲＢＡアナライザ１１の一部を形成し、ＣＯＲＢＡインターフェース・リポジトリ１０を介してＩＤＬファイル９からも情報を受け取り、ＧＩＯＰメッセージ１２を送達する。
【００１８】
図２に、このようなトレース・ツールが、監視するプロトコル・データ単位（ＰＤＵ）を別の評価のために転送するようにどのように意図されるかを示す。システムの様々な地点、例えば各ホストでのプロトコル・データ単位（ＰＤＵ）の監視は同時に行われる。
【００１９】
図３は、以下で例示によってさらに詳細に説明する方法により、監視するプロトコル・データ単位（ＰＤＵ）、接続パラメータ、および図４による関連するＩＤＬ定義だけに基づいて、一般ＯＲＢ間プロトコル・データ単位（ＧＩＯＰ ＰＤＵ）を図５に示すように完全に復号することが可能となることを示す。
【００２０】
使用する接続指向プロトコル特有の情報により、記録された一般ＯＲＢ間プロトコル・メッセージを、２つの通信するエージェントまたはコンポーネント１および１’と関連付けることが可能となる。さらに、要求で符号化されるターゲット・アドレスを介して、アドレス指定したＣＯＲＢＡオブジェクトを一意的に識別することも可能となる。やはり送られる「応答ｉｄ（Ｒｅｐｌｙ ｉｄ）」により、応答が同じ接続を介して関連する要求として送られることによって、応答を一意的に関連付けることができる。
【００２１】
受動ＧＩＯＰデコーダ３によるプロトコル・データ単位（ＰＤＵ）の分析中に問題が存在する。その解決策を以下で説明する。
【００２２】
ロギングした要求プロトコル・データ単位（要求ＰＤＵ）は、それ自体で呼び出すメソッドの名前だけを含み、そのＩＤＬ定義や、アドレス指定したオブジェクトの下にあるインターフェースの名前を含まない。したがって、プロトコル・データ単位（ＰＤＵ）を復号するために必要な情報が欠けている。図６に示す例示的実施例は、受け取ったプロトコル・データ単位（ＰＤＵ）をＧＩＯＰデコーダ３が常に復号することが可能となる方法を表す。
【００２３】
図６は、ＵＭＬ表現のインターフェース定義を含む。
【００２４】
既に説明したように、メソッド「Ｃｏｕｎｔ」を呼び出したという情報は、インターフェースＡ１、インターフェースＡ２、またはこれらの定義から継承するインターフェース定義のうち１つがアドレス指定したオブジェクト下にあるかどうかを判定するのに十分ではない。メソッドｇｅｔＥｌｅｍの呼出しも、どのインターフェース定義がオブジェクト下にあるかを一意的に判定するのに十分ではない。しかし、他のインターフェース定義は、この方法の範囲内で完全に可能である。したがって、この方法の基本的概念は、プロトコル・データ単位（ＰＤＵ）から導出される個々の不完全な情報の集合を単一オブジェクトごとに個別に収集し、相関させることである。このようにして、復号中に基礎とするインターフェース定義用の十分な選択基準が、複数の必要条件から得られる。
【００２５】
この状況では、単一オブジェクトに関連して、ＧＩＯＰデコーダ３で以下の段階を識別することができる。
１．初期化
すべての可能なインターフェース定義のリストを作成する。このリストは、具体的には、特定のホスト、特定のエージェント、すなわちＧＩＯＰメッセージを送受信することを担当するエンティティ、またはエージェント特有のターゲット・アドレスに関して記憶される。追加の情報が周知でない場合、最も一般的なケースでは、システム全体で使用するすべてのインターフェース定義のリストだけを初期化すべきである。
２．学習
排他基準（ｅｘｃｌｕｓｉｏｎ ｃｒｉｔｅｒｉａ）を使用して、評価されたメッセージをまだ一意的に復号することができない可能性の数を減らす。このような場合、特定のオブジェクト下にある可能性のある複数のインターフェース定義が存在する。
３．復号
どのインターフェース定義がそのオブジェクト下にあるかを一意的に確認した。したがって、オブジェクトと送受信するメッセージを復号することができる。
【００２６】
原理上は、特に段階２と段階３との間に明確な区分はない。段階３から段階２に部分的に戻ることが必要となる可能性がある。段階３にまだ到達していないために復号することができないすべてのメッセージは、単に非復号形式で出力するか、または復号プロセスを後に完了しなければならない可能性がある。特に単純かつ有利な実施例は、始めにすべての記録されたプロトコル・データ単位（ＰＤＵ）と共に段階２を実施し、その後ですべてのこれらのプロトコル・データ単位（ＰＤＵ）を段階３で再度復号することである。
【００２７】
ＩＩＯＰプロトコルに基づいてＣＯＲＢＡオブジェクトを一意的にアドレス指定するために使用する相互運用オブジェクト参照（ＩＯＲ）の交換中、情報がサーバからクライアントに送られる。この情報を得ることにより、ＧＩＯＰメッセージの後の復号をずっと容易にすることができる。しかし、相互運用オブジェクト参照（ＩＯＲ）の交換は、実際に後続のメッセージ交換の前提条件ではあるが、その一部を形成しない。このため、実際のクライアント・サーバ接続に加えて、別のＩＩＯＰ接続を選択的にロギング／トレースし、それを後続の復号に含めることが助けになる。しかし、これにより、解析すべき追加の知識がシステム上に必要となる。これに関して、命名サーバまたは情報リポジトリへの接続が特に興味深い。
【００２８】
請求項に記載の方法の、別の有利な実施例は、アクティブなサーバに関して得られる情報、下にあるインターフェース定義、ならびに選択的なロギング／記録および復号による関連するアドレスが、非システム・クライアント実装に渡されるものである。この手順により、あらかじめオブジェクト参照をロードし、または要求したりせずに、分散アプリケーションの通信で仲裁することが可能となる。これにより、多くのアクティブ・テスト・アプリケーションで共通の問題、すなわちオブジェクト参照が分散アプリケーションの外部で周知でないときにオブジェクト参照を得る問題が回避される。
【００２９】
次に、以下ではある条件におけるいくつかの特殊なケースを説明する。
【００３０】
第１のケースでは、呼出しメソッドおよび関連するインターフェース定義が、インターフェース・リポジトリ（ＩｎｔｅｒＦａｃｅ Ｒｅｐｏｓｉｔｏｒｙ：ＩＦＲ）内に格納されないと仮定する。この状況では、分散アプリケーションで使用されるインターフェース定義のすべてが、ＧＩＯＰデコーダ３のインターフェース・リポジトリ（ＩＦＲ）内に格納されるわけではないと仮定する。このケースでは、インターフェース・リポジトリ（ＩＦＲ）で、メソッドが適切な名前で全く定義されていないと仮定する。したがって、メソッドＡＮＤは要求プロトコル・データ単位（ＰＤＵ）で呼び出され、したがってインターフェース・リポジトリ（ＩＦＲ）（例えばインターフェースＡ、インターフェースＡ１およびＡ２）に存在するインターフェース定義に基づいて、アドレス指定したオブジェクトに対して可能なインターフェース定義の数を制限することができず、このプロトコル・データ単位（ＰＤＵ）の復号に関して情報を得ることもできない。したがって、このプロトコル・データ単位（ＰＤＵ）は、どちらの復号形式でも表すことができない。
【００３１】
第２の特殊ケースでは、ＡｌＳｕｂで定義されるメソッドｇｅｔＥｌｅｍが要求プロトコル・データ単位で符号化されると仮定する。さらに、メソッドｇｅｔＥｌｅｍが同時にＡ２にも定義されると仮定する。議論する要求に関する可能なインターフェース定義の集合内にインターフェース定義Ａ２が依然として存在する場合、ＧＩＯＰデコーダ３は、符号化ＧＩＯＰメッセージを定義Ａ２：ｇｅｔＥｌｅｍを使用して復号できないことを確立することになる。このために、ＧＩＯＰデコーダ３はインターフェースＡ２を除外し、それから継承したすべての定義は、アドレス指定したオブジェクトに対して可能なインターフェース定義の集合に属する。したがってこの例では、定義Ａ２およびＡ２Ｓｕｂは、Ａ２ＳｕｂはＧＩＯＰデコーダ３ではいずれにしても注目されないことを除けば、除外することができる。
【００３２】
第３の特殊ケースＡ３では、呼び出すメソッドおよび関連するインターフェース定義がインターフェース・リポジトリ（ＩＦＲ）内に格納されると仮定する。しかし、それと両立する定義は、別のインターフェース定義内のインターフェース・リポジトリＩＦＲの外部に存在する。メソッドＡ２「Ｓｕｂ：：ｉｓｍｅｍｂｅｒ」を起動する要求は、このメソッドによってインターフェース定義Ａ１に間違って関連付けられる。インターフェース定義Ａ１が、このメソッドを含むインターフェース・リポジトリ（ＩＦＲ）内の唯一の定義であるからである。したがって、正しくプロトコル・データ単位（ＰＤＵ）を復号することが実際に可能であるが、将来の要求は、オブジェクトに対して使用されるインターフェース定義に関する偽データのために復号することができない。この不規則な挙動を除外するため、２つの基本的手順を実装することができる。
１．ＧＩＯＰデコーダ３のオペレータは、分散アプリケーションで使用されるすべてのＩＤＬ定義がインターフェース・リポジトリ（ＩＦＲ）内に格納されることを保証しなければならない。この例で、Ａ２Ｓｕｂがインターフェース・リポジトリＩＦＲ内でも周知であった場合、ここで説明した不規則な判定は生じない。
２．ブロック化リストに基づいて、含まれるメソッド名を介して識別されるある要求を使用してインターフェース定義を除外しないように、ＧＩＯＰデコーダを手動で構成する。
【００３３】
２つの別の特殊ケースＢ１およびＢ２では、要求プロトコル・データ単位（ＰＤＵ）を単一インターフェース定義に一意的に関連付けることができないが、同一のメソッド定義だけが異なるインターフェース定義内で選択用に残されているので、プロトコル・データ単位を事前に復号することができると仮定する。それでも、特殊ケースＢ１では、能力が共通祖先を介して継承されるので復号が可能である。したがって、メソッド定義は等しいだけでなく、同一であり、より厳密なステートメントが可能となるまで定義Ａがオブジェクト下にあると仮定することができる。
【００３４】
特殊ケースＢ２では、共通祖先を用いずに複数のインターフェース定義が可能であると仮定する。したがって、特定のメソッドが実際には共通祖先を介して継承されたのではなく、何回かの定義が存在し、それによってＡ１：Ｘを表したのか、それともＡ２：Ｘを表したのかに関する判定を行うことさえせずに要求を復号することが可能となるケースが生ずる。
【００３５】
最後に、要求を複数の異なるメソッド定義に基づいて復号することができる特殊ケースＣを説明する。定義は互いに異なるので、プロトコル・データ単位（ＰＤＵ）の復号は、各ケースで、結果として異なるメッセージを生成することになる。したがって、プロトコル・データ単位（ＰＤＵ）は、非両立な定義を他のプロトコル・データ単位（ＰＤＵ）に基づいて除外することができる場合にのみ復号することができる。
【００３６】
疑似コードとして単純化形式で表されるメソッドの基本シーケンスを以下で説明する。
【００３７】
話を簡単にするために、ＴＣＰを移送プロトコルとして使用すると仮定する。やはり話を簡単にするために、ＧＩＯＰメッセージ・タイプの要求および応答だけが存在すると仮定する。しかし、このことは、メソッドのオペレーションの基本モードについて何ら変更を行うものではない。
１．次のＴＣＰメッセージを読み取る
２．メッセージ・タイプを判定する
２．１ 要求の場合、３に進む
２．２ 応答の場合、４に進む
３．要求を復号する
３．１ フィールドｉＡｄｄｒＤｅｓｔおよびＤｅｓｔＰｏｒｔからＣＯＲＢＡエージェントを判定する
３．２ ＧＩＯＰコーディングから呼び出すメソッドの名前を判定する
３．３ 使用するｏｂｊｅｃｔ＿ｋｅｙ下の、このエージェントに対するすべてのインターフェース定義のリストを確立する
３．３．１ リストが格納されていない場合、ＩＦＲ内に格納されているすべてのインターフェース定義を含む新しいリストを生成する
３．３．２ リストをロードする
３．４ メソッド名がブロック化メソッドのリスト中にある場合、３．５をスキップし、３．６に進む
３．５ リストを更新する
３．５．１ インターフェース定義で現メソッドが許可されていないすべての要素をリストから除去する
３．５．１．１ メソッドがインターフェース定義のいずれにも格納されていない場合、特殊ケースＡ１が当てはまる。このステップをやり直し、１に進む
３．５．１．２ 現メッセージを復号することができるようにメソッドがインターフェース定義のいずれにも格納されていない場合、特殊ケースＡ２が当てはまる。このケースでは、非両立のメソッドを定義する要素だけを除去し、１に進む
３．５．１．３ このメソッドを非両立に定義するか、または全く定義しないすべての要素を除去する
３．５．２ 更新したリストを格納する
３．６ メッセージを復号する
３．６．１ １つのインターフェース定義だけがリスト内に格納されている場合、このインターフェース定義を取り、メッセージを復号する。３．７に進む
３．６．２ 固有の階層的継承関係がリスト内に含まれるインターフェース定義間に存在する場合、特殊ケースＢ１が当てはまる。この場合、リスト内に含まれる共通祖先のＩＤＬ定義を取る。３．７に進む
３．６．３ それぞれのメソッドがリスト内に含まれるインターフェース定義内に等しく定義された場合、特殊ケースＢ２が当てはまる。この場合、復号のために含まれる任意のＩＤＬ定義を取る。３．７に進む
３．６．４ 特殊ケースＣが当てはまる。メッセージは現在、一意的に復号可能ではない。１に進む
３．７ 応答を復号するための情報を、「ｉＡｄｄｒＳｏｕｒｃｅ」、「ＳｏｕｒｃｅＰｏｒｔ」、「ｉＡｄｄｒＤｅｓｔ」、および「ＤｅｓｔＰｏｒｔ」から構成されるラベルの下に格納する。
３．８ １に進む
４．応答を復号する
４．１ フィールドｉＡｄｄｒＳｏｕｒｃｅおよびＳｏｕｒｃｅＰｏｒｔからＣＯＢＲＡエージェントを決定する
４．２ 関連する要求がｉＡｄｄｒＤｅｓｔ、ＤｅｓｔＰｏｒｔ、ｉＡｄｄｒＳｏｕｒｃｅ、およびＳｏｕｒｃｅＰｏｒｔから構成されるラベルの下に格納されていない場合、１に進む
４．３ 関連する要求をロードする
４．４ 要求のＩＤＬ定義を取り、応答を復号する
４．５ １に進む
【図面の簡単な説明】
【図１】
インターネットＯＲＢ間プロトコル（ＩＩＯＰ）の例による、受動ＧＩＯＰデコーダの使用法を示す図である。
【図２】
ＴＣＰ／ＩＰを介して送られるＧＩＯＰメッセージ用のトレース・インターフェースを表す図である。
【図３】
記録されたＧＩＯＰメッセージの表現である。
【図４】
インターフェースのＩＤＬ定義を示す図である。
【図５】
手動で復号されるＧＩＯＰメッセージを示す図である。
【図６】
階層インターフェース定義のＵＭＬ表現を示す図である。
【符号の説明】
１，１’ ＩＩＯＰを介するクライアント／サーバ分散型ＣＯＲＢＡアプリケーションのコンポーネント
２ ＩＩＯＰインターネットＯＲＢ間プロトコル
３ ＧＩＯＰデコーダ
４ オブジェクト・リクエスト・ブローカ
５ タイプ名またはコード
６ 値
７ ＣＤＲコーダ
８ インターフェース
９ ＩＤＬファイル
１０ ＣＯＲＢＡ ＩＦＲ
１１ 受動ＣＯＲＢＡアナライザ
１２ ＧＩＯＰメッセージ
１３ ＴＣＰ接続
１４ 分散ＣＯＲＢＡアプリケーション
１５ ＧＩＯＰ ＰＤＵを用いたＴＣＰ／ＩＰメモリ・ダンプ
１６ トレース・ツール

Claims (11)

1. ２つのオブジェクト・リクエスト・ブローカ（４）間で通信して、含まれるメッセージの可能な限り完全な表現を得るためのプロトコルの、送信済みプロトコル・データ単位（ＰＤＵ）を解析する方法であって、例えば分散ＣＯＲＢＡアプリケーション（１４）の２つのコンポーネント（１、１’）が互いに通信し、一方のコンポーネント（１、１’）がクライアント役として動作し、他方がサーバ役として動作し、各コンポーネントがどちらも異なるホスト上にインストールされ、
   個々のプロトコル・データ単位（ＰＤＵ）から導出される不完全な情報の集合を、単一オブジェクトごとに個別に収集し、相関させ、
   復号中に基礎とするインターフェース定義用の十分な選択基準が、複数の必要条件から得られ、
   復号を３つの段階で実施し、
   第１段階が、すべての可能なインターフェース定義のリストが作成される初期化段階であり、
   第２段階が、可能性の数を減らすための排他基準が導入される学習段階であり、どのインターフェース定義がオブジェクト下にあるかを一意的に決定し、
   復号段階である第３段階で、オブジェクトと送受信するメッセージを復号する方法。
2. 請求項１に記載の方法において、
   最初に、交換する情報の集合を収集し、それをロギングすることによって排他的受動的に分析し、
   交換した情報の集合（ＰＤＵ）を、分散アプリケーション（１４）で使用されるＩＤＬ定義に基づいて復号し、
   既存のあいまいさの一部を、復号したメソッド名の一意性またはその固有パラメータ表示によって直ちに除外し、
   単一プロトコル・データ単位（ＰＤＵ）で復号された情報を使用して除外することができないあいまいさを、一般ＯＲＢ間プロトコル（ＧＩＯＰＰＤＵ）の複数のプロトコル・データ単位を介して反復的系統的に解決することを特徴とする方法。
3. 請求項１に記載の方法において、
   最初に、すべての記録したプロトコル・データ単位（ＰＤＵ）を用いて段階２を実施し、
   その後で、これらプロトコル・データ単位（ＰＤＵ）のすべてを、段階３で再び復号することを特徴とする方法。
4. 請求項１乃至３のいずれかに記載の方法において、
   使用するインターフェース定義を確立するために、特定のエージェントについての予備段階で、初期可能性の制限を構成し、前記特定のエージェントが、インターネットＯＲＢ間プロトコル（８）では、ＩＰアドレスおよびＴＣＰポート（１３）によって定義されることを特徴とする方法。
5. 請求項１乃至３のいずれかに記載の方法において、
   どのインターフェース定義が使用可能であるかに関する初期可能性を制限するために、特定のホストについての予備段階で構成し、前記特定のホストが、インターネットＯＲＢ間プロトコル（８）では、ＩＰアドレスによって定義されることを特徴とする方法。
6. 請求項１乃至５のいずれかに記載の方法において、
   情報の不足により復号することができないプロトコル・データ単位（ＰＤＵ）をキュー内に置き、
   後で、この情報を他の復号済みプロトコル・データ単位（ＰＤＵ）に基づいて得たときに、これらのプロトコル・データ単位を復号することを特徴とする方法。
7. 請求項１乃至６のいずれかに記載の方法において、
   ブロック化リストに基づいて、含まれるメソッド名を介して定義することができるある要求がインターフェース定義を除外する目的でアクティブとならないことを特徴とする方法。
8. 請求項１乃至７のいずれかに記載の方法において、
   ＧＩＯＰデコーダ（３）の任意選択設定のために、プロトコル・データ単位（ＰＤＵ）の不規則な復号により、必ずしも下にあるインターフェース定義が除外されず、
   正しく復号したメソッドが、時折コーディング・エラーとなる場合であっても依然として復号可能であることを特徴とする方法。
9. 請求項１乃至８のいずれかに記載の方法において、
   オブジェクトの下にあるインターフェース定義に関する情報を供給するＣＯＲＢＡ標準で定義されるメソッドの内容を、アドレス指定したオブジェクトに対する可能なインターフェース定義の数を制限するために評価されることを特徴とする方法。
10. 請求項１乃至９のいずれかに記載の方法において、
    一般ＯＲＢ間プロトコル（ＧＩＯＰ）のロギングしたプロトコル・データ単位（ＰＤＵ）が、インターネットＯＲＢ間プロトコル（ＩＩＯＰ）を介して送られることを特徴とする方法。
11. 請求項１乃至１０のいずれかに記載の方法において、
    一般ＯＲＢ間プロトコル（ＧＩＯＰ）の復号メッセージによって得られる情報が、アクティブ・サーバを介して使用され、非システム・クライアント・アプリケーションを使用してこれらのサーバへの接続が確立され、これらのサーバに対する要求、例えばＣＯＲＢＡ要求が送信されることを特徴とする方法。

Images