JP2005339550A - サーバプール使用時の効率のよいメッセージ経路指定 - Google Patents

Abstract

【課題】 サーバプール使用時の効率よいメッセージ経路指定を提供する。
【解決手段】 システムは、サーバプールが、別個の名前を持つ複数のサーバを含む場合であってもクライアントがサーバプールのドメイン名を指定できるようにすることによって、サーバの高可用性を保証しようとする。クライアントがサーバプールのドメイン名を用いてセッションを開始すると、システムは異なる名前を持つ利用可能なサーバを選択でき、そのセッション中の要求および後続メッセージを選択されたサーバに経路指定する。システムは、プールから最低の負荷を有するサーバを選択すること、セッション中の後続メッセージが通過すべきサーバを指示することもでき、その場合後続メッセージは指示されたサーバに経路指定されて、指示されたサーバ上のアプリケーションがそれらのメッセージおよびメッセージの指定に基づいて処置できる。
【選択図】 図３

Description

以下で説明する技術は、一般に、データ通信に関し、より詳細には、サーバプール使用時にメッセージを効率よく経路指定する方法およびシステムに関する。

アプリケーションは、時として、コンピューティングデバイス間のセッションを確立し、それを管理することを必要とする。セッションとは、ある期間にわたって発生するコンピューティングデバイス間の一連の対話である。例えば、ＭＩＣＲＯＳＯＦＴ（登録商標） ＭＥＳＳＥＮＧＥＲや「ＶｏＩＰ」（インターネットプロトコル上の音声）などのリアルタイム通信アプリケーションは、ユーザに代わって通信するデバイス間のセッションを確立する。これらのアプリケーションは、「セッション開始プロトコル」（「ＳＩＰ」）など、様々な機構を用いてセッションを確立することができる。ＳＩＰは、デバイスが、相互に発見し合い、デバイス間のセッションを確立し、変更し、終了するのに使用し得るアプリケーション層の制御プロトコルである。ＳＩＰはインターネットで提案された標準である。その規格「ＲＦＣ３２６１」は＜ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ３２６１．ｔｘｔ＞で入手可能である。イベント通知に関するＳＩＰの拡張の規格、「ＲＦＣ３２６５」も＜ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ３２６５．ｔｘｔ＞で入手可能である。これらの規格両方の全体を参照により本明細書に組み込むものとする。

アプリケーションはＳＩＰを別のプロトコルと共に使用して情報を送信または受信することができる。例えば、アプリケーションは、ＳＩＰをリアルタイムトランスポートプロトコル（「ＲＴＰ」）と共に使用してセッション時にリアルタイムデータを移送することができる。ＳＩＰを他のプロトコルと共に使用することにより、アプリケーションは、セッションを作成、管理し、そのセッションの間に情報を交換することができる。ＳＩＰと共に情報を交換するための使用されるプロトコルは、その情報を複数のメッセージに分割することができる。各デバイスはＳＩＰメッセージを交換することもできる。このセッション時のメッセージの交換を「ダイアログ」という。ＳＩＰは、一般に用いられるトランスポート層およびネットワーク層プロトコルである、伝送制御プロトコル／インターネットプロトコル（「ＴＣＰ／ＩＰ」）といった下位レベルの通信層を用いてダイアログのメッセージを移送することができる。

ＳＩＰネットワークは、クライアント、サーバ、またはその両方としてダイアログに参加し得るエンティティを備える。ＳＩＰは４種類のエンティティ、すなわち、ユーザエージェント、プロキシサーバ、リダイレクトサーバ、レジストラをサポートする。ユーザエージェントは、他のＳＩＰエンティティとメッセージを交換することにより、セッションを開始し、終了する。ユーザエージェントは、一般に、ＳＩＰ要求を開始するデバイスであるユーザエージェントクライアントとすることもでき、一般に、ＳＩＰ要求を受け取り、そのような要求に応答するデバイスであるユーザエージェントサーバとすることもできる。例えば、「ＩＰ電話」、携帯情報端末、他の任意の種類のコンピューティングデバイスをユーザエージェントとすることができる。１つのデバイスを、あるダイアログではユーザエージェントクライアントとし、別のダイアログではユーザエージェントサーバとすることもでき、デバイスがダイアログの間に役割を変更することもできる。プロキシサーバは、クライアントに対するサーバおよびサーバに対するクライアントとして働くエンティティである。その際、プロキシサーバは、クライアントとサーバの間でメッセージを代行受信し、解釈し、または転送する。リダイレクトサーバは、ＳＩＰ要求を受け入れ、別のネットワークリソースにコンタクトするよう求める要求を送信したクライアントを導く応答を生成する。レジストラは、ＳＩＰクライアントから登録情報を受け入れ、位置情報サービスに受け取った登録情報を知らせるサーバである。

ＳＩＰは２種類のメッセージをサポートする。それらは、クライアントからサーバに送信される要求と、一般に要求に応答するときにサーバからクライアントに送信される応答である。ＳＩＰメッセージは３つの部分から構成される。ＳＩＰメッセージの第１の部分は「開始行」であり、メッセージタイプおよびプロトコルバージョンを指示するフィールドを含む。ＳＩＰメッセージの第２の部分は、その値が名前／値対として表されるヘッダフィールドを備える。ＳＩＰメッセージの第３の部分はメッセージの本文であり、開始すべきセッションを記述するのに使用され、またはそのセッションに関連するデータを含む。メッセージ本文は要求または応答として表示され得る。

ＳＩＰメッセージはそのヘッダフィールドの内容に基づいて経路指定される。有効であるためには、ＳＩＰ要求は少なくとも、Ｔｏ、Ｆｒｏｍ、ＣＳｅｑ、Ｃａｌｌ−ＩＤ、Ｍａｘ−Ｆｏｒｗａｒｄｓ、およびＶｉａという６つのヘッダフィールドを含む必要がある。Ｔｏヘッダフィールドは、要求の受信側の論理識別情報を指示する。Ｆｒｏｍヘッダフィールドは、要求の開始側の論理識別情報を指示する。Ｍａｘ−Ｆｏｒｗａｒｄｓヘッダフィールドは、その宛先に到着する前に要求が行い得るホップ数を指示する。例えば、デバイスＡからのメッセージが宛先デバイスＣに到着する前にデバイスＢを通過する場合、そのメッセージは２つのホップを行っていると（デバイスＢおよびＣなど）という。Ｖｉａヘッダフィールドは、その要求がそれまでにたどったパス（その要求が通過したデバイスのネットワークアドレスのシーケンスなど）を指示し、その応答を経路指定するときにたどるべきパスを指示する。ヘッダは、その後の要求および応答を指示されたデバイスを経由して経路指定すべきことを指示するのに使用されるＲｅｃｏｒｄフィールドおよびＲｅｃｏｒｄ−Ｒｏｕｔｅフィールドも含み得る。様々なネットワークデバイスは、ダイアログ中の後続メッセージをそのデバイスを経由して経路指定させるようとしてＳＩＰメッセージを転送するときに、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダフィールドを挿入することができる。Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダフィールドは、そのデバイスおよびパラメータの識別子（ネットワークアドレスなど）を含み得る。メッセージを処理するデバイスは、そのメッセージを、メッセージのＲｏｕｔｅヘッダフィールドに記載されたデバイスに経路指定させることができる。Ｒｏｕｔｅヘッダフィールド値は、デバイスによって挿入されたＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダフィールド値に基づくものとすることができる。上記その他のヘッダフィールドは前述のＳＩＰ規格に記載されている。

