JP2008306714A - ネットワークアプリケーションにおける通信方法、通信装置及びそのためのプログラム - Google Patents

Abstract

【課題】トランスポート用のサービスレベルの選択、通信チャネルの制御、通信帯域幅の管理、およびトランスポートに関連した通信チャネルのスケジューリングを可能にする。
【解決手段】ネットワークアプリケーションにおける通信のためのシステム、方法及び製造物。置換可能なトランスポートへの接続又は通信経路が、ネットワークアプリケーションにて起動される（図１２）。起動後、ネットワークアプリケーションは、接続又は通信経路を受け付けるために、オブジェクトを生成する。接続又は通信経路が一旦確立すると、ネットワークアプリケーションは、置換可能なトランスポートのためのＱｏＳを、置換可能なトランスポート、及び、接続又は通信経路に対応した少なくとも１つのオブジェクトに提供する。
【選択図】図１２

Description

（発明の説明）
（関連出願）
本発明は、２００１年４月９日出願の米国仮出願番号第６０／２８２，１６３による利益を請求するものであり、その開示内容全体が、ここに一体に組み入れられる。

（発明の分野）
本発明は、通信ソフトウェアに関し、特に、通信チャネル内のサービス品質に対する共通の抽象化を提供すること、並びに、分散システムにおけるコンピュータプロセッサ及び通信チャネルリソースのスケジューリングを調整することに関する。

（発明の背景）
通信ハードウェア及びソフトウェアは、共通の通信リソースに関して競合している複数の通信チャネルから選択を行う機構を提供しようとするものである。これらのリソースの性質は、それぞれの通信機構において多種多様である。通信リソースの例としては、帯域幅、メッセージキュー、割込、メモリマッピング、バス優先度、及びＤＭＡプロセッサタイム等がある。ある通信チャネルを他のものに優先させるために、通信アーキテクチャは、選択されたチャネルに、他のチャネルよりも優先させて重要な通信リソースを使用させるための機構、及び、それに関連して、ユーザがこれらの機構を制御する方法を、提供することになる。これらの機構、及び該機構を制御する方法は、通信サービス品質を操作可能とするものであるため、サービス品質すなわちＱｏＳと称される。通信リソースは多種多様であるため、通信アーキテクチャにおける結果としてのＱｏＳ特性も多種多様となる。

ほとんどのシステムでは、ある程度、分散処理がなされている。分散処理の単純な例として、ＣＰＵが、その機器の１つとバスを通じて通信することがある。より複雑な分散処理システムによると、ノードは、無線信号やネットワークを通じて、他のノードと通信することができる。

リアルタイムの制約を満たそうとする各分散システムは、同様の成功条件及び障害の制約下にある。リアルタイムミドルウェア（リアルタイムＯＲＢ（Object Request Broker）を含む）の目標は、ローカル及びリモートの通報又は「呼出（invocation）」を、終端間での予測可能性を伴った状態で実行することである。分散システムは、通信ハードウェア内のプロセッサタイム及びリソースを利用する。通信ハードウェア内のリソースは、プロセッサ間の通信方式における個々のハードウェア機構に応じて、多種態様となりうる。
通例、通信システムには、通信ノード上の通信ハードウェア間にて、データ通信に利用可能な帯域幅、通信ハードウェアの実行に関与する専用プロセッサ、及びあらゆる中継装置（スイッチ、クロスバー、ハブ、ルータ、ブリッジ、ゲートウェイ等）が、含まれる。

（ｉ）ノード内通信を考慮することなくプロセッサタイムをスケジューリングすること並びに、（ｉｉ）プロセッサタイムを考慮することなくノード内通信及び帯域幅をスケジューリングすることの双方について、多くの研究がなされてきており、理論的な基礎が存在している。ノード内通信のスケジューリングと、中央処理装置のノードのスケジューリングとを調整することについて、いくつかの研究が存在するが、その結果として、個別の分散システムや分散システムのクラスをスケジューリングするのに役立つ理論的な基礎は、ほとんどない。

このような理論的基礎が存在しないにもかかわらず、分散システムの適時の目標を最適化することに関わる分散システム設計者は、プロセッサ及び通信リソースのスケジューリングを調整することについて、決定を強いられている。通例、リソース領域、プロセッサ、及び通信についてのスケジューリングの決定は、分散システムの設計における初期に位置づけられている。分散システム設計者が、ミドルウェア等のインフラ通信ソフトウェアにより使用されるロジックを交換可能とすることにより、その設計者は、分散システムの開発中及びその後であっても、システムの構成やアプリケーションのソースコードを変更することなしに、スケジューリング調整の決定を変更できるようになる。

リアルタイムＣＯＲＢＡ（Real-Time Common Object Request Broker Architecture）規格は、優先度固定のＣＯＲＢＡシステムにおける適時の「終端間での予測可能性」について、以下のように規定している。すなわち、ＣＯＲＢＡ呼出処理中のリソースの競合を解決するために、クライアント及びサーバ間のスレッドの優先度を考慮し、終端間処理中のスレッドの優先度の逆転の継続時間を制限し、動作呼出の待ち時間を制限するというものである。

ＣＯＲＢＡとは、Object Management Group（登録商標）（ＯＭＧ（商標））により開発された規格であり、現在利用可能な多数のハードウェア及びソフトウェア製品における相互運用可能な分散コンピューティングを可能とするものである。ＣＯＲＢＡは、基本的には、ＯＲＢ（Object Request Broker：オブジェクト・リクエスト・ブローカ）のための設計仕様である。ＯＲＢは、オブジェクトが、ローカルで、リモートの機器上で、異なる言語で記述され、あるいは、ネットワーク上の別々の場所へと通信するのに必要となる機構を提供している。ＣＯＲＢＡに関するさらなる情報については、インターネットの<www.omg.org>にて常に更新されている“The Common Object Request Broker: Architecture and Specification”を参照されたい。これとは別に、容易に入手可能な市販のＯＲＢとして、ORBexpress（商標）がある。これは、オブジェクトインタフェースにより開発されたものである。ORBexpress（商標）は、高性能であり、ＣＯＲＢＡ（Common Object Request Broker Architecture）技術の第３世代の実装である。

しかしながら、従来のシステムでは、アプリケーションプログラマは、トランスポート用のサービスレベルを選択したり、通信チャネルを制御したり、通信帯域幅を管理することや、トランスポートに関連した通信チャネルをスケジューリングすることができなかった。

（発明の概要）
本発明による一実施形態は、ネットワークアプリケーションにおける通信方法であって、置換可能なトランスポートに対応した通信経路を、ネットワークアプリケーションにて起動し、前記ネットワークアプリケーションにおける前記通信経路を受け付けるオブジェクトを生成し、前記ネットワークアプリケーションにて前記通信経路が一旦確立されると、前記置換可能なトランスポートのためのサービスレベルを反映した情報を、前記置換可能なトランスポートと、前記通信経路に対応した少なくとも１つのオブジェクトとに提供することを特徴とする通信方法に関する。

本発明による他の実施形態は、ネットワークアプリケーションにおける通信方法であって、置換可能なトランスポートに対応した通信経路を、ネットワークアプリケーションにて起動し、前記ネットワークアプリケーションにおける前記通信経路を受け付けるオブジェクトを生成し、前記ネットワークアプリケーションにて前記通信経路が一旦確立されると、前記置換可能なトランスポートのためのサービスレベルを反映した情報を、前記置換可能なトランスポートと、前記通信経路に対応した少なくとも１つのオブジェクトとに提供し、リクエストを受信してメッセージを送信し、前記リクエストは、選択された通信経路及び選択されたサービスレベルの少なくとも１つを反映した情報を含み、前記の選択されたサービスレベルは、前記メッセージの配信に伴う指定されたサービス品質（ＱｏＳ）、及びサーバが前記メッセージを処理する優先度の少なくとも１つを反映しており、前記リクエストに伴う情報に基づいて、前記リクエストにサービスするための通信経路及び優先度を選択することを特徴とする通信方法に関する。

本発明のさらなる実施形態は、ネットワークアプリケーションにおける通信方法であって、リクエストを受信してメッセージを送信し、前記リクエストは、選択された通信経路及び選択されたサービスレベルの少なくとも１つを反映した情報を含み、前記の選択されたサービスレベルは、前記メッセージの配信に伴う指定されたサービス品質（ＱｏＳ）、及びサーバが前記メッセージを処理する優先度の少なくとも１つを反映しており、前記リクエストに伴う情報に基づいて、前記リクエストにサービスするための通信経路及び優先度を選択することを特徴とする通信方法に関する。

本発明によるさらに別の実施形態は、ネットワークアプリケーションにおける通信装置であって、置換可能なトランスポートに対応した通信経路を、ネットワークアプリケーションにて起動し、前記ネットワークアプリケーションにおける前記通信経路を受け付けるオブジェクトを生成し、前記ネットワークアプリケーションにて前記通信経路が一旦確立されると、前記置換可能なトランスポートのためのサービスレベルを反映した情報を、前記置換可能なトランスポートと、前記通信経路に対応した少なくとも１つのオブジェクトとに提供するプログラムを有するメモリと、前記プログラムを実行するプロセッサとを、備えたことを特徴とする装置に関する。

本発明による他の実施形態は、ネットワークアプリケーションにおける通信装置であって、置換可能なトランスポートに対応した通信経路を、ネットワークアプリケーションにて起動する手段と、前記ネットワークアプリケーションにおける前記通信経路を受け付けるオブジェクトを生成する手段と、前記ネットワークアプリケーションにて前記通信経路が一旦確立されると、前記置換可能なトランスポートのためのサービスレベルを反映した情報を、前記置換可能なトランスポートと、前記通信経路に対応した少なくとも１つのオブジェクトとに提供する手段とを、備えたことを特徴とする装置に関する。

本発明による他の実施形態は、コンピュータに、ネットワークアプリケーションにおける通信方法を実行させるコンピュータ可読媒体であって、前記方法は、置換可能なトランスポートに対応した通信経路を、ネットワークアプリケーションにて起動し、前記ネットワークアプリケーションにおける前記通信経路を受け付けるオブジェクトを生成し、前記ネットワークアプリケーションにて前記通信経路が一旦確立されると、サービス品質（ＱｏＳ）パラメータのリストを反映した情報を、前記置換可能なトランスポートと、前記通信経路に対応した少なくとも１つのオブジェクトとに提供することを特徴とするコンピュータ可読媒体に関する。

本発明による他の実施形態は、ネットワークアプリケーションにおける通信装置であって、置換可能なトランスポートに対応した通信経路を、ネットワークアプリケーションにて起動し、前記ネットワークアプリケーションにおける前記通信経路を受け付けるオブジェクトを生成し、前記ネットワークアプリケーションにて前記通信経路が一旦確立されると、前記置換可能なトランスポートのためのサービスレベルを反映した情報を、前記置換可能なトランスポートと、前記通信経路に対応した少なくとも１つのオブジェクトとに提供し、リクエストを受信してメッセージを送信し、前記リクエストは、選択された通信経路及び選択されたサービスレベルの少なくとも１つを反映した情報を含み、前記の選択されたサービスレベルは、前記メッセージの配信に伴う指定されたサービス品質、及びサーバが前記メッセージを処理する優先度の少なくとも１つを反映しており、前記リクエストに伴う情報に基づいて、前記リクエストにサービスするための通信経路及び優先度を選択するプログラムを有するメモリと、前記プログラムを実行するプロセッサとを、備えたことを特徴とする装置に関する。

