JP2005339538A - 分散データモデル - Google Patents

Abstract

【課題】効率的なインターフェースメカニズムを提供する。
【解決手段】送信装置から受信装置にデータを転送する方法は、データの構造の記述を準備するステップと、該記述を送信装置および受信装置に提供するステップと、送信装置及び受信装置のそれぞれにおいて、実行中に、該記述を使用して該データ構造の参照モデルを作成するステップと、要求に応じて、送信装置において、該データで、該参照モデルのインスタンスを作成するステップと、該インスタンスにおけるデータをシリアル化するステップと、該シリアル化されたデータを、送信装置から受信装置に転送するステップと、該参照モデルに基づいて、受信装置において、該データのインスタンスを作成するステップと、を含む。
【選択図】図２

Description

本発明は、データを転送する方法に関する。

ルーターなどのネットワーク装置は、誤伝送や致命的な誤りを極小化するべく、広範囲に試験される。本出願の譲受人であるＡｇｉｌｅｎｔ Ｔｅｃｈｎｏｌｏｇｉｅｓ社のＲｏｕｔｅｒ Ｔｅｓｔｅｒを含む様々な試験装置を市場において入手することができる。これらの試験装置は、通常、シミュレートされた様々な入力に対するルーターの応答を監視する。

ルーティングプロセスとは、簡単に言うと、ノードが、すべての可能な宛先に対する経路を見出すことである、と要約することができる。ルーティングは、レイヤ１（物理レイヤ）から上位のすべてのレイヤに存在している。但し、大部分の人々が慣れ親しんでいるルーティングは、レイヤ３（ネットワークレイヤ）において実行されるものであり、従って本明細書においても、レイヤ３の（および、より具体的には）ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ルーティングのみを指すものとする。ルーターは、テーブルを使用して、パケットを転送すべき場所を判定する。これらのテーブルの更新は、ルーティングプロトコルによって実行される機能の１つである。それぞれのルーターは、１つ又は複数のプロトコルに応答する。

ルーティング情報を交換するプロトコルにより、世界中の複数のルーターが接続され、それらの異種ではあるが一般的には整合性を有しているルーティングテーブルを介して、それらのルーターに、ネットワークの共通のビューが提供される。ルーティングテーブルには、そのサイズとは無関係に、そのネットワーク上のすべての宛先に到達するためにルーターが必要とするすべての情報が保存されている。ネットワークのルーティングテーブルに寄与するよう使用されるルーティングプロトコルには、様々なものがある。ＢＧＰ、ＯＳＰＦ、ＲＩＰ、及びＩＳＩＳなどのプロトコルは、ネットワークの正しく且つ首尾一貫した状況を、該ネットワーク上のすべてのルーターに対して伝達するのに有用である。

既存のルーターテスタ(router tester)は、ネットワーク上に存在するライブデータ(live data)に特有のデータであって、特別に生成されたデータの「試験パケット」を使用し、ネットワークトラフィックをシミュレートする。これらの試験パケットは、被試験ネットワーク上のネットワーク装置に伝送される。トラフィックシミュレータシステム（これには、Ｒｏｕｔｅｒ Ｔｅｓｔｅｒが含まれる）によって試験されるパラメータには、ルーティングの検証、負荷下におけるＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）レベルの達成状況、及び他の装置との正確なインターワーキング(inter-working)が含まれる。又、これらの所謂「パケットブラスタ（Packet blaster）」の多くは、或るプロトコルに従ってメッセージを生成及び伝送することにより、該プロトコルに対し該ネットワーク装置が遵守する能力をも試験する。

図１は、トラフィックシミュレータ試験システム１００のブロック図である。具体的には、このトライフィックシミュレータ試験システム１００は、Ａｇｉｌｅｎｔ Ｔｅｃｈｎｏｌｏｇｉｅｓ社が提供しているＲｏｕｔｅｒ Ｔｅｓｔｅｒを概略的に表している。Ｒｏｕｔｅｒ Ｔｅｓｔｅｒは、ルーター試験システムの一例であり、具体的には、エンタープライズ(enterprise)、メトロ／エッジ(metro/edge)、コアルーティング(core routing)、及び光学ネットワーキング装置の性能を検証するためのマルチポート(multi-port)トラフィック生成、プロトコルエミュレーション、及び分析試験システムとして宣伝されている。このシステムは、一般に、被試験システム（この場合には、ルーター１０４である）に接続された複数のプロトコルエミュレーションカード(protocol emulation card)１０２ｎを有している。これらのプロトコルエミュレーションカード１０２ｎのそれぞれは、一般に、関連するメモリ及びＩ／Ｏを備えたプロセッサを有している。これらのプロトコルエミュレーションカード１０２ｎは、ＷＩＮＤＯＷＳ環境が稼働するＰＣなどのコンピュータ１０６によって制御される。該コンピュータ１０６は、グラフィカルユーザーインターフェースのようなインターフェース１０８に応答する。

プロトコルエミュレーションカード１０２ｎによって生成される試験パケットは、産業界の多くの規格団体によって定義されているような、通信プロトコルの規則及び解釈に従って構築される。使用されている通信プロトコルには、多くのものがあり、新しいプロトコルも継続的に開発されている。通常、新規のプロトコルは、当初、機器製造者によって開発され、実際にはその所有者のものである。多くの場合、該プロトコルは、その後、規格団体によって認可され、産業界において広範に実施されることになる。

トラフィックシミュレータ試験システムに関連する現在のソフトウェアアーキテクチャにおいては、グラフィカルユーザーインターフェース、スクリプティングＡＰＩ、構成（configuration）及び制御コンポーネント、プロトコル状態機械自体を含む、プロトコルエミュレーションによるソリューションのすべての部分をハードコーディングする必要がある。それぞれのプロトコルに必要な該ハードコーディングのために、大量のコードの生成に膨大な量の人的能力が使用されることとなる。このコードの多くの部分は、コンピュータ１０６を、それぞれの新しいプロトコルエミュレーションカード１０２ｎとインターフェースさせるために費やされる。

コンピュータ１０６を、それぞれの新しいプロトコルエミュレーションカード１０２ｎとインターフェースさせるための従来の手法によると、インターフェースを作成してインターフェース記述言語（Ｉｎｔｅｒｆａｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ：ＩＤＬ）によってハードコーディングする時点で、方法および関連パラメータが判明していることが必要である。このような状況下において、新しいプロトコルエミュレーションが作成されたり古いプロトコルが拡張されるたびに、毎回、新しい方法及びパラメータが継続的に生成される。この結果、数百もの方法及びパラメータを含む巨大なＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）が生成され、結果的にコードの集合体が生成され、これは、保守するのに費用を要する。又、既存の方法によれば、結果的に、ＡＰＩがいくつかの異なるレイヤにおいて複製されることになり、この結果、これらの問題が更に悪化することになる。即ち、ＡＰＩに対する個々の変更により（それがどれほど小さなものであったとしても）、システム内における大量のコード及び異なるレベルの更新が必要となる。又、この方法の副次的な影響の１つとして、それぞれのプロトコル及びそのそれぞれの更新について、固有のＧＵＩを生成しなければならないことがある。即ち、ＡＰＩと同様に、プロトコルの数が増大するに伴って、必要なＧＵＩの実装も増大する。