ＳＩＰサーバは、単一障害点となることがあり、多数の同時セッションをサポートできないことがある。このサーバが単一障害点となり得るのは、あるクライアントから、またはそのクライアントへのすべてのＳＩＰメッセージがこのサーバを通過し得るからであり、このサーバに障害が発生した場合、位置情報サービスがそのクライアントを障害が発生したサーバと関連付けるために、そのクライアントはＳＩＰダイアログに参加できなくなる可能性がある。単一のサーバは、ハードウェア（プロセッサやメモリなど）およびネットワーク帯域幅の制限のために多数のクライアントをサポートできないことがある。そのような場合、多数のクライアントがサーバサポートを拒絶され、それらのクライアント上で実行されているアプリケーションの障害を発生させることがある。

これらのＳＩＰの欠点を克服する有効な手法があれば大いに役立つはずである。

サーバプールを用いてメッセージを効率よく経路指定する手法が提供される。一実施形態では、システムは、サーバプールが、それぞれ別個の名前を持つ複数のサーバを含む場合であってもクライアントがそのサーバプールのドメイン名を指定できるようにすることによって、サーバの高可用性を保証しようとする。クライアントがそのサーバプールのドメイン名を用いてセッションを開始すると、システムは、異なる名前を持つ利用可能なサーバを選択することができ、そのセッション中の要求および後続メッセージを選択されたサーバに経路指定する。システムは、プールから最低の負荷を有するサーバを選択することができる。システムは、セッション中の後続メッセージが通過すべきサーバを指示することもできる。その場合、後続メッセージは指示されたサーバに経路指定されて、指示されたサーバ上のアプリケーションが、それらのメッセージおよびメッセージの指定に基づいて処置を講じることが可能になる。

一実施形態では、サーバプールを用いてメッセージを効率よく経路指定（ｒｏｕｔｉｎｇ）するシステムが提供される。このシステムは、サーバプールがそれぞれ別個の完全修飾ドメイン名（「ＦＱＤＮ」）を持つ複数のサーバを備える場合であってもクライアントがそのサーバプールの単一のＦＱＤＮを指定できるようにすることによって、サーバの高可用性を保証しようとする。クライアントがそのプールのＦＱＤＮを用いてＳＩＰセッションを開始すると、システムは、プールから利用可能なサーバ（または「フロントエンドサーバ」）を選択することができ、そのセッション中の要求および後続メッセージを選択されたサーバに経路指定する。選択されたサーバのＦＱＤＮは、そのサーバプールのＦＱＤＮと異なっていてもよい。システムは、サーバプールから最低の負荷を有するサーバを選択することができる。後続メッセージは選択されたサーバを通過することになるため、システムは、メッセージを直接選択されたサーバに経路指定して他のサーバへのホップを最小限に抑えようと試みることができる。メッセージが直接選択されたサーバに経路指定されず、他の中間サーバに経路指定された場合、それらのサーバが不必要にトラフィックを処理しているために全体のサーバの負荷が増大し得る。さらに、ホップが増加するために、全体のメッセージ待ち時間も増大し得る。メッセージの直接経路指定を可能にするために、システムは、要求のヘッダフィールドにパラメータとして選択されたサーバのＦＱＤＮを付加することにより、メッセージのヘッダを変更する。ネットワーク上のデバイスはこのパラメータを用いてメッセージを直接選択されたサーバに経路指定することができる。システムは、メッセージの受信側の登録サーバ（レジストラなど）のＦＱＤＮをヘッダフィールドに付加することもできる。ネットワーク上のデバイスは、このヘッダフィールドを用いて、例えば、受信側に関連する情報を探し出すために、登録サーバと通信することができる。ＳＩＰ規格に従ってメッセージを経路指定するデバイスは、そのセッション中に交換される後続のＳＩＰメッセージにこれらのヘッダフィールドおよびパラメータを保持する。これらのヘッダフィールドおよびパラメータを評価することにより、ネットワークデバイスは、メッセージを直接選択されたサーバに経路指定し、受信側に関連付けられた登録サーバに格納された情報を探し出すことができる。その後のセッションでは、あるいは選択されたサーバが（クラッシュしたなどの理由で）利用不能になったためにセッションを再確立する必要がある場合、システムはクライアントに別のサーバを選択することができる。ゆえに、システムは、サーバの高可用性を保証し、サーバ全体にわたって負荷を平衡化させることができる。

一実施形態では、メッセージのパスに沿ったサーバ上で走るアプリケーションが、通過するメッセージを正しく処理することができるように、各サーバはメッセージのヘッダにサーバの役割を指示するフラグを付加することができる。例えば、パス上のサーバは、ユーザによって送信または受信されたメッセージに関連する課金情報を記録することができる。アプリケーションがすべてのメッセージトラフィックを知り、その役割に基づいて適切な処置を講じることができるように、システムは、メッセージのヘッダフィールドにＴｏ／Ｆｒｏｍフラグを付加する。ヘッダフィールドから、そのサーバの役割が、そのセッション作成要求の元の送信側からのメッセージを処理することか、それとも元の送信側へのメッセージを処理することか判定することにより、アプリケーションは、サーバの役割を決定するための高価なデータベース検索を実行せずに、適切な処置を講じることができる。ヘッダフィールド中のパラメータを用いてサーバの役割を指示することは、システムが、メッセージに対してアプリケーションに関連した処置を講じるサーバを限定することも可能にする。この情報が、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダフィールドのパラメータとして出現すると、システムによって制御されないＳＩＰ対応デバイスは、その情報を返す。メッセージと共に移動することになるヘッダフィールドおよびパラメータを付加した結果として、データベースや他のルックアップが回避され、メッセージが正しく処理される。

一実施形態では、システムは、完全修飾でないドメイン名およびデバイス名を使用する。例えば、システムは、相対ドメイン名またはマシン名を使用することができる。システムは、これらのドメイン名およびデバイス名を解決し、またはそれらを用いてサーバプールまたはデバイスを一意に識別することができる。

