JP2007527587A - アプリケーションサーバ及びトランザクションベースシステムにおけるコンテキスト伝搬のためのシステム及び方法 - Google Patents

Abstract

【課題】アプリケーションサーバ、メッセージングシステム、及びトランザクションベースシステム内でコンテキスト伝搬するためのシステム及び方法を提供する。
【解決手段】コンテキストエリアは、ユーザが、システムの内部及び外部の両方に対して、その後全てのリクエストと共に搬送されるアプリケーションと情報を関連付けできるようにする。ダウンストリームコンポーネントは、それが発信者に逆戻りして搬送され得るように、この情報に追加し又はこの情報を変更し得る。この機能性に対する共通のユースケースは、診断モニタリング、アプリケーショントランザクション、アプリケーション負荷平衡、及び情報が帯域外で搬送される必要がある全く任意の状況を含む。帯域外情報を伝搬するための能力は、ユーザＡＰＩの汚染を妨げ、また、リードオンリー（すなわちサードパーティ）コンポーネントに対する情報の追加を許容する。
【選択図】図２

Description

本発明は、概して、アプリケーションサーバ、メッセージングシステム及びトランザクションベースシステムに関し、より詳細には、それらのシステムにおけるコンテキスト伝搬のためのシステム及び方法に関する。

[優先権主張]
出願番号第６０／５７２，６４７のアプリケーションサーバ及びトランザクションベースシステムにおけるコンテキスト伝搬のためのシステム及び方法と題する米国仮出願は、Ａｎｄｒｅｗ Ｐｉｐｅｒによって２００４年５月１９日に出願され（Ａｔｔｙ．Ｄｏｃｋｅｔ番号：ＢＥＡＳ−０１５４８ＵＳ０）、この中に参照によって取り込まれるものである。

出願番号第＿＿＿のアプリケーションサーバ及びトランザクションベースシステムにおけるコンテキスト伝搬のためのシステム及び方法と題する米国特許出願は、Ａｎｄｒｅｗ Ｐｉｐｅｒによって２００５年５月１６日に出願され（Ａｔｔｙ．Ｄｏｃｋｅｔ番号：ＢＥＡＳ−０１５４８ＵＳ１）、この中に参照によって取り込まれるものである。

Ｊａｖａ（登録商標、以下同様）プログラミング言語およびＪａｖａ２エンタープライズエディション（Ｊ２ＥＥ）は、多段の又は多層のソフトウェアアプリケーション開発用のフレームワークを提供する。これらのアプリケーションは、セキュリティサービス及びトランザクションサービスなどの標準的な組織全体のサービスを利用する。Ｊ２ＥＥソフトウェア開発セットの例は、ＢＥＡシステムＩｎｃからウェブロジックサーバ（ＷＬＳ）およびウェブロジックインテグレーション（ＷＬＩ）生成を含んでいる。ソフトウェア開発者は、これらの開発セットを利用し、アプリケーションサーバ上に配備される複雑なアプリケーションであって、いろいろなソース−おそらく開発セットの異なるサブシステム又は企業内開発されたコンポーネント又はサードパーティコンポーネントからのコンポーネントを順番に利用する複雑なアプリケーションを開発する。

しかしながら、これらの異なるコンポーネントの全てを最終的なアプリケーションに統合することは、自明な事項ではない。多くの例において、アプリケーションは、全てのコンポーネントのために全ての方式に関するパラメータとして現実的に宣言され得ないデータを必要とする。幾つかのセキュリティ及びトランザクションコンポーネントがアプリケーションサーバフレームワークによって理解され得るコンテキスト情報を追加する能力を提供する一方で、伝統的な開発セットは、この特徴を拡張して特定のアプリケーションに的確であるコンテキストを追加するための能力を欠く。

この制限を解消するための１つの技術は、パラメータをシステムの各インターフェースに追加することである。しかしながら、これは困難であり、サードパーティコンポーネントが統合されなければならない場合には不可能になり得る。他の技術は、ポータブルインターセプタを利用するなどの中央セキュリティ主導者又は精巧な次善策に頼るものである。

