JP2010108479A - 一意性保証情報設定管理プログラム、アプリケーション・プログラム、負荷分散プログラム、一意性保証実現方法、セッション管理方法、一意性保証情報設定管理装置、及び負荷分散装置 - Google Patents

Abstract

【課題】複数のサーバに負荷を分散させる場合に、複数の通信プロトコル間の連携に対応した一意性保証を実現させるための技術、更には、通信ネットワーク上のトラフィック等による送信時間の増大に適切に対応した一意性保証を実現するための技術を提供する。
【解決手段】振分対象サーバ３０の複数プロトコル連携部３３は、複数の通信プロトコルを連携させたサービスが提供可能である。セッション情報監視部３４は、その連携部３３によるセッション生成を監視し、セッションが生成された場合に、そのＩＤをセッション情報通知部３５に渡す。それにより、セッションＩＤ、及びセッションを生成したサーバ３０のアドレスが一意性保証情報設定管理装置４０に通知される。管理装置４０は、セッションＩＤと振分対象サーバ３０のアドレスの対応関係を示す一意性保証情報を生成し、別の通信プロトコルでの一意性保証用にサーバロードバランサ２０に設定する。
【選択図】図４

Description

本発明は、複数の通信プロトコルでそれぞれサービスを提供可能な複数のサーバのなかから端末装置からの関連する要求（メッセージ）を同じサーバに振り分ける一意性保証を実現させるための技術に関する。

サーバの負荷分散は通常、ＳＬＢ（Server Load Balancer：負荷分散装置）が利用される。ＳＬＢはクライアントである端末装置からの要求（メッセージ）をラウンドロビン方式等の自律振分アルゴリズムに従って複数のサーバのうちの一つに振り分ける。その振り分けによって、情報が交換されている時間の単位であるセッションがサーバに生成され、そのセッションを一意に識別するためのセッションＩＤ（識別情報）がＳＬＢを介して端末装置に通知される。

ＳＬＢは、セッションＩＤとそのＩＤのセッションを保持するサーバとの関係を振分テーブルに登録する。端末装置は、セッションＩＤをヘッダに格納したメッセージにより要求を行う。ＳＬＢは、ヘッダに格納されたセッションＩＤを用いて振分テーブルを参照することにより、そのセッションＩＤのセッションを保持するサーバにメッセージを振り分ける。そのようにしてＳＬＢは、セッションが継続する間、同じ端末装置からのメッセージは同じサーバに振り分ける機能を持っている。この機能は一意性保証機能（或いはセッション維持機能）と呼ばれる。

図１、及び図２は、一意性保証の実現方法を説明する図である。図１は、インターネット電話などで用いられるＳＩＰ（Session Initiation Protocol）で一意性保証を実現する場合の説明図であり、図２は、Ｗｅｂサーバと端末装置（ブラウザ）がデータを送受信するのに使われるＨＴＴＰ（HyperText Transfer Protocol）で一意性保証を実現する場合の説明図である。

複数のサーバ１７３０は、ＳＬＢ１７２０により仮想化され、仮想サーバとして端末装置であるクライアント１７１０からアクセスされる。クライアント１７１０からのＳＩＰを用いたサービスの要求は、トランスポート・ヘッダの宛先アドレスを仮想サーバのアドレスとしたメッセージ（パケット）の送信により行われる。そのメッセージのＳＩＰヘッダには、識別用のコールＩＤが格納されている。

クライアント１７１０から送信されたメッセージは、ＳＬＢ１７２０により、トランスポート・ヘッダの宛先アドレス（Ｄｓｔ）がサーバ１７３０のうちの一つのアドレスに変換され、振り分けられる。その振り分けによってクライアント１７１０に対応付けられたサーバ１７３０にＳＩＰセッション１７３２が生成される。サーバ１７３０は、そのセッション１７３２に割り当てた形のコールＩＤをＳＩＰヘッダに、自サーバ１７３０のアドレスをトランスポート・ヘッダの送信元アドレス（Ｓｒｃ）として格納したメッセージを生成し、ＳＩＰ用のＩ／Ｆ１７３１を介してＳＬＢ１７２０に送信する。

ＳＬＢ１７２０は、コールＩＤをセッション識別用の情報として、コールＩＤとサーバ１７３０のアドレスの組み合わせをＳＩＰ用の振分テーブル１７２１に登録する。サーバ１７３０から受信したメッセージは、トランスポート・ヘッダに格納された送信元アドレスを仮想サーバのアドレスに変換し、ＳＩＰクライアント１７１０に送信する。

以降クライアント１７１０は、ＳＩＰヘッダにコールＩＤ、トランスポート・ヘッダの宛先アドレスとして仮想サーバのアドレスを格納したメッセージを送信する。ＳＬＢ１７２０は、振分テーブル１７２１を参照し、ＳＩＰヘッダ内のコールＩＤからメッセージの送信先とするサーバ１７３０を特定し、特定したサーバ１７３０にメッセージを転送する。その転送のために、トランスポート・ヘッダの宛先アドレスはサーバ１７３０のアドレスに変換する。サーバ１７３０から送信されたメッセージは、トランスポート・ヘッダの送信元アドレスは仮想サーバのアドレスに変換する。そのようにしてＳＬＢ１７２０は、セッション１７３２が保持されている間、クライアント１７１０から送信されたメッセージは同じサーバ１７３０に処理させる。この結果、一意性保証が実現される。

一意性保証は、通信プロトコルがＳＩＰからＨＴＴＰに変わっても、図２に示すように同様の方法によって実現される。ＨＴＴＰでは、ＳＬＢ１７２０によって振り分けられたクライアント１７１０からのメッセージはサーバ１７３０のＨＴＴＰ用のＩ／Ｆ１７３５によって受信され、ＨＴＴＰセッション１７３６が生成される。サーバ１７３０は、そのセッション１７３６に割り当てられたセッションＩＤをＨＴＴＰヘッダのｃｏｏｋｉｅに格納したメッセージを生成し、Ｉ／Ｆ１７３５を介してＳＬＢ１７２０に送信する。

ＳＬＢ１７２０は、セッションＩＤとサーバ１７３０のアドレスの組み合わせをＨＴＴＰ用の振分テーブル１７２２に登録する。サーバ１７３０から受信したメッセージは、トランスポート・ヘッダに格納された送信元アドレスを仮想サーバのアドレスに変換し、クライアント１７１０に送信する。それにより以降、振分テーブル１７２２を参照して、クライアント１７１０から受信したメッセージの転送先を決定することにより、一意性保証を実現させる。

振分テーブル１７２１に登録されたコールＩＤとサーバ１７３０のアドレスの組み合わせ、振分テーブル１７２２に登録されたセッションＩＤとサーバ１７３０のアドレスの組み合わせは共に、一意性保証を実現させるための情報である。このことから以降「一意性保証情報」と総称する。

ところで、例えばＮＧＮ（Next Generation Network）のＳＤＰ（Service DiscoveryProtocol）の分野では、複数の通信プロトコルを組み合わせたサービスを要求可能なアプリケーション・プログラム（以降「連携アプリケーション」と総称する。アプリケーション・プログラムは「アプリケーション」或いは「アプリ」と略記する）が提供されるようになっている。その連携アプリケーションとは、ＳＩＰの呼確立後にＨＴＴＰ経由で呼情報を表示可能なものや、Ｗｅｂページ経由でＳＩＰの呼制御を行えるものなどである。その連携アプリケーションの代表例として、ＳＩＰとＨＴＴＰとを連携可能なＣＳＢＮＡ（Call Schedule on Busy or No Answer）アプリケーションがある。

連携アプリケーションでは、通信プロトコル間の連携を実現するために、或る通信プロトコル経由でセッションが生成されたサーバに他の通信プロトコル経由でも到達させる必要がある。つまり、通信プロトコル間の連携にも、一意性保証の実現が必要である。しかしＳＬＢは、通信プロトコル毎にメッセージを振り分けるサーバを選択する。このため、複数の通信プロトコルを連携させる場合、複数の通信プロトコルで一意性保証をサポートしない。

図３は、従来、サーバ群の前段に配置したＳＬＢにより負荷分散させる場合のクライアント、ＳＬＢ、及びサーバの動作を示すシーケンス図である。このシーケンス図は、アリス（Alice）が使用する端末装置であるクライアントにより、ボブ（Bob）が使用するクライアントとの間でＳＩＰを用いた通話の開始を要求し、その通話が開始できなかったことから、アリスが使用するクライアントがＨＴＴＰを用いてＵＲＬ（Uniform Resource Locator）にアクセスするケースを例にとったものである。通話は、サーバ群のうちの一つであるＳＩＰサーバ１７３０を介して行うことを想定している。

図３では、アリス及びボブがそれぞれ使用するクライアントは、通信プロトコル別に論理的な実体（エンティティ）を表記している。クライアントの一つであるＳＩＰメッセージを処理するＵＡ（ユーザ・エージェント）は、アリスの使用するクライアントでは「ＡＳＵ」（「Alice's SIP UA」の略記）、ボブの使用するクライアントでは「ＢＳＵ」（「Bob's SIP UA」の略記）とそれぞれ表記している。符号としては１７１１、１７１３をそれぞれ付している。アリスのクライアントで実行されるブラウザは「ＡＢ」（「Alice's browser」の略記）と表記し、符号として１７１２を付している。論理的な実体に言及する必要がない場合には、図１および図２から「クライアント１７１０」と表記する。

ＳＬＢ１７２０では、構成要素として、送受信・識別部１７２５、ＳＩＰ処理部１７２６、およびＨＴＴＰ処理部１７２７を表記している。送受信・識別部１７２５は、クライアント１７１０との間の通信や、クライアント１７１０が送信したメッセージから通信プロトコルを識別する構成要素である。ＳＩＰ処理部１７２６は、ＳＩＰにより送信されたメッセージ（ＳＩＰメッセージ）を処理する構成要素である。ＨＴＴＰ処理部１７２７は、ＨＴＴＰにより送信されたメッセージ（ＨＴＴＰメッセージ）を処理する構成要素である。

ＳＩＰサーバ１７３０では、構成要素として、ＣＳＢＮＡアプリケーション（図中「ＣＳＢＮＡアプリ」と略記）１７３３、及びＳＩＰ ＵＡ１７１１による要求によって生成されるセッション（図３中「アプリセッション＃１」と表記）１７３２を表記している。

先ず、ＳＩＰ ＵＡ１７１１は、アリスの指示によりステップＳＢ４１の処理を実行し、ボブとの通話を開始するためにＩＮＶＩＴＥ要求をＳＬＢ１７２０に送信する（シーケンスＳ２１０１）。ＩＮＶＩＴＥ要求のためのメッセージのＳＩＰヘッダには、ＳＩＰ ＵＡ１７１１によるコールＩＤ（図３中「Ｃａｌｌ−ＩＤ＃１」と表記）が格納される。このＩＮＶＩＴＥ要求は、送受信・識別部１７２５がステップＳ４０１を実行することによりＳＩＰメッセージと認識され、ＳＩＰ処理部１７２６に送られる（シーケンスＳ２１０２）。ＳＩＰ処理部１７２６は、ステップＳＥ４１を実行することにより、振り分け先を決定し、ＳＩＰサーバ１７３０に送る（シーケンスＳ２１０３）。また、一意性保証を実現するために、コールＩＤと振り分けたＳＩＰサーバ１７３０のアドレスの組み合わせを一意性保証情報として振分テーブル１７２１に登録する（シーケンスＳ２１０４）。

ＳＩＰサーバ１７３０のＣＳＢＮＡアプリケーション１７３３は、ステップＳＨ４１を実行し、ボブ側（着呼側）で使用するコールＩＤを決定して、そのコールＩＤをＳＩＰヘッダに格納したＩＮＶＩＴＥ要求をＳＬＢ１７２０に返信する（シーケンスＳ２１０５）。

一方、ＣＳＢＮＡアプリケーション１７３３は、発呼者向けに、処理中であることを通知するための１００Ｔｒｙｉｎｇ応答を生成して送信する（シーケンスＳ２１３１）。この応答は、送受信・識別部１７２５がステップＳＤ４３を実行することで識別され、ＳＩＰ処理部１７２６に渡される（シーケンスＳ２１３２）。ＳＩＰ処理部１７２６は、ステップＳＥ４３を実行することにより、１００Ｔｒｙｉｎｇ応答をアリスが使用するクライアント１７１０に送信する。この結果、ＳＩＰ ＵＡ１７１１がステップＳＢ４２を実行することで１００Ｔｒｙｉｎｇ応答は処理される。

ＳＩＰサーバ１７３０から送信されたＩＮＶＩＴＥ要求は、送受信・識別部１７２５がステップＳＤ４２を実行することによりＳＩＰメッセージと識別され、ＳＩＰ処理部１７２６に送られる（シーケンスＳ２１０６）。ＳＩＰ処理部１７２６は、ステップＳＥ４２を実行して、ＩＮＶＩＴＥ要求中のコールＩＤとＳＩＰサーバ１７３０のアドレスの組み合わせを一意性情報として振分テーブル１７２１に登録する（シーケンスＳ２１０７）。その後、ＩＮＶＩＴＥ要求をボブが使用するクライアント１７１０に送信する（シーケンスＳ２１０８）。

ボブのクライアント１７１０に送信されたＩＮＶＩＴＥ要求は、ＳＩＰ ＵＡ１７１３がステップＳＣ４１を実行することで処理される。ここでは、他の通話を行っているなどの理由により、通話を開始できない旨を送信元（アリス）に通知するための４８６Ｂｕｓｙ応答（レスポンス）を送信する（シーケンスＳ２１０９）。

４８６Ｂｕｓｙ応答は、ＳＬＢ１７２０の送受信・識別部１７２５がステップＳＤ４４を実行することで識別され、ＳＩＰ処理部１７２６に渡される（シーケンスＳ２１１０）。ＳＩＰ処理部１７２６は、ステップＳＥ４４を実行することにより、４８６Ｂｕｓｙ応答中のコールＩＤを用いて振分テーブル１７２１を参照し、この応答を振り分けるべきＳＩＰサーバ１７３０を特定する（シーケンスＳ２１１１）。それにより、この応答は特定したＳＩＰサーバ１７３０に送信する（シーケンスＳ２１１２）。