次に図を見ると、図１は、サーバプール使用時の効率のよいメッセージ経路指定のためのシステムの実施形態を示すブロック図である。このシステムは少なくとも１つのサーバプール１０２を備える。システムは、さらなるサーバプールを含むことができ、それらは１つまたは複数の他のサーバプールに接続され得る。一実施形態では、サーバプールは、様々な相互接続されたドメインでホストされ得る。例えば、１つのサーバプールが「Ａ．ｃｏｍ」でホストされ、第２のサーバプールがドメイン「Ｂ．ｏｒｇ」でホストされ得る。「Ａ．ｃｏｍ」および「Ｂ．ｏｒｇ」は第２レベルドメインとみなされ、他方「．ｃｏｍ」および「．ｏｒｇ」は第１レベルドメインとみなされる。サーバプールは、それぞれ第３レベルおよび第４レベルのドメインである「Ｘ．Ａ．ｃｏｍ」や「Ｎ．Ｙ．Ｂ．ｏｒｇ」といった下位レベルドメインによっても識別され得る。

システムのサーバプールはネットワーク１０８に結合され得る。ネットワークはイントラネットとすることも、インターネットとすることも、他の任意の種類のネットワークとすることもできる。ネットワークは、１つまたは複数のユーザデバイス１１０にも結合され得る。これらのユーザデバイスは、ネットワークを用いてサーバプールとメッセージを交換することができる。

図２は、図１のサーバプールの実施形態を示すブロック図である。サーバプール２０２は、「フロントエンドサーバ」とも呼ばれる複数のサーバ２０４を備える。これらのサーバは、そのサーバプールのドメイン名に関連したマシン名によって識別され得る。例えば、サーバ１（ｓｅｒｖｅｒ１）という名前のサーバが「Ｘ．Ａ．ｃｏｍ」という名前のドメインを持つサーバプールのメンバである場合、そのサーバは、そのＦＱＤＮ「ｓｅｒｖｅｒ１．Ｘ．Ａ．ｃｏｍ」で識別され得る。これらのサーバは、相互に結合されてサーバのネットワークを形成することができる。

サーバは、データベースサーバ２０６など、他のネットワークリソースにも結合され得る。一実施形態では、各サーバ２０４はそれ自身のデータベースを持つ。代替として、サーバは、データベースサーバにあるデータベースを使用することもできる。データベースは、サーバとは別のコンピューティングデバイスにも、サーバと同じコンピューティングデバイスにも存在し得る。データベースを用いてセッションに関連する情報を格納することができる。例えば、データベースを用いて、サーバが処理する各セッションごとのサーバの役割（ｒｏｌｅ）を格納し得る。

サーバ２０４は、ロードバランサ２０８にも結合され得る。セッション作成要求がロードバランサに到着すると、ロードバランサは、各サーバ上の負荷などに基づいて、サーバプールからその要求を処理するサーバを選択することができる。例えば、サーバプールが３つのサーバを備え、１つのサーバが保守のためにサービス停止しており、残り２つのサーバの１つが高い、プロセッサまたはネットワークの利用率を持つ場合、ロードバランサは第３のサーバを選択し得る。

サーバプールは、プロキシサーバ２１０に結合され得る。プロキシサーバは、ヘッダを解釈または変更する、メッセージを転送する、メッセージをネットワークから除去するなどを含めて、それが処理するメッセージに対して様々な処置を講じる。プロキシサーバは、複数のネットワークインターフェースを備え得る。１つのインターフェースは、インターネットに結合され、別のインターフェースはサーバプールに結合され得る。サーバプールがプロキシサーバを利用するとき、クライアントとサーバプール間のすべてのトラフィックはそのプロキシサーバを通過し得る。着信要求メッセージは、まず、プロキシサーバによって処理され、そこでその要求メッセージのヘッダフィールドに現れた経路指定情報が検証され得る。次いで、メッセージは、それがシステムに存在する（図示せず）場合には、エンタープライズサービスコンポーネントに、次いで、他のアプリケーション（図示せず）に転送され得る。これらのコンポーネントは、サーバプール中のサーバによって実行され得る。

着信応答メッセージも、まず、プロキシサーバによって経路指定情報を検証するために処理され得る。次いで、応答メッセージは、（要求メッセージ処理とは逆の順序で）各アプリケーションに、次いで、それが存在する場合は、エンタープライズサービスコンポーネントに転送され得る。その場合、プロキシサーバは、その応答メッセージを転送する前に、経路指定情報を更新することができる。

図３は、要求メッセージのヘッダを検証するルーチンの実施形態を示す流れ図である。このルーチンは、プロキシサーバによって実行され、ブロック３０２から開始し、そこでパラメータとしてメッセージを受け取る。ブロック３０４で、ルーチンは、メッセージに指示されたＲｅｑｕｅｓｔ−ＵＲＩを処理する。Ｒｅｑｕｅｓｔ−ＵＲＩは、要求メッセージの受信側として識別されたユニフォームリソース識別子（「ＵＲＩ」）である。例えば、要求メッセージは、Ｒｅｑｕｅｓｔ−ＵＲＩ中でユーザまたはデバイスを識別することができる。Ｒｅｑｕｅｓｔ−ＵＲＩは「ｍａｄｄｒ」パラメータを持ち得る。ｍａｄｄｒパラメータは、ＵＲＩのヘッダフィールドによって指示されたサーバアドレスではなく、使用するサーバアドレスを指示するＵＲＩと関連付けられ得る。例えば、ＵＲＩはユーザエージェントによって使用されるサーバを指示し得るが、そのＵＲＩのｍａｄｄｒパラメータは、ユーザにコンタクトするのに使用するプロキシサーバを指示し得る。ルーチンは、Ｒｅｑｕｅｓｔ−ＵＲＩ中のｍａｄｄｒパラメータが、プロキシサーバが結合されたサーバプールのＦＱＤＮまたはプロキシサーバが接続要求のためにリッスンするＩＰアドレスを指示するかどうかチェックすることによってＲｅｑｕｓｔ−ＵＲＩを処理する。そうである場合、ルーチンは、ＲＦＣ３２６１に準拠してｍａｄｄｒパラメータを除去する。次いで、ルーチンは、Ｒｅｑｕｅｓｔ−ＵＲＩが、プロキシサーバが結合されたサーバプールのＦＱＤＮを指示するかどうか、およびＲｏｕｔｅヘッダフィールドもまたＦＱＤＮを含むかどうかチェックする。そうである場合、ルーチンは、そのＲｅｑｕｅｓｔ−ＵＲＩを最初のＲｏｕｔｅヘッダフィールドにし、最後のＲｏｕｔｅヘッダフィールドに含まれる値をＲｅｑｕｅｓｔ−ＵＲＩにする。

ブロック３０６で、ルーチンは、メッセージが信頼される接続上で到着したかどうか判定する。例えば、接続は、その接続がトランスポート層セキュリティ（「ＴＬＳ」）を使用し、システムが、そのメッセージを送信するエンティティがＴＬＳ証明書を持つか、あるいはその接続がシステムの管理者によって信頼されているとマークされていることを確認されたときに信頼される。ＴＬＳは証明書を用いて、デバイス間の専用ディジタル通信を可能にする。この技法は、ケルベロス（Ｋｅｒｂｅｒｏｓ）、ＡＥＳ（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ（高度暗号化標準））、ＤＥＳ（Ｄａｔａ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ（データ暗号化標準））などを含む任意の技術を用いて専用通信を可能にすることができる。接続が信頼される場合、ルーチンはブロック３１０に進む。そうでない場合、ルーチンはブロック３０８に進む。