Ｊａｖａソフトウェアコミュニティで目下開発されている１つのアプローチは、Ｊａｖａコミュニティプロセスワークエリア技術であり、一般にＪＳＲ−１４９仕様などに参照されており、この中に参照によって取り込まれる。ワークエリア仕様により、開発者はプロパティをアプリケーションコンテキストとして定義することができ、そのアプリケーションコンテキストは、その後、リモートリクエストをわたって流れ、ダウンストリームコンポーネントが特定の呼び出しクライアントのコンテキスト内で機能することができるようにする。特に、ワークエリアにより、Ｊ２ＥＥコンポーネントは、プロパティを設定すると共に、特定のアプリケーションによって定義され、特定のリクエストと関連する分散型コンテキストに対して及び分散型コンテキストからプロパティを回復することができる。

しかしながら、上述の技術は、ＪＳＲ−１４９を含めて、柔軟性を与えるものではない。それらは、例えば、ＲＭＩにおけるコールパラメータがＡＰＩの一部でないかを理解されるようにする。アプリケーションコンテキストはまた、ＳＰＩが各ステップで再度プログラムされる必要がないように伝搬され得る。しかしながら、これらの技術は、例えば、企業のいたるところに診断情報を分散するための能力に容易に対して拡張され得ない。必要とされるのは、診断及び他の目的で、情報がシステムに対して通信され、その後、システムのいたるところに循環され得るより柔軟性のある手段である。

本発明の一実施形態によると、アプリケーションサーバ、メッセージシステム及びトランザクションベースシステム内のコンテキスト伝搬のためのシステム及び方法が提供される。コンテキストエリアにより、ユーザは、システムの内部及び外部に対して、情報を全てのリクエストに加えてその後に搬送されるアプリケーションと関連させることができる。ダウンストリームコンポーネントは、この情報に追加し又はこの情報を変更することができ、それは発信者に戻され得る。この機能に対する共通のユースケースは、診断モニタリング、アプリケーショントランザクション、アプリケーション負荷平衡及び情報が帯域外を搬送されることが必要である全く任意の状況を含んでいる。帯域外情報を伝搬する能力は、ユーザＡＰＩの汚染を防ぎ、また、リードオンリー（すなわちサードパーティ）コンポーネントに対する情報の追加を可能する。

また、コンテキストエリア技術は、並んでいる配置に対して用いられ、そこでアプリケーションの異なるバージョンは展開され、特定の環境内で共存する。

なお、開発者は、リクエストの宛先及びどのように伝搬されるべきであるかを特定し得る。加えて、システムは、トランスポート特定のコンテキスト情報をそれらのトランスポートに関するリクエストをマーシャリングする際に使用するために提供でき、その技術は、例えば、ＪＭＳ、ＳＯＡＰ又はサーブレットと共に用いられる。

システムは、特に、顧客、層をなした製品（特に統合化製品）、及び帯域外情報を送信する要求を有するサブシステムに対して有用である。

本発明の一実施形態によると、アプリケーションサーバ、メッセージングシステム及びトランザクションベースシステム内のコンテキスト伝搬のためのシステム及び方法が提供される。コンテキストエリアにより、システムに対する内部及び外部の両方のユーザは、情報を全てのリクエストに加えてその後に搬送されるアプリケーションと関連させることができる。ダウンストリームコンポーネントは、この情報に追加し又はこの方法を変更することができ、それは発信者に戻され得る。この機能に対する共通のユースケースは、診断モニタリング、アプリケーショントランザクション、アプリケーション負荷平衡、及び情報が帯域外を搬送されることが必要である全く任意の状況を含んでいる。帯域外情報を伝搬する能力は、ユーザＡＰＩの汚染を妨げ、また、リードオンリー（すなわちサードパーティ）コンポーネントに対する情報の追加を可能にする。

コンテキストエリア技術はまた、並んでいる配置に対して用いられ、そこでアプリケーションの異なるバージョンは展開され、特定の環境内で共存する。

なお、開発者は、リクエストの宛先及びどのように伝搬されるべきであるかを特定し得る。

加えて、システムは、トランスポート特定のコンテキスト情報をそれらのトランスポートに関するリクエストをマーシャリングする際に使用するために提供でき、その技術は、例えば、ＪＭＳ、ＳＯＡＰ又はサーブレットと共に用いられる。

システムは、特に、顧客、層をなした製品（特に統合化製品）、及び帯域外情報を送信する要求を有するサブシステムに対して有用である。