上述の問題のいくつかを軽減する汎用のシステムを設計するべく、現在、努力が傾注されている。その一例が、下記の特許文献１に記述されている。この特許文献１（参照により、本明細書に取り入れられる）においては、外部のＸＭＬプロトコル記述を使用して、汎用のＰＤＵエンコード／デコードエンジンを駆動する。次の段階では、プロトコルエミュレータに対する汎用インターフェースを構築するが、該プロトコルエミュレータは、それぞれの新しいエミュレータ又はそれらの変更のたびに、新しいコード又はハードコーディングされたインターフェースの変更を必要としない。

この問題に対する既存の方法の１つは、ＤＣＯＭ又はＣＯＲＢＡなどのインターフェース記述言語（ＩＤＬ）の使用である。しかしながら、ＩＤＬの場合には、それぞれのインターフェースの詳細がコンパイルの時点において判明していることが必要であるため、適切でないことがわかっている。別の選択肢は、データ構造を定義するための言語であるＡＳＮ．１−ａの使用である。既存のＡＳＮ．１コンパイラは、このような構造をエンコード及びデコードするためのインターフェースコードを生成する。しかしながら、このＡＳＮ．１も、ＩＤＬと同様に、それぞれのインターフェースについて具体的に記述されたコードを必要とするコンパイル時点のソリューションである。更に別の選択肢は、ＤＯＭ（Ｄｏｃｕｍｅｎｔ Ｏｂｊｅｃｔ Ｍｅｄｅｌ）などの、利用可能なＸＭＬデータモデルのうちの１つを使用することである。しかしながら、ＸＭＬデータは、帯域幅の使用が非効率的なテキストファイルとして伝送される。さらに、ＸＭＬデータは、時間のかかる解析を伴い、通常、非常にプロセッサ集約的な演算を必要とする。更には、ＤＯＭ構造のナビゲーションは、低速であり、表データ（これは、プロトコルエミュレータインターフェースにおいて、一般的なものである）を自然に表現することができない。
米国特許出願第１０／２６６，５０７号（公開番号：ＵＳ２００４００６８６８１Ａ１）明細書

したがって、本発明者らは、すべての命令、構成データ、及びプロトコルエミュレーションからの出力を表す能力を有する新しいインターフェースメカニズムのニーズを認識した。更に、このようなメカニズムは、表データと同様に、階層構造データの場合にも十分な能力を有しているのがよい。

本発明の一つの側面によると、送信装置から受信装置にデータを転送する方法は、データの構造の記述を準備するステップと、該記述を送信装置および受信装置に提供するステップと、送信装置及び受信装置のそれぞれにおいて、実行中に、該記述を使用して該データ構造の参照モデルを作成するステップと、要求に応じて、送信装置において、該データによって、該参照モデルのインスタンスを作成するステップと、該インスタンスにおけるデータをシリアル化するステップと、該シリアル化されたデータを、送信装置から受信装置に転送するステップと、受信装置において、該参照モデルに基づいて、該データのインスタンスを作成するステップと、を含む。

本発明の他の側面によると、プロトコルエミュレーションと通信する方法は、プロトコルエミュレーションの制御に必要なデータの構造の記述を準備するステップと、該記述をコントローラおよび前記プロトコルエミュレーションに提供するステップと、コントローラおよびプロトコルエミュレーションのそれぞれにおいて、実行中に、該記述を使用して該データ構造の参照モデルを生成するステップと、要求に応じて、コントローラにおいて、該データによって前記参照モデルのインスタンスを作成するステップと、該インスタンスにおけるデータをシリアル化するステップと、該シリアル化されたデータを、コントローラからプロトコルエミュレーションに転送するステップと、プロトコルエミュレーションにおいて、該参照モデルに基づいて、該データのインスタンスを作成するステップと、を含む。

図面に関連して本発明の実施例に関する以下の詳細な説明を参照することにより、本発明について十分に理解することができよう。

尚、以下の説明においては、要素識別子に隣接して使用されている小文字の「ｎ」は、図面に記述されている（又は、本明細書に記述されている）、要素番号に隣接した他の英子文字により示される特定の要素ではなく、その要素の非特定のインスタンス(instance)を表すものである。

本発明の実施例を参照するが、これらの例は、図面に示されている。これらの図面において、同じ参照符号は同じ要素を示している。以下の詳細な説明においては、コンピュータ可読媒体、関連するプロセッサ、データ生成、及び取得カード、並びにこれらに類似するものにおいて、データビット操作のルーチン及び記号的な表現(symbolic representation)によって実現可能な方法を示す。尚、本明細書においては、また一般的には、ルーチンとは、所望の結果をもたらすステップのシーケンスまたはアクション（動作）であると考えることができ、従って、これには、「プログラム」、「オブジェクト」、「関数」、「サブルーチン」、及び「手順」などの用語が含まれる。これらの記述及び表現は、当業者が自らの研究内容を他の当業者に効果的に伝達するのに使用される手段である。又、わかりやすくするべく、本明細書及び請求項における「ネットワーク」という用語は、通信ネットワーク、ネットワーク装置、他の通信装置、並びに、データの試験パケットを使用して試験可能な通信システムの１つ又は複数の側面のうちの１つ又は複数を示すよう使用されている。

Ａｇｉｌｅｎｔ Ｒｏｕｔｅｒ Ｔｅｓｔｅｒに類似した構成を有するルーターテスタ上の実現を参照して、本発明に従う方法の実施例について説明するが、本明細書に開示する方法は、様々なルーターテスタのうちの任意のものについて動作可能である。より端的に言えば、本明細書に開示されている方法は、特定の装置に本質的に関連づけられるものではなく、本明細書の開示されている手法に従うルーチンを用いて、様々な装置に使用可能である。具体的には、装置間においてデータを転送するための本明細書に記述されている方法は、ルーターテスタ機能に関して記述されているが、データ通信分野に一般的に適用可能である。又、本明細書に記述されている機能を実行することのできる機械には、Ａｇｉｌｅｎｔ Ｔｅｃｈｎｏｌｏｇｉｅｓ， Ｉｎｃ．、Ｈｅｗｌｅｔｔ ｐａｃｋａｒｄ、及びＴｅｃｔｒｏｎｉｘ， Ｉｎｃ．、並びに通信機器の他の製造者などの企業によって製造されるものが含まれる。