ＳＩＰサーバ１７３０のＣＳＢＮＡアプリケーション１７３３は、ステップＳＨ４２を実行して、受信した４８６Ｂｕｓｙ応答を処理する。それにより、セッション１７３２を生成する（シーケンスＳ２１１３）。そのセッション１７３２ではステップＳＩ４１を実行して、そのＩＤを返す（シーケンスＳ２１１４）。また、ＣＳＢＮＡアプリケーション１７３３は、セッション１７３２のデータとして、発呼者（ここではアリスのＳＩＰ−ＵＲＩ（Uniform Resource Identifier））と着信者（ここではボブのＳＩＰ−ＵＲＩ）とを保存する（シーケンスＳ２１１５、ステップＳＩ４２）。その後セッション１７３２からの応答が返ると（シーケンスＳ２１１６）、ＨＴＴＰ経由でアクセスするためのＵＲＬに取得したセッションＩＤを埋め込み、そのＵＲＬをコンタクトＵＲＩヘッダに記載した３０２応答（Redirect）をＳＬＢ１７２０に送信する（シーケンスＳ２１１７）。３０２応答は、ボブのＳＩＰ ＵＡ１７１３から４８６Ｂｕｓｙ応答が返信されたことにより、発呼者に別の対応を促すために送信される。

この３０２応答は、送受信・識別部１７２５がステップＳＤ４５を実行することにより識別され、ＳＩＰ処理部１７２６に渡される（シーケンスＳ２１１７）。ＳＩＰ処理部１７２６は、ステップＳＥ４５を実行することにより、３０２応答をアリスが使用するクライアント１７１０に送信させる（シーケンスＳ２１１９）。クライアント１７１０に送信された３０２応答は、ＳＩＰ ＵＡ１７１１がステップＳＢ４３を実行することで処理される。それにより、ブラウザ１７１２が起動される（シーケンスＳ２１２０）。

起動されたブラウザ１７１２は、ステップＳＡ４１を実行することにより、３０２応答のコンタクトＵＲＩヘッダに記載されたＵＲＬにアクセスするためのＨＴＴＰ ＧＥＴ要求を送信する（シーケンスＳ２１２１）。この要求は、ＳＬＢ１７２０の送受信・識別部１７２５がステップＳＤ４６を実行することで識別され、ＨＴＴＰ処理部１７２７に渡される（シーケンスＳ２１２２）。ＨＴＴＰ処理部１７２７は、ステップＳＦ４１を実行することにより、ＨＴＴＰ ＧＥＴ要求で指定されたＵＲＬからセッションＩＤを抽出し、振分テーブル１７２２を参照する（シーケンスＳ２１２３）。

この参照時では、ＨＴＴＰ ＧＥＴ要求はアリスが使用するクライアント１７１０から受信した最初のＨＴＴＰメッセージである。このため振分テーブル１７２２には、その要求が指定するＵＲＬから抽出されたセッションＩＤは登録されていない。それにより、自律振分の対象とされる。その結果、ＨＴＴＰ ＧＥＴ要求はＳＩＰメッセージと同じＳＩＰサーバ１７３０に振り分けることは保証できないこととなる。

ＳＬＢ１７２０の自動振分機能により、ＨＴＴＰメッセージがＳＩＰメッセージを振り分けるＳＩＰサーバ１７３０とは異なるサーバ１７３０に振り分けられた場合、その異なるサーバ１７３０にはＵＲＬに含まれるセッションＩＤによって特定されるセッション１７３２が存在しない。このため、エラーとなり、処理を継続できなくなる。このようなことから、複数のサーバに負荷を分散させる場合であっても、複数の通信プロトコル間の連携に対応した一意性保証を考慮することが重要と考えられる。

サーバ上に生成されたセッションは、一定時間、端末装置からの要求を受信しないことを条件に削除するのが普通である。これは、不要、或いは不要である可能性の高いセッションを残すことによる資源の浪費を抑えるのが主な理由である。

セッションを削除する条件として設定される時間（以降「タイムアウト時刻」）は、様々な状況を考慮して決定される。しかし、端末装置とＳＬＢを接続する通信ネットワーク上のトラフィックやＳＬＢの負荷状態等により、端末装置から要求が送信されてからサーバが受信するまでに比較的に長い時間がかかる場合がある。その場合、本来はセッションが削除されないタイミング（タイムアウトとならないタイミング）で端末装置から要求を送信したにも係わらず、サーバがセッションを削除してしまう可能性がある。

セッションを削除した後にサーバが要求を受信した場合もエラーとなる。サーバの負荷を軽減するためには、エラー処理を行う頻度は抑えるのが望ましい。しかし、本来はタイムアウトとならないタイミングで端末装置から要求を送信したとしても、通信ネットワーク（電気通信回線）上のトラフィック等による送信時間の増大により、タイムアウトとなる場合がありうる。このことから、一意性保証の実現では、サーバの負荷を抑えるために、送信時間の増大に適切に対応できるようにすることも重要と考えられる。

特開２００４−２４７９１６号公報 特開２００５−３１８４３９号公報 特許第３９６３６９０号公報

dynamicsoft Inc., "SIP Servlet API Version 1.0",February 4, 2003.

本発明は、複数のサーバに負荷を分散させる場合に、複数の通信プロトコル間の連携に対応した一意性保証を実現させるための技術を提供することを目的とする。
また、本発明は、通信ネットワーク上のトラフィック等による送信時間の増大に適切に対応した一意性保証を実現するための技術を提供することを目的とする。

本発明を適用した１システムでは、端末装置から第１の通信プロトコルを用いたサービスの提供の要求により、負荷分散装置が複数のサーバのなかから選択したサーバ内で生成されるセッションを識別するための識別情報を取得し、取得した識別情報とその識別情報に対応するセッションを生成したサーバとの対応関係を第２の通信プロトコルによるサービスで一意性保証用の一意性保証情報として負荷分散装置に設定し、端末装置から第２の通信プロトコルを用いたサービスの提供が要求された場合に、設定された一意性保証情報を負荷分散装置に参照させて、サービスを提供させるサーバを複数のサーバのなかから選択させる。

第１の通信プロトコルを用いた要求によりサーバにセッションが生成されたことを契機に、その要求を行った端末装置が第２の通信プロトコルを用いた要求を行うことを想定し、その第２の通信プロトコルで一意性保証用の一意性保証情報を負荷分散装置に設定する。このため、一意性保証情報を設定した後に端末装置から第２の通信プロトコルを用いた要求は、その端末装置から第１の通信プロトコルを用いた要求によりセッションを生成したサーバに振り分けられる。この結果、複数の通信プロトコルを連携させる場合であっても、一意性保証を実現できることとなる。

また、本発明を適用した他の１システムでは、端末装置の要求を負荷分散装置が振り分けたことにより生成したセッションを削除する場合に、サーバはその削除を負荷分散装置に予告し、その予告を行ってからセッションを実際に削除すべきタイミングとなるまでの間に、端末装置からそのセッションに対応する要求が送信されたか否か監視し、その監視により対応する要求の送信が確認された場合に、予告を行ったセッションの削除を中止させる。

上記監視を行う監視期間を設けたことにより、端末装置から送信された要求が実際にサーバに受信されるまでの送信時間が何らかの理由によって増大（遅延）したとしても、その増大分は監視期間により吸収可能となる。その結果、送信時間の増大に適切に対応した一意性保証を実現できることとなる。

本発明を適用した場合には、負荷分散装置により複数のサーバに負荷を分散させるシステム構成であっても、複数の通信プロトコル間の連携に対応した一意性保証を実現させることができる。

また、本発明を適用した場合には、通信ネットワーク上のトラフィック等による送信時間の増大に適切に対応した一意性保証を実現することができる。

一意性保証の実現方法を説明する図である（ＳＩＰの場合）。 一意性保証の実現方法を説明する図である（ＨＴＴＰの場合）。 従来、サーバ群の前段に配置したＳＬＢにより負荷分散させる場合のクライアント、ＳＬＢ、及びサーバの動作を示すシーケンス図である。 第１の実施形態による一意性保証情報設定管理装置を用いて構築された通信ネットワークシステムの構成を示す図である。 クライアント１０からのメッセージ送信によりＳＬＢ２０、振分対象サーバ３０、及び一意性保証情報設定管理装置４０で実行される処理の流れを示す図である。 個別処理１のフローチャートである。 個別処理２のフローチャートである。 個別処理３のフローチャートである。 クライアント１０、ＳＬＢ２０、振分対象サーバ３０及び一意性保証情報設定管理装置４０の動作を示すシーケンス図である。 クライアント１０からのメッセージ送信によりＳＬＢ２０、振分対象サーバ３０、及び一意性保証情報設定管理装置４０で実行される処理の流れを示す図である（第２の実施形態）。 個別処理１のフローチャートである（第２の実施形態）。 個別処理３のフローチャートである（第２の実施形態）。 個別処理４のフローチャートである（第２の実施形態）。 クライアント１０、ＳＬＢ２０、振分対象サーバ３０及び一意性保証情報設定管理装置４０の動作を示すシーケンス図である（第２の実施形態）。 クライアント１０、ＳＬＢ２０、振分対象サーバ３０及び一意性保証情報設定管理装置４０の動作を示すシーケンス図である（第２の実施形態の変形例）。 個別処理２のフローチャートである（第３の実施形態）。 個別処理３のフローチャートである（第３の実施形態）。 個別処理３のフローチャートである（第３の実施形態の変形例）。 本発明を適用可能なコンピュータのハードウェア構成の一例を示す図である。 バッファ対象ＩＤテーブルの構成を説明する図である。 削除ＩＤ管理テーブルの構成を説明する図である。 結果データ管理テーブルの構成を説明する図である。 第４の実施形態におけるＳＬＢ２０、振分対象サーバ３０、及び一意性保証情報設定管理装置４０の動作を示すシーケンス図である（クライアント１０からメッセージが送信されない場合）。 第４の実施形態におけるＳＬＢ２０、振分対象サーバ３０、及び一意性保証情報設定管理装置４０の動作を示すシーケンス図である（クライアント１０からメッセージが送信された場合）。 振分対象サーバが実行する処理のフローチャートである（第４の実施形態）。 一意性保証情報設定管理装置が実行する処理のフローチャートである（第４の実施形態）。 ＳＬＢが実行する処理のフローチャートである（第４の実施形態）。 タイマー管理テーブルの構成を説明する図である。

以下、本発明の実施形態について、図面を参照しながら詳細に説明する。
＜第１の実施形態＞
図４は、第１の実施形態による一意性保証情報設定管理装置を用いて構築された通信ネットワークシステムの構成を示す図である。その通信ネットワークシステムは、複数の通信プロトコルに対応した複数の振分対象サーバ３０の前段にサーバロードバランサ（ＳＬＢ。負荷分散装置）２０を配置することにより、端末装置であるクライアント１０からの要求を振り分ける振分対象サーバ３０を複数の振分対象サーバ３０のなかからＳＬＢ２０に選択させる構成となっている。本実施形態による一意性保証情報設定管理装置４０は、ＳＬＢ２０による振り分けによって振分対象サーバ３０に生成されるセッションを監視して、そのセッションを生成させた通信プロトコルとは異なる通信プロトコル用の一意性保証のための情報（一意性保証情報）をＳＬＢ２０に設定させることにより、複数の通信プロトコル間の連携を可能とさせる一意性保証を実現させる。クライアント１０とＳＬＢ２０間は、インターネット等の通信ネットワークにより接続され、ＳＬＢ２０、複数の振分対象サーバ３０、及び一意性保証情報設定管理装置４０間はＬＡＮ等の通信ネットワークによって接続されている。

クライアント１０は、メッセージ送受信部１１を介してＳＬＢ２０にメッセージ（パケット）を送信する。そのメッセージは、ＳＬＢ２０のクライアント発メッセージ受信部２１によって受信され、メッセージ識別部２２に渡され、メッセージの通信プロトコルの識別が行われる。メッセージ識別部２２の後段には、通信プロトコル（メッセージ）別に複数のプロトコル／メッセージ別処理部２３が配置されている。メッセージ識別部２２は、その識別結果に応じて、メッセージを対応するプロトコル／メッセージ別処理部２３に渡す。

各プロトコル／メッセージ別処理部２３は、一意性保証情報識別部２３ａ、ＭＳＧ振分部２３ｂ及び一意性保証情報記録部２３ｃを備えている。各部２３ａ〜２３ｃはそれぞれ以下のように動作する。

一意性保証情報識別部２３ａは、対応する通信プロトコルのメッセージ中に存在する一意性保証情報の識別情報（例えばセッションＩＤ或いはコールＩＤ）を識別（抽出）する。その識別は、一意性保証情報識別ルール２０３を参照して行う。その識別ルール２０３には、通信プロトコル別、メッセージ別に一意性保証情報の識別情報が格納されている位置に関する情報が定義されている。

ＭＳＧ振分部２３ｂは、一意性保証情報識別部２３ａが識別した識別情報を用いて、一意性保証ＤＢ２０１及び通信プロトコル／メッセージ別に用意された一意性保証テーブル２０２を参照し、メッセージを振り分ける振分対象サーバ３０を決定する。一意性保証ＤＢ２０１及び各一意性保証テーブル２０２には、振分対象サーバ３０に生成されるセッション毎に、そのセッションを一意に特定する識別情報、及びそのセッションを持つ振分対象サーバ３０を一意に特定する識別情報が一意性保証情報として格納されている。このことから、一意性保証情報識別部２３ａが識別した識別情報が一意性保証ＤＢ２０１、或いは一意性保証テーブル２０２の何れかに格納されていた場合、その識別情報を有する一意性保証情報中の他の識別情報が示す振分対象サーバ３０を振分先として決定する。一意性保証情報識別部２３ａが識別した識別情報が一意性保証ＤＢ２０１、及び一意性保証テーブル２０２の何れにも格納されていない場合には、ラウンドロビン方式等により自律的に振分先を決定する。このとき決定した振分先とする振分対象サーバ３０の識別情報は一意性保証ＤＢ２０２に格納する。以降は混乱を避けるために、振分対象サーバ３０の識別情報としては「アドレス」を想定する。その識別情報は、振分対象サーバ３０に割り当てた番号、名称などであっても良い。

一意性保証情報記録部２３ｃは、メッセージの種類に応じて、セッションの識別情報を一意性保証ＤＢ２０１に格納する。格納する識別情報は、例えばＳＩＰでのコールＩＤである。ＨＴＴＰでは識別情報の格納は通常、行われない。

このようにしてメッセージ識別部２２からメッセージが渡されたプロトコル／メッセージ別処理部２３は、そのメッセージの振分先を決定する。クライアント発メッセージ送信部２４は、その決定に従ってメッセージを複数の振分対象サーバ３０のうちの一つに宛てて送信する。

上記一意性保証ＤＢ２０１は、ＳＬＢ２０自体が設定する一意性保証情報の保存に用いられる。一意性保証情報設定管理装置４０により設定される一意性保証情報の保存には、その一意性保証情報に対応するプロトコル／メッセージ別一意性保証テーブル２０２が用いられる。メッセージの振分先は、一意性保証ＤＢ２０１の他に、各プロトコル／メッセージ別一意性保証テーブル２０２を参照して決定する。このため、複数の通信プロトコルの連携時でも一意性保証が実現される。