本発明によるさらなる実施形態は、ネットワークアプリケーションにおける通信装置であって、リクエストを受信してメッセージを送信し、前記リクエストは、選択された通信経路及び選択されたサービスレベルの少なくとも１つを反映した情報を含み、前記の選択されたサービスレベルは、前記メッセージの配信に伴う指定されたサービス品質（ＱｏＳ）、及びサーバが前記メッセージを処理する優先度の少なくとも１つを反映しており、前記リクエストに伴う情報に基づいて、前記リクエストにサービスするための通信経路及び優先度を選択するプログラムを有するメモリと、前記プログラムを実行するプロセッサとを、備えたことを特徴とする装置に関する。

本発明による他の実施形態は、ネットワークアプリケーションにおける通信装置であって、リクエストを受信してメッセージを送信し、前記リクエストは、選択された通信経路及び選択されたサービスレベルの少なくとも１つを反映した情報を含み、前記の選択されたサービスレベルは、前記メッセージの配信に伴う指定されたサービス品質（ＱｏＳ）、及びサーバが前記メッセージを処理する優先度の少なくとも１つを反映しており、前記リクエストに伴う情報に基づいて、前記リクエストにサービスするための通信経路及び優先度を選択するプログラムを有するメモリと、前記プログラムを実行するプロセッサとを、備えたことを特徴とする装置に関する。

本発明による他の実施形態は、コンピュータに、ネットワークアプリケーションにおける通信方法を実行させるコンピュータ可読媒体であって、前記方法は、リクエストを受信してメッセージを送信し、前記リクエストは、選択された通信経路及び選択されたサービスレベルの少なくとも１つを反映した情報を含み、前記の選択されたサービスレベルは、前記メッセージの配信に伴う指定されたサービス品質（ＱｏＳ）、及びサーバが前記メッセージを処理する優先度の少なくとも１つを反映しており、前記リクエストに伴う情報に基づいて、前記リクエストにサービスするための通信経路及び優先度を選択することを特徴とするコンピュータ可読媒体に関する。

本発明による他の実施形態は、ネットワークアプリケーションにおける通信方法のための装置において、リクエストを受信してメッセージを送信する手段であって、前記リクエストは、選択された通信経路及び選択されたサービスレベルの少なくとも１つを反映した情報を含み、前記の選択されたサービスレベルは、前記メッセージの配信に伴う指定されたサービス品質（ＱｏＳ）、及びサーバが前記メッセージを処理する優先度の少なくとも１つを反映している手段と、前記リクエストに伴う情報に基づいて、前記リクエストにサービスするための通信経路及び優先度を選択する手段とを、備えたことを特徴とする装置に関する。

（実施形態の説明）
添付の図面は、本明細書に組み込まれていて、本明細書の一部を構成するものであり、その記述内容とともに、本発明の特徴及び原理を説明している。

ここで、添付の図面に示された本発明の例示的な実施形態を詳細に参照する。その記述内容には、例示的な実施形態が含まれるが、他の実施形態も実現可能であり、本発明の真意及び範囲を逸脱することなく、実施形態に対して変更が加えられてもよい。以下の詳細な説明は、発明を限定するものではなく、本発明の範囲は、添付の特許請求の範囲及びその均等の範囲により規定されるものである。

（術語及び定義）
以降の説明を通じて用いられる術語の解説を以下に示す。

アプリケーション・プログラミング・インタフェース（ＡＰＩ）：ＡＰＩは、動作を実行するために呼出可能な機能の組。

挙動（behavior）：リクエストされた動作を実行するオブジェクトの観測可能な効果であり、その結果の結合を含む。言語結合（language binding）、動的呼出、静的呼出、又は選択肢のためのメソッドの解決を参照。

クラス：選択肢用のインタフェース及びインプリメンテーションを参照。

クライアント：オブジェクト上にオペレーションを呼び出すコード又はプロセス。他のオブジェクト、コンポーネント、又はアプリケーションからのサービスをリクエストするオブジェクト、コンポーネント、又はアプリケーション。オブジェクト又はサーバのインプリメンテーション。オブジェクト、コンポーネント、又はアプリケーションは、あるリクエストに対してはクライアントとなって、他のリクエストに対してはサーバとなってもよい。

ＣＯＲＢＡ：Common Object Request Broker Architecture。

ＣＯＲＢＡＳｅｒｖｉｃｅｓ：CORBAServicesとは、開発者に対して基本的な支援を提供するオブジェクトの仕様であり、ＯＲＢを増強するものである。いくつかのサービスには、ネーミング、イベント通知、ライフサイクル、トランザクション、及びいくつかをネーミングするプロパティが、含まれている。

データ型：格納され、渡され、使用されるデータの種類についての記述。値の動作の引数の分類であり、通例、挙動及び表現の双方を含む（すなわち、従来の非〇〇プログラム言語の型の概念）。

動作停止（deactivation）：起動の反対

ドメイン：相互運用可能性について重要な概念で、明確な範囲であり、その内部では、共通の特性が示され、共通の規則が守られ、そこでは配信の透明性が保たれている。

例外：予期せぬイベント。イベントは、データを含むことがあり、言語、開発者、又はＣＯＲＢＡ規格により規定されてもよい。例外は、動作により、選択肢として返されてもよい。通常は、エラー状態を示すために用いられる。

外部化オブジェクトリファレンス：ＯＲＢ別の文字列として表現されたオブジェクトリファレンス。ファイルや他の外部媒体内に格納するのに適している。

フォワード宣言（forward declaration）：ＩＤＬ内のフォワード宣言により、インタフェースは、宣言される前に参照可能となる。

ＧＩＯＰ：General Inter-ORB Protocol（ＧＩＯＰ）は、メッセージフォーマットの組と、ＯＲＢ間の通信のための共通のデータ表現とを規定する。

ＩＩＯＰ：Internet Inter-ORB Protocol（ＩＩＯＰ）は、ＧＩＯＰメッセージが、ＴＣＰ／ＩＰネットワークを通じてどのように交換されるかを、規定する。

インプリメンテーション（Implementation）：オブジェクトを生成するのに必要な情報を提供するとともに、そのオブジェクトが適切なサービスの組を提供するのに関与できるようにする定義。通例、インプリメンテーションには、オブジェクトに伴う基本的な状態を表すのに用いられるデータ構造の記述、及びそのデータ構造にアクセスするメソッドの定義が、含まれる。また、通例、オブジェクトが意図するインタフェースについての情報が含まれる。

インプリメンテーション継承：他のインプリメンテーションを追加的に修正することによるインプリメンテーションのコンストラクション。ＯＲＢは、インプリメンテーションの継承を提供しない。インプリメンテーションの継承は、より高レベルのツールにより提供されてもよい。

インプリメンテーション・オブジェクト：インプリメンテーションの定義の役割を果たすオブジェクト。インプリメンテーション・オブジェクトは、インプリメンテーション・リポジトリ（repository）内に存在する。

インプリメンテーション・リポジトリ：オブジェクトのインプリメンテーション情報の格納場所。

継承：他の定義を追加的に修正することによる定義のコンストラクション。他のオブジェクトが継承するコンポーネント。オブジェクトは、オペレーション及び属性のみを継承する。インタフェースが２つ以上のインタフェースからの継承を行う場合には、複数の継承が発生する。「インタフェース」及び「インプリメンテーション継承」を参照。

インスタンス：オブジェクトは、インタフェースにより指定されたオペレーション、シグニチャ（signature）及びセマンテックス（semantics）を提供する場合には、インタフェースのインスタンスである。オブジェクトは、挙動がインプリメンテーションにより提供される場合には、インプリメンテーションのインスタンスである。インスタンスは、実行されるオブジェクト・インプリメンテーションの表現である。

インタフェース：オブジェクトが提供するオペレーション及び属性のリスト。これには、オペレーションのシグニチャ、及び属性の型が含まれる。インタフェースの定義は、セマンテックスをも含むことが望ましい。オブジェクトは、インタフェースにより記述された潜在的な各リクエストの中で、対象オブジェクトとして指定されることが可能であれば、インタフェースに適合するという。インタフェースは、オブジェクトのインプリメンテーション及びクライアントに共通のサービスを提供するオペレーションの集まりである。
これには、ＯＲＢの初期化及びオブジェクトリファレンスの取得が、含まれる。

インタフェース定義言語（ＩＤＬ）：オブジェクトのインタフェースを指定する言語で、あらゆるプログラム言語から独立である。

インタフェース継承：他のインタフェースの追加的修正によるインタフェースのコンストラクション。ＩＤＬ言語は、インタフェース継承を提供する。

インタフェース・オブジェクト：インタフェースを記述する役割を果たすオブジェクト。インタフェース・オブジェクトは、インタフェース・リポジトリ内に存在する。

インタフェース・リポジトリ：インタフェース情報用の格納場所。インタフェース・リポジトリにより、アプリケーションは、ランタイムで、オブジェクトのインタフェース・プロパティを判別することができる。

インタフェース型：個々のインタフェースに適合するあらゆるオブジェクトが適合する型。

相互運用可能性：２つ以上のプログラムが共通のプロトコルを用いてメッセージを交換する能力。

相互運用可能オブジェクトリファレンス（ＩＯＲ）：相互運用可能オブジェクトリファレンスは、分散され、ネットワーク能力があり、位置の透明性のあるポインタと等価である。

言語結合又はマッピング：個々のプログラム言語で記述を行うプログラマが、オブジェクトコードのライブラリの機能にアクセスする手段及び規則。

位置の透明性：クライアントは、対象オブジェクトが自身のアドレス空間についてローカルであるか、同一の機器上の別のプロセスでインプリメントされているのか、別の機器上のプロセス内でインプリメントされているのかについて、関知しないこと。

マーシャリング（marshalling）：データを、ネットワークを通じて転送可能なプラットフォーム独立なものに変換するプロセス。

メソッド：オペレーションのインプリメンテーション。リクエストされたサービスを遂行するために実行されうるコード。メソッドは、１つ以上のプログラムとして構成されうるオブジェクトに対応する。

メソッドの解決（method resolution）：リクエストされたオペレーションを遂行するためのメソッドの選択。

ミドルウェア：ミドルウェアは、単一のコンピュータシステムとして動作する複数のサーバを仮想させる。

モジュール：モジュールとは、インタフェースのグループであり、オブジェクトのグループに対して名前空間（name space）を提供する。モジュール内にあるオブジェクトが、総称可能である。

多重継承（multiple inheritance）：２つ以上の他の定義を追加的に修正することによる定義のコンストラクション。

マルチスレッド：スレッドとは、順次実行される活動である。２つ以上のスレッドが実行される場合に、その活動は、マルチスレッドと総称される。

ネーミングサービス：ネーミングサービスとは、単に、標準的に定義されたインタフェースがあるＣＯＲＢＡサーバのことである。ＣＯＲＢＡ仕様は、Resolve_Initial_Referencesを、ネーミングサービスへのリファレンスを得るためのショートカットとして提供する。それにより、分かりやすい名前をＩＯＲに対して容易にマッピングする方法が得られる。