又、本明細書に記述されているソフトウェアに関し、当業者であれば、本明細書に概説されている手順を実行するソフトウェアを生成するためのプラットフォーム及び言語には、様々なものが存在することを認識するであろう。本発明の実施例は、Ｃ^＋＋を含むＣの多数の変形のうちのいずれを使用しても実現可能である。但し、当業者であれば、好適なプラットフォーム及び言語の選択肢は、しばしば、構築する実際のシステムの詳細によって決定され、この結果、あるタイプのシステムにおいて動作することができるものが、別のシステムにおいては効果的ではない場合があることをも認識するであろう。又、本明細書に記述されているルーチン及び演算は、コンピュータ上においてソフトウェアとして実行されるものに限定されず、ハードウェアプロセッサ内においても実現可能であることを理解されたい。例えば、ルーチン及び演算を、様々な設計ツールを使用して、ＦＧＰＡにおいて、またはＡＳＩＣにおいて、ＨＤＬ（Ｈａｒｄｗａｒｅ Ｄｅｓｉｇｎ Ｌａｎｇｕａｇｅ）により実現することができよう。

データ転送の方法
図２は、本発明の一実施例に従ってデータを転送する方法を概略的に示すブロック図である。この図示の方法は、第１の場所２００ａから第２の場所２００ｂにデータを転送するためのものである。図１に示されているように、プロトコルエミュレータの場合には、第１の場所２００ａは、制御アプリケーションを実行するコンピュータ１０６（すなわち、「クライアント」）として考えることができ、第２の場所は、サービスアプリケーションを実行するプロトコルエミュレーションカード１０２ｎ（すなわち、「サーバー」）として考えることができる。制御アプリケーションは、データを送受信するための通信ルーチンと共に、グラフィカルユーザーインターフェースを含む。サービスアプリケーションは、データを送受信するための通信ルーチンと共に、プロトコルエミュレーションアプリケーションを含んでいる。

わかりやすくするために、本発明の説明対象の実施例によって使用されるデータ構造を、「パーセル（Ｐａｒｃｅｌ）」と呼ぶ。パーセルとは、命令(command)、構成(configuration)データ、及び任意のルーチンからの出力を表すことのできる、柔軟な、注釈の付加されるデータ構造であると考えることができる。クライアントによって生成されるパーセルには、命令、セッションデータ、及びトポロジー(topology)が含まれることになろう。一方、プロトコルエミュレーションカードによって生成されるパーセルには、統計情報(statistics)、トポロジー、及びメッセージトレース(message trace)が含まれることになろう。

図２に示されている転送方法は、パーセル定義２０２ａから始まっている（尚、これは、本明細書においては、「定義(definition)」又は「記述(description)」とも呼ばれる）。パーセル定義２０２ｎは、１つ又は複数のパーセルの要素(element)の記述を、その属性と共に提供する。好適なパーセルのデータ構造は、階層構造であり、ここで、それぞれのノードは、値(value)、サブノード、関数(function)、値の配列(array)、又は値の表(table)を含むことができる。パーセル定義２０２ａは、パーセルのリストを提供すると共に、それぞれのパーセル、それぞれのノードのタイプ、及びノード間の相互関係を備える要素（ここでは、「ノード」と呼ぶ）を規定するテキストファイルと同程度に単純なものであってよい。また、それぞれのノードに、記述属性（descriptive attribute, この例については、後述する）を使用して、注釈を付加することができる。

パーセル定義２０２ａを、ＸＭＬによって作成することが望ましいが、必ずしもこの必要はない。より具体的には、生成とその変更を容易にするべく、容易にアクセス可能なフォーマットで、パーセル記述をフォーマットするのが望ましい。ＸＭＬが提供するネストタグ構造(nested tag structure)によれば、階層関係構造および表構造の文書化を、容易に行うことができる。パーセル定義２０２ａは、一般に、第１の場所２００ａに保存され、第１の場所２００ａにおいて稼働するアプリケーションによって実行（ランタイム）時に抽出される。

パーセル定義２０２ａを解析し、パーセル参照モデル２０４ａを生成する（これは、「参照モデル」とも呼ばれる）。一般に、パーセル参照モデルは、Ｃ^＋＋などによるデータ構造であり、ここから、パーセルのインスタンス（例：パーセルオブジェクト２０６ｂ）を生成することができる（即ち、インスタンス化する(instantiate)ことができる）。恐らく、最も近い類似した構造は、Ｃ^＋＋における汎用タイプ（generic type）であろう。１つの相違点は、該汎用タイプは、コンパイル時に定義されなければならないが、パーセルは、実行中に導入されることができる。パーセルの場合には、そのタイプが、実際のパーセルが導出される元となる参照モデル２０４ａによって定義される。使用の際には、動作中に必要となりうるすべての潜在的なパーセルの参照モデルを生成するよう、システムの起動時に、すべてのパーセル定義２０２ｎを解析することが有益であろう。但し、時間と記憶容量を考慮する必要がある場合には、現在のセッションに必要とされるであろう参照モデルのみを生成することが推奨されよう。

パーセルデータを取り扱う汎用インターフェースを提供することのできるＰａｒｓｅｌ ＡＰＩ（後述される）を使用して、パーセルオブジェクトを管理することができる。本発明の場合には、パーセルを取り扱う方法の１つは、第２の場所２０２ｂに伝送するためにそれらをシリアル化することである。保存／回復を目的とした適切なＸＭＬを含む様々なフォーマットであって、他の場所との通信に好適なバイナリフォーマットに、パーセルをシリアル化することができる。概念的には、シリアル化とは、データ構造からのデータの採取と、伝送のための線形ファイル又はデータストリームの形成であると考えることができる。受信側で該バイナリストリームをデコードして該パーセルを復元するのに使用される参照モデル２０４ｎを識別することのできるデータ構造が提供される。この再構築中に、参照モデル２０４ｎに含まれている構造的な情報を使用し、該バイナリストリーム内のデータを解析する。

従って、第２の場所２００ｂには、パーセル定義２０２ａのコピー（パーセル定義２０２ｂとして示されている）が提供される。第２の場所２００ｂは、このパーセル定義２０２ａを解析して参照モデル２０４ｂを生成する（これは、参照モデル２０４ａのコピーのはずである）。第２の場所２００ｂは、バイナリデータ２０８を受信した際に、このパーセル参照モデル２０４ｂをインスタンス化し(instantiate)、結果として生成されたデータ構造に、このバイナリデータ２０８を実装する(populate)ことにより、パーセルオブジェクトを形成する。