振分対象サーバ３０から送信されたメッセージは、サーバ発メッセージ受信部２５により受信され、メッセージ識別部２６により通信プロトコルが識別される。それにより、後段に位置する通信プロトコル（メッセージ）別の複数のプロトコル／メッセージ別処理部２７のうちの一つにメッセージが渡される。

各プロトコル／メッセージ別処理部２７は、一意性保証情報識別部２７ａ、及び一意性保証情報記録部２７ｂを備えている。一意性保証情報識別部２７ａは、一意性保証情報識別ルール２０３を参照して、メッセージ中に存在する一意性保証情報の識別情報を識別（抽出）する。一意性保証情報記録部２７ｂは、その識別情報を必要に応じて一意性保証ＤＢ２０１に格納する。識別情報を格納するのは、セッションの生成により識別情報が確定する通信プロトコルのメッセージの場合である。メッセージを受信した振分対象サーバ３０のアドレスと、そのメッセージ中の識別情報とを持つ一意性保証情報が一意性保証ＤＢ２０１に格納されていないことを条件に、メッセージ中から抽出した識別情報は、振分対象サーバ３０のアドレスのみを持つ一意性保証情報のセッションの識別情報として格納する。

このような処理が行われたメッセージは、サーバ発メッセージ送信部２８を介してクライアント１０に送信される。
一方、各振分対象サーバ３０は、ＳＬＢ２０から送信されたメッセージをメッセージ送受信部３１により受信し、メッセージの通信プロトコルに対応するプロトコル処理部３２に渡す。プロトコル処理部３２の後段には、個別にサービスを提供する複数プロトコル連携部３３が位置している。この複数プロトコル連携部３３は、複数の通信プロトコルを連携したサービスを提供する。メッセージが渡されたプロトコル処理部３２は、そのメッセージを解析して、複数プロトコル連携部３３に渡す。

複数プロトコル連携部３３は、複数の通信プロトコルの連携が可能なアプリケーションを振分対象サーバ３０が実行することで実現される。サービスを提供可能な構成要素として複数プロトコル連携部３３のみを図４に示しているのは、複数の通信プロトコル間の連携を可能とさせる一意性保証を実現させる対象だからである。このことから、サービス提供部としては複数プロトコル連携部３３のみ着目する。

複数プロトコル連携部３３は、プロトコル処理部３２から渡されたメッセージにより、そのプロトコル生成部３２に対応する通信プロトコルのセッションを生成し、そのセッションに係わるデータ（セッションデータ３０１）を保存する。そのセッションデータ３０１は、セッションを一意に特定する識別情報、及びセッションに付随するデータを含むものである。ここでは識別情報としてセッションＩＤを想定する。

セッション情報監視部３４は、サービス提供部（アプリケーション）によるセッション生成を監視し、セッションが生成された際に、セッション関連情報、例えばセッションＩＤをセッション情報通知部３５に渡す。セッション情報通知部３５は、セッションＩＤ、及びそのセッションＩＤのセッションを生成した振分対象サーバ３０を一意に特定する識別情報、例えばその振分対象サーバ３０のアドレスをメッセージの形で一意性保証情報設定管理装置４０に送信する。

一意性保証情報設定管理装置４０は、振分対象サーバ３０から送信されたメッセージをセッション情報収集部４１で受信する。受信されたメッセージは一意性保証情報生成部４２に渡される。一意性保証情報生成部４２は、渡されたメッセージが示すセッションＩＤと振分対象サーバ３０の対応関係からＳＬＢ２０に設定すべき一意性保証情報を生成し、システム構成情報４０１を参照して、生成した一意性保証情報の設定を要求すべきＳＬＢ２０を決定する。

システム構成情報４０１には、振分対象サーバ３０毎に、その振分対象サーバ３０の前段に位置するＳＬＢ２０を一意に特定する識別情報、例えばそのアドレスが示されている。そのシステム構成情報４０１を参照することにより、複数の振分対象サーバ３０を備えたサービス提供用のシステム別に一意性保証情報を設定することも可能となっている。

一意性保証情報記録要求部４３は、一意性保証情報生成部４２が決定したＳＬＢ２０に、その一意性保証情報生成部４２が生成した一意性保証情報の設定を要求するメッセージを送信する。

このようにして一意性保証情報設定管理装置４０から送信されたメッセージは、ＳＬＢ２０の一意性保証情報記録受付部２９により受信される。この一意性保証情報記録受付部２９は、受信したメッセージを対応するプロトコル／メッセージ別処理部２７に渡し、処理させる。それにより、メッセージ中の一意性保証情報を対応するプロトコル／メッセージ別一意性保証テーブル２０２に記録させる。一意性保証情報を記録するプロトコル／メッセージ別一意性保証テーブル２０２は、例えば振分対象サーバ３０でセッションを生成した通信プロトコルから特定した別の通信プロトコル用のものである。より具体的には、セッションを生成した通信プロトコルがＳＩＰであれば、別の通信プロトコルはＨＴＴＰである。一意性保証情報設定管理装置４０から要求された一意性保証情報を１つ以上のプロトコル／メッセージ別一意性保証テーブル２０２に記録することにより、複数の通信プロトコルを連携させる場合であっても、複数の通信プロトコルでそれぞれ同じクライアント１０から送信された関連するメッセージはＳＬＢ２０で同じ振分対象サーバ３０に振り分けられることになる。この結果、一意性保証が実現される。

以降は、図５〜図８に示すフローチャート、及び図９に示すシーケンス図を参照して、ＳＬＢ２０、ＳＬＢ２０によってメッセージが振り分けられた振分対象サーバ３０、及び一意性保証情報設定管理装置４０の動作についてより具体的に説明する。

図５は、クライアント１０からのメッセージ送信によりＳＬＢ２０、振分対象サーバ３０、及び一意性保証情報設定管理装置４０で実行される処理の流れを示す図である。クライアント１０から送信されるメッセージとして想定するのは、何れの振分対象サーバ３０でもセッションが生成されていないものである。図５、及び図６〜図８を参照して、振分対象サーバ３０でのセッション生成により一意性保証情報をＳＬＢ２０に設定するためにその振分対象サーバ３０、一意性保証情報設定管理装置４０、及びＳＬＢ２０でそれぞれ行われる処理について詳細に説明する。

先ず、ステップＳ１では、メッセージが振り分けられたことでセッションを生成する振分対象サーバ３０で個別処理１が実行される。この個別処理１を振分対象サーバ３０が実行することにより、生成したセッションに係わる情報が一意性保証情報設定管理装置４０に送信される。

ステップＳ１に続くステップＳ２では、振分対象サーバ３０からセッションに係わる情報を受信した一意性保証情報設定管理装置４０で個別処理２が実行される。この個別処理２を一意性保証情報設定管理装置４０が実行することにより、一意性保証情報が生成され、生成した一意性保証情報の設定がＳＬＢ２０に対して要求される。

ステップＳ２に続くステップＳ３では、一意性保証情報の設定が要求されたＳＬＢ２０で個別処理３が実行される。この個別処理３をＳＬＢ２０が実行することにより、一意性保証情報がプロトコル／メッセージ別一意性保証テーブル２０２に記録される。この結果、ＳＬＢ２０は、異なる通信プロトコルであっても一意性保証を実現するように動作するステップＳ４の状態に移行する。

図６は、上記個別処理１のフローチャートである。この個別処理１は、振分対象サーバ３０が実行する処理のなかで一意性保証情報の設定に係わる処理を抽出してその流れを示したものである。セッションを生成していないメッセージの受信を契機に実行される。

先ず、ステップＳ１１では、クライアント１０からのメッセージによりセッションを生成する。続くステップＳ１２では、そのセッション生成イベントを検知し、識別情報としてセッションＩＤを取得する。次のステップＳ１３では、取得したセッションＩＤに自振分対象サーバ３０のアドレス（図中「サーバＩＤ」と表記）を付与し、一意性保証情報設定管理装置４０に送信する。その送信により、この個別処理１が終了する。

図４に示す構成において、上記ステップＳ１１は複数プロトコル連携部３３によって実現される。ステップＳ１２は、セッション情報監視部３４によって実現される。ステップＳ１３は、セッション情報通知部３５によって実現される。

図７は、上記個別処理２のフローチャートである。この個別処理２は、振分対象サーバ３０からセッションＩＤ等の受信を契機に一意性保証情報設定管理装置４０が実行する処理である。一意性保証情報設定管理装置４０としての機能を搭載したプログラム（一意性保証情報設定管理プログラム）をその一意性保証情報設定管理装置４０のＣＰＵが実行することで実現される。

先ず、ステップＳ２１では、振分対象サーバ３０から送信されたセッションＩＤやアドレスを含むメッセージ（図中「セッション情報通知」と表記）を受信する。次のステップＳ２２では、メッセージ中からセッションＩＤおよびそのセッションＩＤが割り当てられたセッションを保持する振分対象サーバ３０のアドレス（サーバＩＤ）を取り出し、一意性保証情報生成部４２に渡す。その後はステップＳ２３に移行する。

ステップＳ２３では、セッションＩＤおよび振分対象サーバ３０のアドレスより一意性保証情報（図中「振り分け情報」と表記）を生成（構築）する。続くステップＳ２４では、振分対象サーバ３０のアドレスをキーにシステム構成情報４０１を検索し、生成した一意性保証情報の配布先とするＳＬＢ２０を決定する。その次に移行するステップＳ２５では、配布先として決定したＳＬＢ２０に一意性保証情報を配布することにより、その一意性保証情報の設定を要求する。その配布により、個別処理２が終了する。

図４に示す構成において、上記ステップＳ２１及びＳ２２はセッション情報収集部４１によって実現される。ステップＳ２３及びＳ２４は、一意性保証情報生成部４２によって実現される。ステップＳ２５は、一意性保証情報記録要求部４３によって実現される。

図８は、上記個別処理３のフローチャートである。この個別処理３は、一意性保証情報設定管理装置４０から一意性保証情報（振り分け情報）の記録を要求するメッセージの受信を契機にＳＬＢ２０が実行する処理である。

先ず、ステップＳ３１では、一意性保証情報設定管理装置４０から送信された一意性保証情報（振分け情報）を含むメッセージを受信する。次のステップＳ３２では、メッセージ中から一意性保証情報を抽出し、プロトコル／メッセージ別一意性保証テーブル２０２に記録する。その記録を行った後、個別処理３が終了する。図４に示す構成において、この個別処理３は一意性保証情報記録受付部２９によって実現される。

図９は、クライアント１０、ＳＬＢ２０、振分対象サーバ３０及び一意性保証情報設定管理装置４０の動作を示すシーケンス図である。このシーケンス図は、図３と同様に、アリス（Alice）が使用する端末装置であるクライアントにより、ボブ（Bob）が使用するクライアントとの間でＳＩＰを用いた通話の開始を要求し、その通話が開始できなかったことから、アリスが使用するクライアントがＨＴＴＰを用いてＵＲＬ（Uniform Resource Locator）にアクセスするケースを例にとったものである。通話は、サーバ群のうちの一つであるサーバ（図中「ＳＩＰアプリサーバ」と表記）３０を介して行うことを想定している。

図９でも図３と同様に、アリス及びボブがそれぞれ使用するクライアントとして、「ＡＳＵ」（「Alice's SIP UA」の略記」、「ＡＢ」（「Alice's browser」の略記」、及び「ＢＳＵ」（「Bob's SIP UA」の略記）を表記している。符号としては１５、１６及び１７をそれぞれ付している。一意性保証情報設定管理装置４０は「振分情報一意性保証情報設定管理装置」と表記している。

ＳＬＢ２０では、構成要素として、送受信・識別部、ＳＩＰ処理部、ＨＴＴＰ処理部、及び一意性保証情報記録受付部２９を表記している。送受信・識別部は、クライアント発メッセージ受信部２１、メッセージ識別部２２、クライアント発メッセージ送信部２４、サーバ発メッセージ受信部２５、メッセージ識別部２６、及びサーバ発メッセージ送信部２８をまとめたものに相当する。ＳＩＰ処理部は、ＳＩＰ用のプロトコル／メッセージ別処理部２３、及びプロトコル／メッセージ別処理部２７をまとめたものに相当する。ＳＬＢ２０では、混乱を避けると共に、冗長的とならないようにするために、一意性保証情報記録受付部２９以外には符号を付さないこととする。

振分対象サーバ３０では、構成要素としてＣＳＢＮＡアプリケーション（「ＣＳＢＮＡアプリ」と略記）３３、及びセッション情報監視・通知部を表記している。ＣＳＢＮＡアプリケーション３３は、複数プロトコル連携部３３を実現させるアプリケーションの１例に相当する。このため、同一の符号を付している。セッション情報監視・通知部は、セッション情報監視部３４、及びセッション情報通知部３５をまとめたものに相当する。ここでは、それらの符号を付さないこととする。

先ず、ＳＩＰ ＵＡ１５は、アリスの指示によりステップＳＢ１の処理を実行し、ボブとの通話を開始するためにＩＮＶＩＴＥ要求をＳＬＢ２０に送信する（シーケンスＳ４１）。ＩＮＶＩＴＥ要求のためのメッセージのＳＩＰヘッダには、ＳＩＰ ＵＡ１５によるコールＩＤ（図３中「Ｃａｌｌ−ＩＤ＃１」と表記）が格納される。このＩＮＶＩＴＥ要求は、ＳＬＢ２０の送受信・識別部がステップＳＤ１を実行することによりＳＩＰメッセージと認識され、ＳＩＰ処理部に渡される（シーケンスＳ４２）。ＳＩＰ処理部は、ステップＳＥ１を実行することにより、一意性保証ＤＢ２０１及びプロトコル／メッセージ別一意性保証テーブル２０２を参照して振り分け先を決定し（シーケンスＳ４３）、送受信・識別部に渡す（シーケンスＳ４４）。送受信・識別部は、決定された振り分け先となる振分対象サーバ３０にＳＩＰメッセージを送信する（シーケンスＳ４５）。一意性保証を実現するために必要であった場合には、コールＩＤと振り分けた振分対象サーバ３０のアドレスの組み合わせが一意性保証情報として一意性保証ＤＢ２０１に登録される。ここでは上記想定により、一意性保証情報の登録は行われない。

振分対象サーバ３０に送信されたＳＩＰメッセージ（ここではＩＮＶＩＴＥ要求）はＣＳＢＮＡアプリケーション３３に渡され、そのアプリケーション３３はステップＳＨ１を実行し、ボブ側（着呼側）で使用するコールＩＤを決定して、そのコールＩＤをＳＩＰヘッダに格納したＩＮＶＩＴＥ要求をＳＬＢ２０に返信する（シーケンスＳ４６）。