ブロック３０８で、ルーチンはいくつかのヘッダフィールドを処理し、変更することができる。例えば、ルーチンは、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダフィールドおよびエッジプロキシの完全修飾ドメイン名を指示するヘッダフィールドを除去することができる。エッジプロキシとは、エッジプロキシのインターネット側にあるデバイスが、そのエッジプロキシを介してのみイントラネット上のデバイスと通信するように（例えば「非武装地帯」すなわち「ＤＭＺ」などとして）イントラネットとインターネットとにまたがるプロキシサーバである。システムがこれらのヘッダフィールドを除去するのは、その接続が信頼されなかったためにシステムがその有効性を信頼しないからである。プロキシサーバがヘッダフィールドを除去しなかった場合、後続のサーバはそれらのヘッダを誤って信頼し得る。接続が信頼され得なかったとき、プロキシサーバはクライアントからの直接接続を期待し、その場合、これらのヘッダフィールドは存在し得ないことになる。クライアントが別のプロキシを介して接続するとき、その接続は信頼されるはずである。というのは、他方のプロキシはＴＬＳを介してそれ自体を検証することができる（または信頼される接続の他の何らかの表示（ｉｎｄｉｃａｔｉｏｎ）を持つ）はずだからである。ヘッダフィールドを処理する間、ルーチンは、Ｒｅｑｕｅｓｔ−ＵＲＩが署名されているかどうか判定することもできる。Ｒｅｑｕｅｓｔ−ＵＲＩが署名されていない場合、システムは、前述と同じ理由で、サーバプール中の特定のサーバのサーバ役割または識別子を指示するパラメータを信頼することができず、そのためそれらのパラメータを除去する。ルーチンは、メッセージ中でコンタクトに指示されたＩＰアドレスが、そのメッセージを送信しているデバイスのものと同じＩＰアドレスであるかどうか判定することにより、Ｃｏｎｔａｃｔヘッダフィールドも検証する。メッセージ中のＣｏｎｔａｃｔヘッダフィールドは、メッセージの送信側がそこで要求を受け取ることになるＵＲＩを含む。

ブロック３１０で、ルーチンは、先頭のＲｏｕｔｅヘッダフィールドが、その値が先頭のＶｉａヘッダフィールドのＩＰアドレスとマッチする「ｍａｄｄｒ」パラメータを持つかどうか判定する。ヘッダフィールドがｍａｄｄｒパラメータを持つが、そのヘッダフィールドに指示されたＩＰアドレスがメッセージを送信しているエンティティのＩＰアドレスとマッチしない場合、ルーチンは、そのヘッダフィールドで識別されたＦＱＤＮに関連するＩＰアドレスおよびポートパラメータを、送信側のＩＰアドレスおよびポートで置き換える。また、ルーチンは、ダイアログの後続メッセージが正しい接続を介して送信されるように、Ｒｅｃｅｉｖｅｄ−ＣＩＤ ＵＲＩパラメータを（例えばダイアログを開始するＩＮＶＩＴＥメッセージに）付加する。Ｒｅｃｅｉｖｅｄ−ＣＩＤパラメータは、クライアントが、以前に参加しなかったダイアログに接続するのを防ぐために使用される一意の番号を含み得る。例えば、クライアントがサーバから適切に切断されず、新しいクライアントがそのサーバの同じポートに接続された場合、その新しいクライアントは、そのダイアログを続行することができる。しかしながら、その新しいクライアントは、サーバがそれをメッセージに付加しないために、正しいＲｅｃｅｉｖｅｄ−ＣＩＤパラメータを所有しないはずである。この不正確なＲｅｃｅｉｖｅｄ−ＣＩＤパラメータは、サーバからみて、その新しいクライアントがそのダイアログに属さないことを指示するものになる。ヘッダフィールドにエッジプロキシのＦＱＤＮ（またはネットワークアドレストランスレータのＦＱＤＮ）が指示される場合、ルーチンは、そのＦＱＤＮを保存し、そのヘッダフィールドを除去してそれがメッセージと一緒にサーバプールに移動するのを防ぐ。

ブロック３１２で、ルーチンは、メッセージが受け取られた接続が連合ドメイン（ｆｅｄｅｒａｔｅｄ ｄｏｍａｉｎ）とのものであるかどうか判定する。連合ドメインとは、プロキシサーバが動作するドメイン以外の信頼されるドメインである。ルーチンは、ルーチンを実行するサーバがエッジプロキシであるとき、接続が連合ドメインとのものであるかどうか評価することができる。メッセージが連合ドメインからのものであった場合、ルーチンはブロック３１４に進む。そうでない場合、ルーチンはブロック３１６に進む。

ブロック３１４で、ルーチンは、メッセージのＲｏｕｔｅヘッダフィールドおよびＲｅｑｕｅｓｔ−ＵＲＩがディジタル署名されているかどうか判定する。これらのフィールドが有効な署名でディジタル署名されている場合、ルーチンはブロック３１６に進む。そうでない場合、ルーチンは、Ｒｏｕｔｅヘッダフィールドが存在しないかどうか、およびＲｅｑｕｅｓｔ−ＵＲＩがディジタル署名されていないかどうか判定する。そうである場合、ルーチンは、サーバの役割を指示するヘッダフィールド中のパラメータを除去し、ブロック３１６に進む。そうでない場合、ルーチンはブロック３２２に進む。ブロック３２２で、ルーチンは、ユーザエージェントサーバが、既存のトランザクション（セッションなど）にマッチしない要求を受け取っていることを指示する応答コード４８１を含む応答を返す。ユーザエージェントクライアントは、そのような応答を受け取ると、それに反応してセッションを再確立しようとすることができる。

ブロック３１６で、ルーチンはＰｒｏｃｅｓｓ＿Ｈｅａｄｅｒサブルーチンを呼び出し、ブロック３１８で、ルーチンはＡｐｐｌｉｃａｔｉｏｎ＿Ｒｏｕｔｉｎｇサブルーチンを呼び出す。これらのサブルーチンについては、以下でそれぞれ図４および５に関連して詳細に説明する。ルーチンはブロック３２０でその呼び出し側に戻る。

図４は、要求メッセージヘッダを処理するためにプロキシサーバによって実行されるルーチンの実施形態を示す流れ図である。このルーチンはブロック４０２から開始し、そこでパラメータとしてメッセージを受け取る。ブロック４０４で、ルーチンは、メッセージにＲｏｕｔｅヘッダフィールドがあるかどうか判定する。Ｒｏｕｔｅヘッダフィールドが見つかった場合、ルーチンはブロック４０６に進む。そうでない場合、ルーチンはブロック４１０に進む。