類似のプロセスを使用して、パーセルオブジェクトを形成することができる。パーセル定義２０２ａを使用し、該定義された要素のそれぞれについて、例えば、テキスト入力フィールドやラジオボタンなどの適切な入力メカニズムを有するグラフィカルユーザーインターフェースを生成する。ユーザーが所望の入力データを供給すると、参照モデル２０４ｎがインスタンス化され、パーセルオブジェクト２０６ｎに、その入力データが実装される。パーセル定義２０２ｎが提供されているパーセルオブジェクト２０６ｎの生成及び管理を取り扱うことのできる汎用ＡＰＩを考案するのが有利である（この例については、後程開示する）。

ＩＤＬに基づいたソリューションとは対照的に、パーセルは、コンパイルされるコードの外部において定義されると共に、新しいパーセルの定義に伴って変更する必要のない汎用のＡＰＩを使用する。この結果、アプリケーションフレームワークを変更又は増大させることなしに、将来のプロトコルソリューションに対応可能なアプリケーションフレームワークを構築することができる。又、この結果、第三者又は顧客の独自のソリューションを構築するために、該第三者または顧客にとって安定したインターフェースを生成することも可能である。従来のＸＭＬソリューションとは対照的に、パーセル構造は、受信したデータパケットごとにではなく、前もって一度だけ定義されるのみである。必要なパーセル参照モデルを、アプリケーションの起動時点において構築することができ、よって、ＸＭＬを継続的に解析する必要性を軽減することができる。パーセルは、効率的なナビゲーションを実現するよう設計されることができ、ＸＭＬ ＤＯＭと比べ、サーチ(searching)が最小化される。パーセルは、効率的なバイナリエンコーディング（符号化）及びデコーディング（復号化）を実現するよう設計されることができ、ＸＭＬテキストと比べて、ソフトウェアシステム間の通信に要するバイナリデータパケットは相対的に小さい。又、パーセルは、表データを含むよう設計されることができ、多くのアプリケーションに対して無理なく適合することができる。

プロトコルエミュレータにおけるパーセルの使用
図３は、本発明の好適な一実施例に従うプロトコルエミュレーションシステム３００のブロック図である。このシステム３００は、一般に、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓシステムの或るバージョンが稼働しているパーソナルコンピュータなどのホスト３０２と、少なくとも１つのプロトコルエミュレータカード３０４（これは、プロトコルエミュレータとも呼ばれる）とを備える、該カード３０４は、一般に、関連するメモリ及びＩ／Ｏ機能を有するプロセッサを備えている。プロトコルエミュレータが、アーキテクチャにおいて、パーソナルコンピュータに似ていることが有益であろう。少なくとも１つの実施例によれば、ホスト３０２は、クライアントとして構成されることができ、プロトコルエミュレータ３０４は、サーバーとして構成されることができる。

ホスト３０２は、他のアプリケーション及びオペレーティングシステムと共に、アプリケーション３０６を実行しており、該アプリケーション３０６は、プロトコルエミュレータ３０４の制御、特に、プロトコルエミュレータカード３０４との通信のためのルーチンを提供する。少なくとも１つの実施例によれば、このアプリケーションは、汎用のプロトコル独立型アプリケーションである。これは、アプリケーション３０６が、好ましくは、プロトコル固有の機能を欠いていることを意味している。このようなプロトコル固有の機能は、実際には、パーセル定義２０２ｎを使用して動的に生成される。アプリケーション３０６は、パーセル参照モデル２０４ｎ（図２を参照されたい）の生成、保守、及び使用と共に、該参照モデルのインスタンス（例：パーセルオブジェクト２０６ｎ）に含まれるデータのシリアル化、送信、受信、及びデシリアル化(de-serialization)の責任を担っている。前述のように、これらの機能に対して、ＡＰＩに類似したインターフェースを提供することができ、これにより、それぞれの異なるプロトコルエミュレーションに、単一の汎用インターフェースを提供するようにすることが好ましい。

グラフィカルユーザーインターフェース３１０を提供し、これにより、ユーザーがプロトコルエミュレーションの起動を要求した際に、アプリケーション３０６が、グラフィカルユーザーインターフェース３１０を介してクライアント３０２とやり取りし、プロトコルエミュレータ３０４の制御に必要なパラメータを入力するためのフォームを表示するようにする。これは、パーセル定義２０２ｎ又はパーセル参照モデル２０４ｎ（図２を参照されたい）を使用して実現されることができる。適切なデータの入力が完了すると、アプリケーション３０６は、参照モデル２０４ｎのインスタンスを生成し、パーセルオブジェクト２０６ｎを形成する。アプリケーション３０６は、このパーセルオブジェクト２０６ｎをシリアル化し、シリアル化されたオブジェクトをプロトコルエミュレータ３０４に送信する。

プロトコルエミュレータ３０４は、他のアプリケーションと共に、アプリケーション３０８を実行しており、該アプリケーション３０８は、選択されたプロトコル３０９ｎのエミュレーション用のモジュールを含む。少なくとも１つの好適な実施例によれば、アプリケーション３０８は、パーセルを使用してホスト３０２と通信するためのルーチンを含む。一般的には、アプリケーション３０６に含まれているものに類似したルーチンを、アプリケーション３０８が含むことが好ましい。これは、パーセルとインターフェースする、ＡＰＩに類似した汎用ルーチンを生成することによって実現されることができる。このようなルーチンの例については、後程提供される。

プロトコルエミュレータ３０４には、パーセル定義２０２ｎの更新済みのコピーが定期的に提供される。ホスト３０２が、起動の際に毎回、定義２０２ｎをプロトコルエミュレータ３０４に提供することが有益であろう。プロトコルエミュレータ３０４は、このパーセル定義２０２ｎを受信した際に、パーセルオブジェクト２０６ｎがインスタンス化されることのできる元となる一組のパーセル参照モデル２０４ｎを生成する。ホスト３０２から、シリアル化されたパーセルオブジェクトを受信した際に、関連するパーセルオブジェクト２０６ｎに基づいて、新しいパーセルオブジェクトがインスタンス化される。次いで、このオブジェクトを使用し、プロトコルエミュレータ３０４上で稼働するプロトコルエミュレーションルーチンによって必要とされるデータを提供する。このように、プロトコルエミュレータ３０４に新しいプロトコルエミュレーションを追加する際、ホスト３０２とプロトコルエミュレータ３０４（及びモジュール３０９ｎ）間の通信を可能にするのに定義する必要のあるのは、新しいパーセル定義２０２ｎのみである。