振分対象サーバ３０から送信されたＩＮＶＩＴＥ要求は、ＳＬＢ２０の送受信・識別部がステップＳＤ３を実行することで処理され、ＳＩＰ処理部に渡される（シーケンスＳ４７）。ＳＩＰ処理部は、ステップＳＥ２の実行により、ＩＮＶＩＴＥ要求中のコールＩＤとサーバのアドレスの組み合わせを一意性保証情報として一意性保証ＤＢ２０１に登録する（シーケンスＳ４８）。その登録後、ボブのクライアントに送信するためにＩＮＶＩＴＥ要求を送受信・識別部に渡す（シーケンスＳ４９）。送受信・識別部はステップＳＤ４を実行して、ＩＮＶＩＴＥ要求をボブのクライアント宛に送信する（シーケンスＳ５０）。

ボブのクライアント宛に送信されたＩＮＶＩＴＥ要求は、ＳＩＰ ＵＡ１７がステップＳＣ１を実行することで処理される。ここでは、他の通話を行っているなどの理由により、通話を開始できない旨を送信元（アリス）に通知するための４８６Ｂｕｓｙ応答（レスポンス）を送信する（シーケンスＳ５１）。

４８６Ｂｕｓｙ応答は、ＳＬＢ２０の送受信・識別部がステップＳＤ５を実行することで識別され、ＳＩＰ処理部に渡される（シーケンスＳ５２）。ＳＩＰ処理部は、ステップＳＥ３を実行し、４８６Ｂｕｓｙ応答中のコールＩＤを用いて一意性保証ＤＢ２０１及びプロトコル／メッセージ別一意性保証テーブル２０２を参照し、この応答を振り分けるべき振分対象サーバ３０を特定する（シーケンスＳ５３）。特定した振分対象サーバ３０は送受信・識別部に通知する（シーケンスＳ５４）。送受信・識別部は、ステップＳＤ６を実行することにより、４８６Ｂｕｓｙ応答を指定された振分対象サーバ３０に送信する（シーケンスＳ５５）。

振分対象サーバ３０のＣＳＢＮＡアプリケーション３３は、ステップＳＨ２を実行して、受信した４８６Ｂｕｓｙ応答を処理する。それにより、セッション３６を生成する（シーケンスＳ５６）。そのセッション３６ではステップＳＩ１を実行して、そのＩＤをＣＳＢＮＡアプリケーション３３に返す（シーケンスＳ５７ａ）。また、そのＩＤはセッション情報監視・通知部に渡す（シーケンスＳ５７）。セッション情報監視・通知部は、ステップＳＪ１を実行することにより、セッションＩＤ及び自振分対象サーバ３０のアドレスを一意性保証情報設定管理装置４０に送信する（シーケンスＳ５８）。

セッション３６の生成により、セッションに関連するデータがセッションデータ３０１として保存される。ここではセッションデータ３０１として、発呼者（アリス）及び受信者（ボブ）のＳＩＰ−ＵＲＩなど、折り返し電話に必要な情報が保存される。

一意性保証情報設定管理装置４０は、ステップＳＫ１を実行することにより、受信したセッションＩＤ及び振分対象サーバ３０のアドレスから一意性保証情報を生成し、生成した一意性保証情報の設定をＳＬＢ２０に要求する（シーケンスＳ５９）。ＳＬＢ２０の一意性保証情報記録受付部２９は、ステップＳＧ１を実行することにより、要求された一意性保証情報を含むメッセージをＨＴＴＰ処理部に渡す。ＨＴＴＰ処理部は、ステップＳＦ１を実行し、メッセージ中の一意性保証情報を対応するプロトコル／メッセージ別一意性保証テーブル２０２に登録する（シーケンスＳ６１）。その登録を行った後、そのことを一意性保証情報記録受付部２９に通知する（シーケンスＳ６１ａ）。

一方、セッションＩＤが返されたＣＳＢＮＡアプリケーション３３は、３０２（Temporarily Unavailable）応答を生成し、ＳＬＢ２０に送信する（シーケンスＳ６２）。その３０２応答のコンタクトＵＲＩヘッダには、ＨＴＴＰ経由でアクセスするためのＵＲＬにセッションＩＤを埋め込んだものを記載する。

ＳＬＢ２０の送受信・識別部は、ステップＳＤ７を実行することにより、３０２応答の通信プロトコルを識別してＳＩＰ処理部に渡す（シーケンスＳ６３）。ＳＩＰ処理部は、ステップＳＥ４を実行することにより、３０２応答の送信を送受信・識別部に要求する（シーケンスＳ６４）。送受信・識別部は、ステップＳＤ８の実行により、要求された３０２応答をアリスの使用するクライアントに送信する（シーケンスＳ６５）。

アリスのクライアントに送信された３０２応答は、ＳＩＰ ＵＡ１５がステップＳＢ２を実行することで処理される。それによりブラウザ１６が起動される（シーケンスＳ６６）。

起動されたブラウザ１６は、ステップＳＡ１を実行することにより、３０２応答のコンタクトＵＲＩヘッダに記載されたＵＲＬにアクセスするためのＨＴＴＰ ＧＥＴ要求を送信する（シーケンスＳ６７）。この要求は、ＳＬＢ２０の送受信・識別部がステップＳＤ９を実行することで識別され、ＨＴＴＰ処理部に渡される（シーケンスＳ６８）。ＨＴＴＰ処理部は、ステップＳＦ２を実行することにより、ＨＴＴＰ ＧＥＴ要求で指定されたＵＲＬからセッションＩＤを抽出し、一意性保証ＤＢ２０１及びプロトコル／メッセージ別一意性保証テーブル２０２を参照して、この要求の振り分け先を特定する（シーケンスＳ６９）。このとき、セッションＩＤを有する一意性保証情報がプロトコル／メッセージ別一意性保証テーブル２０２に登録されていることから、セッション３６を保持する振分対象サーバ３０が振り分け先として決定される（シーケンスＳ７０）。それによりＨＴＴＰ処理部は、ＨＴＴＰ ＧＥＴ要求をその振分対象サーバ３０に送信することを送受信・識別部に指示する（シーケンスＳ７１）。この結果、ＨＴＴＰ ＧＥＴ要求はセッション３６を保持する振分対象サーバ３０に送信される（シーケンスＳ７２）。

振分対象サーバ３０に送信されたＨＴＴＰ ＧＥＴ要求は、ＣＳＢＮＡアプリケーション３３がステップＳＨ３を実行することで処理される。この要求中に存在するセッションＩＤから対応するセッション３６を特定し、そのセッションデータ３０１を取得する（シーケンスＳ７３、Ｓ７４、及びステップＳＩ２）。取得したセッションデータ３０１から、通話終了後の折り返し電話設定を行うためのＷｅｂページを生成し、ＳＬＢ２０に送信する（シーケンスＳ７５）。このＷｅｂページは、送受信・識別部で識別され、特には図示していないが、ＨＴＴＰ処理部に渡された後、送受信・識別部からアリスの使用するクライアントに送信される（シーケンスＳ７６）。送信されたＷｅｂページは、ブラウザ１６によって処理される。

＜第２の実施形態＞
上記第１の実施形態では、振分対象サーバ３０による３０２応答のクライアント１０への送信、及び一意性保証情報設定管理装置４０によるＳＬＢ２０への一意性保証情報の設定は並行して行われる形となっている。そのように並行して振分対象サーバ３０及び一意性保証情報設定管理装置４０がそれぞれの処理を実行する場合、他の通信プロトコルでの一意性保証を実現できない可能性がある。つまりＨＴＴＰのプロトコル／メッセージ別一意性保証テーブル２０２への一意性保証情報を登録する前に、ＨＴＴＰ ＧＥＴ要求がクライアント１０から送信される可能性がある。このようなことから第２の実施形態は、確実に一意性保証を実現できるようにしたものである。

第２の実施形態における一意性保証情報設定管理装置の構成は基本的に第１の実施形態と同じである。動作も大部分は同じである。これは、ＳＬＢ２０でも同様である。このようなことから、第１の実施形態で付した符号をそのまま用いて、第１の実施形態から異なる部分についてのみ説明する。

第２の実施形態では、一意性保証情報設定管理装置４０による一意性保証情報を設定した後、振分対象サーバ３０に３０２応答を送信させることにより、アリスのクライアント１０からのＨＴＴＰメッセージはセッション３６を保持している振分対象サーバ３０に確実に振り分けられるようにしている。このため、第１の実施形態から以下の部分が異なっている。図１０〜図１４を参照して詳細に説明する。

図１０は、クライアント１０からのメッセージ送信によりＳＬＢ２０、振分対象サーバ３０、及び一意性保証情報設定管理装置４０で実行される処理の流れを示す図である。始めに図１０を参照して、第２の実施形態におけるその処理の流れについて具体的に説明する。

図１０では、第１の実施形態と基本的に同じ処理には同一の符号を付している。それによりフローチャートでも、第１の実施形態から異なる部分についてのみ説明する。
先ず、ステップＳ８１では、メッセージが振り分けられたことでセッションを生成する振分対象サーバ３０で個別処理１が実行される。この個別処理１では、図１１に示すように、ステップＳ１２の実行後、ステップＳ９１に移行して、セッションを生成したアプリケーションから制御をセッション情報監視部３４に譲渡させる。それにより、アプリケーション、例えば複数プロトコル連携部３３を一時的に停止させる。この停止後、ステップＳ１３に移行する。

ステップＳ８１の次にはステップＳ２で個別処理２が一意性保証情報設定管理装置４０で実行され、その実行後はステップＳ８２で個別処理３がＳＬＢ２０で実行される。その個別処理２では、図１２に示すように、ステップＳ３２の実行後、ステップＳ９０１に移行して、一意性保証情報記憶要求部４３に、一意性保証情報の設定が完了した旨を示す設定完了応答を返す。その応答を返した後、個別処理３を終了する。

ステップＳ８２の個別処理３の実行後は、ステップＳ８３に移行する。そのステップＳ８３では、振分対象サーバ３０で制御を譲渡させたアプリケーションに制御を返す個別処理４が一意性保証情報設定管理装置４０で実行される。その個別処理４の実行後、ステップＳ４に移行する。

図１３は、個別処理４のフローチャートである。ここで図１３を参照して、この個別処理４について詳細に説明する。この個別処理４は。ＳＬＢ２０からの設定完了応答の受信を契機に実行される一意性保証情報設定管理装置４０の処理の他に、振分対象サーバ３０が実行する処理が含まれる。一意性保証情報設定管理装置４０が実行する処理は、一意性保証情報設定管理装置４０としての機能を搭載したプログラム（一意性保証情報設定管理プログラム）をその一意性保証情報設定管理装置４０のＣＰＵが実行することで実現される。

先ず、ステップＳ１００１では、設定完了応答の受信により、セッション情報収集部４１に対し、その旨を振分対象サーバ３０に通知するための応答を送信するための発行要求を行う。続くステップＳ１００２では、セッション情報収集部４１に、発行要求に応じた応答（通知完了応答）を送信させる。このステップＳ１００１及びＳ１００２は一意性保証情報設定管理装置４０が実行する。ステップＳ１００３以降は、振分対象サーバ３０が実行する。

ステップＳ１００３に続くステップＳ１００３では、通知完了応答をセッション情報通知部３５により受信し、セッション情報監視部３４にその旨を通知する。それによりセッション情報監視部３４は、ステップＳ１００４を実行して、譲渡されていた制御をアプリケーション（複数プロトコル連携部３３）に返す。そのようにしてアプリケーションの停止を解除させた後、ステップＳ４に移行する。

図１４は、第２の実施形態におけるクライアント１０、ＳＬＢ２０、振分対象サーバ３０及び一意性保証情報設定管理装置４０の動作を示すシーケンス図である。このシーケンス図では、第１の実施形態と同じ処理、動作には同一の符号を付している。それにより、第１の実施形態から異なる部分のみ説明する。

第２の実施形態では、セッションＩＤ、及び振分対象サーバ３０のアドレスを含むメッセージを振分対象サーバ３０から受信した一意性保証情報設定管理装置４０は、ステップＳＫ１１を実行する。それにより、生成した一意性保証情報の設定をＳＬＢ２０に要求する（シーケンスＳ１１０１）。その要求により、ステップＳＧ１１及びＳＦ１が実行され、シーケンスＳ６０〜Ｓ６１ａが実現される。一意性保証情報記録受付部２９は、シーケンスＳ６１ａにより一意性保証情報の設定が通知されると、その旨を通知するための設定完了応答を一意性保証情報設定管理装置４０に送信する（シーケンスＳ１１０２）。

一意性保証情報設定管理装置４０は、ＳＬＢ２０に一意性保証情報の設定を要求した後、この設定完了応答の受信を待つ状態に移行している。この設定完了応答を受信すると、振分対象サーバ３０に一意性保証情報の設定が完了したことを通知するために、通知完了応答を振分対象サーバ３０に送信する（シーケンスＳ１１０３）。

ＣＳＢＮＡアプリケーション３３はセッション３６の生成に伴うセッションＩＤをセッション情報監視・通知部に通知して制御を渡し停止する。セッション情報監視・通知部は、セッション３６に制御を返し（シーケンスＳ１１０４）、それによってセッション３６からＣＳＢＮＡアプリケーション３３に制御が返る（シーケンスＳ１１０５）。そのようにして制御が返ったＣＳＢＮＡアプリケーション３３は、セッションＩＤを埋め込んだＵＲＬをコンタクトＵＲＩヘッダに記載した３０２応答をＳＬＢ２０に送信する（シーケンスＳ６２）。

なお、第２の実施形態では、ＣＳＢＮＡアプリケーション３３を一時的に停止することにより、３０２応答によるＨＴＴＰメッセージがクライアント１０から送信される前に、ＳＬＢ２０での一意性保証情報の設定を完了させるようにしているが、別の方法を採用しても良い。例えば図１５に示すように、振分対象サーバ３０にメッセージの送受信を制御・管理する送信制御部３７を搭載し、その送信制御部３７の制御により、振分対象サーバ３０から３０２応答を送信するタイミングを調整するようにしても良い。図１５に示す変形例では、ＳＬＢ２０から一意性保証情報の設定完了を一意性保証情報設定管理装置４０に通知することにより、送信制御部３７には、一意性保証情報設定管理装置４０から一意性保証情報の設定完了を通知するようになっている。その設定完了の通知は、要求された一意性保証情報をＳＬＢ２０に解析させることにより、ＳＬＢ２０から振分対象サーバ３０に行わせることもできる。

＜第３の実施形態＞
上記第１及び第２の実施形態では、一意性保証情報を登録するプロトコル／メッセージ別一意性保証テーブル２０２は、セッションを生成した通信プロトコルにより固定的に定めた通信プロトコルのプロトコル／メッセージ別一意性保証テーブル２０２に一意性保証情報を一意性保証情報設定管理装置４０により登録するようになっている。第３の実施形態は、セッションを生成した通信プロトコルに応じて、一意性保証情報を設定すべき通信プロトコルを選択し、設定するようにしたものである。