システムの可能性のある使用例は以下を含む。
アプリケーションサーバシステムのアドミニストレータは、なぜ特定のアプリケーションファンクションが過度に長時間を要するのかを決定することを必要とする。アドミニストレータは、コンテキストエリアサブシステムを介してシステムに入るリクエストに対する診断情報を追加するためのシステムを構成する。システムにおいて適切なポイントカットでインストールされる状況は、タイムスタンプ情報をＣｏｎｔｅｘｔＡｒｅａコンテキストに追加し、結果として生ずるデータは、アドミニストレータによって収納される。これはまた、リクエスト“ダイイング”として知られる。

アプリケーションクライアントは、サーバに対するリクエストの負荷平衡を保たせる必要がある。コンテキストエリアサブシステムは、クライアントが適切な負荷平衡を決定することができるように、負荷情報を応答に対して追加するのに用いられる。

性能を改善するために、ＥＪＢ ＣＭＰコンテナは、それが内部のコンテキストを介して伝搬されるクライアントからのヒントに基づいて使用するキャッシュセットを変化させる。

自己同調機能は、優先度に基づいてリクエストを動的に類別する。

統合化サービスベンダ（ＩＳＶ）は、それらの取引製品をアプリケーションサーバ（例えばＷＬＳ）に統合するのに必要である。ＩＳＶは、コンテキストエリアＡＰＩを利用して、リクエストに対するアプリケーショントランザクションをＷＬＳに追加する。ＩＳＶは、その後、適切なＣｏｎｔｅｘｔＡｒｅａコンテキストを検査することによって、ＷＬＳから出てくるリクエストをそれらのアプリケーショントランザクションと相関させる。

顧客は、アプリケーションデータに基づいたＳＯＡＰリクエストをフィルタリングしたいものである。顧客は、コンテキストエリアサブシステムを用いてアプリケーションデータを全てのＳＯＡＰリクエストに追加する。データはＳＯＡＰレベルで透過的であるので、それらは標準的なＳＯＡＰツールを用いてフィルタリングすることができる。

顧客は、自分のネットワークの至るところにグローバルセキュリティトークンを伝播したいものである（例えば、カーベロスチケット）。このトークンは、外国のサーバと相互作用するために用いられ得る。

顧客は、コンテキストエリアＡＰＩを用いている自分のアプリケーションを、あるブランドのアプリケーションサーバから別のものに転送（移動）したいものである。

本システム及び方法の他の利用及び応用は、上述したものに加えてなされ得る。システムの利用は、ここに述べられている特定の例に限定されるものではないことは明らかであるが、その他の使用は、本発明の意図及び範囲内で開発され得るものである。

以下の用語は次の記載の範囲内で用いられる。

ＲＭＩ−リモートメソッドインボケーション
ＷＬＳ−ウェブロジックサーバ
ＷｏｒｋＣｏｎｔｅｘｔＭａｐ−スレッドローカルプロパティのセット
Ｃｏｎｔｅｘｔ Ｄａｔａ／Ｒｕｎｔｉｍｅ Ｃｏｎｔｅｘｔ／ＷｏｒｋＣｏｎｔｅｘｔ−スレッドローカルプロパティ値
Ａｐｐｌｉｃａｔｉｏｎ Ｔｒａｎｓａｃｔｉｏｎｓ−ＪＳＲ−９５によって定義される拡張されたトランザクション
ＵｓｅｒＣｏｎｔｅｘｔＡｒｅａ−オーバーラップする可能性のあるワークコンテキストマップのセット
Ｏｖｅｒｌａｙ／ｏｖｅｒｒｉｄｅ−同じ名前を用いた別のものによるワークコンテキストの一時隠蔽

図１は、コンテキスト伝搬を可能にする本発明の一実施形態に従う環境の例証を示す。図１に示されるように、クライアント１００は、サーバ１０４で実行する１又は複数のアプリケーション１０６、１０８に関するリクエスト１１０を生成する。ユーザコンテキストエリア１１８は、クライアント又はアプリケーションＪＮＤＩ環境の一部として提供され、ＪＮＤＩを介してアクセスされ得る。ユーザコンテキストエリアは、オーバーラップする可能性のあるユーザコンテキストマップ１２０、１２２のセットを含んでいる。ユーザコンテキストマップは、コンテキストが異なる種類のリクエストを用いて伝搬されるようにする低レベルＡＰＩのセットである。