ブロック４０６で、ルーチンは、先頭のＲｏｕｔｅヘッダフィールドのＦＱＤＮが、そのサーバが属するサーバプールのＦＱＤＮにマッチするかどうか判定する。ＦＱＤＮがマッチする場合、ルーチンはブロック４０８に進む。そうでない場合、ルーチンはブロック４２０に進む。ブロック４０８で、ルーチンは、Ｒｏｕｔｅヘッダから、サーバの役割と、メッセージがそこに経路指定されるサーバの識別を指示するパラメータを抽出する。

ブロック４１０で、ルーチンは、Ｒｅｑｕｅｓｔ−ＵＲＩから、サーバの役割と、メッセージがそこに経路指定されるサーバの識別を抽出する。これらのパラメータは、あるエンティティによって、そのエンティティが、そのヘッダを処理するプロキシサーバが果たす役割を決定したときに、Ｒｅｑｕｅｓｔ−ＵＲＩに付加されたものとすることができる。ブロック４１２で、ルーチンは、宛先サーバを指示するパラメータが、ルーチンを実行するサーバ以外のサーバを指示するかどうか判定する。そうである場合、ルーチンはブロック４１４に進む。そうでない場合、ルーチンはブロック４１６に進む。ブロック４１４で、サーバの役割を指示するパラメータが抽出された場合、その役割は、さらなる処理を実行するアプリケーションが、その役割に関連する情報を取り出すことができるように、例えば、そのサーバに結合されたデータベースに格納される。ブロック４１６で、ルーチンは、このルーチンが実行されているサーバにメッセージを送信したエンティティによって挿入されたように見えるように、先頭のＲｏｕｔｅヘッダを複製する。ブロック４２０で、ルーチンは、要求を受け取ったユーザエージェントサーバが、対応するトランザクション（セッションなど）を持たないことを指示する、４８１の応答コードを用いて応答する。ブロック４１８で、ルーチンは呼び出し側に戻る。

図５は、要求メッセージを処理するためにシステムのエンタープライズサービスコンポーネントによって実行されるルーチンの実施形態を示す流れ図である。エンタープライズサービスコンポーネントは、アプリケーションによってメッセージに基づく特別な処理を実行するのに使用され得るロジックを提供する。このコンポーネントは、それが「Ｔｏ」サーバであるかそれとも「Ｆｒｏｍ」サーバであるかに基づいて処理を実行する（例えば、送信または受信されたメッセージに関連する課金情報を収集する）ことができる。「Ｔｏ」サーバは、元のセッション作成要求の宛先のサーバプール中のサーバである。それに対して、「Ｆｒｏｍ」サーバは、元のセッション作成要求の送信側のサーバプール中のサーバである。サーバが「Ｆｒｏｍ」サーバであるかそれとも「Ｔｏ」サーバであるかをそのサーバの「役割」と呼ぶ。

ルーチンは、ブロック５４８でサーバがＮＯＴＩＦＹメッセージを作成したとき、またはブロック５０２において他の任意の状況で（例えばそれがメッセージを処理するときなどに）開始し得る。サーバがＮＯＴＩＦＹメッセージを生成すると、ルーチンはブロック５４８で実行開始する。そのような場合、サーバの役割は暗黙的に「Ｆｒｏｍ」に設定することができる。ＮＯＴＩＦＹメッセージはリソースの状態を指示する、あるユーザエージェントから別のユーザエージェントへのメッセージである。ブロック５４９で、ルーチンは、生成されたＮＯＴＩＦＹメッセージがすでにＲｏｕｔｅヘッダを持っているかどうか判定する。サーバは、データベースからＲｏｕｔｅヘッダを取り出し、それらを生成されたＮＯＲＩＦＹメッセージに入れていることがある。ＮＯＴＩＦＹメッセージがすでにＲｏｕｔｅヘッダを持っている場合、ルーチンはブロック５０８に進む。そうでない場合、ルーチンはブロック５２８に進む。

ルーチンは、ブロック５０２でパラメータとしてメッセージを受け取った場合に開始し得る。ブロック５０４で、ルーチンは、メッセージが認証について信頼されているかどうか判定する。メッセージは、それが、ルーチンを実行するサーバと同じドメインの別のサーバからのＴＬＳ接続で、メッセージが信頼されていることを指示するエッジプロキシからのＴＬＳ接続で、または管理者によって信頼されるとマークされた接続で到着したときに、認証について信頼される。前述のように、この技法は、専用通信を可能にする任意の技術と共に使用することができる。メッセージが認証について信頼される場合、ルーチンはブロック５０６に進む。そうでない場合、ルーチンは、ブロック５３６に進む。

ブロック５０６で、ルーチンは、メッセージにＲｏｕｔｅヘッダが存在するかどうか判定する。メッセージ中のＲｏｕｔｅヘッダフィールドの存在は、サーバがすでにメッセージの次のホップを指示していること、または、メッセージが、経路（ホップシーケンスなど）が前のメッセージによってすでに確立されている既存のセッションの一部であり、そのため、サーバは次のホップを決定する必要がないこと、を示すものである。一実施形態では、サーバは、それがメッセージのヘッダに指示されたＵＲＩに責任を負わないことを検証することもできる。Ｒｏｕｔｅヘッダが存在する場合、ルーチンはブロック５０８に進む。そうでない場合、ルーチンはブロック５１２に進む。ブロック５０８で、ルーチンは、以下で図６に関連して詳細に説明するＯｔｈｅｒ＿Ｒｏｕｔｉｎｇサブルーチンを呼び出す。ブロック５１０でルーチンはその呼び出し側に戻る。

ブロック５１２で、ルーチンは、役割パラメータが、（例えば、プロキシサーバ、そのメッセージを処理した前のサーバによって、またはそのセッションの前のメッセージを経路指定することによって）以前に保存されたかどうか判定する。そのようなパラメータが以前に保存されたとき、それはルーチンからみて、そのサーバの役割が以前に決定されていることを示すものである。そうである場合、ルーチンはブロック５１４に進む。そうでない場合、ルーチンはブロック５２８に進む。

ブロック５１４で、ルーチンは、サーバの役割が「Ｔｏ」であるかどうか判定する。そうである場合、ルーチンはブロック５１６に進む。そうでない場合、ルーチンは、ブロック５２４に進む。ブロック５１６で、ルーチンは、要求の宛先が「Ｔｏ」サーバプールのサーバであるかどうか判定する。そうである場合、ルーチンはブロック５１８に進む。そうでない場合、ルーチンはブロック５２０に進む。ブロック５１８で、ルーチンはその要求を処理し、応答を送信することができる。