パーセル
以下の説明は、パーセルの一実施例に焦点を合わせているが、当業者であれば、ここで説明されるパーセル構造に対する変更も可能であり、それらも依然として本発明の範囲に属することを認識するであろう。ここで説明される実施例においては、パーセルは、一般に、ヘッダと、一組の要素(element)と、を有している。一組の要素は、一般に、構造(structure)を提供するコンテナ(container)要素と、１つの値又は一連の値を保存するデータ要素という２つのカテゴリに分かれている。表１には、パーセルの一組の要素（「ノード」でない）のタイプの一例が示されている。

それぞれの要素には、記述属性を使用して注釈を付加することができる。このような属性は、パーセルを文書化し、よって、パーセルが自己文書化（Ｓｅｌｆ−ｄｏｃｕｍｅｎｔｉｎｇ）することを可能にする。これらの属性を、パーセル定義や、（ことによると）パーセル参照モデルと共に保存することにより、パーセルを操作し且つこれとインターフェースするよう提供されるルーチンを、本質的に汎用的なものにすることができる（例えば、データ構造は、ルーチン内にコーディングされるのではなく、実行中に提供される）。例えば、これらの属性を使用することにより、汎用的なグラフィカルユーザーインターフェースを使用した任意のパーセルの提示及び編集に必要なすべての情報を提供することができる。表２には、可能な属性のいくつかの例が示されている。当業者であれば、この表２のリストがすべてを網羅してはおらず、本発明の実現形態に応じて、他の属性も有益であることを認識するであろう。

表３には、ＸＭＬによるパーセル定義の一例が含まれている。具体的には、表３には、「ａｄｄＩｐｖ４ＲｏｕｔｅＰｏｏｌ」と「ａｄｄＩｐｖ６ＲｏｕｔｅＰｏｏｌ」という２つの命令（command）と共に、「ｂｇｐＳｅｓｓｉｏｎＤａｔａ」と「ｒｏｕｔｅＰｏｏｌｓ」という２つのパーセルの定義が含まれている。パーセル「ｂｇｐ」は、ｂｇｐエミュレーションセッションを生成するのに必要な起動データを定義する。一方、パーセル「ｒｏｕｔｅＰｏｏｌｓ」は、ルーティングプロトコルによって公にされる、到達可能な一組のアドレスを定義する。「ｒｏｕｔｅＰｏｏｌｓ」内には、２つの表が定義されている（１つは、Ｉｐｖ４アドレス、もう１つは、Ｉｐｖ６アドレスに関するものである）。アドレスの範囲は、開始アドレス(start address)、プレフィックス長(prefix length)、及びカウント(count)を使用して、パラメータ的に定義されている。命令は、「ｒｏｕｔｅＰｏｏｌｓ」パーセルを参照し、その内容を実装する。これらの命令は、ルートプール(route pool)表から選択された行を、パラメータとして使用する。

要素には、しばしば、定義の内外において規定された他の値に応じて、異なる既定値を設定する必要がある。このような場合には、この種のタスクを実行するよう呼び出されることができるＴＣＬ（Ｔｏｏｌ Ｃｏｍｍａｎｄ Ｌａｎｇｕａｇｅ）手順を内蔵(integration)することが有益であろう。このような機能を、ＸＭＬパーセル定義内に指定することができる。当業者であれば、このＴＣＬ内蔵を実行することができるであろうから、本明細書においては、この内蔵の具体的な詳細に関する説明は省略する。表４には、このＴＣＬ機能を内蔵するパーセル定義の一部の例が示されている。

この例においては、「ｈｏｌｄＴｉｍｅｒ」にどのような値が設定された場合にも、「ｋｅｅｐａｌｉｖｅ」の既定値は、「ｈｏｌｄＴｉｍｅｒ」の二倍に維持される。このＴＣＬ機能は、パーセルをインスタンス化する際（例：パーセルのインスタンスの生成）に実行されることができる。又、パーセル定義及び／又はモデルをレビューし、実行中にこのような機能によって影響を受ける値を更新するためのルーチンを生成することもできる。

パーセルの取り扱い
図４は、本発明の一実施例に従ってパーセル参照モデル２０４及びパーセルオブジェクト２０６を生成するためのパーセル定義２０２の使用を示すブロック図である。一般的に言えば、参照モデル２０４は、データ構造の詳細を含むすべてのパーセル属性のリポジトリ(repository)として機能する。尚、この説明対象の実施例の場合には、該構造に、階層構造ノードと基本表が含まれるが、本発明は、これらの構造に限定されるものではなく、例えば、リレーショナルな構造を含むように拡張することもできる。又、この参照モデル２０４により、パーセル間又はパーセルノード間におけるＸＭＬ内のすべての相互参照（クロスレファレンス）が解決される。

図５は、パーセルオブジェクト２０６を生成する方法のフローチャートである。この方法は、ステップ５００において始まる。次いで、ステップ５０２において、利用可能なＸＭＬパーセル定義ファイル（例：パーセル定義ファイル２０６）の＜ｐａｒｃｅｌ＞タグが読みとられ、ファイルに対する該タグ名のルックアップテーブルを構築する。

ステップ５０４において、パーセル参照モデル２０４がまだ形成されていないパーセルオブジェクト２０６が要求されているならば、本方法は、ステップ５０６に進む。一方、そうでない場合には、本方法は、後述するステップ５１４に進む。ステップ５０６において、ステップ５０２において構築されたルックアップテーブルを読み取り、要求されているパーセルオブジェクト２０６に対応するＸＭＬファイルを識別する。次いで、ステップ５０８において、該識別されたＸＭＬファイルを、例えば、ｅｘｐａｔなどのパブリックドメインのＸＭＬパーサー(parser)を使用して解析する。このＸＭＬパーサーは、Ｃ＋＋タグオブジェクトのベクトルを生成し、該ベクトルは、ステップ５１０における関連参照モデル２０４の構築に使用される。

図４に示されている例を参照すると、参照モデル２０４には、最上位レベルノードであるセット（１）が含まれており、これに、表ノード（２）と値ノード（６）が含まれている。そして、表ノード（２）は、値ノード（３）、配列ノード（４）、及び値ノード（５）という３つのノードを含む。この例のパーセルオブジェクト２０６においては、表ノード（２）の３つの行を生成することにより、１２個のノードが生成される。

起動時にすべてのＸＭＬファイルを解析し、セッション全体についてすべてのモデルが利用可能となるようにすることが有益であろう。但し、所与の試験セッションに必要とされるのがパーセルのサブセットのみである場合があり、この場合には、これは不要であろう。従って、図５に関連して説明する要求に基づいて解析することが有益であろう。

