(57)【要約】【課題】プラグ可能なモジュラチャネルコンポーネントを有するランタイム通信チャネルを生成できるチャネルモデルを提供する。【解決手段】各チャネルコンポーネント１２５は、多様な形式で表されるコンポーネント間の通信セマンティクスの詳細を処理することを可能にする１組の標準インターフェースのうち１つを実装する。メッセージおよび対応する通信セマンティクスは、標準インターフェースを使用し、チャネルコンポーネントを介して再帰的に渡され、どの様に通信セマンティクスが実行されるかについての特定の実装の詳細から、他のモジュールおよびコンポーネントを抽出する。次いで、メッセージを更なる処理のために次の適切なモジュールに送ることができ、或いは、その特定のコンポーネントまたはモジュールで処理を完了できる。同様のやり方でサービス側でメッセージを多重分離することもできる。【選択図】図１Ａ
2006216033.tif 000002
【特許請求の範囲】
【請求項１】
分散システムにおいて、ランタイム通信チャネルのプラグ可能なモジュラチャネルコンポーネントを介してメッセージを再帰的に渡すことによるエンドポイント間の転送のためのメッセージ構成方法であって、該コンポーネントの夫々が、多様な様式で表される他のコンポーネントまたはモジュール間の通信セマンティクスの詳細な処理を可能にする標準インターフェースの１つを実装する方法において、
少なくともメッセージ交換パターンを含む通信セマンティクスをランタイム通信チャネルにおける第１のチャネルコンポーネントで受け取る動作であって、該セマンティクスが、前記メッセージ交換パターンに基づいて複数の標準インターフェースから選択された標準インターフェースを介して受け取られる動作、
該標準インターフェースを介して前記メッセージ交換パターンの一部であるメッセージを受け取る動作、および、
該メッセージ上の前記通信セマンティクスの少なくとも一部を実行する動作であって、前記標準インターフェースが、該実行するための実装の詳細を前記ランタイム通信チャネルと対話する他のコンポーネントまたはモジュールから抽出する動作
を含むことを特徴とする方法。
【請求項２】
前記メッセージをさらなる処理のために次の適切なモジュールまたはコンポーネントに送る動作をさらに含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記通信セマンティクスの残りの部分を前記ランタイム通信チャネルにおける第２のチャネルコンポーネントで受け取る動作であって、該残りの部分が前記標準インターフェースを介して受け取られる動作、
前記標準インターフェースを介して前記メッセージ交換パターンの一部である前記メッセージを受け取る動作、および、
前記メッセージ上の前記残りの通信セマンティクスの少なくとも一部を実行する動作であって、前記標準インターフェースが、該実行するための実装の詳細を前記他のコンポーネントまたはモジュールから抽出する動作
をさらに含むことを特徴とする請求項２に記載の方法。
【請求項４】
前記第１のチャネルコンポーネントと第２のチャネルコンポーネントの間のプロセスの順序は交換可能であることを特徴とする請求項３に記載の方法。
【請求項５】
前記メッセージおよび通信セマンティクスは、アプリケーションモジュールから受け取られることを特徴とする請求項１に記載の方法。
【請求項６】
前記メッセージおよび通信セマンティクスを前記アプリケーションモジュールから受け取るのに先立って、該モジュールは、前記ランタイム通信チャネルが前記通信セマンティクスをサポートすると判断することを特徴とする請求項５に記載の方法。
【請求項７】
前記通信セマンティクスの少なくとも一部を実行する前記動作が前記第１のチャネルコンポーネントで完了され、前記メッセージが前記他のモジュールまたはコンポーネントに渡されないようにすることを特徴とする請求項１に記載の方法。
【請求項８】
前記メッセージ交換パターンは、入力、出力、応答、または二重から選ばれることを特徴とする請求項１に記載の方法。
【請求項９】
前記ランタイム通信チャネルは、先行のランタイム通信チャネルをクライアントから受け入れることに応答して、サービスにおいて作られることを特徴とする請求項１に記載の方法。
【請求項１０】
前記通信セマンティクスは、トランスポートタイプ、エンコーディングタイプ、ユニキャストサポート、マルチキャストサポート、セッションサポート、トランザクションサポート、セキュリティサポート、プロテクションサポート、信頼性メッセージング保証、およびキューサポートのうち１つまたは複数をさらに含むことを特徴とする請求項１に記載の方法。
【請求項１１】
分散システムにおいて、サービス通信チャネルのプラグ可能なモジュラチャネルコンポーネントを介してメッセージを再帰的に渡すことによるサービス内のエンドポイントにおける消費のためのメッセージ処理方法であって、該コンポーネントの夫々が、多様な様式で表されるコンポーネントまたはモジュール間の通信セマンティクスの詳細な処理を可能にする標準インターフェースの１つを実装する方法において、
ランタイム通信チャネルを受け入れるための要求をリスナで受け取る動作、
少なくともメッセージ交換パターンを含む通信セマンティクスに対応する前記ランタイム通信チャネルを受け入れる動作、
前記通信セマンティクスに従って処理されたメッセージであって前記メッセージ交換パターンの一部であるメッセージを受け取る動作、
サービス通信チャネルを、該メッセージを前記通信セマンティクスに従って多重分離するために作る動作、
前記通信セマンティクスを前記サービス通信チャネルにおける第１のチャネルコンポーネントに、複数の標準インターフェースから前記メッセージ交換パターンに基づいて選択された標準インターフェースを介して渡す動作、
前記メッセージを前記第１のチャネルコンポーネントに、該標準インターフェースを介して前記通信セマンティクスの少なくとも一部の多重分離のために渡す動作であって、該標準インターフェースが、前記メッセージ上の前記通信セマンティクスの少なくとも一部の前記多重分離のための実装の詳細を前記サービス通信チャネルと対話する他のコンポーネントまたはモジュールから抽出する動作
を含むことを特徴とする方法。
【請求項１２】
前記通信セマンティクスは、トランスポートタイプ、エンコーディングタイプ、ユニキャストサポート、マルチキャストサポート、セッションサポート、トランザクションサポート、セキュリティサポート、プロテクションサポート、信頼性メッセージング保証、およびキューサポートのうち１つまたは複数をさらに含むことを特徴とする請求項１１に記載の方法。
【請求項１３】
前記メッセージは、前記リスナに、リスナファクトリから該リスナのためのメッセージフィルタに基づいて渡されることを特徴とする請求項１１に記載の方法。
【請求項１４】
前記メッセージ交換パターンに基づいて、前記リスナが、前記標準インターフェースを実装する１つまたは複数のプラグ可能なモジュラチャネルコンポーネントを含む別のランタイム通信チャネルを作ることを特徴とする請求項１１に記載の方法。
【請求項１５】
分散システムにおいて、サービス通信チャネルのプラグ可能なモジュラチャネルコンポーネントを介してメッセージを再帰的に渡すことによるサービス内のエンドポイントにおける消費のためのメッセージ処理方法であって、該コンポーネントの夫々が、多様な様式で表されるコンポーネントまたはモジュール間の通信セマンティクスの詳細な処理を可能にする標準インターフェースの１つを実装する方法において、
少なくともメッセージ交換パターンを含む通信セマンティクスをサービス通信チャネルにおける第１のチャネルコンポーネントで受け取る動作であって、該セマンティクスが、複数の標準インターフェースから前記メッセージ交換パターンに基づいて選択された標準インターフェースを介して受け取られる動作、
該標準インターフェースを介して、前記通信セマンティクスに従って処理されたメッセージであって前記メッセージ交換パターンの一部であるメッセージを受け取る動作、および、
該メッセージ上の前記通信セマンティクスの少なくとも一部を多重分離する動作であって、前記標準インターフェースが、該多重分離するための実装の詳細を前記サービス通信チャネルと対話する他のコンポーネントまたはモジュールから抽出する動作
を含むことを特徴とする方法。
【請求項１６】
前記通信セマンティクスは、トランスポートタイプ、エンコーディングタイプ、ユニキャストサポート、マルチキャストサポート、セッションサポート、トランザクションサポート、セキュリティサポート、プロテクションサポート、信頼性メッセージング保証、およびキューサポートのうち１つまたは複数をさらに含むことを特徴とする請求項１に記載の方法。
【請求項１７】
前記通信セマンティクスの残りの部分を前記サービス通信チャネルにおける第２のチャネルコンポーネントで受け取る動作であって、該残りの部分が前記標準インターフェースを介して受け取られる動作、
前記標準インターフェースを介して前記メッセージ交換パターンの一部である前記メッセージを受け取る動作、および、
前記メッセージ上の前記残りの通信セマンティクスの少なくとも一部を多重分離する動作であって、前記標準インターフェースが、該多重分離するための実装の詳細を前記他のコンポーネントまたはモジュールから抽出する動作
をさらに含むことを特徴とする請求項１５に記載の方法。
【請求項１８】
前記第１のチャネルコンポーネントと第２のチャネルコンポーネントの間のプロセスの順序は交換可能であることを特徴とする請求項１７に記載の方法。
【請求項１９】
前記メッセージ交換パターンは、入力、出力、要求、応答、または二重から選ばれることを特徴とする請求項１５に記載の方法。
【請求項２０】
前記通信セマンティクスの少なくとも一部を多重分離する前記動作が前記第１のチャネルコンポーネントで完了され、前記メッセージが前記他のモジュールまたはコンポーネントに渡されないようにすることを特徴とする請求項１５に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、サービス指向システムにおけるエンドポイント間のメッセージの転送に関する。より詳細には、本発明は、１組の標準インターフェースのうちの１つを利用するプラグ可能なモジュラチャネルコンポーネント（pluggable modular channel component）を有するランタイム通信チャネルを提供する。この様なシステムは、多様な形式で表されるチャネルコンポーネント間の通信セマンティクスの詳細の処理を可能にする。
【背景技術】
【０００２】
コンピュータシステムおよび関連する技術は、社会の多くの側面に影響する。実際に、コンピュータシステムの情報処理能力は、私達の生活および仕事の方法を変化させた。コンピュータシステムは、現在では、一般に、コンピュータシステムの出現前には手作業で行われていたタスク（例えば、文書処理、スケジューリング、およびデータベース管理など）のホストを行っている。さらに最近では、コンピュータシステムは、互いに結合されて、コンピュータネットワークを形成し、それらのネットワークを介して、コンピュータシステムは、データを電子的に共用することができる。サービス指向システム（例えば、Ｗｅｂサービス）は、この様なコンピュータシステム間の通信を発展させる原動力となっており、私達がソフトウェアを構築し使用する方法を徹底的に変えつつある。
【０００３】
サービス指向アーキテクチャは、それらのアプリケーションがどの様に構築されたかどんなオペレーティングシステムまたはプラットフォーム上で走っているか、並びに、それらにアクセスするためにどんなデバイスが使用されるかを問わずに、アプリケーションに、データを共有させ、より強力に他のアプリケーションからの機能を呼び出させる。一般に、これらのシステムは、ＳＯＡＰ（シンプルオブジェクトアクセスプロトコル）、ＸＭＬ（拡張マークアップ言語）、ＵＤＤＩ（ユニバーサル記述、発見、および統合（Universal Description Discovery Integration））、ＷＳＤＬ（Ｗｅｂサービス記述言語）などを含む業界標準プロトコルによって、インターネットを介して呼び出される。それらのサービスは、互いに独立したままであるが、特定のタスクを実行する共同グループとして緩やかにそれら自体を結び付けることができる。
【０００４】
しばしば、サービス指向ネットワークにおける電子通信は、サーバコンピュータシステム（以下では、「サービス」と呼ぶ）におけるネットワークサービス（例えば、Ｗｅｂサービス）にアクセスを要求する、クライアントコンピュータシステム（以下では、「クライアント」と呼ぶ）を含む。したがって、クライアントは、サービスに、そのシステムリソースに対する特定のアクセスを求める要求を送り、その場合、クライアントが許可され有効とされた場合、サービスは、例えば求められた情報を提供する応答メッセージによって応答する。もちろん、クライアントとサービスの間の他のメッセージ交換パターン（並びに、後述する他の通信セマンティック）が利用可能であり、それらは、単純な単一のメッセージとともに、例えば、通知、送信請求−応答（solicit-response）、パブリッシュ−サブスクライブ（pub-sub）パターン、キューイング（queuing）などのような、より洗練された複数メッセージの交換を含む。
【０００５】
サービスを作るために、開発者は、指定されたプログラミングモデルに従って、ソースコード（例えば、Ｃ＃、Ｃ＋＋、またはＶｉｓｕａｌ  Ｂａｓｉｃ）を書く。次いで、このソースコードは、サービスタイプにコンパイルすることができ、サービスタイプは、クライアントコンシューマ（consumer）にサービスを提供するために、サーバランタイムで実行される。しかし、異なるプログラムモデルは、異なる方法で分散メッセージング機能を実装し得る。例えば、あるプログラムモデルは、要求メッセージとそれに対応する応答メッセージの両方を、別々のメソッドを有する単一のインターフェースを使用して実装することができる。この単一インターフェースは、要求メッセージのための第１のメソッドと、対応する応答メッセージのための別の第２のメソッドを有することができる。
【０００６】
また、異なるプログラミングモデルは、異なる通信セマンティクスに従って構成され得る。例えば、各モデルは、異なる、エンコーディング、トランスポート、セキュリティオプション、高信頼メッセージングオプション（reliable messaging option）、メッセージロギングオプション（message logging option）、接続スロットリングオプション（connection throttling option）などを有することができる。したがって、同じ機能（例えば、数学演算を実行する）を実装するために設計された２つのサービスは、異なるやり方でその機能を実装することがある。
【０００７】
さらに、分散アプリケーションは、それらのプログラミングモデルに固定されていて、それらのサービスランタイムに密結合された１つのプログラミングモデルのみを許容する。したがって、互換性のために、（例えば、サービスコシューマにおける）クライアントランタイムは、通常、サーバランタイムと同じプログラミングモデルに従って開発されたクライアントプログラムまたはモジュールを利用することが必要である。例えば、サービスが、要求と応答のメッセージについて別個のインターフェースを使用して開発された、あるいは、特定のメッセージエンコーディングおよびトランスポートプロトコルを使用している場合、そのサービスコンシューマは、それらも実装しなければならない。同じプログラミングモデルに従って開発されたクライアントプログラムまたはモジュールを使用することができないと、クライアントランタイムがサービスランタイムと通信することが妨げられるおそれがある。
【０００８】
この様な固定性と、サービス開発者によって指定される特定の通信セマンティクスとの緊密な結合は、いくつかの特有の欠点を持つ。例えば、通常、会社は、独自仕様のネットワーク通信セマンティクスを使用して、会社自体のネットワーク内でサービスを分散する。それらは、使用するセキュリティ、信頼性、トランスポートおよびエンコーディングのタイプなどについて特定の要件を有することがある。その会社が、（例えば、合併または買収によって）他の会社を取得する場合、これらの特定の通信セマンティクスまたはプロトコルを、被取得会社のシステムが同様に実装できなければならない。しかし、その様な要件は非常に稀であり、したがって、被取得会社のアプリケーション（または、取得会社のアプリケーション）は、指定された通信セマンティクスに準拠して書き直されるまたは構成されなければならない。
【０００９】
容易に分かるように、この様な書直しおよび／または再構成は、費用が高くなるおそれがあり、環境に依存せずに複数のデバイスにサービスを提供するというサービス指向アーキテクチャ（例えば、Ｗｅｂサービス）の基本目的を反映していない。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
したがって、システムを要件の変更に対してより柔軟にするために、拡張可能かつプラグ可能な方法で、通信セマンティクスをモデル化する必要がある。
【課題を解決するための手段】
【００１１】
上記に示した現在の分散システムの不具合および欠点は、本発明の様々な例示的実施形態によって解消される。例えば、本発明が提供するチャネルモデルにより、ランタイム通信チャネルのプラグ可能なモジュラチャネルコンポーネントを介してメッセージを再帰的に渡すことによって、エンドポイント間転送のためのメッセージを構成することができる。各プラグ可能なモジュラチャネルコンポーネントは、多様な形式で表されるコンポーネント間の通信セマンティクスの詳細を処理することを可能にする１組の標準インターフェースの１つを実装する。
【００１２】
一例示的実施形態では、通信セマンティクスは、ランタイム通信チャネルにおける第１のチャネルコンポーネントで受け取られる。上記通信セマンティクスは少なくとも１つのメッセージ交換パターンを含み、複数の標準インターフェースから上記メッセージ交換パターンに基づいて選択された標準インターフェースを介して受け取られる。メッセージもまた、上記標準インターフェースを介して受け取られ、上記メッセージ交換パターンの一部である。したがって、上記通信セマンティクスの少なくとも一部は上記メッセージに基づいて実行でき、上記標準インターフェースが、上記ランタイム通信チャネルと対話する他のコンポーネントまたはモジュールから上記メッセージ上の上記通信セマンティクスの上記少なくとも一部を実行するための実装の詳細を抽出する。上記通信セマンティクスの上記少なくとも一部の多重分離は、チャネルコンポーネントを使用して同様の方法で実行することもできる。
【００１３】
他の例示的実施形態が提供するチャネルモデルは、メッセージを多重分離するためにランタイム通信を受け入れるように構成される。この実施形態では、ランタイム通信チャネルを受け入れることを求める要求がリスナ（listener）で受け取られる。上記ランタイム通信チャネルは次いで受け入れられ、少なくとも１つのメッセージ交換パターンを含む通信セマンティクスに対応する。上記通信セマンティクスに従って処理され、上記メッセージ交換パターンの一部であるメッセージが、その後またはその前に受け取られる。さらに、上記メッセージを上記通信セマンティクスに従って多重分離するためのサービス通信チャネルが作られ、上記通信セマンティクスは、上記サービス通信チャネルにおける第１のチャネルコンポーネントに渡すことができる。上記通信セマンティクスは、上記メッセージ交換パターンに基づいて複数の標準インターフェースから選択された標準インターフェースを介して渡される。次いで上記メッセージもまた、上記通信セマンティクスの少なくとも一部を多重分離するために上記標準インターフェースを介して第１のチャネルコンポーネントに渡され、上記標準インターフェースが、上記ランタイム通信チャネルと対話する他のコンポーネントまたはモジュールから上記メッセージ上の上記通信セマンティクスの上記少なくとも一部を実行するための実装の詳細を抽出する。
【００１４】
本発明の追加の特徴および利点は、以下の説明に示され、部分的にはその説明から明らかとなり、或いは本発明の実施によって理解することができる。本発明の特徴および利点は、特許請求の範囲に詳細に示される手段によって実現し獲得することができる。本発明の上記その他の特徴は、以下の説明および添付の特許請求の範囲からより完全に明らかとなり、或いは、以下に示されるような本発明の実施によって理解することができる。
【００１５】
本発明の上記その他の利点および特徴を得ることができる方法を説明するために、図面に示される本発明の幾つかの特定の実施形態を参照することにより、上記に簡潔に説明した本発明のより詳細な説明を与える。これらの図面は、本発明の典型的実施形態のみを示し、したがって本発明の範囲を限定するとは見なされないという理解のもと、図面を用いて追加の詳細および細部とともに本発明が記述され説明される。
【発明を実施するための最良の形態】
【００１６】
本発明は、１組の標準インターフェースのうちの１つを利用するプラグ可能なモジュラチャネルコンポーネントを有するランタイム通信チャネルのための方法、システム、およびコンピュータプログラムプロダクトに及ぶ。本発明の実施形態は、後で詳しく論じるように、様々なコンピュータハードウェアを含む専用または汎用コンピュータを含むことができる。
【００１７】
一般に、本発明は、プラグ可能なモジュラチャネルコンポーネントを有するランタイム通信チャネルを生成することができるチャネルモデルを提供する。これらのチャネルコンポーネントは、多様な形式で表されるコンポーネントまたはモジュールの間の通信セマンティクスの詳細を処理することを可能にする１組の標準インターフェースのうちの１つを実装する。図１Ａは、サービス指向システムにおける、この様な例示的通信チャネルの特定の事例を示す。
【００１８】
分散システム１００において、クライアントまたはプロキシ１０５は、サービス１６０によって提供されるサービスにアクセスすることを望み、処理のためにメッセージ１１０をサービス１６０に送る。大まかに言えば、サービス１６０は、エンドポイント１５５の集合体であり、エンドポイント１５５は、特定のタイプのメッセージを送受信することができる、ある位置にある一まとまりのコードを表す。サービスにアクセスするために、クライアントは、チャネルファクトリ（channel factory）１３０にチャネルを要求する。チャネルファクトリ１３０は、サービス１６０のエンドポイント１５５に、チャネルを作るためのメカニズムを提供する。チャネル、例えばランタイム通信チャネル１２０は、クライアント１０５とサービス１６０の間のメッセージの交換のための中核のアブストラクション（abstraction）を表す。下記でより詳細に論じるように、ランタイム通信チャネル１２０は、１組の標準インターフェースのうちの１つを使用して、様々なチャネルコンポーネント１２５およびモジュールの間の通信を行い、それによって、各チャネルコンポーネント１２５内の特定の実装の詳細を、分散システム内の他のコンポーネント１２５およびモジュールから抽出する。（本明細書では、用語の「コンポーネント」と「モジュール」は、交換可能であることに留意されたい。）
【００１９】
チャネルファクトリ１３０は、ランライム通信チャネル１２０を作り、クライアント１０５に（ランタイム通信チャネル１６５またはその識別子であり得る）ハンドル１４０を返す。次いで、クライアント１０５は、通常はサービス開発者に由来する指定された通信セマンティクスに従って、ランタイム通信チャネルを使用してメッセージ１１０をサービス１６０に渡す（ただし、通信セマンティクスは、既定値、または、サービス側のシステム管理者によって指定変更された値とすることもできることに留意されたい）。例示的実施形態は、様々な通信セマンティクス、例えばそれらが実装し得るメッセージ交換パターン（ＭＥＰ）に従って、チャネル１２０、１２５が型付けされ作られることを可能にする。メッセージ交換パターンは、クライアント１０５とサービス１６０の間、あるいは場合によっては他のサービスエンドポイント間のメッセージ通信についてのパターンを表す。現在のエンドポイントは、これらに限定されないが、単方向（例えば、出力チャネルおよび入力チャネル）要求−応答（要求チャネルおよび応答チャネル）、および二重メッセージング（duplex messaging）（二重チャネル）を含む、多数の基本的メッセージ交換パターンをサポートする。これらのＭＥＰは、充分に拡張可能であることに留意されたい。したがって、上記のＭＥＰの一部またはその変形が、必要に応じて実装され得る。さらに、後でより詳しく述べるように、これらのＭＥＰのそれぞれは、セッションフル（sessionful）であり得る。
【００２０】
他の例示的実施形態では、信頼性（例えば、ＷＳ−ＲｅｌｉａｂｌｅＭｅｓｓａｇｉｎｇ、ＨＴＴＰＲなど）、セキュリティ（例えば、ＷＳ−Ｓｅｃｕｒｉｔｙ、ＨＴＴＰＳ、署名のタイプ、暗号化のタイプなど）、チャネルがユニキャスト（unicast）またはマルチキャスト（multicast）をサポートするかどうか、セッションが、トランザクションサポート（transacted support）、キューイング、パブリッシュおよびサブスクライブ、エンコーディングメカニズム（例えば、ＳＯＡＰエンベロープ、バイナリ、テキストなど）についてサポートされているかどうか、並びに、サービスとメッセージを交換するためにどんなトランスポートを使用するか（例えば、ＨＴＴＰ（ハイパーテキスト転送プロトコル）、ＦＴＰ（ファイル転送プロトコル）、ＳＭＴＰ（簡易メール転送プロトコル）、ＴＣＰ（伝送制御プロトコル）、ＵＤＰ（ユーザデータグラムプロトコル）、ＳＭＳ（ショートメッセージサービス）、ＳＮＡ（システムネットワークアーキテクチャ）、ＧＰＲＳ（汎用パケット無線サービス（General Packet Radio Service））など）などのような他の通信セマンティクスに従って、個々のチャネルコンポーネント１２５を含むランタイム通信チャネル１２０が型付けされ作られることを可能にする。
【００２１】
ランタイム通信チャネル１２０を型付けするために使用される他の多数の通信セマンティクスのタイプがあることも留意されたい。したがって、上記のリストは、すべてを包括するものではなく、ランタイム通信チャネル１２０を作り型付けするための通信セマンティクスに対するどの特定の参照も、例示の目的のみに使用され、明示されていない限り本発明の範囲を限定したり狭めるものではない。
【００２２】
ランタイム通信チャネル１２０がどの様に型付けされ作られるかに関わらず、チャネル１２０は、入出力（Ｉ／Ｏ）アブストラクションを表し、（１）アプリケーションデータまたはメッセージ１１０（例えば、ＳＯＡＰメッセージ）を受け入れること、（２）様々な通信セマンティクス（ここでは、信頼性チャネルコンポーネント１２５、セキュリティチャネルコンポーネント１２５、およびトランスポートチャネルコンポーネント１２５として示される）を実装すること、（３）チャネルコンポーネント１２５に従って伝送のためにメッセージ１１０をフォーマットすること、並びに、（４）「ワイヤ（wire）」を介してメッセージ１１０を送信することを担当する。
【００２３】
サービス側１６０で、リスナファクトリ（listener factory）１７０は、新しいメッセージ、例えばメッセージ１１０に対する特定のネットワークアドレスをリスン（listen）し、サービスの特定のエンドポイント１５５と通信するリスナ１４５を作るためのメカニズムを提供する。特定のリスナ１４５のフィルタに合致するリスナファクトリ１７０から受け取られたメッセージ１１０が、そのリスナ１４５に送達されることができるように、各個別のリスナ１４５は、固有のメッセージフィルタ１５０を有する。つまり、リスナファクトリ１７０は、デマルチプレクサ（demux）１７５を利用して、メッセージ１１０の一部分を多重分離し、メッセージを適切なリスナ１４５に、そのメッセージフィルタ１５０に基づいて送る。
【００２４】
リスナ１４５は、サービス側１６０上で新しいランタイム通信チャネル１２０をリスンし受け入れるためのアブストラクションを表す。エンドポイント１５５は、準備ができているとき、「ａｃｃｅｐｔ  ｃｈａｎｎｅｌ」を呼び出す。新しいチャネル１２０がリスナ１４５に検出されると、「ａｃｃｅｐｔ  ｃｈａｎｎｅｌ」に対する呼出しが完了し、適切なエンドポイント１５５に新しいチャネル１２０の存在を通知する。次いで、このサービス通信チャネル１４７は、エンドポイント１５５が適切にメッセージ１１０を処理できるように、メッセージ１１０上の通信セマンティクスを多重分離するために、ランタイム通信チャネル１２０の逆のやり方で使用され得る。つまり、メッセージ１１０は、ランタイム通信チャネル１２０で実装された通信セマンティクスを多重分離するために、サービス通信チャネル１４７のプラグ可能なモジュラチャネルコンポーネントを介して再帰的に渡される。
【００２５】
別の通信チャネルが作られても、セッション通信チャネルはランタイム通信チャネル１２０と同じであり得ることに留意されたい。つまり、リスナ１４５は、同じランタイム通信チャネル１２０をちょうど逆の順序で使用することができる。したがって、サービス通信チャネル１４７は、ランタイム通信チャネル１２０を含むように広く解釈されるべきである。
【００２６】
他の例示的実施形態は、上述のメッセージ交換パターンが、コネクションレス（connectionless）チャネルと、コネクション指向チャネル例えばセッションチャネルの両方を有することができる。一般に、セッションは、メッセージ交換パターンのすべての参加者の間で共有されるコンテキストである。セッションは、３つの主要構成要素、すなわち、（１）セッション確立−すべての参加者の間の共有コンテキストを確立するためのプロセス、（２）メッセージ相関−メッセージのグループを共有コンテキストのインスタンスに関連付ける方法、および、（３）セッション終了−すべての参加者の間の共有コンテキストを終了するためのプロセスを有することができる。セッション確立とセッション終了の両方は、明示的または暗黙的にすることができることに留意されたい。つまり、（例えば、信頼性およびＴＣＰにおける）明示的セッション確立があることも、セッション確立が暗黙的である（例えば、相関ＩＤが使用される）こともある。例示的実施形態はまた、直接セッション（この場合、セッションの寿命はチャネル１２０の存続時間と対になる）、およびキューセッション（queued session）（この場合、２つの存続期間は切り離されている）であるセッションチャネルを提供する。
【００２７】
コネクションレスチャネルについては、例示的実施形態では、クライアント１０５がランタイム通信チャネル１２０を呼び出すまたは要求し得る回数と、サービス１６０がチャネル１２０を呼び出すまたは受け入れる回数の間の無相関がもたらされる（この場合、通常、これらのタイプのチャネル１２０を介して伝送されるすべてのメッセージは、データグラムと見なされる）。「直接」セッションについては、通常、クライアントがサービス１６０へのチャネル１３５を呼び出すまたは要求する回数と、サービス１６０が「ａｃｃｅｐｔ  ｃｈａｎｎｅｌ」を呼び出す回数の間の一対一対応が存在する。「キュー」セッションについては、関与する当事者間で共有される単一セッションが存在する。チャネルは、セッションの状態を変更することなく、セッションに付加する、またはセッションから切り離すことができる。したがって、クライアントがランタイム通信チャネル１２０を要求する回数と、サービス１６０がチャネル１２０を受け入れる回数の間の対応はない。
【００２８】
例示的実施形態は、通信オブジェクト（例えば、チャネルファクトリ１３０、リスナファクトリ１７０、リスナ１４５、およびチャネル１２０）が共通の状態マシンを共有することを可能にする。共通状態マシンの遷移の例は図１Ｃに示され、３つのメインの状態と３つの中間状態を有している。一般に、通信オブジェクトは、ｃｒｅａｔｅｄ１９２状態で開始する。ｃｒｅａｔｅｄ１９２状態では、オブジェクトの構成やイベント登録などが行われ得る。ユーザは、オブジェクトの構成を終了した後、Ｏｐｅｎ（）呼出しを使用して、オブジェクトをｏｐｅｎｅｄ１９６状態に移行することができる。これは、オブジェクトをアクティブおよび使用可能にする。オブジェクトがＯｐｅｎ（）呼出しの開始とＯｐｅｎ（）呼出しの完了するときの中間にある、ｃｒｅａｔｅｄ１９２状態とｏｐｅｎｅｄ１９６状態の中間状態があることに留意されたい。したがって、通信オブジェクトは、ロックダウンされ、また作用され得るが、Ｉ／Ｏは、まだ受け入れられない筈である。
【００２９】
オブジェクトは、使用可能であることを正常あるいは異常に中止することがある。オブジェクトは、Ｏｐｅｎｅｄ１９６状態からＣｌｏｓｅ（）イベントを呼び出すことによって正常に終了することができ、これにより、オブジェクトがｏｐｅｎｅｄ１９６状態からｃｌｏｓｅｄ１９８状態に移行する。あるいは、エラー状態または外部の刺激が、オブジェクトを異常終了させることがある。したがって、図１Ｃに示されるように、任意のメイン状態において、Ａｂｏｒｔ（）呼出しは、現在の状態からｃｌｏｓｅｄ１９８状態への通信オブジェクトの移行に合うように構成することができる。エラーがデータを取り扱うのに先立ち発生することがあること、および、メッセージ１１０の処理中のエラーは標準例外を介して伝搬されることに留意されたい。さらに、セッションの失敗は、Ａｂｏｒｔ（）イベントを介して伝搬されることがあることも留意されたい。
【００３０】
図１Ｂは、例示的実施形態による、ランタイム通信チャネル１２０のより詳細なモデルを示す。示されているように、通信チャネル１２０内の各オブジェクトは、標準インターフェース１８０を使用して通信する。標準インターフェース１８０は、あるモジュール１６５またはコンポーネント１８５、１９０から他に通信セマンティクスを渡す単純なインターフェースである。さらに、この標準インターフェース１８０は、前述の任意のメッセージ交換パターンに基づいて選択される１組の標準インターフェースのうちの１つである。様々なチャネルコンポーネント１８５、１９０、あるいはアプリケーション１６５も、通信セマンティクスの部分を実行することができる。次いで、残りの部分は、標準インターフェース１８０を介して、通信チャネル１２０内の次のチャネルコンポーネント１８５、１９０に渡すことができる。
【００３１】
様々なチャネルコンポーネント１８５、１９０のうち任意の１つが、メッセージ１１０上の通信セマンティクスを完了することができることに留意されたい。例えば、チャネルコンポーネントが信頼性コンポーネントであり、メッセージ１１０が複製の場合、チャネルコンポーネントは、単にメッセージ１１０を破棄することにより、通信セマンティクスを完了することができる。他の例は、より高いチャネルコンポーネントまたはモジュール（例えば、チャネルコンポーネント１８５）がこれらのメッセージ１１０について知ることなしに、より低いチャネルコンポーネント（例えば、トランスポートチャネルコンポーネント１９０）の間で交換され得るメッセージ１１０が存在する、明示的なセッションの作成を用いるプロトコルにおけるセッションの確立であり得る。したがって、メッセージ１１０は、ランタイム通信チャネル１２０と対話する各チャネルコンポーネント１８５、１９０、あるいは他のコンポーネントまたはモジュール（例えば、アプリケーションモジュール１６５）を介して伝搬されることもそうでないこともある。
【００３２】
例えば、メッセージ１１０は、アプリケーションモジュール１６５で受け取ることができ、この場合、要求−応答およびセキュリティの通信セマンティクスが受け取られる。アプリケーションモジュール１６５は、様々なチャネルコンポーネント１８５、１９０を介してこれらの通信セマンティクスを中継または委譲するために標準インターフェース１８０を使用することができ、各チャネルコンポーネントは、他のコンポーネント１８５、１９０、またはモジュール１６５の特定の実装の詳細から抽出される。例えば、チャネルコンポーネント１８５は、例えばＷＳ−Ｓｅｃｕｒｉｔｙを使用して、セキュリティコンポーネントを実装することができ、トランスポートチャネルコンポーネント１９０は、例えばＨＴＴＰを使用して、要求−応答トランスポートとすることができる。したがって、通信セマンティクスは、通信チャネル１２０内の異なるチャネルコンポーネント１８５、１９０によって実施することができ、他のコンポーネント１８５、１９０、またはモジュール１６５は、特定の実装の詳細から抽出される。
【００３３】
アブストラクションのこのレイヤのため、特定の通信セマンティクスを実行するコンポーネント１８５、１９０、またはモジュール１６５が、多様な形式で提供される。したがって、代替として、アプリケーションモジュール１６５は、同じ通信セマンティクス（すなわち、要求−応答およびセキュリティ）を、標準インターフェース１８０を介して、指示された通信セマンティクスを例えばＨＴＴＰＳを使用して実行することができる（特定のトランスポートチャネルコンポーネント１９０における）単一チャネルコンポーネントに、渡すことができる。さらに、任意の数のチャネルコンポーネント１８５が、標準インターフェース１８０を介して通信し、総体的な通信セマンティクスの部分を提供することができる。その後、チャネルコンポーネント１８５、１９０（または、モジュール、例えばアプリケーションモジュール１６５）は、残りの部分を、標準インターフェース１８０を介して渡すことができ、通信セマンティクスがどの様に層化されるかについての特定の実装から抽出されることができる。
【００３４】
上記から分かるように、各チャネルコンポーネント１８５、１９０は、充分にプラグ可能であり、したがって、新しいチャネルコンポーネント１８５、１９０が必要とされる、または古いチャネルコンポーネントが望ましくないことに応じて、それらは、総体的通信チャネル１２０に対しプラグインおよびプラグアウトすることができる。さらに、モデルは、多様な形式で表されるため、チャネル自体が拡張可能である。例えば、上記の例では、モデルを破棄することなく、要求−応答通信セマンティクスは、代替のトランスポート、例えばＴＣＰによって満たされ得る。したがって、各チャネルコンポーネント１８５は、プラグ可能であるとともに充分に拡張可能であり、それにより、通信チャネル１２０は単にメッセージ交換パターンに結び付けられる。この充分に拡張可能かつプラグ可能なモデルは、いくつかの有利な特徴を有する。例えば、更新されたバージョンおよび新しい通信セマンティクスが使用可能になるのに伴い、それらは、現在の通信チャネル１２０を破棄するまたは書き換えることなく、システム内にプラグすることができる。
【００３５】
通信チャネルは、上記の様に、ＭＥＰに束縛されているが、メッセージ交換パターン自体は、やはり拡張可能かつプラグ可能である。したがって、新しいメッセージ交換パターンが識別され展開されるとき、これらの通信セマンティクスも、上記と同様のやり方でモデル化または追加することができる。各通信コンポーネント１８５、１９０は、拡張可能かつプラグ可能であるため、本発明は、特定のメッセージ交換パターン以外のどの特定の通信セマンティクスにも拘束されない。したがって、通信セマンティクスに対するどの参照も、例示の目的のみに用いられ、明示されていない限り本発明の範囲を限定したり狭めたりするものではない。
【００３６】
また、チャネルコンポーネント１８５の順序は、交換可能であることに留意されたい。例えば、セキュリティのためのチャネルコンポーネント１８５は、信頼性のためのチャネルコンポーネント１８５の前に発生することがある。しかし、信頼性通信セマンティクスが、セキュリティ通信セマンティクスの前に生じるように、これら２つのチャネルコンポーネント１８５の順序が交換可能であり得る。したがって、他の固定モデルと異なり、現行の通信チャネルは、フレキシブル、スケーラブル、プラグ可能、かつ拡張可能である。
【００３７】
チャネルコンポーネント１８５の特定の実装の詳細はアプリケーションモジュール１６５から抽出されるが、アプリケーション１６５は、特定の通信セマンティクスがサポートされるかどうかを知る必要がある時が存在することがある。したがって本発明は、総体的通信セマンティクスの一部分を実行するかどうかを決定するために通信チャネル１２０内の様々な通信コンポーネントを照会することができるチャネルの検査および制御を可能にする。次いで、この情報はアプリケーションモジュール１６５に中継される。アプリケーションモジュール１６５は通信セマンティクスを満たすことができるかどうかを判断することができるが、どのチャネル１８５、１９０が通信セマンティクスをどの様に実行するかなどの特定の実装の詳細を依然として知ることができないことに留意されたい。
【００３８】
特定のメッセージ交換パターン、（例えば、二重ＭＥＰ）が生じた際に、逆のランタイム通信チャネル１２０が必要とされることがあることに留意されたい。したがって、他の例示的実施形態は、ランタイム通信チャネル１２０が、第１のランタイム通信チャネル１２０を受け取ることに基づいて、型付けおよび／または作られ得ることを可能にする。この実施形態では、サービス１６０およびクライアント１０５の役割は、サービス１６０が、クライアント１０５からランタイム通信チャネル１２０を受け取り受け入れた後、逆にされる。詳細には、クライアント１０５からランタイム通信チャネル１２０を受け取った後、サービス１６０は、チャネルファクトリ１３０にチャネルを要求１３５し、ハンドル１４０を受け取り、チャネルファクトリ１３０から作られたランタイム通信チャネル１２０に従って、応答メッセージを処理することができる。次いで、クライアント１０５は、上記の例示的実施形態による応答メッセージを多重分離することができる。
【００３９】
本発明は、機能ステップおよび／または非機能的動作を含む方法の観点から記述することもできる。以下は、本発明を実施する際に実行することができるステップおよび／または動作の記述である。通常、機能ステップは、達成される結果の観点から本発明を記述し、一方、非機能的動作は特定の結果を達成するためのより具体的な活動を記述する。機能ステップおよび／または非機能的動作は特定の順序で記述または請求され得るが、本発明はステップおよび／または動作のどの特定の順序にも限定される必要はない。さらに、特許請求の範囲の記載並びに図２〜図４の流れ図の以下の記述における、ステップおよび／または動作の使用は、それらの用語の望ましい特定の使用を示すために用いられている。
【００４０】
図２〜図４は、本発明の様々な例示的実施形態に関する例示的流れ図を示す。図２〜図４の以下の記述は、図１Ａ〜１Ｃにおける対応する要素を折にふれて参照する。これらの図面の特定の要素に対して参照が行われことがあるが、その様な要素は、例示の目的のみに使用され、明示されていない限り本発明の範囲を限定したり狭めるものではない。
【００４１】
図２は、ランタイム通信チャネルのプラグ可能なモジュラチャネルコンポーネントを介してメッセージを再帰的に渡すことによってエンドポイント間で転送するためにメッセージを構成する方法２００を示している例示的流れ図である。各プラグ可能なモジュラチャネルコンポーネントは、多様な形式で表されるコンポーネント間の通信セマンティクスの詳細を処理することを可能にする複数の標準インターフェースの一つを実装する。
【００４２】
方法２００は、少なくとも１つのメッセージ交換パターンを含む通信セマンティクスを受け取る動作２０５を含む。例えば、ランタイム通信チャネル１２０における第１のチャネルコンポーネント１８５は、入力、出力、要求、応答、またはこれらの任意の二重またはセッションフル状態のうちの１つまたは複数を含む、通信セマンティクスを受け取ることができる。他の通信セマンティクスは、トランスポートタイプ、エンコーディングタイプ、ユニキャストサポート、マルチキャストサポート、トランザクションサポート、セキュリティサポート、プロテクションサポート、信頼性メッセージング保証（reliable messaging guarantee）、パブリッシュおよびサブスクライブサポート、およびキューサポート（queued support）も含む。この様な通信セマンティクスは、メッセージ交換パターンに基づいて複数の標準インターフェースから選択された標準インターフェースを介して受け取られる。（すべての使用可能な選択肢を意味し得る）「セット」ではなく、２以上を意味する「複数」が、流れ図の以下の説明および特許請求の範囲の記載において使用されていることに留意されたい。したがって、本発明は、すべての標準インターフェースが選択するために使用可能であることを必要としない。）
【００４３】
方法２００はまた、メッセージ交換パターンの一部であるメッセージを標準インターフェースを介して受け取る動作２１０を含む。例えば、通信コンポーネント１８５はメッセージ１１０を標準インターフェース１８０を介して受け取ることができる。その後、方法２００は、メッセージ上の通信セマンティクスの少なくとも一部を実行する動作２１５も含む。例えば、通信セマンティクスが要求−応答メッセージ交換パターンである上記の例と同様、セキュリティ（例えば、ＷＳ−Ｓｅｃｕｒｉｔｙ）チャネルコンポーネント１８５はメッセージ上の通信セマンティクスのセキュリティ部分を実行することができる。
【００４４】
標準インターフェース１８０は、ランタイム通信チャネルと対話する他のコンポーネントまたはモジュールから、メッセージ１１０上の通信セマンティクスの少なくとも一部を実行するための実装の詳細を抽出する。例えば、第１のチャネルコンポーネント１８５内の実装の詳細は、アプリケーションモジュール１６５、トランスポートチャネルコンポーネント１９０、および、ランタイム通信チャネル１２０と対話する他のモジュールまたはコンポーネントから抽出される。
【００４５】
その後、メッセージ１１０、および、もしあればその残りの通信セマンティクスを、さらなる処理のために、次の適切なモジュールまたはコンポーネントに送られることがある（あるいは前述の様に送られないことがある）。例えば、通信コンポーネント１８５は、メッセージ１１０および任意の残りの通信セマンティクスを、標準インターフェース１８０を介して送ることができる。このプロセスは、メッセージ１１０が通信セマンティクスの多重分離のためのサービスに送られることができる時点である、すべての通信セマンティクスが実装されるまで、この様なモジュラコンポーネントを介して実行することができる。あるいは、第１のチャネルコンポーネント１８５が通信セマンティクスを完了した場合、メッセージ１１０は、ランタイム通信チャネル１２０と対話する他のチャネルコンポーネント１９０またはモジュール１６５に渡されないことになる。
【００４６】
図３は、メッセージから通信セマンティクスを多重分離するように構成されたサービス通信チャネルを作る方法３００の例示的流れ図を示す。方法３００は、ランタイム通信チャネルを受け入れるための要求を受け取る動作３０５を含む。したがって、サービス１６０で、リスナファクトリ１７０またはリスナ１４５は、メッセージ１１０を受け取ることができる。リスナファクトリ１７０は、メッセージ１１０を受け取る場合、デマルチプレクサ１７５を使用して、メッセージの一部分を多重分離し、適切なリスナ１４５を生成することができる。その後、適切なメッセージフィルタ１５０を有するリスナは、ランタイム通信チャネル１２０に送られ得る。
【００４７】
方法３００はまた、ランタイム通信チャネルを受け入れる動作３１０を含む。例えば、エンドポイント１５５の準備ができているとき、エンドポイント１５５は、「ａｃｃｅｐｔ  ｃｈａｎｎｅｌ」を呼び出し、その呼出しは、ランタイム通信チャネル１２０がリスナ１４５によって検出されたときに返すことができる。ランタイム通信チャネル１２０は、少なくとも１つのメッセージ交換パターンを含む通信セマンティクスに対応する。このメッセージ交換パターンは、上述の任意の交換パターンであっても、または任意の新しいまたは他の周知のメッセージ交換パターンであってもよい。
【００４８】
その後、方法３００は、通信セマンティクスに従って処理されたメッセージを受け取る動作３１５も含む。例えば、リスナ１４５は、信頼性、セキュリティ、および要求−応答メッセージ交換パターンの様な通信セマンティクスに従って処理されたメッセージ１１０を受け取ることができる。方法３００はさらに、サービス通信チャネルを作る動作３２０を含む。例えば、リスナ１４５はメッセージ交換パターンなどのメッセージおよび通信セマンティクスを受け取ると、通信セマンティクスに従ってメッセージを多重分離するためにサービス通信チャネル１４７を作ることができる。その後、方法３００は、メッセージ１１０の少なくとも一部を多重分離するための標準インターフェースを介して、サービス通信チャネルにおける第１のチャネルコンポーネントに通信セマンティクスおよびメッセージを渡す動作３２５を含む。標準インターフェース１８０はメッセージ交換パターンに基づいて複数の標準インターフェースから選択される。さらに、標準インターフェース１８０は、サービス通信チャネル１２０と対話する他のコンポーネントまたはモジュールからメッセージ１１０の少なくとも一部を多重分離するための実装の詳細を抽出する。
【００４９】
メッセージおよび通信セマンティクスは、ランタイム通信チャネル１２０に関して上記と同様に委譲され得る。しかし、通信セマンティクスに従ってメッセージ１１０を処理するのではなく、メッセージは多重分離され、この場合、通信セマンティクスに従って少なくとも一部のメッセージが多重分離される。その後、メッセージは他のモジュールおよびコンポーネントに処理のために再帰的に渡される（例えば、メッセージを処理し出力で応答するために、メッセージをエンドポイント１５５に処理のために送ることができる）。
【００５０】
より詳細には、図４に示されるように、本発明は、サービス通信チャネルのプラグ可能なモジュラチャネルコンポーネントを介してメッセージを再帰的に渡すことによって、サービス内のエンドポイントにおいて消費するためにメッセージを処理する方法４００を提供する。方法４００は方法３００と同様、少なくとも１つのメッセージ交換パターンを含む通信セマンティクスを受け取る動作４０５を含む。上記の様に、通信セマンティクスはメッセージ交換パターンに基づいて複数の標準インターフェースから選択された標準インターフェースを介して受け取られる。方法４００はまた、標準インターフェースを介してメッセージ交換パターンの部分であるメッセージを受け取る動作４１０を含む。メッセージ１１０は、様々な通信セマンティクス、例えば、信頼性、セキュリティ、およびメッセージ交換パターンに対する出力などの様々な通信セマンティクスに従って処理される。
【００５１】
その後、方法４００は、メッセージ上の通信セマンティクスの少なくとも一部を多重分離する動作４１５を含む。詳細には、サービス１４７は、メッセージ上にある通信セマンティクスの少なくとも一部、例えば信頼性部分を多重分離することができる。標準インターフェースは、サービス通信チャネルと対話する他のコンポーネントまたはモジュールから、メッセージ上の通信セマンティクスの少なくとも一部を多重分離するための実装の詳細を抽出する。
【００５２】
前述の様に、メッセージおよび残りの通信セマンティクスは、適切な処理のために、他のチャネルコンポーネントまたはモジュール、例えばエンドポイント１５５に送るまたは渡されることもそうでないこともある。これは、前述の様に、（例えば、メッセージ１１０が破棄される、またはより低次のコンポーネントのみの間で伝達されるとき）チャネルコンポーネントが通信セマンティクスを完了するかどうかによって条件付けされる。
【００５３】
本発明の範囲内の実施形態はまた、格納されるコンピュータ実行可能命令またはデータ構造を運搬するまたは有するためのコンピュータ可読媒体を含む。この様なコンピュータ可読媒体は、汎用または専用コンピュータによってアクセスすることができる任意の使用可能な媒体とすることができる。この様なコンピュータ可読媒体には、限定ではなく例として、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ、他の光ディスクストレージ、または他の磁気ディスク記憶装置、あるいは、所望のプログラムコード手段をコンピュータ実行可能命令またはデータ構造の形態で搬送または格納するために使用することができかつ汎用または専用コンピュータによってアクセスすることができる他の任意の媒体が含まれる。情報が、ネットワークまたは他の通信接続（有線、無線、またはそれらの組合せ）を介してコンピュータに転送または提供されるとき、このコンピュータは、その接続をコンピュータ可読媒体と見なす。したがって、その様な任意の接続は、コンピュータ可読媒体と称することが適切である。上記の組合せも、コンピュータ可読媒体の範囲内に含まれるべきである。コンピュータ実行可能命令には、例えば、汎用コンピュータ、専用コンピュータ、または専用処理装置に、特定の機能または機能群を実行させる命令およびデータが含まれる。
【００５４】
図５および以下の議論は、本発明を実装することができる適切なコンピューティング環境の簡潔な一般的記述を与えることを意図している。必須ではないが、本発明は、ネットワーク環境内のコンピュータによって実行されているプログラムモジュールの様なコンピュータ実行可能命令の一般的コンテキストで記述される。一般に、プログラムモジュールには、特定のタスクを実行しまたは特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。コンピュータ実行可能命令、関連するデータ構造、およびプログラムモジュールは、本明細書に開示の方法のステップを実行するためのプログラムコード手段の例である。この様な実行可能命令または関連するデータ構造の特定のシーケンスは、この様なステップに記述される機能を実装するための対応する動作の例を表す。
【００５５】
本発明は、パーソナルコンピュータ、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラマブル家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、およびメインフレームコンピュータなどを含む多数のタイプのコンピュータシステム構成を有するネットワークコンピューティング環境において実施することができることは当業者には理解されよう。本発明はまた、通信ネットワークを介して（有線リンク、無線リンク、またはそれらの組合せによって）リンクされたローカルおよびリモートの処理装置によってタスクが実行される、分散コンピューティング環境において実施することもできる。分散コンピューティング環境において、プログラムモジュールは、ローカルとリモートの両方もメモリ記憶装置に配置することができる。
【００５６】
図５を参照すると、本発明を実装するための例示的実施形態は、処理装置５２１、システムメモリ５２２、および、システムメモリ５２２を含めた様々なシステムコンポーネントを処理装置５２１に結合するシステムバス５２３を含む、従来のコンピュータ５２０の形態で、汎用コンピューティングデバイスを含んでいる。システムバス５２３は、任意の様々なバスアーキテクチャを使用する、メモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含めていくつかのタイプの任意のバス構造とすることができる。システムメモリは、ＲＯＭ（読取り専用メモリ）５２４、およびＲＡＭ（ランダムアクセスメモリ）５２５を含む。始動時などにコンピュータ５２０内の要素間で情報を転送する助けとなる基本的ルーチンを含むＢＩＯＳ（基本入出力システム）５２６は、ＲＯＭ５２４に格納することができる。
【００５７】
コンピュータ５２０はまた、磁気ハードディスク５３９から読み取りそれに書き込むための磁気ハードディスクドライブ５２７、リムーバル磁気ディスク５２９から読み取りそれに書き込むための磁気ディスクドライブ５２８、および、ＣＤ−ＲＯＭまたは他の光媒体などのリムーバル光ディスク５３１から読み取りそれに書き込むための光ディスクドライブ５３０を含むことができる。磁気ハードディスクドライブ５２７、磁気ディスクドライブ５２８、および光ディスクドライブ５３０は、それぞれ、ハードディスクドライブインターフェース５３２、磁気ディスクドライブインターフェース５３３、および光ディスクドライブインターフェース５３４によってシステム５２３に接続される。ドライブおよびそれらに関連するコンピュータ可読媒体は、コンピュータ５２０のためのコンピュータ実行可能命令、データ構造、プログラムモジュール、および他のデータの不揮発性ストレージを提供する。本明細書に記載の例示的実施形態では、磁気ハードディスク５３９、リムーバル磁気ディスク５２９、およびリムーバル光ディスク５３１を使用しているが、磁気カセット、フラッシュメモリカード、ＤＶＤ、Ｂｅｒｎｏｕｌｉ カートリッジ、ＲＡＭ、およびＲＯＭなどを含めて、データを格納するための他のタイプのコンピュータ可読媒体を使用することもできる。
【００５８】
オペレーティングシステム５３５、１つまたは複数のアプリケーションプログラム５３６、他のプログラムモジュール５３７、およびプログラムデータ５３８を含め、１つまたは複数のプログラムモジュールを含むプログラムコード手段は、ハードディスク５３９、磁気ディスク５２９、光ディスク５３１、ＲＯＭ５２４、またはＲＡＭ５２５に格納することができる。ユーザは、キーボード５４０、ポインティングデバイス５４２、または、マイク、ジョイスティック、ゲームパッド、パラボラアンテナ、スキャナなどのような他の入力装置（図示せず）を介して、コンピュータ５２０に、コマンドおよび情報を入力することができる。上記および他の入力装置は、しばしば、システムバス５２３に結合されるシリアルポートインターフェース５４６を介して処理装置５２１に接続される。あるいは、入力装置は、パラレルポート、ゲームポート、ＵＳＢ（ユニバーサルシリアルポート）の様な他のインターフェースによって接続することができる。モニタ５４７または他の表示装置もまた、ビデオアダプタ５４８の様なインターフェースを介してシステムバス５２３に接続される。モニタに加えて、パーソナルコンピュータは、通常、スピーカやプリンタの様な他の出力周辺装置（図示せず）を含む。
【００５９】
コンピュータ５２０は、リモートコンピュータ５４９ａおよび５４９ｂなど１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク化された環境で動作する。図５では、メモリ記憶装置５５０ａおよび５５０ｂとそれらに関連するアプリケーションプログラム５３６ａおよび５３６ｂのみが図示されているが、リモートコンピュータ５４９ａおよび５４９ｂはそれぞれ、他のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他の共通ネットワークノードとすることができ、通常、コンピュータ５２０に関係する上記の要素の多くまたは全部を含む。図５に示す論理接続は、ＬＡＮ（ローカルエリアネットワーク）５５１、およびＷＡＮ（広域ネットワーク）５５２を含むが、それらは、限定ではなく例として示されている。この様なネットワーク環境は、オフィスまたは企業規模のコンピュータネットワーク、イントラネット、およびインターネットにおいて一般的である。
【００６０】
ＬＡＮネットワーク環境で使用する場合、コンピュータ５２０は、ネットワークインターフェースまたはアダプタ５５３を介してローカルネットワーク５５１に接続される。ＷＡＮネットワーク環境で使用する場合、コンピュータ５２０は、通常、モデム５５４、無線リンク、または、インターネットなどのＷＡＮ５５２を介して接続を確立する他の手段を含む。モデム５５４は、内蔵でも外部でもよく、シリアルポートインターフェース５４６を介してシステムバス５２３に接続される。ネットワーク環境では、コンピュータ５２０に関係して示されたプログラムモジュールまたはその部分をリモートメモリ記憶装置に格納することができる。ここに示したネットワーク接続は例示であり、ＷＡＮ５５２を介して接続を確立する他の手段を使用することもできることは理解されよう。
【００６１】
本発明は、本発明の趣旨または本質的特徴から逸脱することなく他の特定の形態で実施することもできる。記載の実施形態は、すべての点において単に例示であって限定ではないと見なすべきである。したがって、本発明の範囲は、以上の説明よりむしろ添付の特許請求の範囲によって示される。請求項の範囲の均等物の意味および範囲に含まれるすべての変更は、それらの範囲に包含されるべきである。
【図面の簡単な説明】
【００６２】
【図１Ａ】本発明の例示的実施形態に従って生成されたランタイム通信チャネルを有する分散システムを示す図である。
【図１Ｂ】例示的実施形態による、ランタイム通信チャネルのチャネルコンポーネント間の１組の標準インターフェースのうちの１つの使用を示す図である。
【図１Ｃ】例示的実施形態による、一般的な状態マシン遷移を示す図である。
【図２】例示的実施形態による、エンドポイント間の転送のためにメッセージを構成する方法を示す流れ図である。
【図３】例示的実施形態による、ランタイムチャネルを受け入れるための方法を示す流れ図である。
【図４】例示的実施形態による、エンドポイントにおける消費のためのメッセージの多重分離の方法を示す流れ図である。
【図５】本発明のための適切な動作環境を提供する例示的システムを示す図である。
【符号の説明】
【００６３】
１０５  クライアント／プロキシ
１１０  メッセージ
１２０  ランタイム通信チャネル
１３０  チャネルファクトリ
１４０  ハンドル
１４５  リスナ
１５０  メッセージフィルタ
１５５  エンドポイント
１６０  サービス
１６５  アプリケーションモジュール
１７０  リスナファクトリ
１８０  標準インターフェース
１８５  チャネルコンポーネント
１９０  トランスポートチャネルコンポーネント
５２１  処理装置
５２２  システムメモリ
５２３  システムバス
５２６  ＢＩＯＳ
５３２  ハードディスクドライブインターフェース
５３３  磁気ディスクドライブインターフェース
５３４  光ドライブインターフェース
５３５  オペレーティングシステム
５３６  アプリケーションプログラム
５３６ａ  アプリケーションプログラム
５３６ｂ  アプリケーションプログラム
５３７  他のプログラムモジュール
５３８  プログラムデータ
５４０  キーボード
５４６  シリアルポートインターフェース
５４７  モニタ
５４８  ビデオアダプタ
５４９ａ  リモートコンピュータ
５４９ｂ  リモートコンピュータ
５５１  ＬＡＮ
５５２  ＷＡＮ
５５３  ネットワークインターフェース
５５４  モデム
【図１Ａ】
2006216033.tif 000003
【図１Ｂ】
2006216033.tif 000004
【図１Ｃ】
2006216033.tif 000005
【図２】
2006216033.tif 000006
【図３】
2006216033.tif 000007
【図４】
2006216033.tif 000008
【図５】
2006216033.tif 000009