ブロック５２０で、ルーチンは、メッセージのヘッダフィールドにエンドポイント識別子（「ＥＰＩＤ」）を指示するパラメータが存在するかどうか判定する。ＥＰＩＤを用いて、１人のユーザに関連する複数のログイン（例えば、デスクトップコンピューティングデバイスからのものとセルラ電話からのものなど）を区別することができる。ＥＰＩＤパラメータの存在は、「Ｔｏ」サーバプールのエンドポイントがすでに選択されていることを示す。というのは、ＥＰＩＤパラメータを最初にメッセージに付加するのは「Ｔｏ」サーバであり、このパラメータが後続メッセージで保持されるからである。ＥＰＩＤパラメータが存在する場合、ルーチンはブロック５２２に進む。そうでない場合、ルーチンはブロック５０８に進む。ブロック５２２で、ルーチンは、次のサーバが「Ｔｏ」サーバであることを指示するＲｏｕｔｅヘッダをメッセージに挿入する。また、サーバは、メッセージがそのプール中の別のサーバに経路指定されない限り、その役割を「Ｔｏ」に設定することもできる。そのプール中の別のサーバに経路指定される場合、サーバは、そのサーバプール中の別のサーバを指し示すために先頭のＲｏｕｔｅヘッダフィールドにパラメータを付加することになる。

ブロック５２４で、ルーチンは、要求の宛先が「Ｆｒｏｍ」サーバであるかどうか判定する。そうである場合、ルーチンは、ブロック５１８に進む。そうでない場合、ルーチンは、ブロック５２６に進む。ブロック５２６で、ルーチンは、サーバの役割が「Ｆｒｏｍ」であるという指示を保存する。ブロック５２８で、ルーチンは、サーバが「Ｔｏ」サーバプールのドメインにあるかどうか判定する。そうである場合、ルーチンはブロック５３０に進む。そうでない場合、ルーチンはブロック５０８に進む。

ブロック５３０で、ルーチンは、「Ｔｏ」サーバプールのＦＱＤＮを取り出す。ブロック５３２で、ルーチンは、ルーチンを実行するサーバが「Ｔｏ」サーバプールのメンバであるかどうか判定する。そうである場合、ルーチンはブロック５１６に進む。そうでない場合、ルーチンはブロック５３４に進む。ブロック５３４で、ルーチンは、次のサーバが「Ｔｏ」サーバであることを指示するパラメータと共に、メッセージのＲｅｑｕｅｓｔ−ＵＲＩに「Ｔｏ」サーバプールのＦＱＤＮを付加する。その結果、Ｒｅｑｕｅｓｔ−ＵＲＩがプロキシサーバによって次に処理されるときに、メッセージは「Ｔｏ」サーバプール中のサーバに送信される。

ブロック５３６で、ルーチンは、メッセージが認証されたかどうか判定する。メッセージが認証された場合、ルーチンはブロック５３８に進む。そうでない場合、ルーチンはブロック５４６に進む。ブロック５４６で、ルーチンは、プロキシサーバに、チャレンジメッセージを発行するよう要求する。

ブロック５３８で、ルーチンは、メッセージに、そのメッセージが既存のセッション中のダイアログの一部であることを指示するＲｏｕｔｅヘッダがあるかどうか判定する。そうである場合、ルーチンはブロック５０８に進む。そうでない場合、ルーチンはブロック５４０に進む。

ブロック５４０で、ルーチンは「Ｆｒｏｍ」サーバプールのＦＱＤＮを取り出す。ブロック５４２で、ルーチンは、ルーチンを実行するサーバが、「Ｆｒｏｍ」サーバプールのメンバであるかどうか判定する。そうである場合、ルーチンはブロック５２４に進む。そうでない場合、ルーチンはブロック５４４に進む。ブロック５４４で、ルーチンは、次のサーバが「Ｆｒｏｍ」サーバであることを指示するパラメータと共に、メッセージのヘッダ中のＲｅｑｕｅｓｔ−ＵＲＩに「Ｆｒｏｍ」サーバプールのＦＱＤＮを付加する。Ｒｅｑｕｅｓｔ−ＵＲＩが次にプロキシによって処理されるとき、メッセージは、「Ｆｒｏｍ」サーバプール中のサーバに送られる。

図６は、アプリケーションに関連した経路指定を可能にするために要求メッセージヘッダを処理するルーチンの実施形態を示す流れ図である。このルーチンは、ブロック６０２で開始し、そこでパラメータとしてメッセージを受け取る。ブロック６０４で、ルーチンは、メッセージにヘッダフィールドおよび関連する値を挿入する。例えば、ルーチンは、プロキシに経路ヘッダを挿入するよう要求することができる。そのような場合、プロキシは、サーバの役割を設定することもできる。ルーチンを実行するサーバ上で走るアプリケーションは、さらにＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダフィールドを付加することができる。例えば、アーカイブアプリケーションは、メッセージがアーカイブされていることを指示するために、メッセージにＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダフィールドを付加することができる。そのメッセージを再度受け取ると（あるいはおそらく、そのメッセージが通過する別のサーバ上で実行されるアプリケーションがそのメッセージを受け取ったときに）、アプリケーションは、そのフィールドがすでに付加されているため、メッセージが以前にアーカイブされたと判定することができるはずである。

ブロック６０６で、ルーチンは、メッセージの次のホップがメッセージのヘッダから判定され得るかどうか評価する。宛先を指示するＲｏｕｔｅヘッダフィールドがある場合、ルーチンは、Ｒｏｕｔｅヘッダから次のホップのためのＦＱＤＮまたはＩＰアドレスを決定する。そうではなく、Ｒｅｑｕｅｓｔ−ＵＲＩでサーバプールのサーバが識別され、メッセージが経路指定について信頼されている場合、指示されたサーバが次のホップとして使用される。そうではなく、Ｒｅｑｕｅｓｔ−ＵＲＩが、そのサーバに関連付けられた静的経路指定表中のパターンにマッチする場合、次のホップはその静的経路指定表から取り出される。メッセージは、それが信頼される接続で受け取られるか、またはそのＲｅｑｕｅｓｔ−ＵＲＩが、サーバ上にインストールされたアプリケーションによって変更されたか、あるいはその経路指定情報がディジタル署名されているときに、経路指定について信頼される。メッセージが経路指定について信頼されている場合、ルーチンは、メッセージのヘッダ中のＲｅｑｕｅｓｔ−ＵＲＩのホスト部分を次のホップとして識別する。次のホップが決定され得ない場合、ルーチンはブロック６２０に進む。そうでない場合、ブロック６０８で、ルーチンは、決定された次のホップのＦＱＤＮまたはＩＰ番号を解決し、識別されたエンティティに接続する（またはすでに開いている接続を使用する）。