ステップ５１２において、マップを作成し、該マップを、参照パーセルオブジェクト（即ち、名前によってインデックス付けされた、参照モデル２０４によって記述されるパーセルオブジェクト）のマップを維持している参照モデル２０４と関連付ける。このことは、単一の参照モデル２０４が複数の参照パーセルオブジェクトの記述が含むことがあるため、望ましい。パーセルオブジェクト２０６がインスタンス化されるとき、このマップを使用することにより、所望のパーセルを記述する適切な参照モデル２０４（又は、その一部）を抽出することができる。

次いで、ステップ５１４において、パーセルオブジェクト２０６を構築するルーチンに対し、この参照モデル２０４を渡す。この結果、関連する参照モデル２０４から、新しいパーセルオブジェクト２０６が作成される（実際には、インスタンス化される）。一般に、パーセルオブジェクト２０６は、関連する参照モデル２０４を示すヘッダと、その参照モデル２０４内に記述されている要素に関係するデータを保持するためのデータ構造を有している。最初に作成されるときは、このデータ構造に、（提供されている場合には）属性内に定義されている既定値を実装する(populate)ことができる。値は、必要に応じて、ユーザー又は他のルーチンによって更新又は入力可能である。

パーセル２０６内のそれぞれのノードは、対応する参照パーセルノードを有している。しかしながら、表の存在は、その対応関係が必ずしも１対１ではないことを意味している。これは、パーセルオブジェクト２０６が、特定のノードについて、複数のインスタンス（テーブル内の行ごとに１つずつ）を有することがあるためである。尚、パーセルオブジェクト２０６は、参照モデル２０４内に含まれている属性情報を含む必要はない（但し、含んでもよい）。必要な場合には、参照パーセル２０４から属性情報を取得することができる。

パーセル内のそれぞれのノードにインデックスを割り当てることにより、パーセルオブジェクト２０６のノード間における効率的なナビゲーションを容易化することができる。図４のそれぞれのノード内の括弧内の数字は、このインデックス付けシステムの例を示している。参照モデル２０４において、それぞれの参照ノードには、インデックスが割り当てられている。セット又は表などのコンテナであるそれぞれの参照ノードは、そのメンバノードのインデックスを記録するよう構成されることができる。パーセルオブジェクト２０６内のそれぞれのノードは、その対応する参照ノード２０４と同一のインデックスを取得する。パーセルオブジェクト２０６内のアクティブ(active)ノードのパーセルインデックスのベクトルを、該オブジェクト内のノードの効率的なナビゲーションのために使用することができる。それぞれのアクティブノードは、そのインデックスを該ベクトル内に記録する。表の場合には、その表の現在の（又は選択された）行を指定することにより、複数の行（従って、ノードインスタンス）の存在を管理することができる。行を選択するとき、選択された行におけるノードは、自らをパーセルインデックスベクトルに登録する。こうして、現在の行におけるノードのみをナビゲートすることができる（ノードにアクセスすることができるようになる前に、行を選択する必要がある）。

パーセル定義をパーセルモデルに変換するプロセスについて十分に理解することができるように、以下に表を提示する。表５は、部分的なパーセル定義（３つの個別のパーセルが含まれている）を示しており、表６は、表５に含まれているパーセル定義に基づいた参照モデル(reference model)の概念的な例である。

実際に、パーセルは、自己文書化データモデルであるため、一群の汎用ルーチンを、該パーセルとインターフェースをとるよう定式化(formulate)することができる。このようなルーチンは、その機能の観点から、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）と考えることができる。パーセルの作成（例：インスタンスの作成）、パーセルの読み取り、及びパーセルの書き込みのためのルーチンを提供することが望ましい。表７には、読み取り及び書き込みインターフェースを含む、パーセルに対する汎用インターフェースを、自己文書化コードを使用して記述したルーチンの例が提供されている。

パーセルの管理のための一連のルーチンを提供することが好ましい。このような管理は、クライアントアプリケーション（例：図３に示されている実施例におけるホスト３０２及びプロトコルエミュレータカード３０４）によって提供されることができる。但し、クライアントアプリケーションによってリンクされることのできる管理ルーチンのコレクション（collection,集まり）を提供することが有益であり、本明細書においては、このようなルーチンをパーセルストア(parcel store)と集合的に呼ぶことにする。好ましくは、パーセルストアは、パーセルを使用して通信するそれぞれのソフトウェアコンポーネントによって提供される。一例として、パーセルストアは、クライアントに代わってのパーセルの作成、パーセルのエンコーディング（符号化）及び宛先パーセルストアへの送信（例：シリアル化）、別のパーセルストアから到来したパーセルのデコーディング（復号化）及びバッファリング、及び新しいパーセルデータが利用可能な場合のクライアントへの通知の責任を担うことができる。表８には、パーセルストアに対するインターフェース用の自己文書化コードの例が提供されている。

メッセージングシステムにおいて望ましい前述のパーセルストアの基本機能の１つが、バッファリングである。一般に、バッファリングとは、パーセル内に含まれている情報を処理するための受信（又は、送信）システムの準備が整うまで、パーセルを一時的に保持することを意味している。例えば、ホストの負荷を最小にすることが必要な場合には、クライアントは、送信側において、バッファからパーセルをプル(pull)することができる。代替的に、受信側の様々なタイプのバッファに対して送信側がパーセルをプッシュ(push)し、応答性を最適化することができる。ＸＭＬパーセル定義内においてバッファのタイプを規定し、パーセル参照モデルに知らしめることができる。代替的に、シリアル化されたパーセル内の情報に基づいて、該タイプを判定することもできる。クライアントインターフェースに影響を与えたり、ソフトウェアの再作成や再コンパイルを必要とすることなしに、ＸＭＬにおけるパーセルバッファタイプを調節することにより、アプリケーションの性能をチューニングすることができる。

表９には、適切なバッファタイプのいくつかの例が開示されている。

帯域幅を節約すべく、送信の前に、パーセルをシリアル化することができる。尚、一般に、本明細書において使用されているこの「シリアル化」という用語は、パーセル内のデータを採取し(strip)、（通常は、要素のそれぞれのインデックスに基づいて）シリアルに配列するプロセスを意味している。受信側においてパーセルを再構築することができるように、シリアル化されたパーセルのヘッダ内に最小限の量の識別情報を提供する。表１０には、パーセルの様々な要素のシリアル化について可能な１つのプロセスが記述されている。

その他
以上、本発明の特定の実施例について説明してきたが、当業者であれば、本発明の原理と精神を逸脱することなしに、これらの実施例に変更を加えることができるということは、理解されたい。従って、本発明の範囲は、請求項及びその等価なものに規定されているとおりである。