第３の実施形態における一意性保証情報設定管理装置の構成は基本的に第１の実施形態と同じである。動作も大部分は同じである。これは、ＳＬＢ２０でも同様である。このようなことから、第１の実施形態で付した符号をそのまま用いて、第１、或いは第２の実施形態から異なる部分についてのみ説明する。

第３の実施形態では、一意性保証情報を設定する通信プロトコルを一意性保証情報設定管理装置４０が選択するために、セッション情報監視部３４は、セッションＩＤの他に、そのセッションＩＤが割り当てられたセッションを生成する契機となった要求の通信プロトコルを示すプロトコル情報をセッション情報通知部３５に渡す。それによりセッション情報監視部３４は、セッションＩＤ、自サーバのアドレス、及びプロトコル情報を含むメッセージを一意性保証情報設定管理装置４０に送信する。このことから、図６、及び図１１に示す個別処理１において、ステップＳ１２でプロトコル情報を取得する部分、及びステップＳ１３でプロトコル情報を送信する部分が第１及び第２の実施形態に追加されている。

図１６は、第３の実施形態で実行される個別処理２のフローチャートである。
第３の実施形態では、ステップＳ２１の次にステップＳ１３０１に移行し、受信したメッセージ中からセッションＩＤ、振分対象サーバ３０のアドレス（サーバＩＤ）、及びプロトコル情報を抽出して一意性保証情報生成部４２に渡すようになっている。また、ステップＳ２４の次にステップＳ１３０２に移行して、ステップＳ１３０２で抽出されたプロトコル情報が示す通信プロトコル、つまりセッション３６の生成契機となった通信プロトコルの種類の判別を行う。この結果、生成契機となった通信プロトコルがＳＩＰと判別した場合、ステップＳ１３０３に移行して、一意性保証情報を設定すべきプロトコル／メッセージ別一意性保証テーブル２０２の通信プロトコルはＨＴＴＰと指定（決定）する。生成契機となった通信プロトコルがＨＴＴＰと判別した場合には、ステップＳ１３０４に移行して、一意性保証情報を設定すべきプロトコル／メッセージ別一意性保証テーブル２０２の通信プロトコルはＳＩＰと指定（決定）する。その何れかの指定を行った後、ステップＳ２５に移行する。

個別処理３としては、図１７或いは図１８に示すものが実行される。図１７及び図１８にそれぞれ示す個別処理３は、図５及び図１０に示すように振分対象サーバ３０、一意性保証情報設定管理装置４０及びＳＬＢ２０の処理が実行される場合のものである。

図１７に示す個別処理３では、ステップＳ３１の次にステップＳ１４０１に移行して、一意性保証情報設定管理装置４０が指定したプロトコル／メッセージ別一意性保証テーブル２０２の通信プロトコルの種類を判別する。この結果、指定の通信プロトコルがＳＩＰと判別した場合、ステップＳ１４０２に移行して、ＳＩＰ用のプロトコル／メッセージ別一意性保証テーブル２０２に一意性保証情報を記録する。指定の通信プロトコルがＨＴＴＰと判別した場合には、ステップＳ１４０３に移行して、ＨＴＴＰ用のプロトコル／メッセージ別一意性保証テーブル２０２に一意性保証情報を記録する。そのようにして何れかのプロトコル／メッセージ別一意性保証テーブル２０２に一意性保証情報を記録した後、この個別処理３が終了する。

一方、図１８に示す個別処理３では、ステップＳ１４０２、或いはＳ１４０３の後、ステップＳ１５０５に移行して、一意性保証情報設定管理装置４０に一意性保証情報の設定が完了した旨を示す設定完了応答を返す。その応答を返した後、個別処理３を終了する。

なお、第３の実施形態では、セッションの生成契機となった通信プロトコルに応じて、一意性保証情報を設定すべき通信プロトコルを決定しているが、セッションを生成したアプリケーションに応じて、一意性保証情報を設定すべき通信プロトコルを決定するようにしても良い。或いは、更にセッションを生成したアプリケーションを考慮しても良い。これは、アプリケーションによって連携可能な通信プロトコルの組み合わせは決まっているからである。その組み合わせの例としては、ＳＩＰとＳＯＡＰ（Simple Object Access Protocol）、ＳＯＡＰとＨＴＴＰ、ＳＯＡＰとＦＴＰ（Simple Object Access Protocol）、ＳＯＡＰとＳＭＴＰ（Simple Mail Transfer Protocol）、ＳＯＡＰとＲＴＰ（Real-time Transport Protocol）等が挙げられる。

ＳＩＰでは、コールＩＤによりメッセージが識別される。ＨＴＴＰとＳＩＰを連携可能なアプリケーションで先にＨＴＴＰメッセージの受信によりセッションを生成した場合、クライアント１０は連携用のセッションＩＤを格納したＳＩＰメッセージを生成して送信する必要がある。そのようなメッセージの送信は、サービスを提供するアプリケーションに応じて行わせれば良い部分である。ＳＬＢ２０による複数の振分対象サーバ３０への負荷分散を実現するシステム構成用にメッセージを変更する必要はない。

また、本実施形態（第１及び第３の実施形態）では、一意性保証情報設定管理装置４０は振分対象サーバ３０、及びＳＬＢ２０とは別の装置として実現しているが、何れかの振分対象サーバ３０、或いはＳＬＢ２０に搭載させる形で実現させても良い。

図４において、セッション情報収集部４１は、振分対象サーバ３０に生成されたセッションの識別情報を取得する識別情報取得部４５として機能し、一意性保証情報生成部４２及び一意性保証情報記録要求部４３は、識別情報を用いて生成する一意性保証情報をＳＬＢ２０に設定する保証情報設定部４６として機能する。それら識別情報取得部４５及び保証情報設定部４６の構成は、一意性保証情報設定管理装置４０を搭載させる装置によって以下のように変化する。

一意性保証情報設定管理装置４０を振分対象サーバ３０に搭載する場合、セッション情報通知部３５は不要となり、セッション情報収集部４１は、他の振分対象サーバ３０から送信されるメッセージの受信に用いられることになる。このことから、識別情報取得部４５はセッション情報監視部３４及びセッション情報収集部４１を含む構成となる。各サーバ４０に一意性保証情報設定管理装置４０を搭載させる想定では、識別情報取得部４５はセッション情報監視部３４のみを含む構成となる。一方、保証情報設定部４６は、一意性保証情報生成部４２及び一意性保証情報記録要求部４３を含む構成のままである。

一意性保証情報設定管理装置４０をＳＬＢ２０に搭載した場合には、例えば一意性保証情報記録要求部４３を不要として、一意性保証情報記録受付部２９に、一意性保証情報生成部４２が生成した一意性保証情報を渡すようにしても良い。そのような想定では、保証情報設定部４６は、一意性保証情報生成部４２及び一意性保証情報記録受付部２９を含む構成となる。識別情報取得部４５はセッション情報収集部４１のみを含む構成となる。

図１９は、本発明を適用可能なコンピュータのハードウェア構成の一例を示す図である。ここで図１９を参照して、一意性保証情報設定管理装置４０として使用可能なコンピュータ、言い換えれば上記一意性保証情報設定管理プログラムを実行させることで一意性保証情報設定管理装置４０を実現可能なコンピュータの構成について具体的に説明する。

図１９に示すコンピュータは、ＣＰＵ６１、メモリ６２、入力装置６３、出力装置６４、外部記憶装置６５、媒体駆動装置６６、及びネットワーク接続装置６７を有し、これらがバス６８によって互いに接続された構成となっている。同図に示す構成は一例であり、これに限定されるものではない。

ＣＰＵ６１は、当該コンピュータ全体の制御を行う。
メモリ６２は、プログラム実行、データ更新等の際に、外部記憶装置６５（あるいは可搬型の記録媒体７０）に記憶されているプログラムあるいはデータを一時的に格納するＲＡＭ等のメモリである。ＣＰＵ６１は、プログラムをメモリ６２に読み出して実行することにより、全体の制御を行う。

入力装置６３は、例えば、キーボード、マウス等の操作装置と接続されたインターフェースである。操作装置に対するユーザの操作を検出し、その検出結果をＣＰＵ６１に通知する。

出力装置６４は、例えば表示装置と接続された表示制御装置である。ネットワーク接続装置６７は、例えば複数の振分対象サーバ３０及びＳＬＢ２０と通信ネットワークを介して通信を行うためのものである。外部記憶装置６５は、例えばハードディスク装置である。主に各種データやプログラムの保存に用いられる。

媒体駆動装置６６は、光ディスクや光磁気ディスク等の可搬型の記録媒体７０にアクセスするものである。
一意性保証情報設定管理プログラムは、外部記憶装置６５、若しくは記録媒体７０に記録されているか、或いは通信ネットワークを介してネットワーク接続６７により取得される。その管理プログラムをメモリ６２に読み出してＣＰＵ６１が実行することにより、一意性保証情報設定管理装置４０は実現される。

＜第４の実施形態＞
振分対象サーバ３０上に生成されたセッションデータ３０１は、そのセッションＩＤを格納したメッセージを一定時間（タイムアウト時間）、受信しないことを条件に削除され、タイムアウトとなる。その削除に合わせて、ＳＬＢ２０が管理する、対応する一意性保証情報が削除される。

端末装置であるクライアント１０から送信されたメッセージが実際に対応する振分対象サーバ３０に受信されるまでに要する送信時間は、クライアント１０とＳＬＢ２０を接続する通信ネットワークのトラフィック等によって変化する。送信時間が増大した場合には、本来はタイムアウトとならないようにクライアント１０から送信されたメッセージが対応する振分対象サーバ３０に届く前に、タイムアウトとなる可能性がある。振分対象サーバ３０から送信されたメッセージがクライアント１０に受信されるまでに要する送信時間の増大は、タイムアウトを発生し易くする。第４の実施形態は、そのような送信時間の増大によるタイムアウトに対応できるように、振分対象サーバ３０に生成したセッションを管理するようにしたものである。

第４の実施形態におけるＳＬＢ、各振分対象サーバ、及び一意性保証情報設定管理装置の構成は大部分、第１の実施形態と同じである。動作も大部分は同じである。このようなことから、第１の実施形態で付した符号をそのまま用いて、第１の実施形態から異なる部分についてのみ説明する。

第４の実施形態では、振分対象サーバ３０がセッションを削除する場合、その削除を予告し、その予告後にクライアント１０からメッセージが受信されるか否か監視し、その監視結果から予告したセッションを実際に削除するか否か決定するようにしている。そのようにして、セッションを削除すべきタイミングとなっても直ちにセッションを削除せず、そのタイミング後にクライアント１０から受信されるメッセージに対応可能な期間を設けることにより、送信時間の増大によって発生するタイムアウトを抑制する。そのタイムアウトの抑制により、エラーの発生もより抑えられる。この結果、エラー処理による振分対象サーバ３０の負荷はより軽減させることができる。

第４の実施形態では、各振分対象サーバ３０、一意性保証情報設定管理装置４０、及びＳＬＢ２０は以下の様になっている。
振分対象サーバ３０のセッション情報通知部３５は、一意性保証情報設定管理装置４０との間でメッセージの送受信を行う。複数プロトコル連携部３３は、図２２に示す結果データ管理テーブル３５１を用いて、生成したセッション（セッションデータ３０１）を管理する。この結果データ管理テーブル３５１には、生成したセッション毎に、セッションを示すセッションＩＤ（図２２中「対象ＩＤ」と表記）、対応するセッションを削除すべきタイムアウト時刻、及びセッションの削除を予告した時刻である通知時刻が格納される。セッションの削除予告は、セッション情報通知部３５を介して一意性保証情報設定管理装置４０に通知する。その削除予告では、例えば削除対象とするセッションのＩＤが併せて通知される。これは、一意性保証情報設定管理装置４０とＳＬＢ２０間で送受信されるメッセージ、一意性保証情報設定管理装置４０から振分対象サーバ３０に送信されるメッセージでも同様である。タイムアウト時刻は、対応するメッセージの受信により、予め定めた一定時間、延長される。

一意性保証情報設定管理装置４０のセッション情報収集部４１は、振分対象サーバ３０との間でメッセージの送受信を行う。一意性保証情報記録要求部４３は、ＳＬＢ２０との間でメッセージの送受信を行う。振分対象サーバ３０から通知された削除予告は、セッション情報収集部４１からＳＬＢ制御メッセージ処理部４５１に渡される。

ＳＬＢ制御メッセージ処理部４５１は、振分対象サーバ３０の複数プロトコル連携部３３から送信されるメッセージに従い、ＳＬＢ２０を制御する。その制御は、図２１に示す様な削除ＩＤ管理テーブル４５２を用いて行う。この削除ＩＤ管理テーブル４５２には、図２２に示す様に、削除予告されたセッション毎に、そのＩＤ、そのセッションを生成している振分対象サーバ３０のアドレス（図２１中「サーバアドレス」と表記）、状態、その状態の最終更新時刻が格納される。

ＳＬＢ制御メッセージ処理部４５１は、削除予告が通知された場合、クライアント１０から受信する削除予告されたセッションに対応するメッセージを転送することなく保存することを指示するためのバッファ開始通知をＳＬＢ２０に送信する。その送信は、一意性保証情報記録要求部４３を介して行われる。

上記したようにシステム構成情報４０１には、振分対象サーバ３０毎に、その振分対象サーバ３０の前段に位置するＳＬＢ２０を一意に特定する識別情報、例えばそのアドレスが示されている。ＳＬＢ制御メッセージ処理部４５１は、システム構成情報４０１を参照して、バッファ開始通知を送信すべきＳＬＢ２０を特定する。特定されるＳＬＢ２０は、削除予告を通知した振分対象サーバ３０の前段に位置するＳＬＢ２０である。

バッファ開始通知を受信したＳＬＢ２０は、その応答を返す。その応答は、一意性保証情報記録要求部４３によって受信され、ＳＬＢ制御メッセージ処理部４５１に渡される。それによりＳＬＢ制御メッセージ処理部４５１は、削除予告応答を振分対象サーバ３０に送信する。

図２１には、削除ＩＤ管理テーブル４５２の状態として「バッファ開始通知」が表記されている。ＳＬＢ制御メッセージ処理部４５１は、バッファ開始通知の送信により、状態として「バッファ開始通知」を格納し、削除予告応答の振分対象サーバ３０への送信により、状態として「削除予告応答」を格納する。そのようにして、メッセージの送信により、そのメッセージの種類に応じて状態を更新する。その更新に合わせて、最終更新時刻も更新する。

ＳＬＢ２０は、バッファ開始通知の受信により、削除予告されたセッションに対応するメッセージを転送することなく保存する。その保存を行う前にクライアント１０から受信した対応するメッセージは、ＳＬＢ２０から振分対象サーバ３０に転送される。そのようにメッセージが転送された振分対象サーバ３０の複数プロトコル連携部３３は、削除予告したセッションの削除を中止し、その旨を一意性保証情報設定管理装置４０に通知する。