ブロック６１０で、ルーチンは、ＦＱＤＮが解決され、接続が開いているかどうか判定する。そうである場合、ルーチンは、ブロック６１２に進む。そうでない場合、ルーチンは、ブロック６２０に進む。ブロック６１２で、ルーチンは、要求がローカルで生成されたかどうか、およびＲｅｃｏｒｄ−Ｒｏｕｔｅが必要とされるかどうか判定する。Ｒｅｃｏｒｄ−Ｒｏｕｔｅは、サーバ役割パラメータが保存されるとき、および他のいくつかの状況において、エッジプロキシ、転送プロキシ上で必要とされる。Ｒｅｃｏｒｄ−Ｒｏｕｔｅは、ＮＯＴＩＦＹ、ＭＥＳＳＡＧＥ、ＩＮＦＯ、ＳＥＲＶＩＣＥメッセージタイプなど、ダイアログを開始しないメッセージには必要とされない。メッセージがローカルで生成されたのではなく、あるいはＲｅｃｏｒｄ−Ｒｏｕｔｅが必要とされる場合、ルーチンはブロック６１４に進む。そうでない場合、ルーチンはブロック６１６に進む。

ブロック６１４で、ルーチンは、メッセージにヘッダフィールドまたはパラメータを付加することができる。どのヘッダおよびパラメータが付加されるかは、メッセージが送信される接続が「一方向」とマークされているかどうかに左右され得る。管理者は、例えば、デバイスをより安全にするために、一方向接続のみにデバイスを使用可能にすることができる（例えば、デバイスが他のデバイスからの接続要求を受け入れることができないなど）。接続が「一方向」とマークされると、ルーチンは、メッセージのＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダフィールドに、そのサーバのＦＱＤＮ、ポートおよびＩＰアドレス情報を付加することができ、それらは、メッセージの受信側が、メッセージを返すときのセッションでそのデバイスによって確立された接続を使用できるようにする。接続が一方向とマークされず、ルーチンを実行するサーバがサーバプールのサーバである場合、ルーチンは、サーバを識別するパラメータ（例えば、サーバ自体のＦＱＤＮまたは単にドメインに関連したサーバの名前）と共にサーバプールのＦＱＤＮをＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダフィールドに付加する。そのセッションでシステムによって後続メッセージが受け取られたとき、システムは、そのパラメータに基づき、どのサーバにその後続メッセージを経路指定すべきか決定することができるはずである。接続が一方向とマークされておらず、ルーチンを実行するデバイスがサーバプールにないとき、ルーチンは、デバイスがエッジプロキシであり、評価されている要求メッセージがクライアントまたは転送プロキシで発信されたかどうか判定する。そうである場合、ルーチンは、後続メッセージが同じエッジプロキシを介して経路指定されるように、接続が一方向とマークされたときに付加されたものと類似のヘッダフィールドおよびパラメータを付加することができる。そうでない場合、ルーチンは、Ｒｅｃｏｒｄ−ＲｏｕｔｅヘッダフィールドにサーバのＦＱＤＮを付加することができる。デバイスがエッジプロキシである場合、デバイスは、メッセージがそこに転送されるデバイスによって解決され得るＦＱＤＮ（すなわち、次のサーバがイントラネットの内部にあるかそれとも外部にあるかに応じて、イントラネットの内部または外部で解決され得るＦＱＤＮ）を付加することができる。これらのヘッダフィールドを付加した後、ルーチンは、逆方向のパラメータ（ｏｐｐｏｓｉｔｅ ｐａｒａｍｅｔｅｒ）が以前に格納されていた場合には、さらに、サーバの役割を（例えばＦｒｏｍをＴｏにまたはその反対に）反転するパラメータを付加することができる。

ブロック６１６で、ルーチンはメッセージを転送する。メッセージを転送する前に、ルーチンは、メッセージがそこで送信される接続が経路指定について信頼されているかどうか判定する。例えば、ＴＬＳ（または専用通信を可能にする他の何らかの機構）を用い、あるいは管理者によって信頼されると明示的に指示された接続が経路指定について信頼される。接続が経路指定について信頼され、プロセスがエッジプロキシによって実行されている場合、ルーチンは、その接続が連合ドメインとのものであるかどうか判定する。連合ドメインは、そのサーバのドメイン以外の信頼されるドメインである。接続が信頼されておらず、または接続が連合ドメインとのものである場合、ルーチンは、メッセージ中の任意のＣｏｎｔａｃｔおよびＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダフィールドにディジタル署名し、署名を先頭のＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダフィールドに入れる。Ｖｉａヘッダもディジタル署名される。次いでルーチンは、メッセージを転送する。ブロック６１８で、ルーチンはその呼び出し側に戻る。ブロック６２０で、ルーチンは、サーバが要求を処理しようとしたときに適時の応答を受け取らなかったことを示す５０４応答コードを用いて応答する。

図７は、応答メッセージを処理するルーチンの実施形態を示す流れ図である。このルーチンはブロック７０２で開始し、そこでパラメータとして応答メッセージを受け取る。ブロック７０６で、ルーチンは、メッセージが複数のＶｉａヘッダフィールドを含むかどうか判定する。メッセージが複数のＶｉａメッセージフィールドを含む場合、それは、その応答を別のサーバに転送する必要がある可能性があることを示すものである。そうである場合、ルーチンはブロック７０８に進む。そうでない場合、ルーチンはローカルでその応答を消費し（ｃｏｎｓｕｍｅ）、ブロック７１６に進む。

ブロック７０８で、ルーチンは、メッセージが受け取られた接続が経路指定について信頼されているかどうか判定する。接続が経路指定について信頼される状況については、先に、例えば、図６との関連で説明した。接続が経路指定について信頼される場合、ルーチンは、ヘッダフィールドがそのような値を指示したときにエッジプロキシのＦＱＤＮを保存し、そのヘッダフィールドを除去する。そうでない場合、ルーチンは、応答メッセージのＣｏｎｔａｃｔヘッダフィールドを、それらのフィールドが、サーバが接続されているエンティティ（またはプロキシ）と同じＩＰアドレスを指示することを検証し、Ｒｅｃｅｉｖｅｄ−ＣＩＤ ＵＲＩパラメータを付加することによって処理し、ルーチンを実行するサーバとセッションを持つ別のクライアントがその同じＩＰアドレスおよびポートを使用しないよう保証しようする。接続が経路指定について信頼され、ルーチンがエッジプロキシによって実行されている場合、ルーチンは、その接続が連合ドメインへのものであるかどうか判定する。その接続が連合ドメインへのものである場合、またはＣｏｎｔａｃｔヘッダフィールドを処理した後、ルーチンは、メッセージ中の経路指定情報が、Ｒｅｃｏｒｄ−ＲｏｕｔｅおよびＶｉａヘッダフィールド中の署名とマッチすることを検証する。接続が連合ドメインからのものではなく、あるいは経路指定署名が検証された場合、ルーチンは、アプリケーションおよびエンタープライズサービスがその応答を処理できるようにする。経路指定署名が（例えばヘッダが適正にディジタル署名されていなかったために）検証されなかった場合、ルーチンはその応答を取り消す。ルーチンは、応答のヘッダフィールドを分析することにより、このルーチンを実行するサーバが、前の要求にＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダフィールドを挿入したかどうか判定する。そうである場合、ルーチンはブロック７１０に進む。そうでない場合、ルーチンは、ブロック７１２に進む。