例えば、定義及び参照モデルを含むパーセル構造を使用する利点の１つは、グラフィカルユーザーインターフェース（ＧＵＩ）要素の構築を自動化することができるという点にある。換言すれば、パーセルの内容を、パーセル自体に基づいて導出されるフォーマットを使用して表示することができる。パーセル定義又は参照モデルを解析することにより、その場でインターフェースを構築することができる。このようなインターフェースを、パケットの内容を参照したり、パケットの作成及び編集に用いることができる。

図６は、表１１に含まれているパーセル定義内に定義される表構造に基づいて構築されたインターフェースを示している。

図７は、表１２内に含まれているパーセル定義内に定義された値のセットに基づいて構築されたインターフェースを示す。図７の場合には、定義内に記述されているデータの階層構造特性を強調するよう、ツリー構造が選択されている。

本発明の原理と精神を逸脱することなく、これらの実施例に加えることができる変更の別の例は、パーセルインスタンスを反復的に作成する機能の提供である。例えば、パーセル間において１つ又は複数の値が異なる一連のパーセルが所望される場合には、該反復機能を提供することにより、＋１などの相対的な関係で、それらのパーセル値を定義することができる。こうして、パーセルの反復を使用することにより、単一のパーセルを使用して多くの異なるパーセルをパラメータによって生成することができる。プロトコルエミュレーションアプリケーションの例を用いると、１つのセッションのパーセルのみを使用して定義された、多くのセッションからなるセッションプールを作成することが、望ましい場合がある。これは、既定の増分（インクリメント）属性によってＸＭＬモデル内の所定の値にタグ付けすることにより、実装されることができる。即ち、この増分を使用して、パーセルのそれぞれの反復におけるそれぞれの値を調節する。例えば、値には、「１０」の既定の増分を指定することができる。第１パーセルにおいて値が５０の場合には、パーセルを１回反復すれば、値は６０になり、パーセルを２回反復すれば、値は７０になる。又、この既定の増分は、増分関数によって算出することもできる。これにより、パーセル内の他の値に基づいて、該既定の増分値をインテリジェントに割り当てることができる。

トラフィックシミュレータ試験システムのブロック図。 本発明の実施例に従ってデータを転送する方法を概略的に示すブロック図。 本発明の好適な実施例に従う、プロトコルエミュレーションシステムのブロック図。 本発明の実施例に従う、パーセル参照モデルとパーセルオブジェクトを作成するためのパーセル定義の使用を示すブロック図。 パーセルオブジェクトを作成する方法のフローチャート。 パーセル定義内に定義されている表構造に基づいて構築されたインターフェースの画面キャプチャ(screen capture)。 パーセル定義内に定義されている値のセットに基づいて構築されたインターフェースの画面キャプチャ。

符号の説明

２０２ パーセル定義
２０４ 参照モデル
２０６ パーセルオブジェクト

Claims (45)

1. 送信装置から受信装置にデータを転送する方法であって、
   前記データの構造の記述を準備するステップと、
   前記記述を、前記送信装置および前記受信装置に提供するステップと、
   前記送信装置及び受信装置のそれぞれにおいて、実行中に、前記記述を使用して前記データ構造の参照モデルを作成するステップと、
   要求に応じて、前記送信装置において、前記データによって、前記参照モデルのインスタンスを作成するステップと、
   前記インスタンスにおける前記データをシリアル化するステップと、
   前記シリアル化されたデータを、前記送信装置から前記受信装置に転送するステップと、
   前記受信装置において、前記参照モデルに基づいて、前記データのインスタンスを作成するステップと、
   を含む、方法。
2. 前記データの構造の記述を準備する前記ステップは、前記データ構造を記述するＸＭＬファイルを作成することを含む、
   請求項１に記載の方法。
3. 前記データの構造の前記記述は、外部プロセスに対する呼び出しを含む、
   請求項１に記載の方法。
4. 前記データの構造の前記記述は、前記データ構造内の他の値に基づく値を含む、
   請求項１に記載の方法。
5. 前記データの構造の記述を準備する前記ステップは、階層構造で前記データを記述することを含む、
   請求項１に記載の方法。
6. 前記データの構造の記述を準備する前記ステップは、表を使用して前記データを記述することを含む、
   請求項１に記載の方法。
7. 前記データの構造の記述を準備する前記ステップは、階層構造で、表を使用し、前記データを記述することを含む、
   請求項１に記載の方法。
8. 前記データの構造の記述を準備する前記ステップは、値、配列、セット、表、およびキーが付けられた表などの定義された要素を使用して、前記データを記述することを含む、
   請求項１に記載の方法。
9. 前記データの構造の記述を準備する前記ステップは、値を保持するための要素または他の要素、および、該要素の属性を定義することを含む、
   請求項１に記載の方法。
10. 前記属性は、前記要素の記述名、前記要素の記述、前記要素の長さ、前記要素の提示フォーマット、および、前記要素の可能な値の範囲を含む、
    請求項９に記載の方法。
11. 前記参照モデルを作成する前記ステップは、
    前記データのそれぞれの要素について、ノードを作成するステップと、
    前記参照モデルの前記ノードに、インデックス付けするステップと、
    を含む、請求項１に記載の方法。
12. 前記データをシリアル化する前記ステップは、該データの要素が取得された前記ノードの前記インデックスに基づいて、線形に該データを順序付けすることを含む、
    請求項１１に記載の方法。
13. 前記データをシリアル化する前記ステップは、該データの要素が取得された前記ノードの前記インデックスに基づいて線形に順序付けされた該データで、バイナリファイルを作成することを含む、
    請求項１に記載の方法。
14. 前記データをシリアル化する前記ステップは、ＸＭＬファイルを作成することを含む、
    請求項１に記載の方法。
15. プロトコルエミュレーションと通信する方法であって、
    前記プロトコルエミュレーションの制御に必要なデータの構造の記述を準備するステップと、
    前記記述を、コントローラおよび前記プロトコルエミュレーションに提供するステップと、
    前記コントローラおよび前記プロトコルエミュレーションのそれぞれにおいて、実行中に、前記記述を使用して前記データ構造の参照モデルを生成するステップと、
    要求に応じて、前記コントローラにおいて、前記データによって前記参照モデルのインスタンスを作成するステップと、
    前記インスタンスにおける前記データをシリアル化するステップと、
    前記シリアル化されたデータを、前記コントローラから前記プロトコルエミュレーションに転送するステップと、
    前記プロトコルエミュレーションにおいて、前記参照モデルに基づいて、前記データのインスタンスを作成するステップと、
    を含む、方法。
16. 前記データの構造の記述を準備する前記ステップは、前記データ構造を記述するＸＭＬファイルを作成することを含む、
    請求項１５に記載の方法。