オブジェクト：該当するリクエストの挙動により特徴づけられる抽象化を明示的に実現する、状態とメソッドの組との組み合わせ。オブジェクトは、インプリメンテーション及びインタフェースのインスタンスである。オブジェクトは、現実世界の実体をモデル化しており、状態及びオペレーションをカプセル化する（データ及びメソッドとして内部的にインプリメントされる）とともにリクエスト又はサービスに応答するコンピュータ上の実体としてインプリメントされる。

オブジェクトアダプタ：オブジェクトリファレンス、起動、及び状態に関連するサービスを、オブジェクト・インプリメンテーションに提供するＯＲＢコンポーネント。異なる種類のインプリメンテーションに対して、異なるアダプタが提供されうる。オブジェクトアダプタは、サーバを使用可能となるように起動する方法を規定したＣＯＲＢＡの一部である。それにより、サーバに対してＯＲＢへのアクセスが提供され、オブジェクトリファレンスが生成され、メソッドが呼び出される。

オブジェクト生成：他のオブジェクトから区別されるオブジェクトが存在するようにするイベント。

オブジェクトのデストラクション：オブジェクトが存在しなくなるようにするイベント。

オブジェクト・インプリメンテーション：オブジェクト・インプリメンテーションは、サーバとも称され、他のオブジェクト、コンポーネント、又はアプリケーションのためのサービスに対するリクエストに応答を提供する。所与のオブジェクト、コンポーネント、又はアプリケーションは、あるリクエストに対してサーバとなり、他のリクエストに対してクライアントとなりうる。

オブジェクトリファレンス：オブジェクトを明白に識別する値。オブジェクトリファレンスには、オブジェクトがどこに位置するのかについて及びそれと通信するのに何が必要であるかについての全ての情報が、含まれる。オブジェクトリファレンスは、他のオブジェクトを特定するために再使用されることはない。

ｏｂｊｒｅｆ：オブジェクトリファレンス（object reference）の略語。

ワンウェイリクエスト（one-way request）：クライアントがリクエストの完了を待ち受けたり、結果を受け付けようとしないリクエスト。遅延同期リクエスト及び同期リクエストとは異なる。

オペレーション：リクエスト可能なサービス。オペレーションには、対応するシグニチャがある。これは、実際のパラメータのどれが有効となるかを制限しうるものである。オペレーションは、オブジェクトが実行する活動であり、クライアントが呼び出し得るサービスである。ＩＤＬ中のオペレーションは、オブジェクト上でなされうる呼出（リモートでもよい）であって、引数がないか又はいくつかの引数があって、戻り値のあるものを定義する。ＩＤＬ中の引数及び戻り値の定義は、オペレーションのシグニチャと称される。

オペレーション名：オペレーションを特定するために、リクエスト中で用いられる名前。

ＯＲＢ：Object Request Broker。クライアントがリクエストを行うとともに応答を取得する手段を提供。ＯＲＢは、リクエストを伝達する。以下を担当する。
・オブジェクトの識別及び特定
・接続の処理
・データ配信

ＯＲＢコア：リクエストをクライアントから対象オブジェクト用の適切なアダプタへと転送するＯＲＢコンポーネント。

パラメータ転送モード：オペレーションパラメータの情報の流れの方向を記述する。パラメータ転送モードには、ＩＮ、ＯＵＴ、及びＩＮＯＵＴがある。

永続的オブジェクト：それを生成したプロセス又はスレッドの後まで存続し続けうるオブジェクト。永続的オブジェクトは、明示的に削除されるまで存続する。

ポータブルオブジェクトアダプタ（ＰＯＡ）：ＰＯＡは、オブジェクトの生成、サーバント登録、及びリクエスト発送等の基本的サービスを提供する。それにより、開発者は、完全にスケーラブルで、高性能のサーバアプリケーションを記述可能となる。

リファレンス：リファレンスとは、Ｃ＋＋におけるポインタのことである。

リファレンスドメイン（referencing domain）：リファレンスドメインは、単に、開発者が定義した文字列であり、開発者の区画領域を表す。リファレンスドメインは、環境変数により設定され、また、コマンドライン引数を通じてデーモンへと渡される。

リファレンスの整合性：オブジェクトに対応した状態にて存在するオブジェクトリファレスが、確実に単一のオブジェクトを特定できるようにする性質。

リポジトリ：インタフェース・リポジトリ、及びインプリメンテーション・リポジトリを参照。

リクエスト：クライアントは、サービスが実行されるようにリクエストを発行する。リクエストには、オペレーションが含まれ、パラメータが含まれていないか、あるいは実際のパラメータが含まれる。

結果：クライアントへと返される情報。それには、リクエストされたサービスを実行しようとして例外条件が発生したかどうかを示す状態情報とともに、値が含まれていてもよい。

サーバント：１つ以上のＣＯＲＢＡオブジェクトを実行するプログラム言語の実体。サーバアプリケーションのコンテクストに存在する。Ｃ＋＋では、サーバントは、個々のクラスのオブジェクトインスタンスである。

サーバ：１つ以上のオブジェクト上の１つ以上のオペレーションをインプリメントするプロセス又は装置。サーバ（オブジェクト・インプリメンテーションとしても知られる）は、他のオブジェクト、コンポーネント、又はアプリケーションからのサービスのリクエストに対する応答を、提供する。オブジェクト、コンポーネント、又はアプリケーションは、あるリクエストに対してはクライアントとなり、他のリクエストに対してはサーバとなりうる。

サーバオブジェクト：サービスのリクエストに対する応答を提供するオブジェクト。所与のオブジェクトは、あるリクエストに対してはクライアントとなり、他のリクエストに対してはサーバとなりうる。

シグネチャ：番号順、データ型、及び転送モード等、所与のオペレーションのパラメータと、もしあれば結果と、起こりうる結論（正常対例外）とを定義する。

単一継承（single inheritance）：１つの定義の追加的修正による定義のコンストラクション。多重継承とは異なる。

スケルトン：オブジェクトアダプタが個々のメソッドへとリクエストを転送するのを支援するオブジェクトインタフェース特有のＯＲＢコンポーネント。サーバのスケルトンは、ＩＤＬコンパイラにより生成される。サーバのコードとは、サーバのオペレーションがどのようにアクセスされるかということである。

状態：オブジェクトの時間変化する特性であり、そのオブジェクトの挙動に影響する。

静的呼出：コンパイル時にリクエストのコンストラクションを行う。スタブプロロシジャ（stub procedure）を通じてオペレーションを呼び出す。

スタブ（stub）：単一のオペレーションに対応したローカルプロシジャであり、呼出時にそのオペレーションを呼び出す。クライアントスタブは、ＩＤＬコンパイラにより生成される。このコードにより、クライアントは、インプリメンテーション・オブジェクトのサービスを呼び出すことが可能となる。

同期リクエスト：クライアントが休止してリクエストの完了を待ち受けるというリクエスト。遅延同期リクエスト、及びワンウェイリクエストとは異なる。

ＴＣＰ／ＩＰ：Transmission Control Protocol/Internet Protocol。

スレッド：順に実行される活動。２つ以上のスレッドが、並行して実行されうる。スレッドの別の用語として、タスクがある。

非常駐オブジェクト（transient object）：オブジェクトを生成したプロセス又はスレッドの存続時間により存在が制限されたオブジェクト。

型（type）：データ型及びインタフェースを参照。

ｔｙｐｅｄｅｆ：ＩＤＬにて、typedef文は、現行のＩＤＬ型（基本（basic）又は複合（composite））の新しい名前を定義する能力を提供する。この新しい名前は、単なる名称変更であり、異なる型とするものではない。

値：リクエスト内の可能な実際のパラメータとなりうるあらゆる実体。オブジェクトを識別する役割を果たす値は、オブジェクトリファレンスと称される。

（概説）
本発明に従うシステム及び方法により、アプリケーションプログラマは、「プラグイン」モジュールを作成することが可能となる。プラグインモジュールにより、アプリケーションは、上述の問題を解決するために、各通信の優先度及びＱｏＳを動的に選択可能となる。さらに、プログラマは、ＣＰＵ及びネットワークリソースのスケジューリングを、最適化及び調整可能である。プログラマは、使用されている個々のアプリケーションについて適切な、代替のチャネル選択アルゴリズムを、選択可能である。

ネットワークアプリケーションは、リクエストを受信してメッセージを送信し、そのリクエストには、選択された接続の１つのＱｏＳ及び選択されたＱｏＳが、含まれている。
リクエストが受信されると、置換可能なトランスポートへの接続又は通信経路が、ネットワークアプリケーション内で起動される。起動後、接続又は通信経路を受け入れるために、オブジェクトが生成される。接続又は通信経路が一旦確立されると、ネットワークアプリケーションは、置換可能なトランスポート用のＱｏＳ情報を、置換可能なトランスポートに対して提供するとともに、接続又は通信経路に対応した少なくとも１つのオブジェクトに対しても提供する。ＱｏＳは、メッセージの配信、及びサーバがメッセージを処理する優先度に、対応している。そして、ネットワークアプリケーションは、リクエストからの情報に基づいて、接続又は通信経路、及びリクエストに対するサービスの優先度を選択する。

（コンピュータ環境）
本発明は、独立した構成すなわちスタンドアロン構成又はネットワーク環境にて構成されたコンピュータシステムを用いて実施されうる。このようなシステムには、ＭＳ−ＤＯＳ、Ｌｉｎｕｘ、ＬｙｎｘＯＳ、Ｔｏｒｎａｄｏ／ＶｘＷｏｒｋｓ、Ｕｎｉｘの変形例のほとんど、Ｗｉｎｄｏｗｓ９５／９８／ＮＴ、及びＭａｃｉｎｔｏｓｈオペレーティングシステム等の様々なオペレーティングシステムを実行するパーソナルコンピュータ、並びに、ＬＩＮＵＸ、ＵＮＩＸ、及びＵＮＩＸの変形例のオペレーティングシステムを実行するコンピュータワークステーションが、含まれうる。図１に、典型的なコンピュータ環境を示す。この図には、本発明によるコンピュータワークステーションの標準的なハードウェア構成が示されている。

コンピュータワークステーション１００には、マイクロプロセッサ等の中央演算処理装置（ＣＰＵ）１１０、及び、システムバス１１２を通じて相互接続されたいくつもの他のユニットが、含まれていてもよい。また、ワークステーションには、ランダムアクセスメモリ（ＲＡＭ）１１４と、読出専用メモリ（ＲＯＭ）１１６と、ディスク記憶ユニット１２０のような周辺機器をバス１１２へと接続する入出力（Ｉ／Ｏ）アダプタ１１８と、キーボード１２４、マウス１２６、スピーカ１２８と、マイクロフォン１３２、及び／又はタッチスクリーン（図示せず）のような他のユーザインタフェース機器を、バス１１２へと接続するユーザインタフェースアダプタ１２２と、ワークステーションを通信ネットワーク（例えば、データ処理ネットワーク）へと接続する通信アダプタ１３４と、バス１１２をディスプレイ装置１３８へと接続するディスプレイアダプタ１３６とが、含まれていてもよい。なお、コンピュータワークステーションがネットワークコンピュータ環境にてサーバとして機能している場合には、１つ以上のディスプレイアダプタ、キーボード、マウス、又は他のＩ／Ｏ要素が省略されてもよいことが、理解されるであろう。通例、ワークステーションは、Microsoft Windowsファミリーのオペレーティングシステム（例えば、Windows NT、Windows 95、Windows 98、Windows CE）、IBM OS/2オペレーティングシステム、MAC OS、LINUXオペレーティングシステム、又はＵＮＩＸオペレーティングシステム等の、そこに常駐しているオペレーティングシステムを有する。