図２は、本発明の一実施形態に従うコンテキスト伝搬に用いられるコンテキストエリアの例証を示す。図２に示されるように、コンテキストエリア１３６により、リクエスト１３４の発信者１３０は、ワークコンテキストマップ１４０を介したリクエストとコンテキスト１４４を関連させることができるようになる。コンテキストは、その後、システムにわたり他のコンポーネントに伝搬され得る。ダウンストリームコンポーネント１４８は、コンテキストを変更し又はコンテキストに追加し得る。この変更後のコンテキストは、その後、帯域外１５０に通信され、リクエストの発信者に戻され得る。

図３は、本発明の一実施形態に従うクライアント／サーバ環境におけるコンテキスト伝搬のための方法のフローチャートを示す。図３に示されるように、ステップ１６０では、ユーザコンテキストエリアは、どのユーザレベルＡＰＩ名が選択されようともプレースホールダーとして定義される。ステップ１６２では、クライアントは、アプリケーションに伝搬されることになる情報と共にリクエストにタグを付ける。ステップ１６４では、リクエストは、その後、アプリケーションに伝達される。ステップ１６６では、サーバは、必要に応じてコンテキスト情報にアクセスする。

図４は、本発明の一実施形態に従う帯域外のコンテキスト伝搬のための方法のフローチャートを示す。図４に示されるように、ステップ１７０では、ユーザコンテキストエリアが定義される。ステップ１７２では、リクエストの発信者は、一定のポリシー制約条件に基づいて伝搬されることになる情報と共にリクエストにタグを付ける。ステップ１７４では、リクエストが、その後、アプリケーションに伝達される。ステップ１７６では、伝搬プロバイダは、必要に応じてコンテキスト情報にアクセスする。ステップ１７８では、コンテキスト情報は、最新の要求に従って必要に応じて変更される。ステップ１８０では、変更後のコンテキスト情報が帯域外で発信者に伝達される。

実装例
一実施形態によると、本システム及び方法は、コンテキストエリア及びコンテキストマップを操作するのに用いられ得る多くの特徴を含んでいる。

ユーザコンテキストエリア
この特徴により、ユーザは、ＪＳＲ−１４９によって定義されるコンテキストエリアを作成し、読み出し、変更し、削除することができる。ユーザコンテキストエリアは、どのユーザレベルＡＰＩ名が選択されようともプレースホールダーである。ユーザコンテキストエリアは、エンドユーザ、ＩＳＶ、及び（リモート又はローカルであるかどうかの）一定のリクエストにタグを付け、一定のポリシー制約条件に基づいた情報を伝搬するための他のメカニズムを提供する。ユーザコンテキストエリアは、クライアント又はアプリケーションＪＤＮＩ環境の一部であり、ＪＤＮＩを介してアクセスし得る。

ＵｓｅｒＣｏｎｔｅｘｔＡｒｅａ ｒｃ＝（ＵｓｅｒＣｏｎｔｅｘｔＡｒｅａ）ｎｅｗ
ＩｎｉｔｉａｌＣｏｎｔｅｘｔ（）．ｌｏｏｋｕｐ（“ｊａｖａ：ｃｏｍｐ／ＵｓｅｒＣｏｎｔｅｘｔＡｒｅａ”）；

ワークコンテキストマップ
この特徴により、内部のユーザは、異なる種類のリクエストと共に伝搬されるコンテキストを作成し、読み出し、変更し、削除することができる。ワークコンテキストマップは、このサービスの内部消費者に対する低レベルＡＰＩのセットである。それは以下のヘルパーを介してアクセスされ得る。

ＷｏｒｋＣｏｎｔｅｘｔＭａｐ ｒｃ＝ＷｏｒｋＣｏｎｔｅｘｔＭａｐＨｅｌｐｅｒ．
ｇｅｔＷｏｒｋＣｏｎｔｅｘｔＭａｐＨｅｌｐｅｒ（）．ｇｅｔＷｏｒｋＣｏｎｔｅｘｔＭａｐ（）；

コンテキストエリアＳＰＩ
本特徴により、伝搬プロバイダは、トランスポート特有の方法でマーシャリングするための下位伝搬コンテキストで得ることができる。

ユーザ定義の情報（内部）の伝搬
このコンテキストにおけるユーザは、実際のサーバ（例えばＷＬＳ）サブシステム及び層をなす製品を意味する。幾つかの実施形態では、サーバによって実装される全てのリクエスト範囲に渡ってユーザ定義されたデータを伝搬することが可能である。これは、以下のものを含んでいる。