削除中止が通知された一意性保証情報設定管理装置４０のＳＬＢ制御メッセージ処理部４５１は、バッファ開始通知により保存したメッセージの転送を指示するためのバッファ転送通知をＳＬＢ２０に送信する。削除ＩＤ管理テーブル４５２の対応する状態は「バッファ転送」に更新する。

そのバッファ開始通知を受信したＳＬＢ２０は、保存したメッセージの転送を行う。その後は、メッセージを保存することなく転送を行う。
バッファ開始通知を受信する前に、ＳＬＢ２０が削除予告されたセッションに対応するメッセージを転送しなかった場合、振分対象サーバ３０の複数プロトコル連携部３３は、削除予告したセッションを削除する。その削除は、一意性保証情報設定管理装置４０から削除予告応答を受信するのを待って行い、その旨を一意性保証情報設定管理装置４０に通知する。

削除を行った旨を示す削除完了通知を受信した一意性保証情報設定管理装置４０のＳＬＢ制御メッセージ処理部４５１は、バッファ開始通知により保存したメッセージの削除を指示するためのバッファ削除通知をＳＬＢ２０に送信する。削除ＩＤ管理テーブル４５２の対応する状態は「バッファ削除」に更新する。

ＳＬＢ２０に送信されたバッファ開始通知は、一意性保証情報記録受付部２９から各プロトコル／メッセージ別処理部２３に渡される。各プロトコル／メッセージ別処理部２３のＭＳＧ振分部２３ｂは、バッファ開始通知が渡されることにより、対応するメッセージをキューイング部２５１に格納する。その格納は、図２０に示す様なバッファ対象ＩＤテーブル２５２を用いて管理する。そのバッファ対象ＩＤテーブル２５２には、セッションＩＤ毎に、メッセージの保存を開始した開始時刻が格納される。それにより、セッションＩＤを持つメッセージがキューイング部２５１に格納される。バッファ開始通知の受信により、プロトコル／メッセージ別処理部２３のうちの一つは、一意性保証情報記録受付部２９を介して応答を一意性保証情報設定管理装置４０に送信させる。

ＭＳＧ振分部２３ｂは、一意性保証情報設定管理装置４０からバッファ削除通知を受信した場合、その通知に対応するメッセージをキューイング部２５１から転送することなく削除する。バッファ転送通知を受信した場合には、その通知に対応するメッセージをキューイング部２５１から読み出して転送する。

図２３及び図２４は、第４の実施形態におけるＳＬＢ２０、振分対象サーバ３０、及び一意性保証情報設定管理装置４０の動作を示すシーケンス図である。図２３は、振分対象サーバ３０が削除予告を通知後にクライアント１０から対応するメッセージが送信されない場合のものであり、図２４は、そのメッセージが送信された場合のものである。次に図２３及び図２４を参照して、ＳＬＢ２０、振分対象サーバ３０、及び一意性保証情報設定管理装置４０の動作について具体的に説明する。図２３及び図２４において、一意性保証情報設定管理装置４０は「経路制御」と表記している。

最初に、図２３を参照して、クライアント１０からメッセージが送信されない場合の動作を説明する。
振分対象サーバ３０は、タイムアウト時刻の到来により、削除すべきタイミングとなったセッションの削除を予告するための削除予告通知を一意性保証情報設定管理装置４０に送信する（シーケンスＳ２３０１）。一意性保証情報設定管理装置４０は、受信した削除予告通知を処理し、ＳＬＢ２０にバッファ開始通知を送信する（シーケンスＳ２３０２）。ＳＬＢ２０は、バッファ開始通知の受信により、その応答（開始応答）を一意性保証情報設定管理装置４０に送信する（シーケンスＳ２５０３）。

その応答を受信した一意性保証情報設定管理装置４０は、削除予告応答を振分対象サーバ３０に送信する（シーケンスＳ２３０４）。振分対象サーバ３０は、削除予告通知を送信してから一意性保証情報設定管理装置４０がバッファ開始通知をＳＬＢ２０に送信するまでの期間ＤＴ、削除予告したセッションに対応するメッセージを受信していない。このため、削除予告したセッションを削除し、その旨を示す削除完了通知を一意性保証情報設定管理装置４０に送信する（シーケンスＳ２３０５）。その削除完了通知を受信した一意性保証情報設定管理装置４０は、保存された対応するメッセージが存在すれば転送することなく削除させるためのバッファ削除通知をＳＬＢ２０に送信する（シーケンスＳ２３０６）。

次に、図２４を参照して、クライアント１０からメッセージが送信される場合の動作を説明する。図２４では、図２３と同じ内容のシーケンスには同じ符号を付している。それにより、図２３から異なる部分に着目して動作を説明する。

図２４に示すケースでは、振分対象サーバ３０が削除予告通知を送信してから一意性保証情報設定管理装置４０がバッファ開始通知をＳＬＢ２０に送信するまでの期間ＤＴ内に、クライアント１０がメッセージをＳＬＢ２０に送信している（シーケンスＳ２４０１）。それにより、そのメッセージはＳＬＢ２０を介して振分対象サーバ３０に転送されている（シーケンスＳ２４０２）。シーケンスＳ２４０３及びＳ２４０４は、そのメッセージが転送された結果、振分対象サーバ３０からの応答の送信によって生じている。シーケンスＳ２４０５は、応答を受信したクライアント１０から更なるメッセージの送信により生じている。

図２４に示す様な期間ＤＴ内におけるメッセージの転送により、振分対象サーバ３０は削除予告したセッションの削除を中止する。このため、削除予告応答を受信した振分対象サーバ３０は、削除中止通知を一意性保証情報設定管理装置４０に送信する（シーケンスＳ２４０６）。その削除中止通知の受信により、一意性保証情報設定管理装置４０は、バッファ転送通知をＳＬＢ２０に送信する（シーケンスＳ２４０７）。

このようにして第４の実施形態では、本来、セッションを削除すべきタイミングとなってから実際に削除すべきタイミングとなるまでの間に、クライアント１０からメッセージが送信されたか否か監視する期間ＤＴを設けている。それにより、その期間ＤＴ分、タイムアウトとするタイミングを遅らせている。このため、送信時間の増大によって発生するタイムアウトは抑制され、エラーの発生もより抑えられることとなる。

以降は、図２５〜図２７にそれぞれ示すフローチャートを参照して、振分対象サーバ３０、一意性保証情報設定管理装置４０、及びＳＬＢ２０が実行する処理について詳細に説明する。

図２５は、振分対象サーバ３０が実行する処理のフローチャートである。この処理は、複数プロトコル連携部３３を実現させるアプリケーションを振分対象サーバ３０が実行することによって実現される。始めに図２５を参照して、その処理について詳細に説明する。この図２５では、生成したセッションの管理に特に係わる部分のみを抜粋して処理の流れを示している。

複数プロトコル連携部３３は、生成したセッションを管理するために、生成したセッションのＩＤを格納したインスタンステーブルを用意している。それにより、クライアント１０側で決定したＩＤ（識別子）を格納したメッセージでなければ、インスタンステーブルにセッションＩＤが格納されていないＩＤを格納したメッセージはエラー処理の対象となる。

先ず、ステップＳ２５０１では、クライアント１０からのメッセージ（リクエスト）が転送されたか否か判定する。そのメッセージをＳＬＢ２０が転送した場合、判定はＹｅｓとなってステップＳ２５０２に移行する。そのメッセージを受信していない場合には、判定はＮｏとなってステップＳ２５１０に移行する。

ステップＳ２５０２では、受信したメッセージ中に格納されたセッションＩＤ（図２５中「識別子」と表記）をキーにインスタンステーブルを検索する。続くステップＳ２５０３では、メッセージに対応するセッション（図２５中「インスタンス」と表記）が存在したか否か判定する。メッセージに格納されたセッションＩＤがインスタンステーブルに登録されていた場合、判定はＹｅｓとなり、ステップＳ２５０４に移行する。そのセッションＩＤがインスタンステーブルに存在しない場合、判定はＮｏとなってステップＳ２５０６に移行する。

ステップＳ２５０４では、結果データ管理テーブル３５１の対応するタイムアウト時刻を一定時間Ｔだけ延長させる。次のステップＳ２５０５では、受信したメッセージへの応答を作成して返信するための処理を実行する。その実行後、一連の処理を終了する。

ステップＳ２５０６では、転送されたメッセージがクライアント１０側でＩＤを付ける通信プロトコルか否か判定する。転送されたメッセージがその通信プロトコルで送信されたもの（例えばＳＩＰメッセージ）であった場合、判定はＹｅｓとなり、ステップＳ２５０７でメッセージのＩＤをインスタンステーブルに登録し、セッションを生成した後、ステップＳ２５０５に移行する。転送されたメッセージがクライアント１０側でＩＤを付けない通信プロトコルで送信されたものであった場合には、判定はＮｏとなり、ステップＳ２５０８でログの書き出しや通知といったエラー処理を実施し、更にステップＳ２５０９でエラー応答を行った後、一連の処理を終了する。

上記ステップＳ２５０１の判定がＮｏとなって移行するステップＳ２５１０では、タイムアウトイベントが到来したか否か判定する。現在時刻が結果データ管理テーブル３５１に登録されたタイムアウト時刻のうちの何れかと一致したような場合、判定はＹｅｓとなってステップＳ２５１１に移行する。現在時刻が何れのタイムアウト時刻とも一致しないような場合には、判定はＮｏとなってステップＳ２５１３に移行する。図２５では、ステップＳ２５１３への移行は、一意性保証情報設定管理装置４０から削除予告応答を受信した場合のみを想定する。

ステップＳ２５１１では、タイムアウト時刻が一致したレコードの通知時刻として現在時刻を設定する。続くステップＳ２５１２では、タイムアウト時刻が一致したレコードのセッションＩＤを格納した削除予告通知を一意性保証情報設定管理装置４０に送信する。その送信を行った後、一連の処理を終了する。

一方、ステップＳ２５１３では、削除予告応答に格納されているセッションＩＤから特定される結果データ管理テーブル３５１中のレコードのタイムアウト時刻が、そのレコードの通知時刻と同じか否か判定する。それらの時刻が一致している（許容範囲内で一致している）場合、判定はＹｅｓとなってステップＳ２５１４に移行する。それらの時刻が一致していない場合、つまり対応するメッセージの転送によってステップＳ２５０４の処理が実行された場合、判定はＮｏとなってステップＳ２５１６に移行する。

ステップＳ２５１４では、上記レコードのセッションＩＤを持つセッションを削除し、その旨を示す削除完了通知を一意性保証情報設定管理装置４０に送信する。次のステップＳ２５１５では、そのセッションＩＤを格納したレコード（エントリ）を結果データ管理テーブル３５１から削除すると共に、そのセッションＩＤをインスタンステーブルから削除する。その後、一連の処理を終了する。ステップＳ２５１６では、削除中止通知を一意性保証情報設定管理装置４０に送信する。その後、一連の処理を終了する。

図２６は、一意性保証情報設定管理装置４０が実行する処理のフローチャートである。この処理は、図２５に示す処理を実行する振分対象サーバ３０に関連する部分の処理の流れを示したものである。それにより、振分対象サーバ３０からの削除予告通知、削除完了通知、或いは削除中止通知の受信、ＳＬＢ２０からのバッファ開始応答の受信に対応する部分の処理のみを示している。次に図２６を参照して、この設定管理装置４０が実行する処理について詳細に説明する。

ＳＬＢ制御メッセージ処理部４５１は、図２６に示す処理を実行することで実現される。図２６に示す処理自体は、例えば上記一意性保証情報設定管理プログラムに搭載された機能によって実現される。

先ず、ステップＳ２６０１では、受信したメッセージは削除予告通知か否か判定する。その削除予告通知を受信した場合、判定はＹｅｓとなってステップＳ２６０２に移行する。その削除予告通知を受信しなかった場合には、判定はＮｏとなってステップＳ２６０５に移行する。

ステップＳ２６０２では、削除予告通知に格納されている、送信元の振分対象サーバ３０のアドレス（図２６中「アプリアドレスＩＰ」と表記）をキーにシステム構成情報４０１を参照し、バッファ開始通知を送信すべきＳＬＢ２０を決定する。続くステップＳ２６０３では、削除ＩＤ管理テーブル４５２に、新たにレコード（エントリ）を登録する。そのレコードは、削除予告通知に格納されているセッションＩＤ、振分対象サーバ３０のアドレスを格納し、最終更新時刻として現在時刻、状態として「バッファ開始通知」が設定されたものである。そのようなレコードを登録した後は、ステップＳ２６０４でバッファ開始通知を決定したＳＬＢ２０に送信する。その後、一連の処理を終了する。

ステップＳ２６０５では、バッファ開始応答を受信したか否か判定する。そのバッファ開始応答を受信した場合、判定はＹｅｓとなってステップＳ２６０６に移行する。バッファ開始応答以外のメッセージを受信した場合には、判定はＮｏとなってステップＳ２６０９に移行する。

ステップＳ２６０６では、バッファ開始応答に格納されたセッションＩＤをキーに削除ＩＤ管理テーブル４５２を参照し、削除予告応答を送信すべき振分対象サーバ３０のアドレスを取得する。次のステップＳ２６０７では、削除ＩＤ管理テーブル４５２のアドレスを取得したレコード中の状態を「削除予告応答」に更新し、最終更新時刻を現在時刻に更新する。その次に移行するステップＳ２６０８では、取得したアドレスを持つ振分対象サーバ３０に削除予告応答を送信する。その後、一連の処理を終了する。

ステップＳ２６０９では、削除完了通知を受信したか否か判定する。その削除完了通知を受信した場合、判定はＹｅｓとなってステップＳ２６１０に移行する。削除完了通知以外のメッセージ、つまり削除中止通知を受信した場合には、判定はＮｏとなってステップＳ２６１３に移行する。

ステップＳ２６１０では、削除完了通知に格納された振分対象サーバ３０のアドレスをキーにシステム構成情報４０１を参照し、バッファ削除通知を送信すべきＳＬＢ２０を決定する。続くステップＳ２６１１では、削除ＩＤ管理テーブル４５２の削除完了通知に格納されたセッションＩＤを持つレコードの状態を「バッファ削除」に更新し、最終更新時刻を現在時刻に更新する。その次に移行するステップＳ２６１２では、決定したＳＬＢ２０にバッファ削除通知を送信する。その後、一連の処理を終了する。

ステップＳ２６１３では、削除中止通知に格納された振分対象サーバ３０のアドレスをキーにシステム構成情報４０１を参照し、バッファ転送通知を送信すべきＳＬＢ２０を決定する。続くステップＳ２６１４では、削除ＩＤ管理テーブル４５２の削除中止通知に格納されたセッションＩＤを持つレコードの状態を「バッファ転送」に更新し、最終更新時刻を現在時刻に更新する。その次に移行するステップＳ２６１５では、決定したＳＬＢ２０にバッファ転送通知を送信する。その後、一連の処理を終了する。

