(57)【要約】【課題】  メッセージングインフラストラクチャ内で処理レイヤを抽象化して、既存の機能を使用し続けながら、変更または強化をインフラストラクチャに行うことができるようにする。【解決手段】  メッセージトランスポート実装がメッセージレイヤ内で抽象化され、インフラストラクチャ内の他のレイヤが、メッセージトランスポートにおおむね関係なく、より一般的な方法でメッセージと対話できるようにする。メッセージレイヤの上のチャネルレイヤは、メッセージ交換実装を抽象化して、インフラストラクチャ内の他のレイヤが、特定の実装のメッセージ交換セマンティクスにおおむね関係なく、より一般的な方法でメッセージを送信および受信できるようにする。チャネルレイヤおよびメッセージレイヤの上のサービスレイヤは、バインディング実装を抽象化し、これはメッセージ交換実装をユーザコード実装にバインドする。【選択図】  図３
2004295898.tif 000002
【特許請求の範囲】
【請求項１】
メッセージングインフラストラクチャを実装し、前記インフラストラクチャ内で様々な処理レイヤを抽象化するコンピュータプログラムであって、前記インフラストラクチャは、ベースレベルのメッセージング機能を提供し、前記抽象処理レイヤは、他の抽象処理レイヤにおいて提供された前記ベースレベルのメッセージング機能を必ずしも再実装する必要なしに、変更または強化を行うことができるように拡張可能であり、前記コンピュータプログラムは、コンピュータ実行可能命令をプログラムモジュールの形態で担持する１または複数のコンピュータ読取り可能媒体に格納され、前記プログラムモジュールは、
１または複数のメッセージのエンドポイントツーエンドポイント伝送を提供し、１または複数のメッセージトランスポートプロトコルのためのサポートを実装する、１または複数のメッセージングレイヤモジュールと、
メッセージ交換セマンティクスを前記１または複数のメッセージレイヤモジュールの上に提供する１または複数のチャネルレイヤモジュールと、
１または複数のプログラミングモデルを前記１または複数のチャネルレイヤモジュールの上に提供して、前記メッセージングインフラストラクチャの１または複数の機能をエクスポーズすることによって、前記メッセージングインフラストラクチャと対話し、前記メッセージングインフラストラクチャを使用するように設計されたソフトウェアによってアクセスされる、１または複数のサービスレイヤモジュールと
を備えたことを特徴とするコンピュータプログラム。
【請求項２】
前記１または複数のメッセージトランスポートプロトコルは、名前付きパイプ、ＴＣＰ、ＨＴＴＰおよびＳＭＴＰのうち少なくとも１つを備えることを特徴とする請求項１に記載のコンピュータプログラム。
【請求項３】
前記１または複数のメッセージングレイヤモジュールは、メッセージがエンドポイントから離れるか、あるいはそれに到着するとき、メッセージインターセプションを可能にすることを特徴とする請求項１に記載のコンピュータプログラム。
【請求項４】
前記１または複数のメッセージングレイヤモジュールは、ルーティング、フィルタリング、ポリシー管理、ロギング、トランザクションおよびセキュリティのうち少なくとも１つを備えるビヘイビアを実装することを特徴とする請求項３に記載のコンピュータプログラム。
【請求項５】
前記１または複数のチャネルレイヤモジュールは、（ｉ）単方向の無相関メッセージングのためのデータグラムチャネル、（ｉｉ）双方向の相関メッセージングのためのダイアログチャネル、（ｉｉｉ）公開／購読メッセージングを含む、単方向のブロードキャストメッセージングのためのモノローグチャネル、および（ｉｖ）単方向の待機メッセージングのためのキューチャネルのうち、少なくとも１つを実装することを特徴とする請求項１に記載のコンピュータプログラム。
【請求項６】
前記１または複数のプログラミングモデルを前記１または複数のチャネルレイヤモジュールの上に提供する前記１または複数のサービスレイヤモジュールは、１または複数のウェブサービス記述言語（ＷＳＤＬ）のポート型と、前記メッセージングインフラストラクチャ内の１または複数の管理される型との間の直接マッピングを実装することを特徴とする請求項１に記載のコンピュータプログラム。
【請求項７】
前記１または複数のメッセージングレイヤモジュールは、アトミックメッセージ送信／受信の抽象化を前記１または複数のチャネルレイヤモジュールに提供するポートを備えることを特徴とする請求項１に記載のコンピュータプログラム。
【請求項８】
前記１または複数のチャネルレイヤモジュールは、メッセージを収集して相関させ、かつ高レベルチャネル抽象化を前記１または複数のサービスレイヤモジュールに提示するチャネルマネージャを備えることを特徴とする請求項１に記載のコンピュータプログラム。
【請求項９】
前記１または複数のサービスレイヤモジュールは、前記１または複数のサービスレイヤモジュールの少なくとも１つと、前記１または複数のチャネルレイヤモジュールの少なくとも１つとの間に、１または複数の接続を確立することによって、前記メッセージングインフラストラクチャを調整するサービスマネージャを備えることを特徴とする請求項１に記載のコンピュータプログラム。
【請求項１０】
前記サービスマネージャは、１または複数のタスクを、前記１または複数のタスクについて適切な前記インフラストラクチャ内の他のモジュールに委託することによって、拡張可能性をサポートすることを特徴とする請求項９に記載のコンピュータプログラム。
【請求項１１】
前記１または複数のチャネルレイヤモジュールは、１または複数のチャネルインスタンスを備え、前記１または複数のサービスレイヤモジュールは、１または複数のサービスバインダ、１または複数のサービスインスタンス、および、前記１または複数のチャネルインスタンスを前記１または複数のサービスインスタンスにバインドする１または複数のサービスプロキシを備えることを特徴とする請求項９に記載のコンピュータプログラム。
【請求項１２】
前記１または複数のサービスインスタンスは、前記メッセージングインフラストラクチャと対話するためのユーザコードの１または複数のインスタンスを表現し、前記１または複数のチャネルインスタンスは、前記１または複数のサービスインスタンスに向かうか、またはそこから発する特定の型の１または複数のメッセージを処理するための１または複数のチャネルの１または複数のインスタンスを表現し、前記１または複数のサービスバインダは、どのように前記１または複数のサービスインスタンスおよび前記１または複数のチャネルインスタンスが、前記１または複数のサービスプロキシを通じて互いに関係し、通信するかを管理することを特徴とする請求項１１に記載のコンピュータプログラム。
【請求項１３】
前記１または複数のサービスレイヤモジュールは、（ｉ）前記１または複数のサービスインスタンスのための物理的ライフタイムを管理するサービスストア、および（ｉｉ）前記１または複数のサービスインスタンスに流れ込み、およびそこから流れ出る１または複数のメッセージをインターセプトする１または複数のサービス拡張を備え、前記１または複数のサービス拡張は、ルーティング、フィルタリング、ポリシー管理およびセキュリティのうち少なくとも１つを備えるビヘイビアを実装することを特徴とする請求項１２に記載のコンピュータプログラム。
【請求項１４】
１または複数のメッセージを処理するためのある初期機能を提供する複数の処理レイヤを備えるメッセージングインフラストラクチャにおいて、前記メッセージングインフラストラクチャ内で前記複数の処理レイヤを抽象化して、前記ある初期機能を使用し続けながら、後の変更または強化を前記メッセージングインフラストラクチャに行うことができるようにする方法であって、
前記メッセージングインフラストラクチャ内で１または複数のより高いレイヤのための１または複数のメッセージトランスポートの実装を抽象化するメッセージレイヤインタフェースを定義する動作と、
チャネルレイヤインタフェースを前記メッセージレイヤインタフェースの上に定義する動作であって、前記チャネルレイヤインタフェースは、前記メッセージングインフラストラクチャ内で１または複数のより高いレイヤのための１または複数のメッセージ交換の実装を抽象化する動作と、
サービスレイヤインタフェースを前記チャネルレイヤインタフェースの上に定義する動作であって、前記サービスレイヤインタフェースは、前記１または複数のメッセージ交換の実装を、前記チャネルレイヤインタフェースを通じて、前記メッセージングインフラストラクチャの上に構築された１または複数のメッセージ処理の実装のためのユーザコードにバインドする１または複数のバインディング実装を抽象化する動作と
を備えることを特徴とする方法。
【請求項１５】
前記サービスレイヤインタフェースは、少なくとも部分的には、前記メッセージングインフラストラクチャを使用するためのプログラミングモデルを記述することを特徴とする請求項１４に記載の方法。
【請求項１６】
前記プログラミングモデルは、１または複数のウェブサービス記述言語（ＷＳＤＬ）のポート型と、前記メッセージングインフラストラクチャ内の１または複数の管理される型との間のマッピングを指定することを特徴とする請求項１４に記載の方法。
【請求項１７】
前記メッセージレイヤインタフェース、チャネルレイヤインタフェースおよびサービスレイヤインタフェースは、前記１または複数のメッセージトランスポート実装、前記１または複数のメッセージ交換実装、および前記１または複数のバインディング実装のための複数のプログラムモジュールにそれぞれ対応することを特徴とする請求項１４に記載の方法。
【請求項１８】
前記１または複数のメッセージトランスポートプロトコルは、名前付きパイプ、ＴＣＰ、ＨＴＴＰおよびＳＭＴＰのうち少なくとも１つを備えることを特徴とする請求項１４に記載の方法。
【請求項１９】
前記１または複数のメッセージ交換の実装は、（ｉ）単方向の無相関メッセージングのためのデータグラムチャネル、（ｉｉ）双方向の相関メッセージングのためのダイアログチャネル、（ｉｉｉ）公開／購読メッセージングを含む、単方向のブロードキャストメッセージングのためのモノローグチャネル、および（ｉｖ）単方向の待機メッセージングのためのキューチャネルのうち、少なくとも１つを備えることを特徴とする請求項１４に記載の方法。
【請求項２０】
前記メッセージレイヤインタフェースは、それぞれアトミックメッセージ送信／受信の抽象化を提供する１または複数のポートをさらに抽象化することを特徴とする請求項１４に記載の方法。
【請求項２１】
前記１または複数のバインディング実装は、前記１または複数のメッセージ交換の実装を、前記メッセージングインフラストラクチャの上に構築された前記１または複数のメッセージ処理の実装にバインドすることを行う１または複数のサービスバインダの実装を備えることを特徴とする請求項１４に記載の方法。
【請求項２２】
前記１または複数のサービスバインダ実装は、１または複数のサービスプロキシ実装を使用して、前記１または複数のメッセージ交換の実装を、前記メッセージングインフラストラクチャの上に構築された前記１または複数のメッセージ処理の実装にバインドすることを行うことを特徴とする請求項２１に記載の方法。
【請求項２３】
前記メッセージングインフラストラクチャは、前記１または複数のメッセージ交換の実装の１または複数のインスタンス、および、前記１または複数のメッセージ処理の実装の１または複数のインスタンスを備え、別のサービスプロキシインスタンスは、前記１または複数の各メッセージ交換インスタンスを、対応するメッセージ処理インスタンスにバインドすることを特徴とする請求項２２に記載の方法。
【請求項２４】
前記サービスレイヤインタフェースは、前記１または複数のメッセージ処理インスタンスのための物理的ライフタイムを管理するサービスストア実装を抽象化することを特徴とする請求項２３に記載の方法。
【請求項２５】
１または複数のメッセージを処理するためのある初期機能を提供する複数の処理レイヤを備えるメッセージングインフラストラクチャについて、前記メッセージングインフラストラクチャ内で前記複数の処理レイヤを抽象化して、前記ある初期機能を使用し続けながら、後の変更または強化を前記メッセージングインフラストラクチャに行うことができるようにする方法を実施するコンピュータ実行可能命令を担持する１または複数のコンピュータ読取り可能媒体に格納されたコンピュータプログラムであって、前記方法は、
前記メッセージングインフラストラクチャ内で１または複数の他のレイヤのための１または複数のメッセージトランスポートの実装を抽象化するメッセージレイヤインタフェースを定義する動作と、
チャネルレイヤインタフェースを前記メッセージレイヤインタフェースの上に定義する動作であって、前記チャネルレイヤインタフェースは、前記メッセージングインフラストラクチャ内で１または複数の他のレイヤのための１または複数のメッセージ交換の実装を抽象化する動作と、
サービスレイヤインタフェースを前記チャネルレイヤインタフェースの上に定義する動作であって、前記サービスレイヤインタフェースは、前記１または複数のメッセージ交換の実装を、前記チャネルレイヤインタフェースを通じて、前記メッセージングインフラストラクチャの上に構築された１または複数のメッセージ処理の実装のためのユーザコードにバインドする１または複数のバインディング実装を抽象化する動作と
を備えることを特徴とするコンピュータプログラム。
【請求項２６】
前記サービスレイヤインタフェースは、少なくとも部分的には、前記メッセージングインフラストラクチャを使用するためのプログラミングモデルを記述することを特徴とする請求項２５に記載のコンピュータプログラム。
【請求項２７】
前記メッセージレイヤインタフェース、チャネルレイヤインタフェースおよびサービスレイヤインタフェースは、前記１または複数のメッセージトランスポート実装、前記１または複数のメッセージ交換実装、および前記１または複数のバインディング実装のための複数のプログラムモジュールにそれぞれ対応することを特徴とする請求項２５に記載のコンピュータプログラム。
【請求項２８】
前記１または複数のメッセージトランスポートプロトコルは、名前付きパイプ、ＴＣＰ、ＨＴＴＰおよびＳＭＴＰのうち少なくとも１つを備えることを特徴とする請求項２５に記載のコンピュータプログラム。
【請求項２９】
前記１または複数のメッセージ交換の実装は、（ｉ）単方向の無相関メッセージングのためのデータグラムチャネル、（ｉｉ）双方向の相関メッセージングのためのダイアログチャネル、（ｉｉｉ）公開／購読メッセージングを含む、単方向のブロードキャストメッセージングのためのモノローグチャネル、および（ｉｖ）単方向の待機メッセージングのためのキューチャネルのうち、少なくとも１つを備えることを特徴とする請求項２５に記載のコンピュータプログラム。
【請求項３０】
前記メッセージレイヤインタフェースは、それぞれアトミックメッセージ送信／受信の抽象化を提供する１または複数のポートをさらに抽象化することを特徴とする請求項２５に記載のコンピュータプログラム。
【請求項３１】
前記１または複数のバインディング実装は、前記１または複数のメッセージ交換の実装を、前記メッセージングインフラストラクチャの上に構築された前記１または複数のメッセージ処理実装に前記バインドすることを行う１または複数のサービスバインダ実装を備えることを特徴とする請求項２５に記載のコンピュータプログラム。
【請求項３２】
前記１または複数のサービスバインダ実装は、１または複数のサービスプロキシ実装を使用して、前記１または複数のメッセージ交換の実装を、前記メッセージングインフラストラクチャの上に構築された前記１または複数のメッセージ処理の実装にバインドすることを行うことを特徴とする請求項２５に記載のコンピュータプログラム。
【請求項３３】
前記メッセージングインフラストラクチャは、前記１または複数のメッセージ交換の実装の１または複数のインスタンス、および、前記１または複数のメッセージ処理の実装の１または複数のインスタンスを備え、別のサービスプロキシインスタンスは、前記１または複数の各メッセージ交換インスタンスを、対応するメッセージ処理インスタンスにバインドし、前記サービスレイヤインタフェースは、前記１または複数のメッセージ処理インスタンスのための物理的ライフタイムを管理するサービスストア実装を抽象化することを特徴とする請求項３２に記載のコンピュータプログラム。
【請求項３４】
１または複数のメッセージを処理するためのある初期機能を提供する複数の処理レイヤを備えるメッセージングインフラストラクチャにおいて、前記メッセージングインフラストラクチャ内で前記複数の処理レイヤを抽象化して、前記ある初期機能を使用し続けながら、後の変更または強化を前記メッセージングインフラストラクチャに行うことができるようにする方法であって、
メッセージレイヤ内で、前記メッセージングインフラストラクチャ内で１または複数の他のレイヤにおいて使用するための１または複数のメッセージトランスポートの実装を抽象化するステップと、
前記メッセージレイヤの上のチャネルレイヤ内で、前記メッセージングインフラストラクチャ内で１または複数の他のレイヤにおいて使用するための１または複数のメッセージ交換の実装を抽象化するステップと、
前記チャネルレイヤの上のサービスレイヤ内で、前記１または複数のメッセージ交換の実装を、前記メッセージングインフラストラクチャを使用する１または複数のメッセージ処理の実装に対応するユーザコードにバインドするための１または複数のバインディング実装を抽象化するステップと
を備えることを特徴とする方法。
【請求項３５】
前記サービスレイヤは、少なくとも部分的には、前記メッセージングインフラストラクチャを使用するためのプログラミングモデルを記述することを特徴とする請求項３４に記載の方法。
【請求項３６】
前記メッセージレイヤ抽象化、前記チャネルレイヤ抽象化および前記サービスレイヤ抽象化は、前記１または複数のメッセージトランスポート実装、前記１または複数のメッセージ交換実装、および前記１または複数のバインディング実装のための複数のプログラムモジュールに対応することを特徴とする請求項３４に記載の方法。
【請求項３７】
前記メッセージレイヤ抽象化は、それぞれアトミックメッセージ送信／受信の抽象化を提供する１または複数のポートをさらに抽象化することを特徴とする請求項３４に記載の方法。
【請求項３８】
前記メッセージングインフラストラクチャは、前記１または複数のメッセージ交換の実装の１または複数のインスタンス、および、前記１または複数のメッセージ処理の実装の１または複数のインスタンスを備え、前記１または複数のバインディング実装は、１または複数のサービスプロキシインスタンスを使用して、各メッセージ交換インスタンスを対応するメッセージ処理インスタンスにバインドする１または複数のサービスバインダ実装を備えることを特徴とする請求項３７に記載の方法。
【請求項３９】
前記サービスレイヤ抽象化は、前記１または複数のメッセージ処理インスタンスのための物理的ライフタイムを管理するサービスストア実装をさらに抽象化することを特徴とする請求項３８に記載の方法。
【請求項４０】
前記１または複数のメッセージトランスポートプロトコルは、名前付きパイプ、ＴＣＰ、ＨＴＴＰおよびＳＭＴＰのうち少なくとも１つを備えることを特徴とする請求項３９に記載の方法。
【請求項４１】
前記１または複数のメッセージ交換の実装は、（ｉ）単方向の無相関メッセージングのためのデータグラムチャネル、（ｉｉ）双方向の相関メッセージングのためのダイアログチャネル、（ｉｉｉ）公開／購読メッセージングを含む、単方向のブロードキャストメッセージングのためのモノローグチャネル、および（ｉｖ）単方向の待機メッセージングのためのキューチャネルのうち、少なくとも１つを備えることを特徴とする請求項４０に記載の方法。
【請求項４２】
１または複数のメッセージを処理するためのある初期機能を提供する複数の処理レイヤを備えるメッセージングインフラストラクチャについて、前記メッセージングインフラストラクチャ内で前記複数の処理レイヤを抽象化して、前記ある初期機能を使用し続けながら、後の変更または強化を前記メッセージングインフラストラクチャに行うことができるようにする方法を実施するコンピュータ実行可能命令を担持する１または複数のコンピュータ読取り可能媒体に格納されたコンピュータプログラムであって、前記方法は、
メッセージレイヤ内で、前記メッセージングインフラストラクチャ内で１または複数の他のレイヤにおいて使用するための１または複数のメッセージトランスポートの実装を抽象化するステップと、
前記メッセージレイヤの上のチャネルレイヤ内で、前記メッセージングインフラストラクチャ内で１または複数の他のレイヤにおいて使用するための１または複数のメッセージ交換の実装を抽象化するステップと、
前記チャネルレイヤの上のサービスレイヤ内で、前記１または複数のメッセージ交換の実装を、前記メッセージングインフラストラクチャを使用する１または複数のメッセージ処理の実装に対応するユーザコードにバインドするための１または複数のバインディング実装を抽象化するステップと
を備えることを特徴とするコンピュータプログラム。
【請求項４３】
前記サービスレイヤは、少なくとも部分的には、前記メッセージングインフラストラクチャを使用するためのプログラミングモデルを記述することを特徴とする請求項４２に記載のコンピュータプログラム。
【請求項４４】
前記メッセージレイヤ抽象化、前記チャネルレイヤ抽象化および前記サービスレイヤ抽象化は、前記１または複数のメッセージトランスポート実装、前記１または複数のメッセージ交換実装、および前記１または複数のバインディング実装のための複数のプログラムモジュールに対応することを特徴とする請求項４２に記載のコンピュータプログラム。
【請求項４５】
前記メッセージレイヤ抽象化は、それぞれアトミックメッセージ送信／受信の抽象化を提供する１または複数のポートをさらに抽象化することを特徴とする請求項４２に記載のコンピュータプログラム。
【請求項４６】
前記メッセージングインフラストラクチャは、前記１または複数のメッセージ交換の実装の１または複数のインスタンス、および、前記１または複数のメッセージ処理の実装の１または複数のインスタンスを備え、前記１または複数のバインディング実装は、１または複数のサービスプロキシインスタンスを使用して、各メッセージ交換インスタンスを対応するメッセージ処理インスタンスにバインドする１または複数のサービスバインダ実装を備えることを特徴とする請求項４５に記載のコンピュータプログラム。
【請求項４７】
前記サービスレイヤ抽象化は、前記１または複数のメッセージ処理インスタンスのための物理的ライフタイムを管理するサービスストア実装をさらに抽象化することを特徴とする請求項４６に記載のコンピュータプログラム。
【請求項４８】
前記１または複数のメッセージトランスポートプロトコルは、名前付きパイプ、ＴＣＰ、ＨＴＴＰおよびＳＭＴＰのうち少なくとも１つを備えることを特徴とする請求項４７に記載のコンピュータプログラム。
【請求項４９】
前記１または複数のメッセージ交換の実装は、（ｉ）単方向の無相関メッセージングのためのデータグラムチャネル、（ｉｉ）双方向の相関メッセージングのためのダイアログチャネル、（ｉｉｉ）公開／購読メッセージングを含む、単方向のブロードキャストメッセージングのためのモノローグチャネル、および（ｉｖ）単方向の待機メッセージングのためのキューチャネルのうち、少なくとも１つを備えることを特徴とする請求項４２に記載のコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はメッセージングインフラストラクチャに関する。より詳細には、本発明は、メッセージングインフラストラクチャ内で処理レイヤを抽象化して、既存の機能を再実装する必要なしに変更または強化を行うことができるようにする方法、システムおよびコンピュータプログラムに関する。
【背景技術】
【０００２】
今日の強力なネットワークの多数が提供するコンピュータ間の接続性が高まるにつれて、分散処理は、より幅広い範囲のアプリケーションにとってますます魅力的になっている。しかし、分散アプリケーションを開発するための大部分の現代のインフラストラクチャは、利用できる新しい通信技術の中から選択することについて、柔軟性をほとんど提供しない。例えば、プログラミングモデル、メッセージ交換セマンティクス、およびメッセージトランスポートは、密結合される傾向がある。結果として、いずれか１つの選択がしばしば他のものを決定づける。
【０００３】
図１Ａは、分散コンポーネントオブジェクトモデル（ＤＣＯＭ）に基づいた、従来技術の密結合メッセージングインフラストラクチャ１００Ａを例示する。ＤＣＯＭは、コンポーネントがネットワーク内でもネットワーク境界を越えても通信できるようにするコンポーネントオブジェクトモデル（ＣＯＭ）の拡張である。ＣＯＭは、単一のマシン内のプロセス間通信に制限されていた。ＤＣＯＭを使用することを望む開発者は、ＤＣＯＭプログラミングモデル１３０Ａ、リモートプロシージャコール（ＲＰＣ）メッセージ交換セマンティクス１２０Ａ、および対応するＲＰＣネットワークコネクトイド（connectoid）１１０Ａをバンドルとして受け入れる。
【０００４】
図１Ｂは、もう１つの従来技術の密結合メッセージングインフラストラクチャ１００Ｂを例示する。図１Ａに示すＤＣＯＭインフラストラクチャと類似して、この他のメッセージングインフラストラクチャ１００Ｂは、他のプログラミングモデル１３０Ｂ、他のメッセージ交換セマンティクス１２０Ｂ、および他のネットワークコネクトイド１１０Ｂを含む。他のプログラミングモデル１３０Ｂ、他のメッセージ交換セマンティクス１２０Ｂ、および他のネットワークコネクトイド１１０Ｂのインターロック部１２１Ｂは、ＤＣＯＭプログラミングモデル１３０Ａ、ＲＰＣメッセージ交換セマンティクス１２０Ａ、およびＲＰＣネットワークコネクトイド１１０Ａのインターロック部１２１Ａとは異なることに留意されたい。インターロック部１２１Ａおよび１２１Ｂの間の違いは、分散アプリケーションを開発するための様々な既存のおよび新しいオプションから選択する際に、従来技術の柔軟性の欠如を例示する。ＤＣＯＭまたはある他の技術およびその対応するインフラストラクチャを選択してしまうと、既存のアプリケーションの開発において費やされた努力を犠牲にすることなく他の技術からの機能を使用することは、比較的困難なタスクとなる。しばしば、このような技術の変更または強化には、本質的に最初からやり直すことが必要である。
【０００５】
従って、切り離されたプログラミングモデル、メッセージ交換セマンティクス、およびメッセージトランスポートは、当技術分野における前進を表す。開発者は、別のレベルの関係のない問題を懸念する必要なしに、インフラストラクチャ内のあるレベルで機能を選ぶことができる。さらに、開発者は、新しいインフラストラクチャを学習する必要なしに、あるプログラミングモデルから別のプログラミングモデルに移動することができる。レイヤを切り離すことはより大きい再使用可能性につながり、革新を促進する。何故ならば、切り離されたインフラストラクチャにおける変更および強化により、既存の開発の成果を使用し続けることができるからである。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
本発明は、メッセージングインフラストラクチャ内で処理レイヤを抽象化して、既存の機能を使用し続けながら、後の変更または強化をインフラストラクチャに行うことができるようにする方法、システムおよびコンピュータプログラムに関する。以下でより十分に説明する本発明の例示的実施形態によれば、インフラストラクチャは、３つの主要なレイヤである、メッセージレイヤ、チャネルレイヤおよびサービスレイヤを含む。これらの各レイヤは機能を抽象化して、特定の実装の詳細が、一般に他のレイヤから隠されるようにする。
【課題を解決するための手段】
【０００７】
１つの例示的実施形態において、メッセージトランスポートの実装は、メッセージレイヤ内で抽象化され、インフラストラクチャ内の他のレイヤが、メッセージトランスポートにおおむね関係なく、より一般的な方法でメッセージと対話できるようにする。メッセージトランスポートの例には、名前付きパイプ、ＴＣＰ（Transmission Control Protocol）、ＨＴＴＰ（Hyper Text Transfer Protocol）、ＳＭＴＰ（Simple Mail Transfer Protocol）などが含まれる。メッセージレイヤの上のチャネルレイヤは、メッセージ交換の実装を抽象化して、インフラストラクチャ内の他のレイヤが、特定のメッセージ交換の実装のメッセージ交換セマンティクスにおおむね関係なく、より一般的な方法でメッセージを送信および受信できるようにする。メッセージ交換の実装の例には、データグラム、ダイアログ、モノローグ、キューなどが含まれる。チャネルレイヤおよびメッセージレイヤの上のサービスレイヤは、バインディング実装を抽象化する。バインディング実装は、メッセージ交換の実装を、インフラストラクチャを使用するユーザコード実装（例えば、アプリケーション）にバインドする。サービスレイヤは、少なくとも部分的には、メッセージングインフラストラクチャを使用するためのプログラミングモデルを記述する。
【０００８】
抽象化の各レイヤは、抽象化された実装のための複数のプログラムモジュールに対応することができる。メッセージレイヤ抽象化は、メッセージのためのアトミック送信／受信の抽象化を提供するポートを抽象化することができる。各抽象化された実装について、インフラストラクチャは、インフラストラクチャ内の使用のための実装を表現する抽象化の特定のインスタンスを含むことができる。例えば、チャネル抽象化のインスタンスを、メッセージを処理するためのサービスまたはユーザコード実装のインスタンスにバインドさせることができる。このバインディングは、チャネルおよびユーザコード実装のためのサービスプロキシによって実行することができる。メッセージがインスタンスおよびサービスプロキシを通じて流れるとき、これらをインターセプトしてさらに処理することができる。サービスレイヤ抽象化は、サービスまたはユーザコードインスタンスの物理的ライフタイムを管理するサービスストア実装を抽象化することができる。
【０００９】
本発明の追加の特徴および利点を、以下に続く説明において述べ、これは部分的にはこの説明から明らかになり、あるいは本発明の実施によって学習することができる。本発明の特徴および利点を、添付の特許請求の範囲で詳細に指摘した手段および組合せを用いて実現し、得ることができる。本発明のこれらおよび他の特徴は、以下の説明および添付の特許請求の範囲からより十分に明らかになり、あるいは、以下に述べる本発明の実施によって学習することができる。
【発明を実施するための最良の形態】
【００１０】
本発明の上記に列挙した、また他の利点および特徴を得ることができる方法を説明するために、簡単に上述した本発明のより詳細な説明を、その具体的な実施形態を参照することによって提供し、これらの実施形態を添付の図面において例示する。これらの図面が本発明の典型的な実施形態のみを示し、従ってその範囲を限定するものとして見なされるべきでないことを理解して、本発明を、添付の図面の使用を通じて、追加の特定性および詳細により記述し、説明する。
【００１１】
本発明は、メッセージングインフラストラクチャ内で処理レイヤを抽象化して、必ずしも既存の機能を再実装する必要なしに、後の変更または強化をインフラストラクチャに行うことができるようにする方法、システムおよびコンピュータプログラムにまで及ぶ。本発明の実施形態は、１または複数の専用および／または１または複数の汎用コンピュータを備えることができ、これらは様々なコンピュータハードウェアを含み、これを以下でより詳細に論じる。
【００１２】
図２は、本発明によるメッセージングインフラストラクチャ２００の一例の高レベル表現を例示する。メッセージングインフラストラクチャの例示的実施態様に関するより詳細を、以下で図５に関連して提供する。インフラストラクチャ２００は、階層化アーキテクチャを通じて分散プログラミングをサポートする（例えば、インフラストラクチャを、サブシステムの順序付けられたセットとして見なすことができ、ここで、各サブシステムは、以前のサブシステムに依存する）。例えば、メッセージングインフラストラクチャ２００において、主要なレイヤは、メッセージングレイヤ２１０、チャネルレイヤ２４０およびサービスレイヤ２７０を含む。
【００１３】
以下でより詳細に説明するように、これら各レイヤは、ある実装の詳細を抽象化して、類似のものを共通の方法で扱うことができるようにする。抽象化は、プログラミングモデル、メッセージ交換セマンティクスおよびメッセージトランスポートを切り離して、開発者が、別のレベルの関係のない問題を懸念する必要なしに、インフラストラクチャ内のあるレベルから機能を選ぶことができるようにする。結果として、開発者は、例えば、新しいインフラストラクチャを学習する必要なしに、あるプログラミングモデルから別のプログラミングモデルに移動することができる。この抽象化は、より大きい再使用可能性につながり、革新を促進する。何故ならば、切り離されたインフラストラクチャにおける変更および強化により、既存の開発努力を使用し続けることができるからである。
【００１４】
最下位レイヤであるメッセージングレイヤ２１０は、メッセージのエンドポイントツーエンドポイント伝送またはトランスポートを提供する。メッセージングレイヤ２１０は、トランスポートの拡張可能性をサポートして、新しいトランスポートが実装されると、これらをインフラストラクチャ内の他のレイヤによって使用できるようにする。例えば、メッセージングレイヤ２１０は、トランスポートプロトコルのための実装を抽象化する。トランスポートプロトコルは、名前付きパイプ、ＴＣＰ、ＨＴＴＰ、ＳＭＴＰなどである。従って、簡単に表現すると、メッセージングレイヤ２１０は、アトミックメッセージ送信／受信の抽象化をインフラストラクチャ内の他のレイヤに提供して、メッセージを送信または受信するために使用された特定のトランスポートプロトコルとは幾分関係なく、他のレイヤがメッセージを処理できるようにする。
【００１５】
メッセージングレイヤ２１０は、メッセージがエンドポイントから離れるか、あるいはエンドポイントに到着するとき、メッセージの拡張可能なインターセプション（interception）を可能にする。拡張可能なインターセプション機構を使用して、ルーティング、フィルタリング、ポリシー管理およびセキュリティなどのビヘイビア（behavior）を実装することができる。メッセージングレイヤ２１０におけるエンドポイントで使用可能なトランスポートおよびビヘイビアを、プログラムまたは構成を通じて確立することができる。
【００１６】
チャネルレイヤ２４０は、メッセージング抽象化を、メッセージングレイヤ２１０によって提供されたトランスポート抽象化の上に提供する。チャネルは、エンドポイントの間で実装されたビヘイビアと、実装されたビヘイビアを抽象化するオブジェクトモデルを表す。共通チャネルの例は、単方向の無相関メッセージングのためのデータグラムチャネル、双方向の相関メッセージングのためのダイアログチャネル、公開／購読または単方向のブロードキャストメッセージングのためのモノローグチャネル、および、単方向の待機メッセージングのためのキューチャネルを含む。アプリケーションまたはユーザコードは、チャネルインスタンス（例えば、インメモリチャネルオブジェクト）をあるエンドポイントで作成すること、およびメッセージをこれらのインスタンスにおいて送信することによって、チャネルを使用する。メッセージが他のエンドポイントに到着するとき、アプリケーションまたはユーザコードは、チャネルの送信側において作成されたチャネルを認識し、チャネルインスタンスを作成して会話に参加する。
【００１７】
サービスレイヤ２７０は、プログラミングモデルをチャネルレイヤ２４０およびメッセージングレイヤ２１０の上に提供する。アプリケーションプログラマは、典型的には、メッセージングインフラストラクチャ２００をサービスレイヤで使用する。サービスレイヤプログラミングモデルは、どのようにメッセージが送信されようとも（例えば、型付けされたメソッド呼び出しに対する構造）、メッセージディスパッチ機構、および型システムによって互いに区別される。サービスレイヤ２７０は、プログラミングモデルのインスタンスを上述のチャネルインスタンスにバインドするための汎用メカニズムを提供する。サービスレイヤ２７０は、また、プログラミングモデルが開発者に提供するために選択する、状態およびライフタイム制御、サービス管理、呼び出しのインターセプション、および同期メッセージディスパッチなどの機能も提供する。単純および複雑なプログラミングモデルを、サービスレイヤのために開発することができる。適切なバインディングおよびインターオペラビリティを容易にするために、プログラミングモデルは、一般的に、メッセージングレイヤトランスポート型と、インフラストラクチャ自体内で定義されおよび制御された型、詳細には、サービスレイヤ２７０内のアプリケーションまたはユーザコードオブジェクトに対応する型の間の固定された関係を定義する。
【００１８】
図３は、本発明によるメッセージングインフラストラクチャ３００の例示的実施形態を示すブロック図である。一般に、メッセージングインフラストラクチャ３００は、チャネルインスタンス（すなわち、インメモリチャネル抽象化オブジェクト）を、サポートされたプログラミングモデルを通じて実装されたコードのインスタンスにバインドするためのモジュールで構成されている。図２に関する上述に類似して、図３は、メッセージングレイヤ３１０、チャネルレイヤ３４０およびサービスレイヤ３７０を含む。図３の説明を、２つの一般的カテゴリである、メッセージングインフラストラクチャ自体、および、メッセージングインフラストラクチャによってサポートすることができるプログラミングモデルに分割することができる。以下の考察は、メッセージングインフラストラクチャを説明することによって開始し、次いで、例示的プログラミングモデルの説明を行う。図３に例示したコンポーネントへの参照を単数において行うことができるが、多数の各コンポーネントを単一のインフラストラクチャ内で提示することができ、またしばしばそのように提示することを理解されたい。
【００１９】
３つのマネージャは、各レイヤ内に１つずつあり、インフラストラクチャ３００によって提供された基本機能の多くを実装する。マネージャは、メッセージングレイヤ３１０内のポート３１２、チャネルレイヤ３４０内のチャネルマネージャ３４２、およびサービスレイヤ３７０内のサービスマネージャ３８２である。従って、図３の説明は最初に、これらの３つのマネージャに一般に焦点を合わせ、次いで、例示される３つのマネージャおよび他のコンポーネントのより詳細な考察を行う。３つのマネージャの最初は、ポート３１２であり、トランスポート実装およびインフラストラクチャの残りの間の多重化ブローカとしての機能を果たす。簡単に表現すると、ポート３１２およびメッセージングレイヤ３１０は、アトミックメッセージ送信／受信抽象化をメッセージングインフラストラクチャ３００に提供する。前述のように、この抽象化は、他のレイヤの、個々のトランスポート実装に関連する詳細を理解する負担を軽減する。むしろ、他のレイヤは、メッセージ抽象化と対話し、メッセージがどのようにメッセージングレイヤ３１０およびポート３１２にトランスポートされるかの詳細をそのまま残す。
【００２０】
３つのマネージャの第２は、チャネルレイヤ３４０内のチャネルマネージャ３４２であり、メッセージを収集して相関させ、場合によってはこれらを格納および／または順序付けし、高レベルチャネル抽象化を一般にサービスレイヤ３７０に、詳細にはサービスマネージャ３８２およびサービスバインダ３７２に提示する。メッセージングレイヤ３１０によって提供されたメッセージ抽象化に類似して、ここでもまた、チャネルレイヤ３４０およびチャネルマネージャ３４２によって提供されたチャネル抽象化は、他のレイヤの、個々のメッセージ交換セマンティクスに関連する詳細を理解する必要性を軽減する。他のレイヤは単にチャネル抽象化と対話し、メッセージがどのようにチャネルレイヤ３４０に交換されるか（例えば、データグラム、ダイアログなど）の詳細をそのまま残す。
【００２１】
３つのマネージャの第３は、サービスマネージャ３８２であり、サービスインスタンス３７６（プログラミングモデルの１つに従って実装されたクラスのインスタンス）を、チャネルマネージャ３４２によって生成されたチャネルインスタンス３４４に接続することを担い、これは、チャネル抽象化のインスタンスを対応するサービスインスタンスに提供する。サービスマネージャ３８２は、特定のチャネルおよびプログラミングモデルの詳細を理解するサービスバインダ３７２を通じて、サービスインスタンス３７６をチャネルインスタンス３４４に接続する。以下でより詳細に説明するように、サービスバインダ３７２は、サービスストア３７８と協調して、インスタンスを作成および登録する。
【００２２】
サービスマネージャ３８２およびサービスバインダ３７２は、サービスインスタンス３７６をチャネルインスタンス３４４に、サービスプロキシ３７４を使用してバインドし、これもまた以下でより詳細に説明する。インスタンスが作成された後、サービスストア３７８は、それらの持続性（例えば、ライフタイムなど）および位置を、インフラストラクチャの残りから抽象化する。サービスインスタンスに流れ込むメッセージおよび呼び出しを、サービスマネージャ３８２に登録されたサービス拡張３９２によって供給されたコードによってインターセプトすることができる。サービスインスタンスは、インフラストラクチャと、サービスインスタンス上のインタフェースを通じて通信し、これはサービスサイトと呼ばれ、インスタンスによって共通して使用された機能を実装する。インスタンスのサービスサイトは、サービスストアがインスタンスを作成するとき、初期化される（あるいは位置を与えられる）。
【００２３】
サービスマネージャ３８２は、チャネルを作成し、インフラストラクチャ内の他のコンポーネントにアクセスするために使用されるインタフェースのセットであり、それを通じてインフラストラクチャが構成されるエンティティである。サービスマネージャが作成されるとき、これはサービスバインダ、サービスストア、および、ポートで使用可能であるサービス型を作成し、これらをインフラストラクチャに接続する。ポートが多数のサービスのためのリクエストを処理することができる場合、単一のサービスマネージャのみがポートについて関連付けられる。従来のインフラストラクチャは、インスタンスを作成してインフラストラクチャの調整を管理するためのサービスマネージャの形態を有することができるが、サービスマネージャ３８２は、そのタスクを間接的に実行し、これは、この作業を特定のタスクについて適切な他のモジュールに委託することによって行う。結果として、サービスマネージャ３８２は、インフラストラクチャ３００の他のコンポーネントのように、高度の拡張可能性をサポートするのに対して、従来のインフラストラクチャにおけるサービスマネージャは、インスタンスを作成してインフラストラクチャの調整を直接管理する傾向があり、革新が困難となる。何故ならば、既存の機能を再実装して新しいビヘイビアまたは機能をサポートする必要の可能性があるからである。
【００２４】
サービスバインダ３７２は、チャネルインスタンス３４４、サービスインスタンス３７６およびサービスストア３７８の間の関係を管理することを担う。従って、サービスバインダ３７２は、典型的には、各使用可能なチャネルおよびプログラミングモデルの特定の知識を有する。チャネルは、特有のイベントおよびインタフェースを実装し、これをサービスバインダ３７２が使用して、メッセージをチャネルレイヤ３４０の内外に移動させる。プログラミングモデルは、複数の型の間のマッピングを指定し、これをサービスバインダが使用して、メッセージをメソッドに適用し、メソッド呼び出しをメッセージに向ける。各チャネルおよびプログラミングモデルは異なるので、サービスバインダは、通常、それぞれの１つをサポートする。従って、実行中のポートは、典型的には、各サポートされたチャネル／プログラミングモデルのペアについての１または複数のサービスバインダに関連付けられる。
【００２５】
例示的プログラミングモデルは、ウェブサービス記述言語（ＷＳＤＬ）のポートの型と、インフラストラクチャランタイム内で管理される型との間でマップすることができる。ＷＳＤＬは、ＸＭＬフォーマットであり、メッセージを交換することができるエンドポイントのセットとしてネットワークサービスを記述するも。これは、下にあるプロトコル（ＳＯＡＰ（Simple Object Access Protocol）、ＨＴＴＰ  ＧＥＴ／ＰＯＳＴなど）または符号化（ＭＩＭＥ（Multipurpose Internet Mail Extensions）など）とは無関係に、リクエストの基本フォーマットを指定するための、比較的単純な機構を提供する。抽象オペレーションおよびメッセージは、特定のネットワークプロトコルおよびメッセージフォーマットにバインドされて、エンドポイントが定義される。従って、ＷＳＤＬサービスは、ポートとしても知られるエンドポイントの集まりである。ＷＳＤＬにおいて、ポートの型は、オペレーションの集まりを記述する。図３は、本発明の例示的実施形態を例示し、これにおいてインフラストラクチャは、ＷＳＤＬにマップされる管理されるコードおよびデータ型を含むことを理解されたい。しかし、本発明を様々な環境において実施することができ、管理されるコード／データ型またはＷＳＤＬポートの型を有するものに限定されない。
【００２６】
上述のように、サービスバインダ３７２は、ポートの作成中にサービスマネージャ３８２に登録される。サービスバインダは、ポート／サービス型のセットに関連付けられる。サービスバインダ中の型の一意性は、サービスバインダに固有であるインタフェース型から継承するサービスを実装する、インフラストラクチャランタイム内の管理される型の結果から生じる。例示的インフラストラクチャ３００において、ポートを開くものと同じプロセスは、サービスマネージャ３８２およびそのポートで使用可能なサービスバインダ３７２のすべてをも開く。開かれるとき、サービスバインダは、それら自体をそれらの対応するチャネルマネージャ３４２に接続する。
【００２７】
ユーザコードが呼び出しをサービスマネージャ３８２に発行してチャネルを作成するとき、サービスマネージャは、登録されたサービスバインダのセット上で繰り返し、それぞれ、指定された型を扱うための機会を提供する。次に、サービスマネージャは、指定された型を認識してサービスインスタンス３７６を作成するサービスバインダを使用し、これをサービスストア３７８に登録し、サービスインスタンスをチャネルインスタンス３４４に、サービスプロキシ３７４によりバインドする。同様に、メッセージが、既存のサービスインスタンスに関連付けられていないチャネルに到着するとき、そのチャネルに付加されたサービスバインダのセットは、入ってくるポート／サービス型を認識するかどうかを尋ねられる。型を認識するサービスバインダ３７２を使用して、サービスインスタンスを作成し、これをチャネルインスタンスに、サービスプロキシによりバインドし、次に入ってくるメッセージがインスタンスおよびプロキシを通じてユーザコードに流れるようにする。
【００２８】
新しいインスタンスについてのリクエストに答えるために、サービスバインダは、サービスインスタンス３７６を作成し、これをサービスストア３７８に登録し、サービスプロキシ３７４を作成し、チャネルインスタンス３４４をサービスプロキシ３７４に、サービスプロキシ３７４をサービスインスタンス３７６内のユーザコードに接続し、チャネル内の最初のメッセージの流れをトリガする。後に、メッセージがチャネルインスタンスからサービスプロキシ３７４に流れ、サービスプロキシ３７４がメッセージを呼び出しスタックに変換し、呼び出しスタックを対応するサービスインスタンスにディスパッチする。同様に、呼び出しがサービスインスタンス３７６から出てサービスプロキシ３７４に流れ、サービスプロキシ３７４が呼び出しをメッセージに変換して、メッセージを、チャネルインスタンスを介してそれらの宛先に送信する。
【００２９】
従来のインフラストラクチャは、サービスバインダのある形態を有することができるが、本発明によるインフラストラクチャは、多数のサービスバインダをサポートすることができる。さらに、従来のインフラストラクチャとは対照的に、サービスバインダの集まりは、全体として、その下のチャネルレイヤ、ならびにサービスストアおよびサービスレイヤ３７０内のプログラミングモデルとは無関係である。従来のインフラストラクチャは、トランスポート、チャネル、バインダ、ストアおよびインスタンス機能を、密結合パッケージにおいて実装する傾向があり、これには、発展する技術およびアプリケーションの必要性に対処するために、強化または変更が行われるたびに、しばしば著しい変更が必要となる。
【００３０】
上述のように、サービスストア３７８はインスタンスを管理する。サービスバインダが、新しいサービスインスタンスを作成するためのリクエストに答えるとき、サービスバインダは、インスタンスを作成し、そのインスタンスをサービスストアに登録する。インスタンスが作成された後、サービスバインダは、このストアを使用してインスタンスに位置を与え（共通して使用される通信インタフェースを初期化し）、次に、サービスバインダは、チャネルをこの位置にバインドする。サービスストア３７８は、インスタンスに関連付けられたチャネルの数を追跡し、チャネルが付加されないとき、インスタンスを解放する。これはサービスバインダ（メッセージ／イベントに近いチャネル、およびプロキシインスタンスの解放を見るもの）に、論理インスタンス（インフラストラクチャの外側から見られるときのインスタンス）のライフタイムの制御に参加するための能力を与える。
【００３１】
バインダは、論理インスタンスのライフタイムを制御し、サービスストア３７８は、物理インスタンス（メモリ内に生きている実際のオブジェクトインスタンス）のライフタイムを管理する。サービスストアが物理インスタンスをメモリから除去することを望むとき、関連するチャネルに通知して、関連するチャネルが物理インスタンスをその関連するサービスプロキシ３７４から切断できるようにする。次に呼び出し／メッセージがインスタンスに適用されるとき、サービスストアは、新しいインスタンスを作成してこれを適切なプロキシに再接続させることを担う。
【００３２】
サービスストア３７８は、インスタンスの状態についての様々な程度の考慮をサポートする。サービスストアは、メモリ内のすべてのインスタンスを維持し、切断／再接続メカニズムを決して使用しない可能性がある。別法として、サービスストアは、メモリ内のすべてのインスタンスを維持し、インスタンスに対しステートレス（statelessness）を実施するために積極的な切断／再接続をサポートすることができる。サービスストアは、切断／再接続を、マシンの負荷、ライセンシング問題（例えば、データベースへの接続）および／または使用パターンに基づいてサポートし、切断／再接続を、インスタンスの並列化／直列化、および処理されたデータベース内のインスタンスの格納に結合して、耐久性があり信頼性のあるインスタンスをサポートすることができる。サービスストアによって使用されるデータベースは、耐久性のあるチャネルによって使用されたストアおよびポートの前のルータと協調して、あるマシンから別のマシンへのインスタンスの移行を実施することができる。サービスストア３７８は、ガベージコレクション、プーリング、長期にわたる接続の管理などにおいて有用である可能性がある。
【００３３】
従来のインフラストラクチャにおけるサービスストアは、物理および論理インスタンスのライフタイムを直接リンクさせる傾向がある。２つの間の関係は、典型的には、インフラストラクチャ内でハードコードされる。結果として、システムの他のエリアに影響を与えることなく、代替物を実施することは困難である。さらに、拡張可能性ポイントとして、あるいはインフラストラクチャが発展するときの、専門家であるユーザによる修正は、サービスストアとインフラストラクチャの他の部分の間の著しい結合が与えられると、非現実的である。
【００３４】
上述のように、サービスプロキシ３７４は、サービスバインダ特有の型のインスタンスであり、特定の型のチャネルインスタンス３４４を特定の型のサービスインスタンス３７６にリンクさせる。入ってくる呼び出しについて、サービスプロキシは、メッセージが使用可能であると知らせるチャネルからのイベントに答え、適切な呼び出しスタックをメッセージから作成し、これをインスタンスに適用する。出て行く呼び出しについて、サービスプロキシ３７４は、呼び出しに答え、必要な場合はこれをメッセージに変換し、チャネルインスタンス３４４を介してこれを送信する。方向に応じて、サービスプロキシ３７４は、型チャネル（例えば、サービスインスタンスから）および管理される型のプロキシ（例えば、チャネルインスタンスから）のように見える。
【００３５】
そのブリッジング機能に加えて、あるビヘイビアもまた、サービスプロキシの使用内で、これを通じて実装される。例えば、１または複数のサービスプロキシは、並行管理を実装することができ、所与の時点で単一のサービスインスタンスにわたる呼び出しの数を制限する。サービスストア３７８に関して上述したように、サービスプロキシは、切断／再接続を実装して、サービスストアが物理インスタンスのライフタイムを論理インスタンスのライフタイムから切り離すことができるようにする。サービスプロキシ３７４により、サービスバインダ３７２およびサービスストア３７８が拡張可能な方法でビヘイビアを実装できるようになることを理解されたい。
【００３６】
ポート３１２、チャネルマネージャ３４２およびサービスマネージャ３８２に加えて、他のマネージャがインフラストラクチャ３００内に存在することができる。これらのマネージャは、ビヘイビアをインフラストラクチャのいくつかまたはすべてのレベルで実装し、これには、メッセージのフィルタリングおよびルーティング、ポリシー交換および適用、セキュリティ、ロギング、およびトランザクショナルサービスが含まれる。拡張可能性を提供する各マネージャは、拡張インタフェースを定義して、他のマネージャがその拡張可能性を実装できるようにする。例えば、メッセージングレイヤ３１０のポート３１２は、ポート拡張を供給し、マネージャがハンドラを、メッセージがそのレイヤで流れるパイプラインに与えることができるようにする。同様に、個々のチャネルマネージャは、拡張を実装して、サービスマネージャのようなモジュールが、チャネルインスタンスをチャネルから作成するためにメッセージをフックできるようにする。
【００３７】
サービス拡張３９２は、サービスマネージャ３８２によって定義されたインタフェースであり、これにより他のマネージャが、インフラストラクチャによってサポートされた呼び出しパス拡張可能性ポイントにフックできるようにする。拡張が最初に確立されるとき、サービスマネージャは、サービスマネージャが知っているサービス型の反映された型情報を、関心のあるマネージャに、サービス拡張を介して渡す。サービス拡張を実装するマネージャは、この反映データをそれら自体の構成と結合して、特定のメッセージ／呼び出しがサービスインスタンスに流れ込み、かつそこから流れ出るときにこれらのマネージャが行いたいことを確立する。メッセージ前後の通知が、マネージャに、サービス拡張を通じて流れるイベントによって通知される。サービス拡張メカニズムのこの程度の拡張可能性は、従来のインフラストラクチャでは見られない。インフラストラクチャが一般にビヘイビアをサポートするように構成される限り、ビヘイビアに関連付けられたマネージャを除いて、ストアまたは他のコンポーネントを、そのビヘイビアをインフラストラクチャに導入するために修正する必要はない。
【００３８】
サービスインスタンス３７６は、管理されるコードサービス型のインスタンスであり、ポート／サービス型に関連付けられたインタフェースを、場合によっては、プログラミングモデルの一部として指定されたラッパを介して実装する。一般に、また以下でさらに詳細に説明するように、プログラミングモデルが異なる１つの方法は、会話があるサービス型におけるインタフェースおよびメソッドに関連付けられる方法である。図３に例示した例示的実施形態では、有効なプログラミングモデルに対して書かれたサービス型は、ＷＳＤＬ会話、オペレーションおよびメッセージと、インフラストラクチャランタイムのマネージドコードインタフェース、メソッドおよび属性型の間の直接マッピングを有する。インフラストラクチャは、非常に異なるように見える可能性のある、異なるプログラミングモデルを使用して作成されたサービス型をサポートすることもできる。関連するサービスプロキシによって使用されたインタフェースに加えて、サービス型は、他のインタフェースを実装して、それら自体を他の態様のインフラストラクチャのビヘイビアにフックすることができる。例えば、サービス型は、あるサービスストアにフックするため、あるいは、サービス拡張によって実装されたビヘイビアに参加するために、特別なインタフェースを実装することができる。
【００３９】
上述のように、サービスインスタンス３７６は、典型的には、位置を与えられる（それ自体に固有のサービスサイトへの参照を含む）。サービスインスタンスは、適切なインタフェースを実装することによって、あるいは、適切なインタフェースを実装する基本クラスから継承することによって、位置を与えられる。サービスバインダ３７２がサービスインスタンスを作成するとき、サービスストア３７８を使用してインスタンスに位置を与える。サービスストアは、サービスサイトプロパティを対応するインタフェース上に設定することによって、インスタンスに位置を与える。サービスサイトプロパティは、インスタンスインフラストラクチャ状態へのアクセスを提供し、これには、そのインスタンスに接続されたアクティブチャネルの集まりなどが含まれる。インスタンスは、この状態情報を使用して、そのチャネルを獲得、検査および修正することができる。サービスストアは、チャネルをサービスインスタンスにバインドし、そこからアンバインドするとき、チャネルをサービスインスタンスのアクティブチャネルから追加および除去するときにも、この状態情報を使用することができる。
【００４０】
図３に例示した例示的実施形態では、インフラストラクチャが、ＷＳＤＬポート型から、インフラストラクチャランタイムのための管理させるコードクラス型への直接マッピングを実装する、いかなるプログラミングモデルをもサポートするように設計される。１つの例示的プログラミングモデルは、管理されるコード属性を使用して、ＷＳＤＬ型と管理されるコード型の間の関連付けを確立する。この型のプログラミングモデルは、管理されるコードクラスと、それらが実装するポート型のＷＳＤＬコントラクトとの間の関係を記述する属性により、修飾された管理されるコードクラスである。プログラミングモデルを実装するツールは、ＷＳＤＬを、適切な属性により修飾された管理されるコードクラスおよびインタフェースから生成することも、適切な属性により修飾された管理されるコードクラスおよびインタフェースをＷＳＤＬから生成することも可能である。他のプログラミングモデルは、リモートオブジェクトモデル、ビジネスプロセスの論理シーケンスを記述するためのモデルなどを含むことができる。従って、サービスという用語は、これらおよび他のプログラミングモデルを包含するように広義に解釈されるべきである。
【００４１】
ＤＣＯＭなど、より従来のリモートオブジェクトモデルを、２つのインタフェースからなるものとして考えることができ、その一方は、オブジェクトのクライアントによって使用されたプロキシにおいて実装され、他方はオブジェクト自体において実装される。これらの２つのインタフェースにおけるアプリケーションのメソッドは、通常、この種のプログラミングモデルにおいて等しいが、各々は、会話の一方の側または他方の側に適切なインフラストラクチャメソッドを含むことができる。
【００４２】
対照的に、ＷＳＤＬ会話は双方向である。そのオペレーションは、会話の一部としていずれかの方向に流れることができる、個々のメッセージまたはリクエスト／レスポンスメッセージのペアである。これらのオペレーションをサポートするために、例示的プログラミングモデルは、４つのインタフェース、２つのサービス実装インタフェース、および２つのチャネルコントロールインタフェースを含む。会話の各々の側は、メッセージまたはリクエストに反応して実行するコードを有するサービス実装インタフェース、ならびに、出て行くメッセージまたはリクエストを送信するプロキシメソッドを有するチャネルコントロールインタフェース、および、入ってくるメッセージまたはリクエストに処理を追加するためにフックさせることができるイベントを有する。
【００４３】
属性は、マネージドコード型の、ＷＳＤＬ型へのマッピング、およびコードを実行するために作成されたインスタンスの品質の詳細を構成することができる。属性の例には、インスタンスライフタイムを決定する属性が含まれ、これは、新しい論理インスタンスが各メッセージ／リクエストについて作成されるかどうか、または、論理インスタンスが、接続が維持される限り続くかどうかなどである。属性は、オペレーションがメッセージであるか、リクエスト／レスポンスメッセージのペアであるかを、属性またはコードと共に適切に指定して、メソッドが同期であるか非同期であるかを指定することができる。他の属性は、マネージドコード型におけるメソッドおよびパラメータの名前と、ＷＳＤＬオペレーション、メッセージおよびパートの名前の間の関係を制御することができる。属性を使用して、メソッド呼び出しの引数をラップする単一パートからなるメッセージへの、あるいは、引数につき１パートからなるマルチパートメッセージへの、メソッド呼び出しのマッピングを制御することができる。最後に、属性は、プログラミングモデルの、ドキュメント／リテラルまたはＲＰＣ／符号化メッセージへのマッピングを制御することができる。また、プログラミングモデルに、サービスインスタンスの下にあるチャネルインスタンスに沿って進むように求めるコードを実装することも可能であるが、これはＷＳＤＬに影響を与えない。
【００４４】
本発明を、機能ステップおよび／または非機能的動作を備える方法に関して説明することもできる。以下は、本発明の実施において行うことができる動作およびステップの説明である。通常、機能ステップは、本発明を実施される結果に関して説明するのに対して、非機能的動作は、特定の結果を達成するためのより具体的な行為を説明する。機能ステップおよび非機能的動作を特定の順序において説明または主張することができるが、本発明は必ずしも、動作および／またはステップのいかなる特定の順序付けまたは組合せにも限定されない。
【００４５】
図４Ａ〜４Ｂは、本発明によるメッセージングインフラストラクチャ内で処理レイヤを抽象化する方法についての動作およびステップの例を示す。メッセージレイヤ内で１または複数のメッセージトランスポート実装を抽象化するためのステップ（４２０）は、メッセージトランスポート実装を抽象化するメッセージレイヤインタフェースを定義する動作（４１０）を含むことができる。メッセージトランスポートの例には、ＴＣＰ４１１、ＨＴＴＰ４１３、ＳＭＴＰ４１５および他のトランスポート４１７が含まれる。ポート４１２は、アトミックメッセージ送信／受信抽象化をチャネルレイヤに提供するトランスポート抽象化の一例である。
【００４６】
チャネルレイヤ内で１または複数のメッセージ交換実装を抽象化するためのステップ（４４０）は、１または複数のメッセージ交換実装を抽象化するチャネルレイヤインタフェースを定義する動作（４３０）を含むことができる。メッセージ交換実装の例には、データグラム４３１、ダイアログ４３３、モノローグ４３５、キュー４３７および他の交換実装４３９が含まれる。メッセージ交換インスタンス４３２またはチャネルインスタンスは、メッセージ交換抽象化の一例である。
【００４７】
サービスレイヤ内で１または複数のバインディング実装を抽象化するためのステップ（４９０）は、１または複数のメッセージ交換実装をユーザコードまたはメッセージ処理実装にバインドする、１または複数のバインディング実装を抽象化するサービスレイヤインタフェースを定義する動作（４５０）を含むことができる。プログラミングモデル４５１に従って書かれたユーザコード４５４は、メッセージ処理インスタンス４５２として動作する。プログラミングモデルＡ、プログラミングモデルＢ、プログラミングモデルＣなどは、プログラミングモデル４５１の例であり、メッセージ処理インスタンス４５２として実行するための対応するユーザコードＡ１、ユーザコードＡ２など、ユーザコードＢ１、ユーザコードＢ２など、ユーザコードＣ１、ユーザコードＣ２などを有する。１または複数のバインディング実装を抽象化するためのステップ（４９０）はさらに、メッセージレイヤ型をサービスレイヤ型に（例えば、ＷＳＤＬを管理されるコード型に）マップすること（４６０）、メッセージ処理インスタンスをメッセージ交換インスタンスに（例えば、サービスインスタンスをチャネルインスタンスに）バインドすること（４７０）、および、メッセージ処理インスタンスの物理的ライフタイムを（例えば、サービスストアを通じて）管理すること（４８０）を含むことができる。
【００４８】
本発明の範囲内の実施形態にはまた、コンピュータ実行可能命令またはデータ構造を担持し、または格納するための、コンピュータ読取り可能媒体が含まれる。このようなコンピュータ読取り可能媒体は、汎用または専用コンピュータによってアクセスすることができるいかなる使用可能な媒体とすることもできる。例として、限定ではなく、このようなコンピュータ読取り可能媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭもしくは他の光ディスク記憶装置、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、または、所望のプログラムコード手段をコンピュータ実行可能命令またはデータ構造の形態で担持し、または格納するために使用することができ、汎用もしくは専用コンピュータによってアクセスすることができる、他のいかなる媒体が含まれる可能性もある。情報が、ネットワークまたは別の通信接続（有線、無線、または、有線もしくは無線の組合せのいずれか）を介してコンピュータに転送または提供されるとき、コンピュータは当然、この接続をコンピュータ読取り可能媒体と見なす。従って、いかなるこのような接続もコンピュータ読取り可能媒体と呼ぶのが妥当である。上記の組合せもまた、コンピュータ読取り可能媒体の範囲内に含まれるべきである。コンピュータ実行可能命令には、例えば、汎用コンピュータ、専用コンピュータまたは専用処理デバイスに、ある機能または機能のグループを実行させる命令およびデータが含まれる。
【００４９】
図５および以下の考察は、本発明を実施することができる適切なコンピューティング環境の簡単な全体的説明を提供するように意図される。必要とされてはいないが、本発明について一般に、プログラムモジュールなど、ネットワーク環境におけるコンピュータによって実行されるコンピュータ実行可能命令に関連して説明する。一般に、プログラムモジュールには、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれ、これらは特定のタスクを実行するか、あるいは特定の抽象データ型を実施する。コンピュータ実行可能命令、関連データ構造およびプログラムモジュールは、本明細書で開示された方法のステップを実行するためのプログラムコード手段の例を表す。このような実行可能命令または関連データ構造の特定のシーケンスは、このようなステップにおいて説明された機能を実施するための対応する動作の例を表す。
【００５０】
本発明を、多くの種類のコンピュータシステム構成を有するネットワークコンピューティング環境において実施することができ、これにはパーソナルコンピュータ、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラマブルなコンシューマエレクトロニクス、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどが含まれることは、当業者には理解されよう。本発明をまた分散コンピューティング環境において実施することもでき、この環境ではタスクが、通信ネットワークを通じて（有線リンク、無線リンクによって、または、有線もしくは無線リンクの組合せによって）リンクされるローカルおよびリモート処理デバイスによって実行される。分散コンピューティング環境では、プログラムモジュールが、ローカルおよびリモートのメモリ記憶デバイス内に位置することができる。
【００５１】
図５を参照すると、本発明を実施するための例示的システムは、従来のコンピュータ５２０の形態における汎用コンピューティングデバイスを含み、これは、処理装置５２１、システムメモリ５２２、および、システムメモリ５２２を含む様々なシステムコンポーネントを処理装置５２１に結合するシステムバス５２３を含む。システムバス５２３は、いくつかの種類のバス構造のいずれかにすることができ、これには、様々なバスアーキテクチャのいずれかを使用するメモリバスまたはメモリコントローラ、周辺機器バスおよびローカルバスが含まれる。システムメモリは、読み取り専用メモリ（ＲＯＭ）５２４およびランダムアクセスメモリ（ＲＡＭ）５２５を含む。基本入出力システム（ＢＩＯＳ）５２６は、起動中など、コンピュータ５２０内の複数の要素の間で情報を転送する助けとなる基本ルーチンを含み、ＲＯＭ５２４に格納することができる。
【００５２】
コンピュータ５２０は、磁気ハードディスク５３９に対する読み書きを行う磁気ハードディスクドライブ５２７、リムーバブル磁気ディスク５２９に対する読み書きを行う磁気ディスクドライブ５２８、および、ＣＤ−ＲＯＭまたは他の光媒体など、リムーバブル光ディスク５３１に対する読み書きを行う光ディスクドライブ５３０をも含むことができる。磁気ハードディスクドライブ５２７、磁気ディスクドライブ５２８、および光ディスクドライブ５３０は、システムバス５２３に、ハードディスクドライブインタフェース５３２、磁気ディスクドライブインタフェース５３３、および光ドライブインタフェース５３４によって、それぞれ接続される。ドライブおよびそれらの関連付けられたコンピュータ読取り可能媒体は、コンピュータ５２０用のコンピュータ実行可能命令、データ構造、プログラムモジュールおよび他のデータの不揮発性記憶装置を提供する。本明細書で説明する例示的環境は、磁気ハードディスク５３９、リムーバブル磁気ディスク５２９、およびリムーバブル光ディスク５３１を使用するが、データを格納するための他の種類のコンピュータ読取り可能媒体を使用することができ、これには磁気カセット、フラッシュメモリカード、デジタル多用途ディスク、ベルヌーイカートリッジ、ＲＡＭ、ＲＯＭなどが含まれる。
【００５３】
１または複数のプログラムモジュールを備えるプログラムコード手段は、ハードディスク５３９、磁気ディスク５２９、光ディスク５３１、ＲＯＭ５２４またはＲＡＭ５２５に格納することができ、オペレーティングシステム５３５、１または複数のアプリケーションプログラム５３６、他のプログラムモジュール５３７およびプログラムデータ５３８が含まれる。ユーザはコマンドおよび情報をコンピュータ５２０へ、キーボード５４０、ポインティングデバイス５４２、または、マイクロフォン、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナなど、他の入力デバイス（図示せず）を通じて入力することができる。これらおよび他の入力デバイスがしばしば処理装置５２１へ、システムバス５２３に結合されるシリアルポートインタフェース５４６を通じて接続される。別法として、入力デバイスを、パラレルポート、ゲームポートまたはＵＳＢ（Universal Serial Bus）など、他のインタフェースによって接続することができる。モニタ５４７または別の表示デバイスもシステムバス５２３へ、ビデオアダプタ５４８などのインタフェースを介して接続される。モニタに加えて、パーソナルコンピュータは通常、スピーカおよびプリンタなど、出力周辺デバイス（図示せず）を含む。
【００５４】
コンピュータ５２０は、ネットワーク環境において、リモートコンピュータ５４９ａおよび５４９ｂなど、１または複数のリモートコンピュータへの論理接続を使用して動作することができる。リモートコンピュータ５４９ａおよび５４９ｂはそれぞれ別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイスまたは他の共通ネットワークノードとすることができ、これらは通常、コンピュータ５２０に関連して上述した要素の多数またはすべてを含むが、メモリ記憶デバイス５５０ａおよび５５０ｂ、ならびにそれらの関連付けられたアプリケーションプログラム５３６ａおよび５３６ｂのみを図５に例示した。図５に示す論理接続は、ローカルエリアネットワーク（ＬＡＮ）５５１およびワイドエリアネットワーク（ＷＡＮ）５５２を含み、これらは限定ではなく例として提示される。このようなネットワーキング環境は、オフィス全体または企業全体のコンピュータネットワーク、イントラネットおよびインターネットにおいて一般的である。
【００５５】
ＬＡＮネットワーキング環境において使用するとき、コンピュータ５２０がローカルネットワーク５５１へ、ネットワークインタフェースまたはアダプタ５５３を通じて接続される。ＷＡＮネットワーキング環境において使用するとき、コンピュータ５２０は、モデム５５４、無線リンク、またはインターネットなどのワイドエリアネットワーク５５２を介して通信を確立するための他の手段を含むことができる。モデム５５４は、内部にあっても外部にあってもよく、シリアルポートインタフェース５４６を介してシステムバス５２３に接続される。ネットワーク環境では、コンピュータ５２０に関連して示したプログラムモジュールまたはその一部を、リモートメモリ記憶デバイスに格納することができる。図示のネットワーク接続は例示的であり、通信をワイドエリアネットワーク５５２を介して確立する他の手段を使用できることは理解されよう。
【００５６】
本発明は、その精神または本質的な特徴から逸脱することなく、他の特定の形態で実施することができる。説明した実施形態は、あらゆる点で、限定的ではなく例示的なものであると見なすべきである。本発明の範囲は、従って、前述の説明によってではなく、添付の特許請求の範囲によって示される。特許請求の範囲の均等性の意味および範囲内に入るすべての変更は、それらの範囲内に包含されるべきである。
【図面の簡単な説明】
【００５７】
【図１Ａ】従来技術例の密結合メッセージングインフラストラクチャを例示する図である。
【図１Ｂ】従来技術例の密結合メッセージングインフラストラクチャを例示する図である。
【図２】本発明にかかるメッセージングインフラストラクチャの高レベル表現を例示する図である。
【図３】本発明にかかるメッセージングインフラストラクチャの例示的実施形態を示すブロック図である。
【図４Ａ】本発明にかかるメッセージングインフラストラクチャ内で処理レイヤを抽象化する方法についての動作およびステップの例を示す図である。
【図４Ｂ】本発明にかかるメッセージングインフラストラクチャ内で処理レイヤを抽象化する方法についての動作およびステップの例を示す図である。
【図５】本発明のために適切なオペレーティング環境を提供する例示的システムを例示する図である。
【符号の説明】
【００５８】
３００  メッセージングインフラストラクチャ
３１０  メッセージングレイヤ
３１２  ポート
３４０  チャネルレイヤ
３４２  チャネルマネージャ
３４４  チャネルインスタンス
３７０  サービスレイヤ
３７２  サービスバインダ
３７４  サービスプロキシ
３７６  サービスインスタンス
３７８  サービスストア
３８２  サービスマネージャ
３９２  サービス拡張
３９４  他のマネージャ
【図１Ａ】
2004295898.tif 000003
【図１Ｂ】
2004295898.tif 000004
【図２】
2004295898.tif 000005
【図３】
2004295898.tif 000006
【図４Ａ】
2004295898.tif 000007
【図４Ｂ】
2004295898.tif 000008
【図５】
2004295898.tif 000009