ワークマネージャインボケーション、すなわちスレッド間の情報の転送。
ＲＭＩインボケーション。
トランザクション。ＪＴＡは一般にトランザクションごとの情報を伝搬するためのそれ自身のメカニズムを有している。コンテキスト情報は、現在のトランザクションと共に搬送され、トランザクションが中断されている又は終了されている場合には伝搬されない。
ＪＭＳ。ＪＭＳは、待ち行列及びトピックを含む多くの異なるデータ通過モデルを有し、個別に取り扱われ得る。
ＳＯＡＰ。特にＪＡＸ−ＲＰＣ。
ユーザ。
ＭＩＭＥ−ＨＥＡＤＥＲＳ。ＨＴＴＰリクエストで生じるクッキー又はＳＭＴＰを介して生じるｍｉｍｅヘッダは、適切なコンテキストに変換され、システムにわたって伝搬される。また、サードパーティ負荷平衡器は、サーバへの注入のためにこれらのヘッダを合成することが可能である。

互いに共同してこれらのモードを利用することは可能であり得る。“ローカル”伝搬を有することは可能であるが、スレッドローカル変数の利用が等価であり望まれる。デフォルト伝搬モードは、ＲＭＩ、ＪＭＳ、ＳＯＡＰ及びＭＩＭＥ−ＨＥＡＤＥＲＳを含む“リモート”である。

任意のＪａｖａデータを伝搬することは、これは、下位の実装に関する性能制約条件が多すぎ、また、Ｊａｖａでない（non-Java）コンテキスト（例えば、Ｃ＋＋又はＸＭＬ）においてアクセスするのは困難であるので望ましくない。インターフェースは、ＡＰＩのユーザが、伝搬するには相対的に複雑な構造を定義することができるように提供され得る。これらの構造は、Ｊａｖａ．ｉｏ．ＤａｔａＯｕｔｐｕｔ及びｊａｖａ．ｌａｎｇ．Ｓｔｒｉｎｇによって許容されるタイプから構築され得る。特に、任意のｊａｖａ．ｉｏ．Ｓｅｒｉａｌｉｚａｂｌｅ又はｊａｖａ．ｉｏ．Ｅｘｔｅｒｎａｌｉｚａｂｌｅデータを通過させることは望ましくない。

この方法において定義されるデータに対する下位の評価メカニズムは存在しない。特定の相互操作性要求を有するクライアントは、自分自身のバージョン情報を定義すべきである。バージョン情報は、コンテキスト名でエンコードされ得る。

幾つかの実施形態では、範囲（スコープ）が変化する場合にコールバックを得るために（例えばノーティフィアブルワークコンテキスト（ＮｏｔｉｆｉａｂｌｅＷｏｒｋＣｏｎｔｅｘｔ）を実装することによって）ワークコンテキスト実装に対するメカニズムが存在する。これにより、コンテキストは、効果的にフォーク（分岐）ポイントを取得することができる。

ユーザ定義される情報（外部）の伝搬
このコンテキストにおけるユーザは、アプリケーションプログラマ及びＩＳＶを意味する。幾つかの実施形態では、ユーザ定義されるデータを上記で定義されるように伝搬することが可能である。なお、これは下位の実装に関して性能制約条件を負わせるが、任意のＪａｖａデータを伝搬することが可能である。外部のユーザ定義されるデータの伝搬は、内部のユーザ定義されるデータの伝搬をサポートするように実装されるＡＰＩをあてにするだろう。
アプリケーションレベルＡＰＩは、ＪＳＲ−１４９、コンテキストエリアＡＰＩの存在、又はサーバ（例えばウェブロジック）特有のＡＰＩの１つであり得る。

幾つかの実施形態では、このメカニズムを用いた単純なデータタイプを伝搬するためのメカニズムも存在する。ユーザは、Ｓｅｒｉａｌｉｚａｂｌｅを用いることを強いられるべきではない。ユーザデータタイプに対する任意のスキーマ要素をサポートすることが可能である。
内部ＳＰＩ
このサービスの内部作成者は、コンテキスト情報を容易にインポート及びエクスポートすることは可能でなければならない。これらのプロバイダは、データマーシャリングのための実装を提供することのみを有しているべきである。スレッドローカル記憶へ／からのインポート及びエクスポートは、ＳＰＩによって提供され得る。ＳＰＩレベルでは、トランザクションをこのメカニズムに切り替えることは意図されていないが、提供される機能性がトランザクションをサポートするのに十分に有力であることが意図されている。