このようにして一意性保証情報設定管理装置４０は、削除予告通知はバッファ開始通知の形でＳＬＢ２０に送信する。同様に、削除完了通知はバッファ削除通知、削除中止通知はバッファ転送通知の形でそれぞれＳＬＢ２０に送信する。それにより、振分対象サーバ３０から送信されるメッセージの種類に応じてＳＬＢ２０は動作することになる。

図２７は、ＳＬＢ２０が実行する処理のフローチャートである。この処理は、図２６に示す処理を実行する一意性保証情報設定管理装置４０に関連する部分の処理の流れを示したものである。それにより、一意性保証情報設定管理装置４０からのバッファ開始通知、バッファ削除通知、或いはバッファ転送通知の受信、端末装置ＳＬＢ２０からのメッセージの受信に対応する部分の処理のみを示している。最後に図２７を参照して、このＳＬＢ２０が実行する処理について詳細に説明する。

図２７に示す処理は、プロトコル／メッセージ別処理部２３のＭＳＧ振分部２３ｂを実現させる処理に相当する。その処理自体は、ＳＬＢ２０に搭載されたプログラム（負荷分散プログラム）をＳＬＢ２０が実行することで実現される。

先ず、ステップＳ２７０１では、受信したメッセージ（図２７中「Ｍｓｇ」と表記）はクライアント１０からのものか否か判定する。そのメッセージをクライアント１０から受信した場合、判定はＹｅｓとなってステップＳ２７０２に移行する。クライアント１０以外から受信したメッセージであった場合には、判定はＮｏとなってステップＳ２７０６に移行する。

ステップＳ２７０２では、メッセージから抽出されたセッションＩＤをキーに、バッファ対象ＩＤテーブル２５２を検索する。続くステップＳ２７０３では、バッファ対象ＩＤテーブル２５２の検索にヒットしないか否か判定する。メッセージにセッションＩＤが格納されていない、或いは格納されたセッションＩＤがバッファ対象ＩＤテーブル２５２に登録されていない場合、判定はＹｅｓとなってステップＳ２７０４に移行する。そのセッションＩＤがバッファ対象ＩＤテーブル２５２に登録されていた場合には、判定はＮｏとなってステップＳ２７０６に移行する。

ステップＳ２７０４では、メッセージ中のセッションＩＤをキーに、一意性保証ＤＢ２０１、及び対応するプロトコル／メッセージ別一意性保証テーブル２０２を参照して、メッセージを転送すべき振分対象サーバ３０のアドレスを抽出し、その振分対象サーバ３０に送信する。転送先とすべき振分対象サーバ３０のアドレスを抽出できなかった場合には、ラウンドロビン方式等により自律的に転送先を選択し転送する。そのようにしてメッセージを転送した後、一連の処理を終了する。

ステップＳ２７０５では、キューイング部２５１にメッセージを格納する。その格納を行った後、一連の処理を終了する。
ステップＳ２７０６では、受信したメッセージはバッファ開始通知か否か判定する。そのバッファ開始通知を受信した場合、判定はＹｅｓとなってステップＳ２７０７に移行する。バッファ開始通知以外のメッセージを一意性保証情報設定管理装置４０から受信した場合には、判定はＮｏとなってステップＳ２７０９に移行する。

ステップＳ２７０７では、バッファ開始通知から抽出したセッションＩＤと開始時刻を格納したレコードをバッファ対象ＩＤテーブル２５２に登録する。開始時刻としては現在時刻を格納する。次のステップＳ２７０８では、バッファ開始応答を一意性保証情報設定管理装置４０に送信する。その後、一連の処理を終了する。

ステップＳ２７０９では、受信したメッセージはバッファ削除通知か否か判定する。そのバッファ削除通知を受信した場合、判定はＹｅｓとなってステップＳ２７１０に移行する。バッファ削除通知以外のメッセージ、つまりバッファ転送通知を一意性保証情報設定管理装置４０から受信した場合には、判定はＮｏとなってステップＳ２７１３に移行する。

ステップＳ２７１０では、バッファ削除通知から抽出したセッションＩＤを格納したエントリをバッファ対象ＩＤテーブル２５２から削除すると共に、そのセッションＩＤを有する一意性保証情報を一意性保証ＤＢ２０１、或いはプロトコル／メッセージ別一意性保証テーブル２０２から削除する。続くステップＳ２７１１では、そのセッションＩＤをキーにキューイング部２５１を参照し、そのセッションＩＤを格納したメッセージのリストを取得する。そのリストにメッセージが存在していれば、つまりエラーとなるタイミングでクライアント１０から送信されたメッセージがキューイング部２５１に存在していれば、その旨を通知するためのメッセージをサーバ発メッセージ送信部（図２７中「エラー通知部」と表記）２８に転送する。その次に移行するステップＳ２７１２では、サーバ発メッセージ送信部２８に転送したメッセージをクライアント１０に送信させる。その後、一連の処理を終了する。

ステップＳ２７１３では、バッファ転送通知から抽出したセッションＩＤを格納したエントリをバッファ対象ＩＤテーブル２５２から削除する。続くステップＳ２７１４では、そのセッションＩＤをキーにキューイング部２５１を参照し、そのセッションＩＤを格納したメッセージのリストを取得する。そのリストにメッセージが存在していれば、つまり転送すべきメッセージがキューイング部２５１に存在していれば、そのメッセージを全て転送すべき振分対象サーバ３０に転送する。その転送を行った後、一連の処理を終了する。

第４の実施形態では、振分対象サーバ３０、一意性保証情報設定管理装置４０、及びＳＬＢ２０は上記のような処理を実行する。それにより、図２３及び図２４に示す期間ＤＴ分、クライアント１０からのメッセージの送信時間が増大したとしても、その増大によってタイムアウトとなるのを回避することができる。

図１９に示すコンピュータは、ＳＬＢ２０及び振分対象サーバ３０として用いることができる。そのコンピュータをＳＬＢ２０或いは振分対象サーバ３０として用いる場合、一意性保証情報設定管理装置４０と同様に、ＳＬＢ２０を実現させる負荷分散プログラム、或いは振分対象サーバ３０の複数プロトコル連携部３３を実現させるアプリケーションは、外部記憶装置６５、若しくは記録媒体７０に記録されているか、或いは通信ネットワークを介してネットワーク接続６７により取得される。そのようにして用意されるプログラムをメモリ６２に読み出してＣＰＵ６１が実行することにより、ＳＬＢ２０、或いは振分対象サーバ３０（の複数プロトコル連携部３３）は実現される。

なお、第４の実施形態では、クライアント１０から送信されたメッセージを監視する監視期間は、振分対象サーバ３０が削除予告通知を送信してからバッファ開始通知をＳＬＢ２０が受信するまでの期間ＤＴとしているが、その監視期間は期間ＤＴに限定されるものではない。削除予告したセッションを実際に削除するまでの範囲内で監視期間は変更可能である。

例えばセッションの削除が通知されるまでの間に、クライアント１０から受信したメッセージを振分対象サーバ３０にＳＬＢ２０に転送させる場合には、期間ＤＴをより長くすることができる。その場合、ＳＬＢ２０はクライアント１０からのメッセージを監視する役割を担っている形となる。

また、キューイング部２５１を利用したメッセージの保存は、第４の実施形態ではバッファ開始通知の受信により、ＳＬＢ２０は無条件に行うようになっているが、無条件に行わないようにしても良い。メッセージの保存を行うべきか否か判定して、メッセージの保存を行うようにしても良い。その判定は、振分対象サーバ３０（複数プロトコル連携部３３）が行い、その判定結果を併せて通知するようにしても良いが、一意性保証情報設定管理装置４０、或いはＳＬＢ２０にその判定を行わせるようにしても良い。

バッファ開始通知の受信によりＳＬＢ２０にメッセージを保存し続けるのは、資源を有効利用するうえで望ましくない。このことから、削除予告通知を送信した振分対象サーバ３０から削除完了通知、或いは削除中止通知を一意性保証情報設定管理装置４０が受信されない状況に対応できるようにしても良い。その対応は、ＳＬＢ制御メッセージ処理部４５１に行わせることが考えられる。

ＳＬＢ制御メッセージ処理部４５１に対応させる場合、例えば図２８に示す様なタイマー管理テーブル４６１をＳＬＢ制御メッセージ処理部４５１に管理させる。そのタイマー管理テーブル４６１には、受信した削除予告通知毎に、セッションＩＤ、起動時刻、及び生成イベントを格納したレコードを登録する。起動時刻は、削除予告通知を受信してから一定時間、経過した後の時刻である。生成イベントは、その起動時刻となるまでの間に、対応する削除完了通知、或いは削除中止通知を受信できなかった場合に生成すべきイベントを示している。その生成イベントとして表記の「削除中止通知」は、削除中止通知を振分対象サーバ３０から受信したイベントを生成することを示している。それにより、バッファ転送通知をＳＬＢ２０に送信することを示している。このようなタイマー管理テーブル４６１を用意し、削除完了通知、或いは削除中止通知が振分対象サーバ３０から受信できなかった場合に対応することにより、ＳＬＢ２０で不要なメッセージを保存することによる資源の浪費を抑えることができる。削除完了通知、或いは削除中止通知が振分対象サーバ３０から受信できた場合には、その通知に対応するレコードをタイマー管理テーブル４６１から削除すれば良い。生成イベントとして削除中止通知を想定しているのは、クライアント１０に対し、エラーの通知を最小限に抑えるのが望ましいと云えるからである。資源の浪費を単に抑えるのであれば、生成イベントは削除完了通知であっても良い。

上記タイマー管理テーブル４６１を用いた対応は、ＳＬＢ２０で行わせても良い。これは、バッファ開始通知を受信した後、バッファ転送通知、或いはバッファ削除通知を一意性保証情報設定管理装置４０からＳＬＢ２０が受信できない状況も考えられるからである。生成イベントを生成する条件としては、削除予告通知が送信されてから経過した時間の他に、保存されたメッセージの数、そのデータ量（或いは保存したメッセージ全体のデータ量）であっても良い。複数の条件を設定し、何れかの条件が満たされた場合に、生成イベントを生成するようにしても良い。

また、第４の実施形態では、削除予告をするセッションは複数の通信プロトコル間の連携に対応したものであるが、一つの通信プロトコルにのみ対応したものであっても良い。このことから、クライアント１０のユーザにサービスを提供するサービス提供システムは、一つ以上のＳＬＢ２０、及び複数の振分対象サーバ３０を備えた構成であっても良い。つまり一意性保証情報設定管理装置４０がない構成であっても良い。