また、本発明が実施されうるハードウェア環境には、ネットワークコンピューティング環境内で動作するように構成されたコンピュータが、含まれていてもよい。ネットワーク環境は、一般にはアクセス不能なネットワークすなわち内部ネットワーク、インターネット等の一般にアクセス可能なネットワーク、又はそれらの任意の組み合わせであってもよい。ネットワークの大きさ、ネットワークのトポロジー、ネットワーク上のノード数、ネットワーク上で使用されている通信プロトコル、及びネットワークの構成及び動作に関する事項等の、ネットワークを管理するパラメータは、当業者が決定できるものである。さらに、本発明は、上記以外のコンピュータプラットフォーム及びオペレーティングシステム上で実施されてもよいことが、当業者にはわかるであろう。

（ソフトウェア実装環境）
本発明は、手続き型プログラム言語か、あるいは、オブジェクト指向プログラムモデル及び方法論を用いて、実施可能である。オブジェクト指向プログラムモデル及び方法論を採用した言語の例として、Ada 95、Java、Smallltalk、C、Objective C、及びC++言語等がある。オブジェクト指向プログラミング（ＯＯＰ）は、ますます、複雑なアプリケーションを開発するための共通の方法となってきている。メッセージインタフェース用のＯＯＰクラス及びオブジェクトの組が提供されるように、これらのＯＯＰの原理が、電子メッセージ処理システムのメッセージ処理インタフェースに適用されることが、要請されている。

このように、様々な問題及びプログラムタスクに対する解決策のための枠組みを開発することを通じて、ソフトウェアの設計及び開発の手間が、著しく削減されるようになる。

（ＣＯＲＢＡ：Common Object Request Broker Architecture）
ＯＲＢが異なると、ＩＤＬコンパイラ、リポジトリ、及び種々のオブジェクトアダプタとともに、インプリメンテーションの選択が非常に異なり、また、異なる特性及び特質を有するクライアント及びオブジェクトのインプリメンテーションに対して、サービスの組が提供される。ある構成では、ＯＲＢは、単一のコンポーネントとして実装される必要はなく、そのインタフェースによって規定される。適切なインタフェースを提供するＯＲＢのあらゆるインプリメンテーションは、本発明の文脈内で許容されうる。インタフェースは、３種類に分類される。
１．全てのＯＲＢインプリメンテーションに対して同一のオペレーション。
２．オブジェクトの個々の型に特有なオペレーション。
３．オブジェクト・インプリメンテーションの個々の形式に特有なオペレーション。

ＯＲＢコアは、オブジェクト及びリクエストの通信の基本的表現を提供するＯＲＢの部分である。ＣＯＲＢＡは、異なるオブジェクト機構に対応するように設計されており、ＯＲＢを、ＯＲＢコア上のコンポーネントで構成することにより、そのようになる。これにより、ＯＲＢコア間の差異をマスク可能なインタフェースが提供される。

図２に、ＯＲＢの構成を示す。ここでは、クライアント２０４が、リクエスト２０２を、オブジェクト・インプリメンテーション２０６へ送っている。クライアント２０４は、オブジェクトのオブジェクトリファレンスへのアクセスを有するとともにオブジェクト上でオペレーションを実行しようとする実体である。オブジェクトリファレンスは、ＯＲＢ内のオブジェクトを特定するのに必要な情報である。クライアント及びオブジェクト・インプリメンテーションの双方は、言語マッピングに基づいてオブジェクトリファレンスの不透明な概念を有するので、そのリファレンスから遮断されている。これは、言語マッピングが、実際のそれらの表現から遮断されていることによる。クライアントへ渡されるオブジェクトリファレンスの表現は、そのクライアントの存続時間にのみ有効である。

クライアント２０４は、インタフェースに基づいてオブジェクトの論理構造のみを認識しており、呼出を通じてオブジェクトの挙動を経験する。個々のオブジェクトに関して何がクライアントとなる旨を、認識することが重要である。例えば、あるオブジェクトのインプリメンテーションは、他のオブジェクトのクライアントとなりうる。

一般に、クライアントは、オブジェクト及びＯＲＢインタフェースを、言語マッピングの視点で認識し、ＯＲＢをプログラマのレベルにまで持ってくる。クライアントは、最大限にポータブルであり、所望のインタフェースをインプリメントする任意のオブジェクトインスタンスで、所望の言語マッピングを支援する任意のＯＲＢ上にて、ソースを変更することなく、動作可能なはずである。クライアントは、オブジェクトのインプリメンテーションについての知識を持たない。そのオブジェクトアダプタは、インプリメンテーションにより用いられるか、あるいはそのＯＲＢがアクセスのために用いられる。

オブジェクト・インプリメンテーション２０６は、オブジェクトの実際のセマンテックスを提供するとともにオブジェクトをインプリメントするコード及びデータである。多くの場合、インプリメンテーションは、他のオブジェクト又は追加のソフトウェアを用いて、オブジェクトの挙動をインプリメントする。ある場合には、オブジェクトの主要な機能は、オブジェクトではない他のものの上の副作用を有することである。一般に、オブジェクト・インプリメンテーションは、ＯＲＢに依存しないか、クライアントがどのようにオブジェクトを呼び出すかということに依存しない。オブジェクト・インプリメンテーションは、オブジェクトアダプタの選択により、ＯＲＢ依存のサービスへのインタフェースを選択してもよい。

ＯＲＢ２０８は、リクエストのためのオブジェクト・インプリメンテーションを検出するのに必要な全ての機構を担当しており、オブジェクト・インプリメンテーションが、リクエストを受信する準備をするとともに、リクエストを構成するデータを伝達する。クライアントが認識しているインタフェースは、オブジェクトがどこに位置しているか、インプリメントされているプログラム言語が何か、あるいは、オブジェクトのインタフェースに反映されない他の側面から、完全に独立している。

図３に、個々のＯＲＢ２０８の構造を示す。斜線のボックスは、ＯＲＢへのインタフェースを示し、矢印は、ＯＲＢが呼び出されているのか、あるいはインタフェースを通じてアップコールしているのかを示すものである。リクエストするために、クライアント２０４は、動的呼出インタフェース３０２（対象オブジェクトのインタフェースから独立な同じインタフェース）、又はＯＭＧ・ＩＤＬ（Object Management Group Interface Definition Language Stub）３１４（対象オブジェクトのインタフェースに依存した特定のスタブ）を、使用可能である。

動的呼出インタフェース３０２により、オブジェクト呼出の動的コンストラクションが可能となる。すなわち、個々のオブジェクト上の個々のオペレーションに特有のスタブルーチンを呼び出すよりも、クライアントは、呼び出されるべきオブジェクト、実行されるべきオペレーション、及び呼出又は一連の呼出を通じてのオペレーション用のパラメータの組を、特定してもよい。クライアントのコードは、実行されるべきオペレーション及び渡されるパラメータの型についての情報（おそらく、インタフェース・リポジトリ又は他のランタイムソースから取得）を、与えるものでなければならない。動的呼出インタフェース３０２の性質は、あるプログラム言語から他のものへのマッピングにより、実質的に様々となりうる。また、クライアント２０４は、いくつかの機能のために、ＯＲＢインタフェース３１６を利用して、ＯＲＢと直接的に相互作用することができる。

ＯＭＧ・ＩＤＬ３１４は、インタフェースを指定することにより、オブジェクトの型を規定している。インタフェースは、命名されたオペレーションの組及び該オペレーションに対するパラメータから構成される。なお、ＩＤＬは、ＯＲＢにより操作されるオブジェクトを記述するための概念的な枠組みを提供しているが、ＯＲＢが機能するために利用可能なＩＤＬソースコードがある必要はない。等価な情報が、スタブルーチン又はランタイム・インタフェース・リポジトリとして利用可能である限り、個々のＯＲＢは、正確に機能可能となるであろう。

それぞれのオブジェクト指向又は非オブジェクト指向プログラム言語は、ＣＯＲＢＡオブジェックトに対して、それぞれの方法でアクセスすることを好むことがある。オブジェクト指向言語については、ＣＯＲＢＡオブジェクトをプログラム言語オブジェクトとして認識することが望ましい。非オブジェクト指向言語であっても、オブジェクトリファレンスやメソッド名等の正確なＯＲＢ表現を隠蔽することが、望ましい。ＯＭＧ・ＩＤＬのプログラム言語に対する個々のマッピングは、全てのＯＲＢインプリメンテーションについて同じであるべきである。言語マッピングには、言語別のデータ型の定義と、ＯＲＢを通じてオブジェクトにアクセスするための手続きインタフェースとが、含まれている。それには、クライアント・スタブ・インタフェース（オブジェクト指向言語には不要）、動的呼出インタフェース、インプリメンテーション・スケルトン、オブジェクトアダプタ、及び直接ＯＲＢインタフェースが、含まれる。ＯＲＢインタフェースは、ＯＲＢに直接達するインタフェースであり、全てのＯＲＢについて同一であり、オブジェクトのインタフェース又はオブジェクトアダプタに依存しない。

また、言語マッピングは、オブジェクト呼出と、クライアント又はインプリメンテーション内での制御のスレッドとの相互作用を、定義している。最も共通するマッピングは、同期呼出を提供する。ここでは、オブジェクトのオペレーションが完結したときにルーチンが戻ってくる。呼出が起動されて制御がプログラムに戻ることを可能とする追加的なマッピングが、提供されてもよい。このような場合には、追加的な言語別のルーチンには、プログラムのスレッドを同期させるために、オブジェクト呼出が提供されなければならない。

オブジェクト・インプリメンテーション２０６は、ＯＭＧ・ＩＤＬ生成スケルトン３１８を通じて、あるいは、動的スケルトン３１０を通じて、リクエストをアップコール（up-call）として受信する。動的スケルトンは、クライアントスタブ及び動的呼出インタフ
ェースの双方から呼び出されうる。クライアントのリクエスト・コンストラクション・インタフェースのいずれの形式によっても、同様の結果がもたらされる。個々のオペレーションに特有のスケルトンを通じてアクセスされるのではなく、オブジェクトのインプリメンテーションには、クライアント側の動的呼出インタフェースと同様にオペレーション名及びパラメータへのアクセスを提供するインタフェースを通じて、到達する。パラメータを特定するために、それらのパラメータの純粋に静的な知識が用いられてもよく、あるいは、動的な知識（おそらく、インタフェース・リポジトリを通じて特定される）が用いられてもよい。