ブロック７１０で、ルーチンは、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダフィールドを処理する。ルーチンは、応答中にＣｏｎｔａｃｔヘッダがない場合、ルーチンを実行するサーバを指示するＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダフィールドがあれば、それを除去する。ルーチンは、現在の応答を生じた前の要求を処理するときに、そのルーチンまたは別のプロキシが挿入した可能性のある他の関連するヘッダフィールドも除去することができる。ルーチンは、ヘッダにサーバの役割を指示するパラメータを付加して（または除去されたパラメータの値を使用して）、前の要求の送信側が後続の要求を送信するときにその役割が識別され、または使用され得るようにすることもできる。ルーチンは、管理者が接続を一方向とマークしたかどうかチェックする。一方向接続とは、ネットワーク中の他のデバイスがそのサーバのＦＱＤＮを解決し、またはそのサーバに戻る接続を確立することができないことを示すものである。例えば、管理者は、サーバを、発信接続を可能にし、着信接続をできないものとするファイアウォールにすることを望むことができる。接続が一方向とマークされている場合、ルーチンは、応答のＲｅｃｏｒｄ−ＲｏｕｔｅヘッダフィールドにサーバのＦＱＤＮ、ＩＰアドレス、およびポート情報を付加することができる。ルーチンは、前のホップのＶｉａヘッダフィールドからの転送ポイントパラメータを用いて、ネットワークアドレストランスレータの通過に関する問題を処理することもできる。

接続が一方向とマークされておらず、ルーチンを実行するデバイスがサーバプールのサーバである場合、ルーチンは、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダフィールドに、サーバのＦＱＤＮを指示するパラメータと共にサーバプールのＦＱＤＮを付加する。そのセッションでシステムによって後続メッセージが受け取られるとき、システムは、そのパラメータに基づいてどのサーバにその後続メッセージを経路指定すべきか決定することができるはずである。接続が一方向とマークされておらず、ルーチンを実行するデバイスがサーバプールにない場合、ルーチンは、そのデバイスがエッジプロキシであり、評価されている要求メッセージがクライアントまたは転送プロキシで発信されたかどうか判定する。そうである場合、ルーチンは、後続メッセージが同じエッジプロキシを介して経路指定されるように、接続が一方向とマークされたときに付加されるものと類似のヘッダフィールドおよびパラメータを付加することができる。そうでない場合、ルーチンは、Ｒｅｃｏｒｄ−ＲｏｕｔｅヘッダフィールドにサーバのＦＱＤＮを付加することができる。デバイスがエッジプロキシである場合、デバイスは、メッセージがそこに転送されるデバイスによって解決され得るＦＱＤＮを付加することができる。これらのヘッダフィールドを付加した後、ルーチンは、逆方向のパラメータが以前に格納された場合は、サーバの役割を（例えばＦｒｏｍをＴｏにまたはその反対に）反転するパラメータを付加することができる。

ブロック７１２で、ルーチンは、先頭のＶｉａヘッダフィールドを除去する。ブロック７１４で、ルーチンは応答を転送する。発信接続が（例えば、それがＴＬＳまたは専用接続を可能にする他の何らかの機構を使用しており、あるいは管理者によって信頼されると指示されているために）経路指定について信頼される場合、ルーチンは、接続が連合ドメインへのものであるかどうか判定する。接続が連合ドメインへのものである場合、ルーチンはＲｅｃｏｒｄ−Ｒｏｕｔｅおよびコンタクト情報を含むヘッダフィールドにディジタル署名する。ルーチンは、発信接続が経路指定について信頼されない場合にもこれらのヘッダフィールドに署名する。次いで、ルーチンは、その応答経路の次のエンティティに応答を転送する。ブロック７１６で、ルーチンはその呼び出し側に戻る。

メッセージを効率よく経路指定するシステムが実施されるコンピューティングデバイスは、中央処理装置、メモリ、入力装置（キーボードやポインティング装置など）、出力装置（表示装置など）、および記憶装置（ディスクドライブなど）を含み得る。メモリおよび記憶装置は、そのセキュリティシステムを実施する命令を含み得るコンピュータ可読媒体である。また、そのデータ構造およびメッセージ構造は、通信リンク上の信号などのデータ伝送媒体によって格納され、送信され得る。インターネット、ローカルエリアネットワーク、広域ネットワーク、ポイントツーポイントダイヤルアップ接続など、様々な通信リンクが使用され得る。

図１および図２には、このセキュリティが実施され得る適当な動作環境の一例が示されている。この動作環境は、適当な動作環境の一例にすぎず、この拡張可能な無線フレームワークの使用または機能の範囲に関するどのような限定も示唆するものではない。使用に適し得る他の公知のコンピューティングシステム、環境および構成には、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップ機器、マルチプロセッサシステム、マイクロプロセッサベースのシステム、プログラム可能家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、前述のシステムまたはデバイスのいずれかを含む分散コンピューティング環境などが含まれる。

このセキュリティシステムは、１つまたは複数のコンピュータまたは他のデバイスによって実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的なコンテキストで説明され得る。一般に、プログラムモジュールには、個々のタスクを実行し、個々の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。通常、プログラムモジュールの機能は、様々な実施形態において、所望に応じて組み合わされ、分散され得る。

以上から、本明細書では、説明のために、本発明の特定の実施形態について説明したが、本発明の精神および範囲から逸脱することなく、様々な変更が加えられ得ることが理解されよう。したがって、本発明は、添付の特許請求の範囲による以外には限定されない。

サーバプール使用時の効率のよいメッセージ経路指定のためのシステムの実施形態を示すブロック図である。 図１のサーバプールの実施形態を示すブロック図である。 プロキシサーバによって要求メッセージヘッダを検証するために実行されるルーチンの実施形態を示す流れ図である。 プロキシサーバによって要求メッセージヘッダを処理するために実行されるルーチンの実施形態を示す流れ図である。 システムのエンタープライズサービスコンポーネントによって要求メッセージを処理するために実行されるルーチンの実施形態を示す流れ図である。 アプリケーションに関連した経路指定を可能にするために要求メッセージヘッダを処理するルーチンの実施形態を示す流れ図である。 応答メッセージを処理するルーチンの実施形態を示す流れ図である。

符号の説明

１０２ サーバプール１〜ｎ
１０８ ネットワーク
１１０ ユーザ１〜ｍ
２０４ サーバ１〜ｎ
２０６ データベース
２０８ ロードバランサ
２１０ プロキシ

Claims (40)

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. 前記役割がＴｏであることを特徴とする請求項３８に記載のコンピュータ可読媒体。
    

Images