以上の変形例を含む実施形態に関し、更に以下の付記を開示する。
（付記１）
複数の通信プロトコルでそれぞれサービスを提供可能な複数のサーバのなかから端末装置が要求するサービスを提供させるサーバを選択する負荷分散装置に対し、該端末装置からの関連する要求を同じサーバに振り分ける一意性保証を実現させる一意性保証情報設定管理装置として用いられるコンピュータに、
前記端末装置から第１の通信プロトコルにより前記サービスの提供が要求された場合に、該要求により前記負荷分散装置が前記複数のサーバのなかから選択したサーバ内で生成されたセッションを識別するための識別情報を取得する識別情報取得機能と、
前記識別情報取得機能により取得した識別情報と該識別情報に対応するセッションを生成したサーバとの対応関係を第２の通信プロトコルによるサービスで前記一意性保証用の一意性保証情報として前記負荷分散装置に設定する保証情報設定機能と、
を実現させるための一意性保証情報設定管理プログラム。
（付記２）
前記保証情報設定機能は、前記一意性保証情報の設定完了が前記負荷分散装置から通知された場合、該一意性保証情報の生成に用いた識別情報を取得したサーバに該設定完了を通知する、
ことを特徴とする付記１記載の一意性保証情報設定管理プログラム。
（付記３）
前記識別情報取得機能は、前記識別情報の他に、前記第１の通信プロトコルを示すプロトコル情報を取得し、
前記保証情報設定機能は、前記プロトコル情報を基に、前記一意性保証情報を設定する第２のプロトコルを選択する、
ことを特徴とする付記１記載の一意性保証情報設定管理プログラム。
（付記４）
前記コンピュータに、
前記サーバからセッションの削除が予告された場合に、前記端末装置から送信される要求のなかで該セッションに対応する要求を転送させずに保存させるためのバッファ開始通知を前記負荷分散装置に送信する開始通知送信機能、
を更に実現させることを特徴とする付記１記載の一意性保証情報設定管理プログラム。
（付記５）
前記コンピュータに、
前記サーバから予告された前記セッションの削除が通知された場合に、保存された前記対応する要求を転送することなく削除させるバッファ削除通知の送信により、該セッションの削除を前記負荷分散装置に通知し、該サーバから該セッションの削除の中止が通知された場合に、該保存された該対応する要求を転送させるバッファ転送通知の送信により、該セッションの削除の中止を該負荷分散装置に通知する転送管理機能、
を更に実現させることを特徴とする付記４記載の一意性保証情報設定管理プログラム。
（付記６）
前記コンピュータに、
前記開始通知送信機能により前記バッファ開始通知を送信した後、予め定めた条件が満たされた場合に、該バッファ開始通知により保存された前記対応する要求を転送させるためのバッファ転送通知を前記負荷分散装置に送信する転送通知送信機能、
を更に実現させることを特徴とする付記４、または５記載の一意性保証情報設定管理プログラム。
（付記７）
前記転送通知送信機能は、前記サーバからセッションの削除が予告された後、一定時間が経過するまでの間に該サーバから該セッションの削除、及び該セッションの削除の中止のうちの一方が通知されなかった場合に、前記条件が満たされたと判定する、
ことを特徴とする付記６記載の一意性保証情報設定管理プログラム。
（付記８）
複数のサーバのなかから端末装置が要求するサービスを提供させるサーバを選択する負荷分散装置に対し、該端末装置からの関連する要求を同じサーバに振り分ける一意性保証を実現させる一意性保証情報設定管理装置として用いられるコンピュータに、
前記負荷分散装置の選択によって前記セッションを生成したサーバから該セッションの削除が予告された場合に、前記端末装置から送信される要求のなかで該セッションに対応する要求を転送させずに保存させるためのバッファ開始通知を該負荷分散装置に送信する開始通知送信機能と、
前記開始通知送信機能により前記バッファ開始通知を送信した後、予め定めた条件が満たされた場合に、該バッファ開始通知により保存された前記対応する要求を転送させるためのバッファ転送通知を前記負荷分散装置に送信する転送通知送信機能と、
を実現させるための一意性保証情報設定管理プログラム。
（付記９）
複数のサーバのなかから端末装置が要求するサービスを提供させるサーバを選択し、該端末装置からの関連する要求を同じサーバに振り分ける負荷分散装置として用いられるコンピュータに、
前記選択によって前記サーバが生成したセッションの削除が該サーバから予告された場合に、前記端末装置から受信される要求のなかで該セッションに対応する要求を転送せずに記憶装置に保存するバッファ機能と、
前記バッファ機能により前記対応する要求の保存を開始した後、予め定めた条件が満たされた場合に、前記記憶装置に保存した該対応する要求を前記サーバに転送させる転送制御機能と、
を実現させるための負荷分散プログラム。
（付記１０）
前記転送制御機能は、前記サーバからセッションの削除が予告された後、一定時間が経過するまでの間に該サーバから該セッションの削除、及び該セッションの削除の中止のうちの一方が通知されなかった場合に、前記条件が満たされたと判定する、
ことを特徴とする付記９記載の負荷分散プログラム。
（付記１１）
複数の通信プロトコルでそれぞれサービスを提供可能な複数のサーバのなかから端末装置が要求するサービスを提供させるサーバを負荷分散装置に選択させる場合に、複数の通信プロトコル間の連携に対応した一意性保証を実現させる方法であって、
前記端末装置から第１の通信プロトコルを用いた前記サービスの提供の要求により、前記負荷分散装置が前記複数のサーバのなかから選択したサーバ内で生成されるセッションを識別するための識別情報を取得する識別情報取得工程と、
前記識別情報取得工程により取得した識別情報と該識別情報に対応するセッションを生成したサーバとの対応関係を第２の通信プロトコルによるサービスで前記一意性保証用の一意性保証情報として前記負荷分散装置に設定する保証情報設定工程と、
前記端末装置から前記第２の通信プロトコルを用いた前記サービスの提供が要求された場合に、前記保証情報設定工程により設定された前記一意性保証情報を前記負荷分散装置に参照させて、該サービスを提供させるサーバを前記複数のサーバのなかから選択させる振分工程と、
を含むことを特徴とする一意性保証実現方法。
（付記１２）
前記保証情報設定工程では、前記負荷分散装置に設定する一意性保証情報の生成に用いた識別情報を取得したサーバに対し、前記第１の通信プロトコルを用いた要求に対する応答を送信するタイミングを制御する、
ことを特徴とする付記１１記載の一意性保証実現方法。
（付記１３）
複数の通信プロトコルでそれぞれサービスを提供可能な複数のサーバのなかから端末装置が要求するサービスを提供させるサーバを選択する負荷分散装置に対し、該端末装置からの関連する要求を同じサーバに振り分ける一意性保証を実現させるための一意性保証情報の設定を管理する一意性保証情報設定管理装置において、
前記端末装置から第１の通信プロトコルにより前記サービスの提供が要求された場合に、該要求により前記負荷分散装置が前記複数のサーバのなかから選択したサーバ内で生成されたセッションを識別するための識別情報を取得する識別情報取得手段と、
前記識別情報取得手段が取得した識別情報と該識別情報に対応するセッションを生成したサーバとの対応関係を第２の通信プロトコルによるサービスで前記一意性保証用の一意性保証情報として前記負荷分散装置に設定する保証情報設定手段と、
を具備することを特徴とする一意性保証情報設定管理装置。
（付記１４）
負荷分散装置により、端末装置の要求の振分先として選択されるサーバとして用いられるコンピュータに、
前記端末装置の要求が振り分けられたことにより生成したセッションを削除する場合に、該削除を前記負荷分散装置に予告する削除予告機能と、
前記削除予告機能により予告を行ってから前記セッションを実際に削除すべきタイミングとなるまでの間に、前記端末装置から該セッションに対応する要求が送信されたか否か監視する監視機能と、
前記監視機能により前記対応する要求の送信が確認された場合に、前記予告を行った前記セッションの削除を中止させる削除管理機能と、
を実現させるためのアプリケーション・プログラム。
（付記１５）
前記サーバは複数の通信プロトコルを連携させたサービスを提供可能であり、該複数の通信プロトコル間の連携に対応した一意性保証を実現させるための一意性保証情報の前記負荷分散装置への設定を管理する一意性保証情報管理装置が存在する場合、前記削除予告機能は、該一意性保証情報設定管理装置に前記予告を行うことにより、該一意性保証情報設定管理装置を介して該予告を該負荷分散装置に通知させる、
ことを特徴とする付記１４記載のアプリケーション・プログラム。
（付記１６）
前記削除管理機能は、前記監視機能により前記対応する要求の送信が確認されなかった場合に、前記予告を行った前記セッションを削除すると共に、前記一意性保証情報設定管理装置を介して、該セッションに対応する一意性保証情報を前記負荷分散装置に削除させる、
ことを特徴とする付記１５記載のアプリケーション・プログラム。
（付記１７）
複数のサーバのなかから端末装置が要求するサービスを提供させるサーバを負荷分散装置に選択させる場合に、該負荷分散装置が選択のサーバに該サービスの提供用に生成されたセッションを管理するための方法であって、
前記端末装置の要求が振り分けられたことにより生成したセッションの削除を前記サーバから前記負荷分散装置に予告する削除予告工程と、
前記削除予告工程により予告を行ってから前記セッションを実際に削除すべきタイミングとなるまでの間に、前記端末装置から該セッションに対応する要求が送信されたか否か監視する監視工程と、
前記監視工程で前記対応する要求の送信が確認された場合に、前記予告を行った前記セッションの削除を前記サーバに中止させる削除管理工程と、
を含むことを特徴とするセッション管理方法。
（付記１８）
端末装置が要求するサービスを提供するサービス提供システムにおいて、
前記サービス提供システムは、前記サービスを提供可能な複数のサーバ、及び該複数のサーバのなかから前記端末装置が要求するサービスを提供させるサーバを選択する負荷分散装置、を備え、
前記複数のサーバのうちの少なくとも一つは、
前記端末装置の要求が振り分けられたことにより生成したセッションの削除を前記負荷分散装置に予告する削除予告手段と、
前記削除予告手段による予告を行ってから前記セッションを実際に削除すべきタイミングとなるまでの間に、前記端末装置から該セッションに対応する要求が送信されたか否か監視する監視手段と、
前記監視手段により前記対応する要求の送信が確認された場合に、前記予告を行った前記セッションの削除を中止させる削除管理手段と、
前記削除管理手段による前記セッションの削除、及び該セッションの削除の中止をしたか否かを前記負荷分散装置に通知するための通知手段と、を備え、
前記負荷分散装置は、
前記端末装置からの要求を格納する要求格納手段と、
前記サーバと該サーバで生成されたセッションを識別するための識別情報の対応関係を示す一意性保証情報を格納する保証情報格納手段と、
前記削除が予告されたセッションに対応する要求を前記端末装置から受信した場合に、該受信した要求を前記要求格納手段に格納するバッファ制御手段と、
前記サーバから前記セッションの削除が通知された場合に、前記バッファ制御手段により前記要求格納手段に格納された前記対応する要求を転送することなく、該セッションに対応する一意性保証情報を前記保証情報格納手段から削除し、該サーバから該セッションの削除の中止が通知された場合に、該保証情報格納手段に格納されている前記一意性保証情報を参照して、該要求格納手段に格納された該対応する要求を転送する転送制御手段と、を備えている、
ことを特徴とするサービス提供システム。
（付記１９）
前記サービス提供システムは、複数の通信プロトコルを連携させたサービスに対応した一意性保証を実現させるための一意性保証情報の前記負荷分散装置への設定を管理する一意性保証情報管理装置、を備え、
前記一意性保証情報設定管理装置は、
前記サーバから前記セッションの削除が予告された場合に、前記端末装置から送信される要求のなかで該セッションに対応する要求を転送させずに保存させるためのバッファ開始通知の送信により、該予告を該負荷分散装置に通知する開始通知送信手段と、
前記サーバから前記セッションの削除が通知された場合に、該セッションに対応する要求を転送することなく前記要求格納手段から削除させるバッファ削除通知の送信により、該セッションの削除を前記負荷分散装置に通知し、該サーバから該セッションの削除の中止が通知された場合に、該要求格納手段に格納されている前記対応する要求を転送させるバッファ転送通知の送信により、該セッションの削除の中止を該負荷分散装置に通知する転送管理手段と、を備えている、
ことを特徴とする付記１８記載のサービス提供システム。

１０ クライアント（端末装置）
２０ サーバロードバランサ（負荷分散装置）
２１ クライアント発メッセージ受信部
２２ メッセージ識別部
２３ プロトコル／メッセージ別処理部
２４ クライアント発メッセージ送信部
２５ サーバ発メッセージ受信部
２６ メッセージ識別部
２７ プロトコル／メッセージ別処理部
２８ サーバ発メッセージ送信部
２９ 一意性保証情報記録受付部
３０ 振分対象サーバ
３１ メッセージ送受信部
３２ プロトコル処理部
３３ 複数プロトコル連携部
３４ セッション情報監視部
３５ セッション情報通知部
４０ 一意性保証情報設定管理装置
４１ セッション情報収集部
４２ 一意性保証情報生成部
４３ 一意性保証情報記録要求部
２０１ 一意性保証ＤＢ
２０２ プロトコル／メッセージ別一意性保証テーブル
２５１ キューイング部
２５２ バッファ対象ＩＤテーブル
３０１ セッションデータ
３５１ 結果データ管理テーブル
４０１ システム構成情報
４５１ ＳＬＢ制御メッセージ処理部
４５２ 削除ＩＤ管理テーブル
４６１ タイマー管理テーブル

Claims (10)

1. 複数の通信プロトコルでそれぞれサービスを提供可能な複数のサーバのなかから端末装置が要求するサービスを提供させるサーバを選択する負荷分散装置に対し、該端末装置からの関連する要求を同じサーバに振り分ける一意性保証を実現させる一意性保証情報設定管理装置として用いられるコンピュータに、
   前記端末装置から第１の通信プロトコルにより前記サービスの提供が要求された場合に、該要求により前記負荷分散装置が前記複数のサーバのなかから選択したサーバ内で生成されたセッションを識別するための識別情報を取得する識別情報取得機能と、
   前記識別情報取得機能により取得した識別情報と該識別情報に対応するセッションを生成したサーバとの対応関係を第２の通信プロトコルによるサービスで前記一意性保証用の一意性保証情報として前記負荷分散装置に設定する保証情報設定機能と、
   を実現させるための一意性保証情報設定管理プログラム。
2. 前記保証情報設定機能は、前記一意性保証情報の設定完了が前記負荷分散装置から通知された場合、該一意性保証情報の生成に用いた識別情報を取得したサーバに該設定完了を通知する、
   ことを特徴とする請求項１記載の一意性保証情報設定管理プログラム。
3. 前記識別情報取得機能は、前記識別情報の他に、前記第１の通信プロトコルを示すプロトコル情報を取得し、
   前記保証情報設定機能は、前記プロトコル情報を基に、前記一意性保証情報を設定する第２のプロトコルを選択する、
   ことを特徴とする請求項１記載の一意性保証情報設定管理プログラム。
4. 前記コンピュータに、
   前記サーバからセッションの削除が予告された場合に、前記端末装置から送信される要求のなかで該セッションに対応する要求を転送させずに保存させるためのバッファ開始通知を前記負荷分散装置に送信する開始通知送信機能、
   を更に実現させることを特徴とする請求項１記載の一意性保証情報設定管理プログラム。
5. 前記コンピュータに、
   前記サーバから予告された前記セッションの削除が通知された場合に、保存された前記対応する要求を転送することなく削除させるバッファ削除通知の送信により、該セッションの削除を前記負荷分散装置に通知し、該サーバから該セッションの削除の中止が通知された場合に、該保存された該対応する要求を転送させるバッファ転送通知の送信により、該セッションの削除の中止を該負荷分散装置に通知する転送管理機能、
   を更に実現させることを特徴とする請求項４記載の一意性保証情報設定管理プログラム。
6. 前記コンピュータに、
   前記開始通知送信機能により前記バッファ開始通知を送信した後、予め定めた条件が満たされた場合に、該バッファ開始通知により保存された前記対応する要求を転送させるためのバッファ転送通知を前記負荷分散装置に送信する転送通知送信機能、
   を更に実現させることを特徴とする請求項４、または５記載の一意性保証情報設定管理プログラム。
7. 前記転送通知送信機能は、前記サーバからセッションの削除が予告された後、一定時間が経過するまでの間に該サーバから該セッションの削除、及び該セッションの削除の中止のうちの一方が通知されなかった場合に、前記条件が満たされたと判定する、
   ことを特徴とする請求項６記載の一意性保証情報設定管理プログラム。
8. 複数のサーバのなかから端末装置が要求するサービスを提供させるサーバを選択する負荷分散装置に対し、該端末装置からの関連する要求を同じサーバに振り分ける一意性保証を実現させる一意性保証情報設定管理装置として用いられるコンピュータに、
   前記負荷分散装置の選択によって前記セッションを生成したサーバから該セッションの削除が予告された場合に、前記端末装置から送信される要求のなかで該セッションに対応する要求を転送させずに保存させるためのバッファ開始通知を該負荷分散装置に送信する開始通知送信機能と、
   前記開始通知送信機能により前記バッファ開始通知を送信した後、予め定めた条件が満たされた場合に、該バッファ開始通知により保存された前記対応する要求を転送させるためのバッファ転送通知を前記負荷分散装置に送信する転送通知送信機能と、
   を実現させるための一意性保証情報設定管理プログラム。
9. 複数のサーバのなかから端末装置が要求するサービスを提供させるサーバを選択し、該端末装置からの関連する要求を同じサーバに振り分ける負荷分散装置として用いられるコンピュータに、
   前記選択によって前記サーバが生成したセッションの削除が該サーバから予告された場合に、前記端末装置から受信される要求のなかで該セッションに対応する要求を転送せずに記憶装置に保存するバッファ機能と、
   前記バッファ機能により前記対応する要求の保存を開始した後、予め定めた条件が満たされた場合に、前記記憶装置に保存した該対応する要求を前記サーバに転送させる転送制御機能と、
   を実現させるための負荷分散プログラム。
10. 複数の通信プロトコルでそれぞれサービスを提供可能な複数のサーバのなかから端末装置が要求するサービスを提供させるサーバを選択する負荷分散装置に対し、該端末装置からの関連する要求を同じサーバに振り分ける一意性保証を実現させるための一意性保証情報の設定を管理する一意性保証情報設定管理装置において、
    前記端末装置から第１の通信プロトコルにより前記サービスの提供が要求された場合に、該要求により前記負荷分散装置が前記複数のサーバのなかから選択したサーバ内で生成されたセッションを識別するための識別情報を取得する識別情報取得手段と、
    前記識別情報取得手段が取得した識別情報と該識別情報に対応するセッションを生成したサーバとの対応関係を第２の通信プロトコルによるサービスで前記一意性保証用の一意性保証情報として前記負荷分散装置に設定する保証情報設定手段と、
    を具備することを特徴とする一意性保証情報設定管理装置。