オブジェクト・インプリメンテーション２０６は、オブジェクトアダプタ３１２及びＯＲＢを、リクエスト処理中又は他の時機に呼び出してもよい。オブジェクトアダプタは、オブジェクト・インプリメンテーションがＯＲＢにより提供されるサービスにアクセスする主要な方法である。多くの場合、ＯＲＢによりオブジェクトアダプタを通じて提供されるサービスには、オブジェクトリファレンスの生成及び解釈、メソッドの呼出、相互作用のセキュリティ、オブジェクト及びインプリメンテーションの起動及び停止、オブジェクトリファレンスのインプリメンテーションへのマッピング、並びに、インプリメンテーションの登録が、含まれる。オブジェクトアダプタを通じて、ＯＲＢは、カスタマイズされたインタフェースと同様の要件を有するオブジェクト・インプリメンテーションの個々のグループを、対象とすることができる。

インタフェースのオブジェクトへの定義は、２通りになされうる。インタフェースは、ＯＭＧ・ＩＤＬ内で静的に定義可能である。この言語は、オブジェクト及び該オブジェクトへのパラメータ上で実行されうるオペレーションに基づいて、オブジェクトの型を定義する。さらに、インタフェースが、インタフェース・リポジトリ・サービスに追加されてもよい。インタフェース・リポジトリ・サービスは、インタフェースのコンポーネントを、該コンポーネントへのランタイムのアクセスを許容しながら、オブジェクトとして表している。

また、インタフェース・リポジトリは、ランタイムで利用可能な形式にて、ＩＤＬ情報を表す永続的オブジェクトを提供する。インタフェース・リポジトリ情報は、ＯＲＢにより、リクエストを実行するのに用いられてもよい。さらに、インタフェース・リポジトリ内の情報を用いて、プログラムは、プログラムがコンパイルされて、しかも、どのオペレーションがオブジェクト上で有効であるか判別可能で、そこで呼出を実行可能な場合、インタフェースが未知のオブジェクトに、出会うことが可能である。ＯＲＢの機能における役割に加えて、インタフェース・リポジトリは、ＯＲＢオブジェクトへのインタフェースに関連した追加の情報を格納するのに共通の場所である。

あらゆるＯＲＢインプリメンテーションにて、ＩＤＬ（本文献での定義を超えているかもしれないが）及びインタフェース・リポジトリは、等価な表現力を有する。ＩＤＬは、個々のオブジェクト・インプリメンテーションが、クライアントとなりうるものに対して、どのオペレーションが利用可能で、それをどのように呼び出すのかを、伝達する手段である。ＩＤＬの定義により、ＣＯＲＢＡオブジェクトを個々のプログラム言語又はオブジェクトシステムにマッピングすることが可能である。

クライアントは、オブジェクトのオブジェクトリファレンスにアクセスし、オブジェクトの型を認識し、実行されるべき所望のオペレーションを認識することにより、リクエストを実行する。クライアントは、オブジェクト固有のスタブルーチンを呼び出すことにより、あるいは、リクエストを図４に示されるようにコンストラクトすることにより、リクエストを起動する。

図４に、スタブ又は動的呼出インタフェースを用いるクライアント２０４を示す。リクエストを呼び出すためのスタブ及び動的インタフェースは、同一のリクエストのセマンテックスに適合している。リクエストの受信側は、リクエストがどのように呼び出されたかが分からない。ＯＲＢは、インプリメンテーションコードの位置を特定し、パラメータを送出し、図５に示すように、ＩＤＬスケルトン又は動的スケルトンを通じて、オブジェクト・インプリメンテーションに制御を移す。スケルトンは、インタフェース及びオブジェクトアダプタに特有のものである。リクエストを実行するのに、オブジェクト・インプリメンテーションは、いくつかのサービスを、ＯＲＢからオブジェクトアダプタを通じて取得してもよい。リクエストが完結すると、制御及び出力値がクライアントへ返される。

図５に、リクエストを受信するオブジェクト・インプリメンテーション５０６を示す。
オブジェクト・インプリメンテーションは、どのオブジェクトアダプタ３１２を用いるかを選択してもよい。この判別は、オブジェクト・インプリメンテーションがどの種類のサービスを必要としているかに基づいてなされる。

図６は、インタフェース及びインプリメンテーションの情報を、クライアント及びオブジェクト・インプリメンテーションに利用可能とするプロセス６００のフローチャートである。インタフェースは、ＯＭＧ・ＩＤＬ及び／又はインタフェース・リポジトリ６２２内で定義されている。その定義は、クライアントスタブ６１４及びオブジェクト・インプリメンテーション・スケルトン６２０を生成するために、用いられる。非オブジェクト指向言語のマッピングのために、各インタフェース型について、スタブへのプログラムインタフェースがある。一般に、スタブは、ＯＭＧ・ＩＤＬに規定されたオブジェクト上のオペレーションへのアクセスを、プログラマが、ＯＭＧ・ＩＤＬ、及び個々のプログラム言語への言語マッピングを知っているならば、そのプログラマにとって容易な方法で、提供することになる。スタブは、個々のＯＲＢコアに対してプライベートであるとともにおそらくは最適化されたインタフェースを用いて、ＯＲＢのその他のものに呼出を行う。２つ以上のＯＲＢが利用可能である場合、それぞれのＯＲＢに対応するそれぞれのスタブが存在しうる。Ｃ＋＋及びSmallTalk等のオブジェクト指向プログラム言語には、スタブインタフェースが必要ではない。

オブジェクト・インプリメンテーションは、インタフェースに準拠したルーチンを書き出し、ＯＲＢは、スケルトンを通じてそれらを呼び出す。スケルトンが存在することは、対応するクライアントのスタブが存在することを、意味するわけではない（クライアントは、動的呼出インタフェースを通じてリクエストすることも可能）。インプリメンテーション・メソッドを呼び出すのに、スケルトンを用いないオブジェクトアダプタを記述することが、可能である。

オブジェクト・インプリメンテーション情報は、インストール時に提供されて、リクエストが配信される際に使用するために、インプリメンテーション・レポジトリ６２４内に格納される。インプリメンテーション・リポジトリには、ＯＲＢがオブジェクトのインプリメンテーションを特定して起動できるようにする情報が、格納されている。インプリメンテーション・リポジトリ内のほとんどの情報は、ＯＲＢ又はオペレーティング環境に特有のものであるが、インプリメンテーション・リポジトリは、このような情報を記録するための通常の場所である。ＯＲＢの機能における役割に加えて、インプリメンテーション・リポジトリは、ＯＲＢオブジェクトのインプリメンテーションに関連した追加の情報を格納するための共通の場所である。

共通のＯＲＢのアーキテクチャ内で可能なＯＲＢインプリメンテーションには、様々なものがある。他の選択肢のいくつかを以下に説明する。なお、個々のＯＲＢは、複数の選択肢及び通信プロトコルに対応しうる。

クライアント及びインプリメンテーション常駐ＯＲＢ。適切な通信機構がある場合、ＯＲＢは、クライアント及びインプリメンテーションに常駐しているルーチン内にインプリメント可能である。クライアント内のスタブは、位置に関して透明性のあるプロセス間通信（ＩＰＣ：Interprocess Communication）機構を用いるか、あるいは、インプリメンテーションとの通信を確立するために、位置特定サービスに直接アクセスする。インプリメンテーションとリンクしたコードは、クライアントによる使用のために、適切なデータベースの設定を担当する。

サーバベースＯＲＢ。ＯＲＢの管理を集中化するために、全てのクライアント及びインプリメンテーションは、クライアントからインプリメンテーションへとリクエストをルーティングすることを担当する１つ又はそれ以上のサーバと通信可能である。ＯＲＢは、基礎となるオペレーティングシステムが考慮されている限り、通常のプログラムであってもよく、ＯＲＢと通信するのに、通常のＩＰＣが用いられてもよい。

システムベースＯＲＢ。セキュリティ、堅牢性、及び性能を向上させるため、ＯＲＢは、基礎となるオペレーティングシステムの基本的なサービスとして、提供されてもよい。
オブジェクトリファレンスは、各リクエスト上での認証の手間を減らしつつ、偽造不能とされうる。オペレーティングシステムは、クライアント及びインプリメンテーションの位置及び構造を認識可能なので、様々な最適化がインプリメント可能である。例えば、両者が同一の機器上にある場合にマーシャリングを防止する。

ライブラリベースＯＲＢ。軽くかつインプリメンテーションが共用されているオブジェクトについて、実際には、インプリメンテーションはライブラリ中にあってもよい。この場合、スタブは、実際のメソッドであってもよい。これは、クライアントプログラムが、オブジェクト用のデータにアクセスできること、及び、インプリメンテーションが、クライアントがデータを損傷しないものと信頼していることを、前提としている。

図７に、クライアント２０４の構造を示す。オブジェクトのクライアント２０４は、そのオブジェクトを指すオブジェクトリファレンスを有する。オブジェクトリファレンスは、呼び出されるか、あるいは、パラメータとして他のオブジェクト上での呼出へと渡されうるトークンである。オブジェクトの呼出には、呼び出されるべきオブジェクト、実行されるべきオペレーション、及びオペレーションへと渡されるかあるいはそれから返却されるパラメータを特定することが、含まれる。ＯＲＢは、オブジェクト・インプリメンテーションへの制御の移転及びデータの移転、並びにそれらがクライアントに復帰することを管理する。ＯＲＢが呼出を完結不能なイベントでは、例外の応答が提供される。通常、クライアント２０４は、呼出を実行するとともにオペレーションが完結した場合に復帰を実行する、プログラム中のルーチンを呼び出す。

クライアントは、そのプログラム中のライブラリルーチンとして、オブジェクト型固有のスタブにアクセスする。このように、クライアントプログラムは、通常の方法でそのプログラム言語中に呼出可能なルーチンを参照する。全てのイプリメンテーションは、オブジェクトを参照するのに用いるために、言語固有のデータ型（多くの場合、不透明なポインタ）を、提供することになる。そして、クライアント２０４は、オブジェクトリファレンスをスタブルーチンに渡して、呼び出しを起動する。スタブは、オブジェクトリファレンス表現にアクセスし、ＯＲＢと対話して呼び出しを実行する。

例えば、コンパイル時にオブジェクトが定義されていない場合に、オブジェクト上での呼出を実行するのに、ライブラリコードの別の組が利用可能である。その場合、クライアントプログラムは、オブジェクトの型及び呼び出されるメソッドを指定するための追加の情報を提供し、パラメータを指定して呼出（invocation）を起動するための一連の呼出（calls）を実行する。

最も一般的には、クライアントは、オブジェクトリファレンスを、それに対してリファレンスを有する他のオブジェクト上の呼出からの出力パラメータとして受信することにより、取得する。クライアントもインプリメンテーションである場合、当該クライアントは、オブジェクトリファレンスを、インプリメントしているオブジェクトへの呼出上の入力パラメータとして受信する。また、オブジェクトリファレンスは、文字列へも変換可能である。なお、この文字列は、ファイル内に格納され、又は他の手段により保存若しくは伝達され、その後、当該文字列を生成したＯＲＢによりオブジェクトリファレンスへと戻されることが可能なものである。