17. 前記データの構造の前記記述は、外部プロセスに対する呼び出しを含む、
    請求項１５に記載の方法。
18. 前記データの構造の前記記述は、前記データ構造内の他の値に基づく値を含む、
    請求項１５に記載の方法。
19. 前記データの構造の記述を準備する前記ステップは、階層構造で前記データを記述することを含む、
    請求項１５に記載の方法。
20. 前記データの構造の記述を準備する前記ステップは、表を使用して前記データを記述することを含む、
    請求項１５に記載の方法。
21. 前記データの構造の記述を準備する前記ステップは、階層構造で、表を使用し、前記データを記述することを含む、
    請求項１５に記載の方法。
22. 前記データの構造の記述を準備する前記ステップは、値、配列、セット、表、およびキーが付けられた表などの定義された要素を使用して、前記データを記述することを含む、
    請求項１５に記載の方法。
23. 前記データの構造の記述を準備する前記ステップは、値を保持するための要素または他の要素、および該要素の属性を定義することを含む、
    請求項１５に記載の方法。
24. 前記属性は、前記要素の記述名、前記要素の記述、前記要素の長さ、前記要素の提示フォーマット、および前記要素の可能な値の範囲を含む、
    請求項２３に記載の方法。
25. 前記参照モデルを作成する前記ステップは、
    前記データのそれぞれの要素について、ノードを作成するステップと、
    前記参照モデルの前記ノードにインデックス付けするステップと、
    を含む、請求項１５に記載の方法。
26. 前記データをシリアル化する前記ステップは、該データの要素が取得された前記ノードの前記インデックスに基づいて、線形に該データを順序付けすることを含む、
    請求項２５に記載の方法。
27. 前記データをシリアル化する前記ステップは、該データの要素が取得された元の前記ノードの前記インデックスに基づいて線形に順序付けされた該データで、バイナリファイルを作成することを含む、
    請求項１５に記載の方法。
28. 前記データをシリアル化する前記ステップは、ＸＭＬファイルを作成することを含む、
    請求項１５に記載の方法。
29. さらに、
    要求に応じて、前記プロトコルエミュレーションにおいて、データの第２のセットによって前記参照モデルのインスタンスを作成するステップと、
    前記インスタンスの前記データの第２のセットをシリアル化するステップと、
    前記シリアル化されたデータの第２のセットを、前記プロトコルエミュレーションから前記コントローラに転送するステップと、
    前記コントローラにおいて、前記参照モデルに基づいて、前記データの第２のセットのインスタンスを作成するステップと、
    を含む、請求項１５に記載の方法。
30. 前記データは、命令、セッションデータ、およびトポロジーのうちの少なくとも１つを有する、
    請求項１５に記載の方法。
31. 前記データの第２のセットは、統計情報、トポロジー、およびメッセージトレースのうちの少なくとも１つを有する、
    請求項２９に記載の方法。
32. 前記作成するステップは、前記コントローラにおいて、前記データによって前記参照モデルの複数のインスタンスを作成することを含み、それぞれの該インスタンスは、ユーザーによって提供される指示に基づいて変化する、
    請求項１５に記載の方法。
33. データを転送するシステムであって、
    一組のデータの構造の記述を含むクライアントコンピュータと、
    実行中に、前記記述を使用して前記構造の参照モデルを作成し、要求に応じて、該一組のデータが実装された前記参照モデルのインスタンスを作成する、前記クライアントコンピュータ上において動作可能なソフトウェアと、
    前記インスタンスにおける前記一組のデータをシリアル化して伝送する、前記クライアントコンピュータ上で動作可能な通信ソフトウェアと、
    受信装置において前記シリアル化された一組のデータを受信し、前記参照モデルに基づいて、前記一組のデータのインスタンスを作成するサーバーと、
    を備える、システム。
34. 前記サーバーには、前記データ構造の前記記述が提供され、該サーバーは、該記述を使用して前記参照モデルのコピーを作成する、
    請求項３３に記載のシステム。
35. 前記クライアントコンピュータは、前記サーバーに対して、起動の際に前記記述を提供する、
    請求項３４に記載のシステム。
36. 前記サーバーは、プロトコルエミュレータを備え、前記データは、命令、セッションデータ、およびトポロジー情報を有する、
    請求項３３に記載のシステム。
37. 第２のデータ構造の記述を使用して該第２データ構造の第２の参照モデルを作成し、要求に応じて、データの第２のセットが実装された該第２の参照モデルのインスタンスを作成する、前記サーバー上で動作可能なソフトウェアと、
    前記インスタンスにおける前記データの第２のセットをシリアル化し、該シリアル化されたデータを前記クライアントコンピュータに伝送する、前記サーバーコンピュータ上で動作可能な通信ソフトウェアと、
    をさらに備える、請求項３３に記載のシステム。
38. 前記サーバーは、プロトコルエミュレータを備え、前記データの第２のセットは、統計情報、トポロジー、およびメッセージトレースのうちの少なくとも１つを有する、
    請求項３５に記載のシステム。
39. 前記ソフトウェアは、前記参照モデルのインスタンスを複数回生成して、複数のオブジェクトを作成する、
    請求項３３に記載のシステム。
40. それぞれのオブジェクトは、定義される方式において、他のオブジェクトと異なる、
    請求項３３に記載のシステム。
41. 前記データから独立した方式で、前記ソフトウェアとインターフェースするアプリケーションプログラミングインターフェースをさらに備える、
    請求項３３に記載のシステム。
42. 前記参照モデルに基づいてインターフェースを動的に構築するグラフィクスユーザーインターフェースをさらに備える、
    請求項３３に記載のシステム。
43. 前記参照モデルは、前記データを記述する属性を含む、
    請求項３３に記載のシステム。
44. 前記参照モデルに含まれる前記属性に基づいて、前記参照モデルの前記インスタンスにおけるデータを表示するためのインターフェースを動的に構築するグラフィクスユーザーインターフェースをさらに備える、
    請求項４３に記載のシステム。
45. プロトコルエミュレータを制御するシステムであって、
    前記プロトコルエミュレータを制御するのに使用される一組のデータの構造の記述を、該構造の参照モデルに変換する手段と、
    前記参照モデルのインスタンスを生成し、前記一組のデータを保持するオブジェクトを生成する手段と、
    前記オブジェクトにおける前記一組のデータをシリアル化して伝送する、ホスト上の通信手段と、
    前記シリアル化された一組のデータを受信し、前記参照モデルに基づいて、受信装置において前記一組のデータのインスタンスを作成するサーバー手段と、
    をさらに備え、
    前記プロトコルエミュレータは、前記サーバー手段上において、前記一組のデータに従って動作する、
    システム。
    

Images