本発明は、従来の一般的な成果又は特定のデジタルコンピュータ又は本開示の教示に従ってプログラムされるマイクロプロセッサを用いて適切に実行され得る。適切なソフトウェアコード化は、ソフトウェア技術の当業者には明らかであるように、本開示の教示に基づいて熟練プログラマによって容易く準備され得る。

幾つかの実施形態では、本発明は、そこに記憶される命令を有する記憶媒体であるコンピュータプログラム製品を含んでおり、コンピュータをプログラムするのに用いられ、本発明のプロセスのいずれかを実行することができる。記憶媒体は、これに限定されるというわけではないが、フロッピー（登録商標）ディスク、光ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブ及び磁気光学ディスクを含むいずれかのタイプのディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリデバイス、磁気又は光カード、（分子メモリＩＣを含む）ナノシステム、又は命令及び／又はデータを記憶するのに適した媒体又はデバイスのいずれかのタイプを含む。

本発明に係る上述の記載は、例証及び説明という目的のために提供されているものである。網羅的であること又は開示されたその形態に本発明を限定することは意図されていない。実施形態は本発明の原理及びその実際のアプリケーションを最良に説明するために選択され記載されたものであり、それによって、他の当業者は、様々な実施形態に対する本発明及び熟慮される特定の使用に適した様々な変更を有する本発明を理解することができる。本発明の範囲は特許請求の範囲及びそれらの均等物によって定義されることが意図される。

コンテキスト伝搬を許容する本発明の一実施形態に従う環境の例証を示す。 本発明の一実施形態に従ってコンテキスト伝搬が用いられるときのコンテキストエリアの例証を示す。 本発明の一実施形態に従うクライアント／サーバ環境におけるコンテキスト伝搬のための方法のフローチャートを示す。 本発明の一実施形態に従う帯域外コンテキスト伝搬のための方法のフローチャートを示す。

Claims (12)

1. リクエストをアプリケーションサーバで実行するアプリケーションに伝達するための第１のコンポーネントと、
   ユーザがコンテキスト情報をその後に全てのリクエストと共に伝搬されるアプリケーションと関連付けすることを許容するコンテキストエリア（ＣｏｎｔｅｘｔＡｒｅａ）と、
   を備えたアプリケーションサーバ内のコンテキスト伝搬のためのシステム。
2. 前記第１のコンポーネントはクライアントであることを特徴とする請求項１に記載のシステム。
3. 前記システムは、前記コンテキスト情報を変更することができる第２のダウンストリームコンポーネントを含むことを特徴とする請求項１に記載のシステム。
4. 変更されたコンテキスト情報は、帯域外通信を利用して前記第１のコンポーネントに逆戻りして伝達されることを特徴とする請求項３に記載のシステム。
5. 前記システムは、トランスポート特定のコンテキスト情報を、それらのトランスポートに関してリクエストをマーシャリングする際に利用するために提供できることを特徴とする請求項１に記載のシステム。
6. アドミニストレータは、診断情報を前記システムに入るリクエストに追加するように前記システムを構成できることを特徴とする請求項３に記載のシステム。
7. リクエストを第１のコンポーネントからアプリケーションサーバで実行するアプリケーションに伝達するステップと、
   ユーザがコンテキスト情報をその後に全てのリクエストと共に伝搬されるアプリケーションと関連付けすることを許容するコンテキストエリア（ＣｏｎｔｅｘｔＡｒｅａ）における前記リクエストをマッピングするステップと、
   を備えたアプリケーションサーバ内のコンテキスト伝搬のための方法。
8. 前記第１のコンポーネントはクライアントであることを特徴とする請求項７に記載の方法。
9. 前記システムは、前記コンテキスト情報を変更できる第２のダウンストリームコンポーネントを含むことを特徴とする請求項７に記載の方法。
10. 変更されたコンテキスト情報は、帯域外通信を利用して前記第１のコンポーネントに逆戻りして伝達されることを特徴とする請求項９に記載の方法。
11. 前記システムは、トランスポート特定のコンテキスト情報を、それらのトランスポートに関してリクエストをマーシャリングする際に利用するために提供できることを特徴とする請求項７に記載の方法。
12. アドミニストレータは、診断情報を前記システムに入るリクエストに追加するように前記システムを構成できることを特徴とする請求項９に記載の方法。

Images