図８に、オブジェクト・インプリメンテーション２０６の構造を示す。オブジェクト・インプリメンテーション２０６は、オブジェクトの実際の状態及び挙動を提供し、種々の様式に構成されうる。オペレーション自体のメソッドを定義することに加えて、インプリメンテーションは、通例、オブジェクトを起動及び停止する手順を定義し、他のオブジェクト又は非オブジェクト機能を用いて、オブジェクトの状態を永続的にし、オブジェクトへのアクセスを制御し、メソッドをインプリメントすることになる。オブジェクト・インプリメンテーションは、種々の方法でＯＲＢと対話して、自身の身元を確立し、新規のオブジェクトを生成し、ＯＲＢ依存のサービスを取得する。これは、主に、オブジェクトアダプタへのアクセスを通じてなされる。なお、それにより、オブジェクト・インプリメンテーションの個々の形式に都合がよいＯＲＢサービスへのインタフェースが、提供される。可能なオブジェクト・インプリメンテーションの範囲を考慮すると、オブジェクト・インプリメンテーションがどのように構成されるかを決定しようとすることは、現実的ではない。

呼出が発生すると、ＯＲＢコア、オブジェクトアダプタ、及びスケルトンは、インプリメンテーションにおける適切なメソッドへの呼出を手配する。そのメソッドへのパラメータが、呼び出されるオブジェクトを指定する。そのオブジェクトは、メソッドがオブジェクトのためのデータの位置を特定するのに使用可能である。スケルトンの定義に基づいて、追加のパラメータが与えられてもよい。メソッドは完結すると、返却され、クライアントへと返送されるべき出力パラメータ又は例外の結果が発生する。

新規のオブジェクトが生成された場合、ＯＲＢは、オブジェクトのためのインプリメンテーションをどこで検出できるかがわかるように、通知を受けてもよい。また、インプリメンテーションは、個々のインタフェースのオブジェクトをインプリメンとするものとして自身を登録し、インプリメンテーションが実行中でなければ、該インプリメンテーションをどのように起動するかを指定する。

ほとんどのオブジェクト・インプリメンテーションは、ＯＲＢ及びオブジェクトアダプタに加えて、機能を用いて自身の挙動を提供する。例えば、ポータブル・オブジェクトアダプタは、オブジェクト識別子（ＯＩＤ又はオブジェクトＩＤ）等のオブジェクトに伴ういくつかの永続的なデータを提供するが、通例、比較的少量のデータが、オブジェクト・インプリメンテーションの選択による記憶サービス内に格納された実際のオブジェクトのデータ用の識別子として用いられる。この構造により、他のオブジェクト・インプリメンテーションが、同一の記憶サービスを使用可能となるだけでなく、オブジェクトが、自身に最も適切なサービスを選択可能となる。

図９に、オブジェクトアダプタ９００の例示的な構造を示す。オブジェクトアダプタ９００は、オブジェクト・インプリメンテーション２０６が、オブジェクト・リファレンスの生成等のＯＲＢサービスにアクセスするための主要な手段である。オブジェクトアダプタ９００は、パブリックインタフェースをオブジェクト・インプリメンテーションへと、プライベートインタフェースをスケルトンへと、エクスポートしうる。さらに、オブジェクトアダプタ９００は、プライベートのＯＲＢ依存インタフェース上に構築される。

オブジェクトアダプタは、以下の機能を担当している。
・オブジェクト・リファレンスの生成及び解釈
・メソッドの呼出
・対話のセキュリティ
・オブジェクト及びインプリメンテーションの起動及び停止
・オブジェクト・リファレンスを対応するオブジェクト・インプリメンテーションへマッピングすること
・インプリメンテーションの登録

これらの機能は、ＯＲＢコア及び必要な他のコンポーネントを用いて実行される。多くの場合、オブジェクトアダプタは、そのタスクを遂行するために、自身の状態を維持することになる。個々のオブジェクトアダプタは、役割の１つ又はそれ以上を、ＯＲＢコアに委任することが可能である。なお、オブジェクトアダプタは、ＯＲＢコア上に構築されている。

図９に示すように、直接のインタフェースはスケルトンを通じてであるが、オブジェクトアダプタは、メソッドの呼出に暗黙的に関係している。例えば、オブジェクトアダプタは、インプリメンテーションの起動又はリクエストの認証に、関係していてもよい。オブジェクトアダプタは、ＯＲＢからのサービスのほとんどを定義する。なお、それは、オブジェクト・インプリメンテーション２０６が依存しうるものである。それぞれのＯＲＢは、それぞれのサービスのレベルを提供してもよい。それぞれのオペレーティング環境は、いくつかのプロパティを暗黙的に提供してもよく、オブジェクトアダプタにより追加されるべき他のものを要求してもよい。例えば、オブジェクト・インプリメンテーション２０６が、呼出中のオブジェクトを容易に識別するために、ある値をオブジェクトリファレンスに格納することを必要とすることは、一般的なことである。新規のオブジェクト生成時に、オブジェクトアダプタにより、インプリメンテーションがこのような値を指定可能である場合、該値をオブジェクトリファレンス内に、それを許容するＯＲＢのために格納可能であってもよい。ＯＲＢコアがこの機能を提供していない場合、オブジェクトアダプタが、自身の記憶域にその値を格納し、呼出中のインプリメンテーションへと提供することになる。オブジェクトアダプタにより、オブジェクト・インプリメンテーション２０６が、サービスにアクセス可能となる。それが、ＯＲＢコアにインプリメントされていてもいなくともである。ＯＲＢコアがそれを提供しているならば、オブジェクトアダプタは、単にそれへのインタフェースを提供することになる。そうでなければ、オブジェクトアダプタは、ＯＲＢコアの上部にそれをインプリメントしなければならない。個々のアダプタの全てのインスタンスは、同一のインタフェース及びサービスを、それがインプリメントされている全てのＯＲＢに提供しなければならない。

また、全てのオブジェクトアダプタが、同一のインタフェース又は機能を提供する必要はない。いくつかのオブジェクト・インプリメンテーションには、特殊な要件がある。例えば、オブジェクト指向データベースシステムが、オブジェクトアダプタに対して個別の呼出をすることなく、何千ものオブジェクトを暗黙的に登録することを要求することがある。このような場合、オブジェクトアダプタが、オブジェクト毎の状態を維持することは、現実的でなく、また、必要なことでもない。このようなオブジェクト・インプリメンテーションに向けて調整されたオブジェクトアダプタのインタフェースを用いることにより、ＯＲＢに対して最も効率的なアクセスを提供するために、個々のＯＲＢコアの詳細を利用可能となる。

（ＣＯＲＢＡを用いたクライアント／サーバ開発の概説）
クライアントが、自身のアドレス空間に対して対象オブジェクトがローカルであるかどうか知らない場合、位置の透明性が、同マシン上の別のプロセス内にインプリメントされるか、あるいは、別のマシン上のプロセス内にインプリメントされる。位置の透明性は、従来から利用可能な技術に対しての、ＣＯＲＢＡの利点である。ＣＯＲＢＡは、分散アプリケーションを開発及び実行するために、位置及びアクセスの透明性の双方を提供する。
アプリケーションのコンポーネント又はオブジェクトは、複数のプロセスに分散されてもよい。クライアント及びサーバの双方は、ＣＯＲＢＡのインフラを利用するのであれば、機器構成、オペレーティングシステム、プログラミング言語、又は位置を考慮せずに、通信可能である。

リモート呼出機能及び遅延結合機能により、ＣＯＲＢＡアプリケーションの構成上の管理のしやすさ、柔軟性、及び再利用性が向上する。アプリケーションは、機能の低下なしに、異なる分散アーキテクチャに亘って再分割可能である。

図１０に、クライアント２０４が、リクエストをＯＲＢを通じてサーバオブジェクト１００６へと、どのように送信するかを示す。最初に、クライアント２０４がリクエストをサーバ１００６へと送信すると、それがサーバから受信される。そして、サーバ１００６からクライアント２０４へと、応答が送信される。クライアント２０４からサーバへのデータ通信、すなわちピアツーピアで、適切に定義されたオブジェクト指向インタフェースを通じて遂行される。ＯＲＢは、対象オブジェクトの位置を特定し、そのオブジェクトへリクエストを送信し、何らかの応答（成功又はエラー状態）を呼出側へ返信する。また、オブジェクト指向技術を通じて、開発者も、継承、カプセル化、ポリモフィズム、及びランタイムでの動的結合等の機能を利用できるようになる。これらの機能により、アプリケーションは、親インタフェースに対する最小限の変更で、変更、修正、及び再利用可能となる。ＣＯＲＢＡを用いる場合、分散アプリケーションではなく、分散オブジェクトの観点から考察するとよい。オブジェクトは、ソフトウェアバス上に存在しているとみなされてもよい。そこでは、バス上の他の全てのオブジェクトにアクセス可能となっている。

ＯＲＢは、他の分散オブジェクト上にオペレーションを呼び出すために、安全でセキュリティ保護された環境を、オブジェクトに提供する。ＯＲＢの主要な機能は、オブジェクトの生成、管理、及び呼出である。ＯＲＢは、クライアント２０４からサーバオブジェクト１００６へのリクエストを処理する。ＯＲＢは、オブジェクトが存在するかどうか判別し、リクエストされたオペレーションをオブジェクト上に呼び出す。

図１１に、ＯＲＢプログラムにおける例示的なマルチスレッドのクライアント・サーバ相互作用１１００を示す。マルチスレッド対応は、ＯＲＢプログラムに固有の部分である。多くの場合、制御に単一スレッドを用いるサーバアプリケーションを開発するのは、困難である。単一のスレッドのみが利用可能な場合、サーバは、クライアントのリクエストをシリアル化しなければならない。新規のリクエストは、オブジェクトアダプタ内でキューに入れられる。なお、これは、ポータブル・オブジェクトアダプタ（ＰＯＡ）又は他のアダプタであってもよい。あるプロセスが長時間を要する場合、同ＰＯＡ内のオブジェクトへの他のリクエストの処理が、妨げられてしまう。キューがあまりにも長くなると、ＰＯＡは、TRANSIENT例外を発生させてクライアントへ返却し、リクエストを再試行するよう伝える。

リクエストがいつ到達したかを検出するため、ＯＲＢインプリメンテーションは、ネットワーク接続を監視するためのイベントループを使用する。リクエストが到達すると、ＯＲＢは、アプリケーションへとリクエストを送信する。このことが生じるために、ＯＲＢは、スレッドの制御を獲得可能でなければならない。長時間実行されるリクエストは、スレッドを拘束し、ＯＲＢ又はサーバからの他のリクエストのための使用を妨げる。このことにより、クライアントのネットワークのトランスポートは、メッセージ送信を完全に停止するか、あるいは、メッセージ送信を続行するとともにネットワークのトランスポート層からエラーを受信することにもなる。いずれにしても、長時間実行されるリクエストは、クライアントに対してサービスを拒絶することにもなりうる。

この種のリクエストのボトルネックを防止するため、
・ＩＤＬオペレーションが、複数の部分に分割されうる。
・複数のスレッドが使用されうる。

マルチスレッドを含むクライアント及びサーバプログラムを生成する能力は、ＯＲＢプログラム環境の基本的機能である。ＯＲＢプログラムにより、クライアント及びサーバは、複数のスレッドを安全かつ自然に作成及び使用可能となる。各スレッドは、自身の独立したローカル変数（すなわちスタック空間）及び自身の制御スレッドを有する。その各々は、他のスレッドの挙動に関係なく、独立して実行又はブロック可能である。

複数のスレッドを用いることにより、ＯＲＢプログラム・クライアント及びサーバのパワーが増強される。
・非ブロッキング挙動−クライアントは、クライアントのプロセス全体をブロックすることのないリモート呼出を、実行可能である。これには、同オブジェクト・インプリメンテーション上の同時呼出、及び他のオブジェクト・インプリメンテーション上の同時呼出が、含まれる。
・より望ましい応答時間−サーバは、単一又は複数の並行したクライアントからの複数のリクエストに、同時に応答可能である。各スレッドは、オペレーションのリクエストに対して、その出所にかかわらず、並行して処理及び応答することが可能である。また、並行処理により、短い処理時間で、要求の多い（“starving”）オペレーションからの長いサーバオペレーションを防止する。また、開発者は、任意のオブジェクト・インプリメンテーションのクラスの本体内における追加のスレッドを使用して、より望ましい応答時間又は追加の並行セマンティックを提供してもよい。例えば、図１１に、２つの重複したマルチスレッドのクライアント・サーバ相互作用１１００を示す。

（置換可能なトランスポート）
ほとんどの分散アプリケーションは、ネットワークインタフェースから設計される。この手法での問題点として、分散アプリケーションの設計及び結果としてのインプリメンテーションが、個々のネットワークインタフェースに縛られ、分散アプリケーションが、他の型のトランスポートとともに動作できなくなるということがある。例えば、ソケット・アプリケーションプログラムインタフェース（ＡＰＩ）の周りに設計されたアプリケーションは、切換ファブリック（switched fabric）の共有メモリインタフェース上で動作するように変更されることが、容易ではない。複数のトランスポート型に対応可能な汎用トランスポートの抽象化を提供することにより、複数のトランスポート型上で動作するアプリケーションが作成される。各トランスポートの対応は、アプリケーション開発者が自身の置換可能なトランスポートを作成可能となるように、構成される。汎用トランスポート上に、ミドルウェア・インフラを構築することにより、ミドルウェア・インフラで構築された抽象化アプリケーションも、特定のあらゆるトランスポートインタフェースから独立したものとなる。

アプリケーション開発者が、新規のトランスポートプロトコルを現行のミドルウェア・インフラ下に作成及び挿入できるということは、例えば以下の如く、多くの様式において有用である。
・アプリケーション開発者は、アプリケーション及びミドルウェアを、ミドルウェアが元々予期していないトランスポート上で、実行可能である。
・アプリケーション開発者は、現行ミドルウェアを、より予測可能なトランスポートプロトコル上で使用可能である。
・アプリケーション開発者は、ＴＣＰの貧弱なエラー回復機構の制限に煩わされることがない。

本発明の一実施形態では、トランスポートを任意のサービスのクラスでサポートしようとするユーザは、１つ以上のＱｏＳパラメータを個々のトランスポート内で指定又は定義するためのＡＰＩを、提供してもよい。これにより、ＱｏＳ方式（例えば、一定のビット速度、信頼性）が使用可能で置換可能なトランスポートがもたらされる。

上述のように、トランスポートを任意のサービスのクラスでサポートしようとするユーザは、トランスポート内でＱｏＳを指定可能である。このためには、アドレス方式（例えば、ＴＣＰ／ＩＰ−ホスト及びポート）が用いられる。また、トランスポートがサポートしうるＱｏＳパラメータは、汎用的に抽象化されている。選択肢として、送信及び受信バッファサイズが、指定可能である。ユーザが、個々のトランスポートＡＰＩに対して、どれが受入可能でどれがそうでないかを規定することが、望ましい。

図１２は、置換可能なトランスポートを提供するプロセス１２００を示すフローチャートである。そのプロセスにおいて、アプリケーションプログラマ等のユーザは、通信用のトランスポートについてＱｏＳ方式（例えば、１つ以上のＱｏＳパラメータ）をユーザが動的に選択可能な「プラグイン」モジュールを作成する。ステップ１２０２では、ユーザは、トランスポートのアドレス方式及びＱｏＳ方式を決定する。次に、ステップ１２０４では、そのトランスポートのアドレス方式及びＱｏＳ方式を用いて動作可能で置換可能なトランスポートが、生成される。ステップ１２０６では、少なくとも１つのアプリケーションが、置換可能なトランスポート上で実行されるように適合される。例えば、自動車制御システムは、コントローラエリアネットワーク（ＣＡＮ）のハードウェア及びソフトウェアにより提供されるＣＡＮ優先メディアアクセスＱｏＳ機能を、ＣＡＮの通信ソフトウェアインタフェースについての特定の知識なしに、利用するかあるいはそれにアクセスする。

ORBexpress（商標）は、ＣＯＲＢＡ技術の第３世代の実装であり、トランスポートのＱｏＳパラメータのカスタマイズ及び構成を可能とする枠組みに、対応している。ＱｏＳパラメータは、トランスポートにおける保証された帯域幅又は構成可能なコンポーネント（例えば、ルーティングアルゴリズムの選択）等のトランスポートの定量的な側面を制御するために、いくつかのトランスポートに用いられる。実際のパラメータは、トランスポートに緊密に束縛されているが、ORBexpress（商標）は、トランスポートのＱｏＳパラメータの組の定義及び管理に対する基礎レベルのサポートを、提供する。

図１３は、置換可能なトランスポートをインプリメントするのに用いられるクラス間の関係を示す例示的な図である。クラスには、回線ファクトリ１３０２、回線１３０４、アクセプタファクトリ１３０６、及びアクセプタ１３０８が、含まれている。トランスポートのＱｏＳは、アクセプタファクトリ１３０６及び回線ファクトリ１３０２のインプリメンテーションに、明示的に設定されてもよく、通信経路が生成される度に、使用されているトランスポートにより提供されるデフォルトのＱｏＳとして、生成されてもよい。リクエストがあると、回線ファクトリ１３０２は、ＯＲＢ内の回線１３０４への呼出を起動する。回線ファクトリ１３０２内で起動された通信経路のインプリメンテーションは、回線のインスタンスを適切に設定することを担当する。図１６に、回線ファクトリクラスの例示的な図を示す。

図１４に、回線クラスの例示的な図を示す。回線１３０４には、read()メソッド、write()メソッド、及びshutdown()メソッドが、含まれる。これらのメソッドの動作は、図１５にまとめられている。read()は、ネットワークからの何バイトものデータを読み取るように動作可能である。ORBexpress（商標）は、返却されたデータを、ストリーム内のセグメントとして取り扱う。返却されたデータは、部分的な汎用ＯＲＢ間プロトコル（ＧＩＯＰ：General Inter-ORB Protocol）メッセージ、完全なＧＩＯＰメッセージ、又は複数のＧＩＰメッセージであってもよい。トランスポートにより付加されたあらゆるヘッダ又は終端部は、関数の結果の返却前に除去されるべきである。実際に読み取ったバイト数が、関数の結果として返却される。ゼロ（０）又はマイナス１（−１）が返却されるということは、回線１３０４における接続又は通信経路の失敗とみなされる。呼出は、データが受信されるか、又は、接続若しくは通信経路が失敗するまで、ブロックされる。

write()は、ネットワークへとデータを書き出すように動作可能である。実際に何バイトが書き込まれたかを特定する結果が返却される前に、所定バイト数が書き込まれることになる。ゼロ（０）又はマイナス１（−１）が返却されるということは、接続又は通信経路の失敗とみなされる。shutdown()は、接続又は通信経路を遮断するように動作可能である。待機フラグは、メソッドが遮断の完結を待機すべきかどうかを示すものである。

通信経路が回線インスタンス内に一旦確立されると、図１７に示すように、アクセプタファクトリ１３０６が、アクセプタ１３０８を生成するように起動される。この図１７は、アクセプタファクトリクラスの例示的な図を示している。アクセプタ１３０８は、ＱｏＳリストを渡すか、そうでなければ、各回線１３０４インスタンスを適切に設定する。図１８に示すように、クライアントは、通信経路のアクセプタ１３０８内の中止をリクエスト可能である。それにより、通信経路は遮断されることになる。この図１８は、アクセプタクラスの例示的な図を示すものである。図１９に示すように、ORBexpress（商標）は、アクセプタ１３０８が遮断後に再利用可能であることを、想定していない。

回線１３０４は、ユーザのリクエストからのトランスポート用のＱｏＳパラメータの静的な設定を、保持している。ＱｏＳリストが一旦定義されると、図１４に示すように、そのリストは、回線１３０４の“qos_list”パラメータでアクセス可能となる。そして、置換可能なトランスポートのためのＯＲＢのリアルタイム回線選択機能に応じて、ＯＲＢは、ランタイムで複数の回線から選択を行う。

ＱｏＳパラメータは、ＯＲＢにおけるＱｏＳリスト内に定義される。より多くのパラメータを定義することにより、複数の異なるトランスポートのためのＱｏＳパラメータは、１つのＱｏＳリスト内で取得可能となり、書き込まれた個々のトランスポートのためのＱｏＳパラメータと他のトランスポートのためのものとの間で、識別可能となる。ＯＲＢは、トランスポートのパラメータを、それらの意味を知ることなく使用可能である。このことにより、トランスポート機構が何から構成されているかを気にすることなく、アプリケーションを構築することが可能となる。ＯＲＢは、ＱｏＳリストを解釈するのではなく、そのリストを格納、選択、及び送信する機構を提供するに過ぎない。特に、通信経路が一旦確立されると、リストは、回線ファクトリ１３０２、アクセプタファクトリ１３０６、及び適切なトランスポートへと送信される。

一実施形態では、ＱｏＳリストからのパラメータには、パラメータが文字列の形式で含まれている。ORBexpress（商標）のＱｏＳの枠組みの基礎は、単一の回線のためのＱｏＳパラメータのリストを表す文字列である。ＱｏＳリストの文字列は、コンマで区切られた文字列形式のＱｏＳパラメータリストである。ＱｏＳパラメータの文字列形式は、“tcp://rcvbuf=65536”等のトランスポートの端点文字列と同様である。コロンより前のテキストは、ＴＣＰ等のトランスポート名である。コロンより後のテキストは、トランスポート別のＱｏＳの規定である。なお、従来のものとの互換性のために、コロンの後でＱｏＳパラメータの前に、“//”が、オプションで置かれてもよい。コロンの前のテキストは、トランスポート名である。ＯＲＢは、パラメータを、ＴＣＰトランスポートへ送信する。トランスポートのインプリメンテーションは、ＱｏＳパラメータを解釈する。コロンより後のテキストは、ＱｏＳの規定である。トランスポートは、通信に用いられる置換可能なトランスポートのために、コロンの後の値を用いてもよい。

独立したＱｏＳリストが、例えば“RTCORBA::PriorityBand”を示すことにより、通信における優先帯域に提供されてもよい。ＱｏＳのインターセプタ、例えば“RTCORBA::QoSInterceptor”は、ＱｏＳに規定されたパラメータに基づいて、複数の優先帯域の中から選択を行ってもよい。さらに、派生クラスのインスタンスを宣言することにより、ＱｏＳインターセプタのオーバーライドが提供可能である。“tcp://rcvbuf=65536”を含んだ文字列が、ＴＣＰトランスポートへと渡されると、ＴＣＰ及びユーザ自身のトランスポートの双方が、いずれも使用されていることがあるので、ＴＣＰトランスポートは、コロンより後の値を用いることになる。従って、トランスポート別のタグを使用した方がよい。

ORBexpress（商標）内でのトランスポートの通信経路に対するＱｏＳのアプリケーションの前提をオーバーライドするということは、ＱｏＳパラメータが、新規の通信経路の生成時にのみ設定可能であるということである。しかしながら、トランスポートの動的選択を伴うトランスポートは、単一のトランスポートの通信経路のために複数の回線オブジェクトをクラス回線１３０４から生成することにより、取得されてもよい。各回線オブジェクトは、ＱｏＳパラメータの静的設定を保持可能である。そして、ＯＲＢは、置換可能なトランスポートについてのＯＲＢのリアルタイム回線選択機能に応じて、複数の回線からランタイムで選択を行うことが可能である。なお、トランスポートにＱｏＳフレームワークを用いることは、オプションである。

（ＱｏＳのスケジューリング）
従来のネットワークアプリケーションの問題点は、通信を起動したスレッドの優先度のみに基づいて通信チャネル（従って通信を完結させるのに用いられるＱｏＳ）を選択することが、低い優先度のビデオデータのスレッドが、優先度のインヘリタンス又は優先度の上限プロトコルをインプリメントする相互排他ロック（mutexes）の使用を通じてその優先度を一時的に上昇させることがありうるため、ビデオデータを音声通信チャネルを通じて送信しようとすることになりうる、ということである。ビデオデータの速度と比較して、音声通信チャネルは、割り当てられた帯域幅の小部分を有するだけなので、結果としてビデオデータを音声通信チャネル上で送ろうとする試みにより、音声データフローの極度の混乱が引き起こされうる。優先度の継承では、相互排他ロックがロックされて優先度の高いスレッドが待機している場合、優先度の低いスレッドの優先度が、迅速な完結を保証するために上昇し、相互排他ロックが、自動的に高い優先度スレッドに開放される。

また、優先度の逆転が発生することがある。すなわち、ソフトウェアは、優先度の低いスレッドが実行されて、優先度の高いスレッドがその出力を待機するように、構成されている。例えば、プログラムが飛行機を旋回させようとしていて、フラップを変化させることが必要であり、一方で、内部接続フロントエンド（ＩＦＥ）が、その変化を起動するために使用されるべきチャネルを有するということがある。フラップの割込がＩＦＥから優先度を引き継ぐように、優先度が設定されている旨を、確認しなければならない。解放された状態があれば、優先度の低いタスクは停止しうる。

従って、本発明のシステム及びメソッドにより、ＱｏＳのスケジューリングが可能となる。スケジューリングには、以下のようにいくつかの要素がある。
・ＯＳ内で動作する発送動作により、どのスレッドが次に実行されるかが決定される。
リアルタイム・オペレーティングシステム（ＲＴＯＳ）では、それは完全にプリエンプティブである。例えば、２５６の優先度があれば、２５６のキュー、及び低い優先度で実行される不使用のスレッドがある。
・リソースの保護は、次に何が実行されて何がどの準備完了キューにあるかという事項及び制御を保護するためのセマフォである。

分散システムには複数のＣＰＵがあり、そのことにより、スケジューリングが分裂してしまうことがある。スケジューリング理論は、最悪の場合の実行時間に対して作成されうる。例えば、マルチプロセッサ（例えば４プロセッサシステム）では、最悪の場合の実行時間が、利用しようとするＣＰＵ及び帯域幅をどのようにスケジューリングするのかを決定するのに、用いられてもよい。例えば、電気通信交換機は、通例、通信チャネルをビジーに保つように設計されるのに対して、防衛システムは、通例、ＣＰＵ実行時間の上界の最小のものを最適化するように設計される。

複数の通信経路が、所与のクライアント及び所与のサーバ間に開かれていることが、望ましい。これらの場合の各々において、あるスレッドが、受信側の通信経路からの読取専用となっている。所与の権限のクライアントがメッセージを作成し、同一又は同様の優先度のスレッドがそれを読み取って、情報の到達を確実にしている。

ＯＲＢは、所与の通信を実行する場合に、以下の２つの決定をしなければならない。
１．通信チャネルのうちの１つを選択する。
２．適切な優先度を得るために、リクエストをどの優先度で送信するか。

本発明の本実施形態により、開発者は、自分の通信チャネルの実行を制御可能となる。
開発者は、ある通信チャネルを使用するか他のものを使用するか決定するのに、スレッドの優先度、通信のＱｏＳ、又は比較的ビジーでない通信チャネル等の様々な事項を利用してもよい。

例えば、ＨＤＴＶをＭＰＥＧ２ストリームとして、ＡＴＭ上で送信している場合、ビデオが毎秒１９Ｍｂｉｔを費やし、音声が毎秒３８４Ｋｂｉｔを費やす。仮に、ビデオ及び音声を他のチャネルで送信したとすれば、ビデオに対してよりも、人間の聴覚には、微小な音声の分裂が感じられる。従って、視聴者は、ジッタを検出せずに、ビデオの丸々１フレームを逃す（１６．７ミリ秒のドロップアウト）こともありうるが、これに対して、音声の１ミリ秒を逃すと、検出可能な変化が起こってしまう。このため、聴覚上の分裂を避けるために、ビデオよりも音声の方が確実に高い優先度となるようにすることが、望ましい。このように、音声データを提供しているスレッドは、ビデオデータを提供しているスレッドよりも高い優先度で実行されることになる。２種のデータを通信するのに用いられる２つのチャネルが存在し、そこで、各チャネルについてのＱｏＳの設定は、データフローに要求される帯域幅に適合することになる。ＡＴＭ上の仮想回線を通信チャネルに用いると、ビデオデータのＱｏＳ設定は、一定のビット速度（ＣＢＲ：Constant Bit Rate）で毎秒１９Ｍｂｉｔが、適切であろう。ＡＴＭ上の仮想回線を通信チャネルに用いると、オーディオデータのＱｏＳ設定は、ＣＢＲで毎秒３８４Ｋｂｉｔが、適切であろう。

本システムでは、プログラマが与えたパラメータに基づいて、リクエストに応じるためのチャネル及び優先度を選択可能となっている。本発明を用いると、アプリケーションプログラマは、選択すべきサービス品質及び優先度を選択するアルゴリズムを決定することができる。例えば、図２０に、メッセージの適切なサービス品質及び優先度を決定するオブジェクト指向の手法を示す。図２１に、メッセージの適切なサービス品質及び優先度を決定する手続き型の手法を示す。当業者には、その他の手法が利用可能であることが理解されるであろう。

本発明は種々の実施形態に関連して説明されているが、当業者には、多くの修正例が容易に明らかとなるであろう。例えば、本発明の各側面は、ＯＲＢ等のミドルウェア内に実装されたものとして説明されているが、これらの側面は、リモートプロシジャコール（ＲＰＣ：Remote Procedure Call）、非ＣＯＲＢＡ分散オブジェクトシステム、メッセージ指向ミドルウェア（ＭＯＭ：Message-Oriented Middleware）、及びパブリッシュ・サブスクライブベースシステム（published-subscribed based system）等のミドルウェアの形式での他のアプリケーション上にも実装可能であることが、当業者には理解されるであろう。さらに、本発明の各側面は、メモリ内に格納されることとして説明されているが、これらの側面は、ハードディスク、フロッピーディスク、又はＣＤ−ＲＯＭのような二次記憶装置や、インターネットのようなネットワークからの搬送波、光学信号、又はデジタル信号や、現在既知であるか以降開発される他の形式のＲＡＭ又はＲＯＭ等の、他の種類のコンピュータ可読媒体に対しても読み書き可能であることが、当業者には理解されるであろう。従って、本発明は、ここでの開示内容に限定されるものではなく、そのあらゆる適用例や変形例に及ぶものである。

本発明による特徴及び側面が実施されうるコンピュータ環境の図である。 クライアントによりオブジェクト・インプリメンテーションへ送られるリクエストを示す図である。 個々のＯＲＢ（Object Request Broker）の図である。 ＯＲＢのスタブ又は動的呼出を用いるクライアントの図である。 ＯＲＢのリクエストを受信するオブジェクト・インプリメンテーションの図である。 インタフェース及びインプリメンテーションの情報を、クライアント及びオブジェクト・インプリメンテーションに利用可能とするためのフローチャートである。 ＯＲＢ内のクライアントの図である。 ＯＲＢのオブジェクト・インプリメンテーションの図である。 ＯＲＢ内のオブジェクトアダプタの図である。 クライアントがＯＲＢを通じてサーバオブジェクトへとリクエストをどのように送るかを示す図である。 ＯＲＢにおけるマルチスレッドのクライアント・サーバ相互作用の図である。 本発明による様式で、置換可能なトランスポートを提供するプロセスの例示的なフローチャートである。 本発明による様式でトランスポートをインプリメントするのに用いられるクラス間の関係を示す図である。 本発明による回線クラスの図である。 本発明による回線クラスに対応したメソッドに予期される動作を示す図である。 本発明による回線ファクトリクラスの図である。 本発明によるアクセプタファクトリクラスの図である。 本発明によるアクセプタクラスの図である。 本発明によるアクセプタクラスに対応したメソッドに予期される動作を示す図である。 メッセージの適切なサービス品質及び優先度を決定するオブジェクト指向の手法を示す図である。 メッセージの適切なサービス品質及び優先度を決定する手続き型の手法を示す図である。

Claims (47)

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. ネットワークアプリケーションにおける通信装置であって、
    リクエストを受信してメッセージを送信し、前記リクエストは、選択された通信経路及び選択されたサービスレベルの少なくとも１つを反映した情報を含み、前記の選択されたサービスレベルは、前記メッセージの配信に伴う指定されたサービス品質（ＱｏＳ）、及びサーバが前記メッセージを処理する優先度の少なくとも１つを反映しており、前記リクエストに伴う情報に基づいて、前記リクエストにサービスするための通信経路及び優先度を選択するプログラムを有するメモリと、
    前記プログラムを実行するプロセッサとを、
    備えたことを特徴とする装置。
46. コンピュータに、ネットワークアプリケーションにおける通信方法を実行させるコンピュータ可読媒体であって、前記方法は、
    リクエストを受信してメッセージを送信し、前記リクエストは、選択された通信経路及び選択されたサービスレベルの少なくとも１つを反映した情報を含み、前記の選択されたサービスレベルは、前記メッセージの配信に伴う指定されたサービス品質（ＱｏＳ）、及びサーバが前記メッセージを処理する優先度の少なくとも１つを反映しており、
    前記リクエストに伴う情報に基づいて、前記リクエストにサービスするための通信経路及び優先度を選択することを特徴とするコンピュータ可読媒体。
47. ネットワークアプリケーションにおける通信方法のための装置において、
    リクエストを受信してメッセージを送信する手段であって、前記リクエストは、選択された通信経路及び選択されたサービスレベルの少なくとも１つを反映した情報を含み、前記の選択されたサービスレベルは、前記メッセージの配信に伴う指定されたサービス品質（ＱｏＳ）、及びサーバが前記メッセージを処理する優先度の少なくとも１つを反映している手段と、
    前記リクエストに伴う情報に基づいて、前記リクエストにサービスするための通信経路及び優先度を選択する手段とを、
    備えたことを特徴とする装置。

Images