JP5458688B2 - 一意性保証支援プログラム、サービス提供システム、及び一意性保証実現方法 - Google Patents

Description

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

複数のサーバに負荷を分散させる負荷分散には通常、サーバロードバランサ（ＳＬＢ、Server Load Balancer、負荷分散装置）が利用される。ＳＬＢはクライアントである端末装置からの要求（メッセージ）をラウンドロビン方式等の自律振分アルゴリズムに従って複数のサーバのうちの一つに振り分ける。その振り分けによって、情報交換の単位であるセッションがサーバに生成される。 生成されたセッションには、一意に識別するための識別情報（例えばセッションＩＤ）が割り当てられ、その識別情報はＳＬＢ、及び端末装置に通知される。ＳＬＢは、識別情報とその識別情報のセッションを保持するサーバとの関係をテーブル等に登録する。端末装置は、識別情報を格納したパケットにより要求を行う。ＳＬＢは、ヘッダに格納された識別情報を用いてテーブルを参照することにより、その識別情報のセッションを保持するサーバにパケットを振り分ける。そのようにしてＳＬＢは、セッションが継続する間、同じ端末装置からの要求は同じサーバに振り分ける機能を維持する。この機能は一意性保証機能（或いはセッション維持機能）と呼ばれる。

識別情報は、通信プロトコルによって異なる。セッションＩＤは、ＨＴＴＰ（HyperText Transfer Protocol）等の通信プロトコルで用いられる。ＨＴＴＰメッセージでの格納場所は、ＨＴＴＰヘッダのｓｅｔ−ｃｏｏｋｉｅ或いはｃｏｏｋｉｅフィールドである。ＳＩＰ（Session Initiation Protocol）では、識別情報としてコールＩＤが用いられる。ＳＩＰメッセージでの格納場所は、ＳＩＰヘッダのｃａｌｌ−ｉｄフィールドである。このコールＩＤは、ＳＩＰメッセージ（パケット）を送信する端末装置によって割り当てられる。 セッションＩＤとサーバの組み合わせ、及びコールＩＤとサーバの組み合わせは共に、メッセージを振り分けるべきサーバに振り分ける一意性保証を実現させるための情報である。このことから以降「一意性保証情報」と総称する。

ところで、例えばＮＧＮ（Next Generation Network）におけるＳＤＰ（Service Discovery Protocol）の分野では、複数の通信プロトコルを組み合わせたサービスを要求可能なアプリケーション（以降「連携アプリケーション」と総称する）が提供されるようになっている。例えば、ＳＩＰの呼確立後にＨＴＴＰ経由で呼情報を表示可能なアプリケーション（以下、アプリと略記する場合がある）や、Ｗｅｂページ経由でＳＩＰの呼制御を行うアプリケーションなどが挙げられる。その連携アプリケーションの代表例としては、ＳＩＰとＨＴＴＰとを連携可能なＣＳＢＮＡ（Call Scheduleon Busy or No Answer）アプリケーションがある。連携アプリケーションでは普通、通信プロトコル間の連携を実現するために、或る通信プロトコル経由でセッションが生成されたサーバに、他の通信プロトコル経由でもメッセージを到達する必要がある。そのため、通信プロトコル間の連携にも、一意性保証を実現する必要がある。しかしＳＬＢは、自律負荷分散（自動振分）機能により、通信プロトコル毎にメッセージを振り分けるサーバを選択する。このため、複数の通信プロトコルでの一意性保証をサポートしない。

複数の通信プロトコルの一意性保証は、サーバでのセッションの生成を契機に、連携アプリケーションがサポートする他の通信プロトコル用の一意性保証情報も生成し、各通信プロトコルの一意性保証情報をＳＬＢに登録することにより実現させることが考えられる。しかし、連携アプリケーションでは、端末装置から任意の通信プロトコルのメッセージを任意のタイミングで送信する必要がある。それにより、端末装置から、或る通信プロトコルのメッセージの他に、別の通信プロトコルのメッセージがほぼ同時に送信されたようなケースにも対応できるようにする必要がある。その理由は、各通信プロトコル用の一意性保証情報をＳＬＢに登録する前に、ＳＬＢに端末装置から別の通信プロトコルのメッセージが届いてしまい、そのメッセージを、ＳＬＢが自動振分機能により任意のサーバに振り分けてしまう可能性があるからである。このようなことから、複数の通信プロトコルの一意性保証、つまり複数の通信プロトコル間の連携に対応した一意性保証を確実に実現するためには、複数の通信プロトコルのメッセージが端末装置からほぼ同時に送信されるようなケースにも対応することが重要である。

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

dynamicsoft Inc., "SIP ServletAPI Version 1.0",February 4, 2003.

本発明は、複数のサーバに負荷を分散させる場合に、複数の通信プロトコル間の連携に対応した一意性保証を確実に実現させるための技術を提供することを目的とする。

本発明を適用した１システムでは、複数の通信プロトコルでそれぞれサービスを提供可能な複数のサーバのなかの一つに端末装置から送信されたメッセージを負荷分散装置により転送させる場合に、以下のようにして、複数の通信プロトコル間の連携に対応した一意性保証を実現させる。

複数のサーバのなかで転送すべきサーバが未定の第１のメッセージを端末装置から負荷分散装置が受信した場合に、該第１のメッセージを転送すべきサーバを選択して転送する。そのようにして第１のメッセージを転送した後、第１のメッセージと同じサーバに転送すべき第２のメッセージを負荷分散装置が端末装置から受信した場合に、その第２のメッセージを保存する。第１のメッセージが転送されたサーバがセッションを生成した場合に、そのセッション（サーバ）とそのセッションに対応するメッセージの対応関係を示す一意性保証情報をそのセッション（アプリケーション・プログラム）が対応する複数の通信プロトコル分、生成する。第２のメッセージが保存されている場合に、生成された各一意性保証情報に従ってその第２のメッセージを転送する。

本発明を適用した場合には、複数のサーバに負荷を分散させる場合に、複数の通信プロトコル間の連携に対応した一意性保証を確実に実現させることができる。

本実施例１によるサービス提供システムを用いて構築されたネットワークシステムの構成を示す図である。 一次ＳＬＢ１３の機能構成を示す図である。 二次ＳＬＢ１４の機能構成を示す図である。 プレゼンスサーバ１１の機能構成を示す図である。 一意性保証情報設定管理装置１５の機能構成を示す図である。 クライアント２、プレゼンスサーバ１１、各ＳＬＢ１３及び１４、並びに一意性保証情報設定管理装置１５の動作を示すシーケンス図である（その１）。 クライアント２、プレゼンスサーバ１１、各ＳＬＢ１３及び１４、並びに一意性保証情報設定管理装置１５の動作を示すシーケンス図である（その２）。 第２のキュー監視プロセス４５が行うメッセージの転送を説明する図である。 シーケンス番号を付加したメッセージのデータ構成を説明する図である（ＳＯＡＰの場合）。 シーケンス番号を付加したメッセージのデータ構成を説明する図である（ＳＩＰの場合）。 プレゼンスサーバ１１から送信されるセッション生成通知のデータ構成例を説明する図である。 一意性保証情報設定管理装置から送信されるセッション生成通知のデータ構成例を説明する図である。 第２のキュー監視プロセス４５がメッセージ転送用に有する一意性保証情報を説明する図である。 キュー監視プロセス管理部４３が管理する情報を説明する図である。 メッセージ受信処理のフローチャートである。 第１のキュー監視プロセス４５が実行する処理を示すフローチャートである。 第２のキュー監視プロセス４５が実行する処理を示すフローチャートである。 本実施例１を適用可能なコンピュータのハードウェア構成の一例を示す図である。 本実施例２の一次ＳＬＢ１３のプロトコル／メッセージ処理部２３が実行する処理を示すフローチャートである。 本実施例２によるサービス提供システムの構成例を示す図である。 アプリ＃１を使用する際のメッセージ形式を示す図である。（ａ）はＳＩＰによるメッセージで、（ｂ）はＳＯＡＰによるメッセージを示す。 アプリ＃２を使用する際のメッセージ形式を示す図である。（ａ）はＳＩＰによるメッセージで、（ｂ）はＳＯＡＰによるメッセージを示す。 一意性保証情報識別ルール２０３の一例を示す図である。 振分先候補サーバIPの設定の一例を示す図である。 一意性保証テーブル２０２の一例を示す図である。（ａ）は一意性保証情報の登録がなされる前の例を示しており、（ｂ）は一意性保証情報の登録がなされた後の例を示している。

以下、本発明の実施形態について、図面を参照しながら詳細に説明する。

図１は、本実施例１によるサービス提供システムを用いて構築されたネットワークシステムの構成を示す図である。そのネットワークシステムは、本実施例１によるサービス提供システムであるプレゼンスサーバシステム１と、端末装置であるクライアント２とを通信ネットワークで接続した形の構成となっている。プレゼンスサーバシステム（以降「サーバシステム」と略記）１は、クライアント２のユーザに、知りたい相手の状態を示すプレゼンス情報を提供するプレゼンス・サービスを行う。相手の状態とは、例えば在席か否か、電話中か否か、多忙か否か、といったものである。

サーバシステム１には、それぞれがプレゼンス・サービスを提供可能なプレゼンスサーバ１１が複数、備えられている。各プレゼンスサーバ１１は、クライアント２からプレゼンス状態（情報）を受信し、データベース（ＤＢ）サーバ１２にプレゼンス情報を格納する。各プレゼンスサーバ１１は、クライアント２に送信すべきプレゼンス情報をＤＢサーバ１２に問い合わせて取得する。

複数の一次ＳＬＢ１３のうちの一つは、クライアント２から送信された要求（メッセージ）を受信する。受信した一次ＳＬＢ１３は、複数のプレゼンスサーバ１１のうちの一つ、或いは二次ＳＬＢ１４に、要求を転送する。ここでは、理解を容易とするために、プレゼンスサーバ１１に搭載されたサービス提供用のアプリケーションは、通信プロトコルとしてＳＩＰ及びＳＯＡＰ（Simple Object Access Protocol）をサポートすると想定する。図１では、ＳＩＰに対して一次ＳＬＢ１３−１、ＳＯＡＰに対して一次ＳＬＢ１３−２を想定する。

負荷分散が行われる複数のサーバそれぞれがサポートする通信プロトコルの組み合わせは、これに限定されるものではない。つまりＳＩＰとＳＯＡＰの組み合わせ以外のものであっても良い。それにより、各サーバが提供可能なサービスの種類や組み合わせも限定されるものではない。

各プレゼンスサーバ１１は、クライアント２からのメッセージの受信によりセッションを生成する。プレゼンスサーバ１１は、セッションを生成後、そのセッションを識別するための識別情報であるセッション識別子を、そのセッションを生成したアプリケーションを識別するための識別情報であるアプリケーション識別子と共に、一意性保証情報設定管理装置に通知する。

一意性保証情報設定管理装置１５に通知されるセッション識別子とアプリケーション識別子の組み合わせは、クライアント２からのメッセージを転送すべきプレゼンスサーバ１１に転送するための転送ルールとなる一意性保証情報である。プレゼンスサーバ１１から通知される一意性保証情報は、１通信プロトコル分である。このことから一意性保証情報設定管理装置１５は、他の通信プロトコル用の一意性保証情報を生成し、２通信プロトコル分の一意性保証情報を各一次ＳＬＢ１３及び二次ＳＬＢ１４に通知して登録させる。

クライアント２は、セッション識別子を格納したメッセージを通信プロトコルによって特定される一次ＳＬＢ１３に送信する。そのようなメッセージを受信した一次ＳＬＢ１３は、そのメッセージと同じ通信プロトコル用に登録している一意性保証情報を参照し、メッセージの転送先を決定する。その参照により、メッセージ中のセッション識別子を有する一意性保証情報が無いことが判明した場合、そのメッセージを二次ＳＬＢ１４に転送する。そのセッション識別子を有する一意性保証情報が見つかった場合、一次ＳＬＢ１３はそのメッセージを一意性保証情報のアプリケーション識別子から特定されるプレゼンスサーバ１１に転送する。このようにして、対応する一意性保証情報が登録されているメッセージは、一次ＳＬＢ１３によって一意性保証が実現される。対応する一意性保証情報が登録されていないメッセージは全て二次ＳＬＢ１４に転送される。

二次ＳＬＢ１４は、一次ＳＬＢ１３から転送されたメッセージをキューの最後尾に格納する。そのメッセージを自律負荷分散機能により振り分けるか否かは、そのメッセージと同じ通信プロトコル用に登録している一意性保証情報の他に、既にプレゼントサーバ１１に自律負荷分散機能により振り分けたメッセージを考慮して決定される。自律負荷分散機能により振り分けたメッセージを考慮するのは、既にプレゼンスサーバ１１に転送したメッセージと同じセッション識別子を格納したメッセージを異なるプレゼンスサーバ１１に転送するのを回避するためである。それにより、同じセッション識別子を格納したメッセージが複数、一次ＳＬＢ１３から転送された場合、二次ＳＬＢ１４は最初に転送されたメッセージのみを自律負荷分散機能により決定したプレゼンスサーバ１１に振り分ける。そのメッセージの後に転送されたメッセージは、対応する一意性保証情報を登録するのを待って、その一意性保証情報が示すプレゼンスサーバ１１に転送される。

このようにして本実施例１では、二次ＳＬＢ１４は、対応する一意性保証情報が登録されていないメッセージ、つまり自律負荷分散機能により振り分けるべきメッセージ、及びそのメッセージの転送から一意性保証情報が登録されるまでの間にクライアント２から送信されたメッセージを処理する。このため、たとえ複数の通信プロトコルそれぞれで複数のメッセージがクライアント２から送信されたとしても、同じセッション識別子を格納したメッセージは、通信プロトコルに係わらず全て同じプレゼントサーバ１１に転送される。この結果、複数の通信プロトコル間の連携に対応した一意性保証は確実に実現される。このようなことから、本実施例１による一意性保証支援装置は、二次ＳＬＢ１４に搭載する形で実現されている。

二次ＳＬＢ１４は、自律負荷分散機能により振り分けたメッセージに、識別用の情報であるシーケンス番号を付加してプレゼンスサーバ１１に送信する。図９及び図１０は、シーケンス番号を付加したメッセージのデータ構成を説明する図である。図９はメッセージの通信プロトコルがＳＯＡＰであるＳＯＡＰメッセージの場合であり、図１０はその通信プロトコルがＳＩＰであるＳＩＰメッセージの場合である。本実施例１では、メッセージに付加したシーケンス番号は、識別用であると共に、自律負荷分散機能により送信していることをプレゼンスサーバ１１に通知する情報として用いている。そのような情報としてシーケンス番号以外のものを採用しても良い。例えばハッシュ値を採用しても良い。

図１０のＳＩＰヘッダに表記の「allice@ps.com」は、メッセージを送信したクライアント２が相手先とするクライアント２のＳＩＰ−ＵＲＩ（Uniform ResourceIdentifier）である。その相手先ＳＩＰ−ＵＲＩは、ＳＯＡＰメッセージではボディ（ＳＯＡＰボディ）中の「presentity」パラメータとして格納されている。このパラメータは、このパラメータとして指定されたＳＩＰ−ＵＲＩに対応するプレゼンス情報を取得するための情報である。本実施例１では、そのように異なる通信プロトコルのメッセージに格納する同一の情報をセッション識別子として用いるようにしている。

相手先ＳＩＰ−ＵＲＩは、クライアント２のユーザが任意の方法により事前に取得可能な情報である。このため、異なる通信プロトコルのメッセージをほぼ同時に送信する場合であっても、各メッセージに格納することができる。セッションを生成したプレゼンスサーバ１１は、そのセッション用のデータとして相手先ＳＩＰ−ＵＲＩを保存する。このため、相手先ＳＩＰ−ＵＲＩはプレゼンスサーバ１１側にとってセッションの識別力を有する情報となっている。相手先ＳＩＰ−ＵＲＩをセッション識別子として用いているのは、このような理由からである。この理由から、セッション識別子は、クライアント２側で事前に取得可能であり、プレゼンスサーバ１１側でセッションの識別力を有する情報であれば良い。そのような情報としては他に、メッセージを送信したクライアント２の送信元ＳＩＰ−ＵＲＩ、相手先、若しくは送信元のＩＰアドレス、等を挙げることができる。

図９或いは図１０に示すようなメッセージを受信したプレゼンスサーバ１１は、セッションを生成した後、その旨をセッション生成通知として一意性保証情報設定管理装置１５に通知する。図１１は、そのセッション生成通知のデータ構成例を説明する図である。その生成通知には、セッションを生成する契機となったメッセージ中の送信先ＳＩＰ−ＵＲＩをセッション識別子、及びセッションを生成したプレゼンスサーバ１１が実行中のアプリケーションを示すアプリケーション識別子（図１１中「Ｐｒｅｓｅｎｃｅ１」と表記）を含む一意性保証情報の他に、そのメッセージ中のシーケンス番号が格納されている。

このセッション生成通知に格納されている一意性保証情報は、１通信プロトコル分である。このため、一意性保証情報設定管理装置１５は、そのセッション生成通知の受信を契機に、別の通信プロトコル分の一意性保証情報を生成し、生成した一意性保証情報をセッション生成通知に加えて二次ＳＬＢ１４及び各一次ＳＬＢ１３にそれぞれ送信する。図１２は、そのようにして一意性保証情報設定管理装置１５から送信されるセッション生成通知のデータ構成例を説明する図である。図１２に示すように、この生成通知には、通信プロトコル別に一意性保証情報が格納されている。

一意性保証情報は、各一次ＳＬＢ１３及び二次ＳＬＢ１４にとって、メッセージを転送すべきプレゼンスサーバ１１を識別するための識別ルールとなる。本実施例１では、識別ルール間の識別を可能とするために、二次ＳＬＢ１４は通信プロトコルによって特有の種別情報をアプリケーション識別子に付加している。図１２中に「Ｐｒｅｓｅｎｃｅ１−」に続けて表記の「ＳＩＰ」及び「ＳＯＡＰ」は共に、付加した種別情報に相当する。そのような情報を付加したアプリケーション識別子は以降「識別ルール識別子」と記載する。一意性保証情報は以降「識別ルール」或いは「転送ルール」とも呼ぶことにする。

二次ＳＬＢ１４は、セッション生成通知に格納されているシーケンス番号から、自律負荷分散機能により振り分けたメッセージを特定する。そのメッセージに格納されたセッション識別子を有するメッセージがキューに存在している場合、そのメッセージをキューから読み出し、一意性保証情報から特定されるプレゼンスサーバ１１に転送する。それにより、二次ＳＬＢ１４に転送された同一のセッション識別子を格納しているメッセージは全て同じプレゼンスサーバ１１に転送する。この結果、一意性保証情報が存在していない状況下でクライアント２から送信されたメッセージの一意性保証が確実に実現される。

次に、図２〜図５に示す各種説明図を参照して、一次ＳＬＢ１３、二次ＳＬＢ１４、プレゼンスサーバ１１及び一意性保証情報設定管理装置１５の各構成、並びに動作について具体的に説明する。

図２は、一次ＳＬＢ１３の機能構成を示す図である。始めに図２を参照して、一次ＳＬＢ１３の構成および動作について詳細に説明する。
一次ＳＬＢ１３は、図２に示すように、クライアント発メッセージ受信部２１、メッセージ識別部２２、通信プロトコル毎に用意されたプロトコル／メッセージ別処理部２３、クライアント発メッセージ送信部２４、サーバ発メッセージ受信部２５、メッセージ識別部２６、通信プロトコル別に用意されたプロトコル／メッセージ別処理部２７、サーバ発メッセージ送信部２８、一意性保証情報記録受付部２９、一意性保証ＤＢ２０１や一意性保証情報識別ルール２０３を格納した記憶装置を備えた構成となっている。

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

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

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

一意性保証ＤＢ２０１には、通信プロトコル別に、一意性保証情報を格納したプロトコル／メッセージ別一意性保証テーブル２０２が用意されている。一意性保証情報設定管理装置１５から送信されたセッション生成通知に格納されている一意性保証情報はそれぞれ、対応するプロトコル／メッセージ別一意性保証テーブル２０２に格納（登録）される。ＭＳＧ振分部２３ｂは、一意性保証情報識別部２３ａが識別したセッション識別子を用いて、一意性保証ＤＢ２０１の対応するプロトコル／メッセージ別一意性保証テーブル２０２を参照し、メッセージの転送先を決定する。その転送先は、識別されたセッション識別子を有する一意性保証情報がその保証テーブル２０２に登録されていた場合、その一意性保証情報から特定されるプレゼンスサーバ１１である。識別されたセッション識別子を有する一意性保証情報がその保証テーブル２０２に登録されていない場合、二次ＳＬＢ１４が転送先として決定される。決定した転送先へのメッセージの転送は、クライアント発メッセージ送信部２４によって行われる。

一意性保証情報記録部２３ｃは、メッセージの種類に応じて、セッションの識別情報を一意性保証ＤＢ２０１の対応するプロトコル／メッセージ別一意性保証テーブル２０２に格納する。この識別情報の格納は、一次ＳＬＢ１３がメッセージを振り分けるプレゼンスサーバ１１を決定する自律負荷分散を行う状況時にのみ行う。つまり、二次ＳＬＢ１４へのメッセージの転送を行わない状況時にのみ行う。

プレゼンスサーバ１１から一次ＳＬＢ１３宛に送信されたメッセージは、サーバ発メッセージ受信部２５により受信され、メッセージ識別部２６により通信プロトコルが識別される。それにより、通信プロトコル（メッセージ）別の複数のプロトコル／メッセージ別処理部２７のうちの一つにメッセージが渡される。

各プロトコル／メッセージ別処理部２７は、一意性保証情報識別部２７ａ、及び一意性保証情報記録部２７ｃを備えている。一意性保証情報識別部２７ａは、一意性保証情報識別ルール２０３を参照して、メッセージ中に存在する一意性保証情報の識別情報を識別（抽出）する。一意性保証情報記録部２７ｂは、その識別情報を必要に応じて一意性保証ＤＢ２０２に格納する。プロトコル／メッセージ別処理部２７により識別情報を格納するのは、プロトコル／メッセージ別処理部２３と同様に、二次ＳＬＢ１４へのメッセージの転送を行わない状況時のみである。

一意性保証情報設定管理装置１５から受信したセッション生成通知中に存在する通信プロトコル別の一意性保証情報はそれぞれ、対応するプロトコル／メッセージ別処理部２３或いは２７の一意性保証情報記録部２３ｃ或いは２７ｂによって一意性保証ＤＢ２０１に格納される。ここでは便宜的に、その格納は一意性保証情報記録部２７ｂが行うと想定する。

一意性保証情報設定管理装置１５から送信されたセッション生成通知は、一意性保証情報記録受付部２９によって受け付けられる。その一意性保証情報記録受付部２９は、受け付けたセッション生成通知を各プロトコル／メッセージ別処理部２７に渡す。それにより各プロトコル／メッセージ別処理部２７の一意性保証情報記録部２７ｂは、対応する一意性保証情報を一意性保証ＤＢ２０１の対応するプロトコル／メッセージ別一意性保証テーブル２０２に登録する。

一次ＳＬＢ１３は、上述したようにして、クライアント２から受信したメッセージの転送先を決定して転送し、一意性保証情報設定管理装置１５から受信したセッション生成通知によって一意性保証ＤＢ２０１を更新する。それにより、複数の通信プロトコル間の連携を可能とする一意性保証を実現させる。

一次ＳＬＢ１３には、通信プロトコル別にプロトコル／メッセージ別処理部２３及び２７が用意されている。それにより、複数の通信プロトコルをサポートしている。このため、１つの一次ＳＬＢ１３を用いて負荷分散を行わせることにも対応できるようになっている。

図３は、二次ＳＬＢ１４の機能構成を示す図である。次に図３を参照して、二次ＳＬＢ１４の構成および動作について詳細に説明する。
二次ＳＬＢ１４は、図３に示すように、クライアント発メッセージ受信部３１、メッセージ識別部３２、通信プロトコル毎に用意されたプロトコル／メッセージ別処理部３３、クライアント発メッセージ送信部３４、サーバ発メッセージ受信部３５、メッセージ識別部３６、通信プロトコル別に用意されたプロトコル／メッセージ別処理部３７、サーバ発メッセージ送信部３８、一意性保証情報関連通知受付部３９、一意性保証ＤＢ３０１や一意性保証情報識別ルール３０３、メッセージメッセージキューイング部４１、キュー監視プロセス管理部４２、キュー監視プロセス生成部４３、メッセージ配送状態管理部４４を備えた構成となっている。各プロトコル／メッセージ別処理部３３は、一意性保証情報識別部３３ａ、ＭＳＧ振分部３３ｂ及び一意性保証情報記録部３３ｃを備えている。各プロトコル／メッセージ別処理部３７は、一意性保証情報識別部３７ａ及び一意性保証情報記録部３７ｂを備えている。

上記構成において、クライアント発メッセージ受信部３１、メッセージ識別部３２、通信プロトコル毎に用意されたプロトコル／メッセージ別処理部３３、クライアント発メッセージ送信部３４、サーバ発メッセージ受信部３５、メッセージ識別部３６、通信プロトコル別に用意されたプロトコル／メッセージ別処理部３７、及びサーバ発メッセージ送信部３８の動作は、一次ＳＬＢ１３と大部分は同じである。このことから、それらの動作については一次ＳＬＢ１３から異なる部分についてのみ説明する。一意性保証ＤＢ３０１は基本的に一次ＳＬＢ１３が管理する一意性保証ＤＢ２０１と内容を含めて同じ構成であり、通信プロトコル別にプロトコル／メッセージ別一意性保証テーブル３０２が用意されている。一意性保証情報識別ルール３０３も基本的に一次ＳＬＢ１３が管理する一意性保証情報識別ルールＤＢ２０３と内容を含めて同じ構成である。

各プロトコル／メッセージ別処理部３３のＭＳＧ振分部３３ｂは、一意性保証情報識別部３３ａが識別したセッション識別子を用いて、一意性保証ＤＢ３０１の対応するプロトコル／メッセージ別一意性保証テーブル３０２を参照し、メッセージの転送先を決定する。その転送先は、識別されたセッション識別子を有する一意性保証情報が保証テーブル３０２に登録されていた場合、その一意性保証情報から特定されるプレゼンスサーバ１１である。識別されたセッション識別子を有する一意性保証情報がその保証テーブル２０２に登録されていない場合には、キュー監視プロセス生成部４３が生成するキュー監視プロセス４５に処理させる。

メッセージ中のセッション識別子を有する一意性保証情報が登録されていないケースは、そのセッション識別子を格納したメッセージが初めて転送されるケースと、初めてのメッセージ（以降「初回メッセージ」）の後に同じセッション識別子を格納したメッセージが転送されるケースとに大別される。プロセス生成部４３が生成するキュー監視プロセス４５は２種類、存在する。一つは、上記自律負荷分散専用であり、もう一つは一意性保証情報に従ったメッセージの転送が可能なものである。以降、便宜的に前者を「第１のキュー監視プロセス」、後者を「第２のキュー監視プロセス」と呼ぶことにする。それら第１及び第２のキュー監視プロセス４５によるメッセージの転送は、クライアント発メッセージ送信部３４を介して行われる。

ＭＳＧ振分部３３ｂは、第１のキュー管理プロセス４５による自律負荷分散が行われないメッセージをメッセージキューイング部４１に格納する。そのメッセージには、状況により初回メッセージが含まれる。このメッセージキューイング部４１は、キューイングのための記憶装置であり、このメッセージキューイング部４１によりキューが実現されている。

第１のキュー監視プロセス４５は、プレゼンスサーバ１１のなかでセッションを生成させるプレゼンスサーバ１１を選択し、メッセージを転送させる。メッセージに格納されているセッション識別子に関係なく、自律負荷分散を行う。このことから、図９及び図１０に示すようなシーケンス番号が付加されたメッセージは、第１のキュー監視プロセス４５によって送信される。メッセージの転送後、消去（消滅）される。

メッセージ配送状態管理部４４は、メッセージキューイング部４１に格納されたメッセージのなかで自律負荷分散が行われたメッセージを管理するために用いられる。具体的には、データの読み書きが可能な記憶装置であり、自律負荷分散によりプレゼンスサーバ１１に転送したメッセージ（例えばセッション識別子）毎に、そのメッセージに付加されたシーケンス番号、及びそのメッセージに対応するセッション生成通知を受信したか否かを示す配送状態の各データ（以降「配送状態管理情報」と呼ぶ）が少なくとも格納される。このことから第１のキュー監視プロセス４５は、例えばメッセージ配送状態管理部４４を参照して、自律負荷分散により選択したプレゼンスサーバ１１に転送するメッセージに付加すべきシーケンス番号を特定し、特定したシーケンス番号をメッセージ配送状態管理部４４に登録する。配送状態としてはセッション生成通知の受信（通知）待ちを示すデータを登録する。

そのメッセージの転送後、一意性保証情報設定管理装置１５からセッション生成通知が送信される。そのセッション生成通知は、一意性保証情報関連通知受付部３９によって受信され、キュー監視プロセス生成部４３に渡される。第２のキュー監視プロセス４５は、そのセッション生成通知がキュー監視プロセス生成部４３に渡されることを契機に生成され、その生成通知に格納された一意性保証情報に従ってメッセージをメッセージキューイング部４１から読み出して転送する。メッセージキューイング部４１に転送すべきメッセージが存在しないことが判明した時点で消去させる。

第１及び第２のキュー監視プロセス４５は共に、例えばそれぞれ用意したソフトウェア（アプリケーション、或いはサブプログラム）を起動させることで生成される。第２のキュー監視プロセス４５では、例えば対応するソフトウェアに割り当てるべき一意性保証情報を割り当てて起動させる。それにより、割り当てた一意性保証情報に従って転送すべきメッセージのみ転送させる。

図１３は、第２のキュー監視プロセス４５がメッセージ転送用に有する一意性保証情報を説明する図である。図１３に示すように第２のキュー監視プロセス４５は、識別用のルール番号を割り当てて各一意性保証情報を管理している。

図８は、第２のキュー監視プロセス４５が行うメッセージの転送を説明する図である。図８に表記のＡ〜Ｃは何れも、メッセージキューイング部４１に格納された、セッション識別子の異なるメッセージを表している。「Ａにマッチするルールを持つ監視プロセス」は、メッセージＡに格納されたセッション識別子を有する一意性保証情報が適用された第２のキュー監視プロセス４５に相当する。メッセージＡに対応することから、符号としては「４５ａ」を付している。同様に、第２のキュー監視プロセス４５ｂは、メッセージＢに格納されたセッション識別子を有する一意性保証情報が適用された第２のキュー監視プロセス４５に相当する。

本実施例１では、図８に示すように、各第２のキュー監視プロセス４５はメッセージキューイング部４１の先頭、つまり最も前に格納されたメッセージから参照し、対応するメッセージのみ転送する。それにより、例えば第２のキュー監視プロセス４５ａはメッセージＡのみメッセージキューイング部４１から読み出して転送し、メッセージＡ以外のメッセージＢ及びＣを対象にした自律負荷分散は行わない。この結果、メッセージキューイング部４１に格納されたメッセージは全て対応する一意性保証情報に従って転送される。

第２のキュー監視プロセス４５は、自律負荷分散を行った結果、生成される。このことから第２のキュー監視プロセス４５は、他の第２のキュー監視プロセス４５が存在しない状況では、消滅の前に第１のキュー監視プロセス４５を生成する。また、その状況では、メッセージキューイング部４１に格納されている初回メッセージの自律負荷分散を行う。自律負荷分散を行った初回メッセージの後に同じセッション識別子を格納したメッセージの転送は行わない。

キュー監視プロセス生成部４５は、第２のキュー監視プロセス４５を生成した後、そのプロセス４５に割り当てた識別用のプロセス番号を適用させた一意性保証情報と共にプロセス管理部４２に通知する。それによりプロセス管理部４２は、第２のキュー監視プロセス４５とそのプロセス４５に適用させた一意性保証情報の対応関係を管理する。実際のプロセス管理部４２は、例えば上記メッセージ配送状態管理部４４と同様に、データの読み書きが可能な記憶装置である。

図１４は、プロセス管理部４３が管理する情報を説明する図である。図１４に示すように、識別ルール識別子とセッション識別子を有する一意性保証情報はプロセス番号を付加する形でプロセス管理部４３に格納される。同一の第２のキュー監視プロセス４５に適用された一意性保証情報には同一のプロセス番号が割り当てられている。

一意性保証情報関連通知受付部３９は、一意性保証情報設定管理装置１５からセッション生成通知を受信した場合、その生成通知をキュー監視プロセス生成部４３に渡すと共に、例えば各プロトコル／メッセージ別処理部３７にも渡す。それにより、通信プロトコル別に、セッション生成通知に格納された一意性保証情報を一意性保証ＤＢ３０２の対応するプロトコル／メッセージ別一意性保証テーブル３０２に登録させる。また、メッセージ配送状態管理部４４からセッション生成通知に格納されたシーケンス番号を有する配送状態管理情報を特定し、その配送状態管理情報中の配送状態を受信待ちでない状態に変更する。

二次ＳＬＢ１４では、各部は上述したように動作する。このことから本実施例１による一意性保証支援装置は主に、クライアント発メッセージ受信部３１、メッセージ識別部３２、通信プロトコル毎に用意されたプロトコル／メッセージ別処理部３３、クライアント発メッセージ送信部３４、通信プロトコル別に用意されたプロトコル／メッセージ別処理部３７、一意性保証情報関連一意性保証情報関連通知受付部３９、一意性保証ＤＢ３０１や一意性保証情報識別ルール３０３、メッセージキューイング部４１、キュー監視プロセス管理部４２、キュー監視プロセス生成部４３、及びメッセージ配送状態管理部４４により実現される。

なお、本実施例１では、対応する一意性保証情報が登録されていないメッセージの処理は第１或いは第２のキュー監視プロセス４５に行わせるようにしているが、その処理は１種類、或いは３種類以上のキュー監視プロセスに行わせるようにしても良い。その処理は、ＭＳＧ振分部３３ｂ、或いは別の構成要素に行わせるようにしても良い。このようなことから二次ＳＬＢ１４を実現させるためのプログラム（一意性保証支援プログラム）は、第１及び第２のキュー監視プロセス４５を生成可能なものである他に、第１及び第２のキュー監視プロセス４５により実現される機能を搭載したものであっても良い。

図４は、プレゼンスサーバ１１の機能構成を説明する図である。図４に示す様にプレゼンスサーバ１１は、メッセージを送受信するためのメッセージ送受信部５１と、通信プロトコル毎に用意された複数のプロトコル処理部５２と、複数の通信プロトコルでサービスを提供可能とするアプリケーションにより実現される複数プロトコル連携部５３と、複数プロトコル連携部５３によるセッションの生成を監視するセッション情報監視部５４と、セッション情報監視部５４による監視結果に応じて、上記セッション生成通知等を送信するセッション情報通知部５５と、を備えている。

各プレゼンスサーバ１１は、一次ＳＬＢ１３、或いは二次ＳＬＢ１４から送信されたメッセージをメッセージ送受信部５１により受信し、メッセージの通信プロトコルに対応するプロトコル処理部５２に渡す。プロトコル処理部５２の後段には複数プロトコル連携部５３が位置している。その複数プロトコル連携部５３は、複数の通信プロトコルを連携したサービス（ここではプレゼンス・サービス）を提供する。メッセージが渡されたプロトコル処理部５２は、そのメッセージを解析して、渡すべき複数プロトコル連携部５３にそのメッセージを渡す。

複数プロトコル連携部５３は、プロトコル処理部５２から渡されたメッセージにより、セッションを生成し、そのセッションに係わるセッションデータ５０１を生成・保存する。そのセッションデータ５０１は、セッションを一意に特定するセッション識別子、及びセッションに付随するデータを含むものである。ＤＢサーバ１２から取得したプレゼンス情報は、セッションデータ５０１の一部として管理され、プレゼンス・サービスの提供に用いられる。

複数プロトコルの連携を１プレゼンスサーバ１１に行わせる一意性保証が実現されない場合、通信プロトコル別にメッセージが転送される各プレゼンスサーバ１１に、ＤＢサーバ１２から取得されるデータ（キャッシュ）が重複して保存される。このため、その場合には、各プレゼンスサーバ１１はデータ参照時にＤＢサーバ１２の原本が更新されているか否かチェックする必要がある。原本が更新されていれば、各プレゼンスサーバ１１はデータを新たにＤＢサーバ１２から取得しなければならない。このようなことから、各プレゼンスサーバ１１の負荷はより重くなり易く、資源はより浪費する形となる。

セッション情報監視部５４は、複数プロトコル連携部５３によるセッション生成を監視し、セッションが生成された際に、セッション関連情報、例えばシーケンス番号、セッション識別子、及びアプリケーション識別子をセッション情報通知部５５に渡す。セッション情報通知部５５は、それらの情報を格納したセッション生成通知を作成し、一意性保証情報設定管理装置１５に送信する。

複数プロトコル連携部５３は、予め定められた条件が満たされることにより、生成したセッションを削除する。例えば対応するメッセージをクライアント２が最後に送信してから一定時間が経過することでセッションを削除する。セッション情報監視部５４は、セッションが削除された場合、セッション関連情報、例えばセッション識別子、及びアプリケーション識別子をセッション情報通知部５５に渡す。セッション情報通知部５５は、それらの情報を格納したセッション削除通知を作成し、一意性保証情報設定管理装置１５に送信する。

図５は、一意性保証情報設定管理装置１５の機能構成を説明する図である。図５に示す様に一意性保証情報設定管理装置１５は、セッション情報等通知受付部６１、一意性保証情報生成部６２、エラー通知メッセージ生成部６３、及び一意性保証情報関連通知送信部６４を備えている。

一意性保証情報設定管理装置１５は、プレゼンスサーバ１１から送信された各種通知（メッセージ）をセッション情報等通知受付部６１で受信する。受信された通知は、一意性保証情報生成部６２及びエラー通知メッセージ生成部６３にそれぞれ渡される。一意性保証情報生成部６２は、渡された通知がセッション生成通知であった場合、セッション生成通知に格納された一意性保証情報中のアプリケーション識別子に対応する通信プロトコルを示す種別情報を付加する。また、そのアプリケーション識別子から、一意性保証情報を生成すべき通信プロトコルを特定し、特定した通信プロトコル用の一意性保証情報を生成する。生成した一意性保証情報はセッション生成通知に格納する。それにより、図１２に示す様なセッション生成通知を生成し、システム構成情報６０１を参照して、生成したセッション生成通知の送信先を決定する。

システム構成情報６０１には、プレゼンスサーバ１１の前段に位置する各一次ＳＬＢ１３、及び二次ＳＬＢ１４を一意に特定する識別情報、例えばそのアドレスが格納されている。一意性保証情報設定管理装置１５は、そのシステム構成情報６０１を参照することにより、セッション生成通知の送信先として各一次ＳＬＢ１３及び二次ＳＬＢ１４を設定する。

一意性保証情報生成部６２は、渡された通知がセッション削除通知であった場合、セッション削除通知に格納された一意性保証情報中のアプリケーション識別子に対応する通信プロトコルを示す種別情報を付加する。また、そのアプリケーション識別子から、一意性保証情報を生成すべき通信プロトコルを特定し、特定した通信プロトコル用の一意性保証情報を生成する。生成した一意性保証情報はセッション削除通知に格納する。それにより、図１２に示す様なセッション生成通知からシーケンス番号を削除した構成のセッション削除通知を生成し、システム構成情報６０１を参照して、生成したセッション削除通知の送信先として各一次ＳＬＢ１３及び二次ＳＬＢ１４を設定する。

エラー通知メッセージ生成部６３は、渡された通知がセッションを生成しなかった旨を示すセッション非生成通知であった場合、そのセッション非生成通知の送信先として二次ＳＬＢ１４を設定する。そのセッション非生成通知には、二次ＳＬＢ１４が対応するメッセージを特定できるように、例えばシーケンス番号が格納されている。

一意性保証情報関連通知送信部６４は、一意性保証情報生成部６２、或いはエラー通知メッセージ生成部６３から送信すべき通知を受け取り送信する。その送信により、各一次ＳＬＢ１３及び二次ＳＬＢ１４における一意性保証情報の登録、或いは削除等が行われる。

なお、本実施例１では、プレゼンスサーバ１１が送信するセッション生成通知に格納されていない通信プロトコル用の一意性保証情報を一意性保証情報設定管理装置１５に生成・追加させているが、その生成・追加を不要とさせても良い。つまり、プレゼンスサーバ１１がセッションの生成により図１２に示す様なセッション生成通知を作成し、送信すべき送信先に送信するようにしても良い。このことから、一意性保証情報設定管理装置１５は各プレゼンスサーバ１１に搭載させても良い。複数のプレゼンスサーバ１１のうちの一つに搭載させても良い。二次ＳＬＢ１４に搭載させても良い。メッセージを受信したプレゼンスサーバ１１上でのセッション生成を認識できる二次ＳＬＢ１４では、追加すべき一意性保証情報の生成、生成した一意性保証情報を含む複数の一意性保証情報の各一次ＳＬＢ１３への送信、及び複数の一意性保証情報の一意性保証ＤＢ３０１への登録等を行えるようにすれば良い。一意性保証情報設定管理装置１５を専用の装置として用意しているのは、各プレゼンスサーバ１１の負荷、及び必要な資源の増大を回避するためである。

図６及び図７は、クライアント２、プレゼンスサーバ１１、各ＳＬＢ１３及び１４、並びに一意性保証情報設定管理装置１５の動作を示すシーケンス図である。図１に示すネットワークシステムで送受信されるメッセージにより動作を示している。メッセージは、プレゼンス・サービスに係わるものは実線の矢印、一意性保証情報に係わるものは破線の矢印で表している。図６は、クライアント２が初回メッセージを送信してから一意性保証情報が各ＳＬＢ１３及び１４に登録されるまでの間のシーケンス例を示している。図７は、一意性保証情報が登録された後のシーケンス例を示している。

プレゼンスサーバシステム１を構成する複数のプレゼンスサーバ１１、ＤＢサーバ１２、複数の一次ＳＬＢ１３、二次ＳＬＢ１４、及び一意性保証情報設定管理装置１５を接続するネットワーク構成は特に限定されるものではない。図６及び図７では便宜的に、プレゼンスサーバシステム１の各構成要素はクライアント２が接続可能な通信ネットワークと接続されていると想定している。その想定から、プレゼンスサーバ１１は直接、クライアント２に返信となるメッセージを送信するものとしている。クライアント２から送信されるメッセージについては、通信プロトコルが異なっても同一のセッション識別子を格納していることを前提としている。

図６に示す様に、クライアント２は例えばＳＩＰで初回メッセージを送信する（シーケンスＳ１ａ）。送信したメッセージが初回メッセージであるため、各ＳＬＢ１３及び１４には対応する一意性保証情報（図６中「転送ルール」と表記）は登録されていない。このため、一次ＳＬＢ１３に受信された初回メッセージは二次ＳＬＢ１４に転送される（シーケンスＳ２ａ）。その後、クライアント２がＳＯＡＰでメッセージを送信すると（シーケンスＳ１ｂ）、そのメッセージも一次ＳＬＢ１３から二次ＳＬＢ１４に転送される（シーケンスＳ２ｂ）。このような一次ＳＬＢ１３から二次ＳＬＢ１４へのメッセージの転送は、一意性保証情報（転送ルール）が登録されるまでの間、クライアント２からメッセージが送信される度に行われる。

初回メッセージが転送された二次ＳＬＢ１４は、自律負荷分散により転送先のプレゼンスサーバ１１を決定してその初回メッセージを転送する（シーケンスＳ３ａ）。初回メッセージが転送されたプレゼンスサーバ１１は、セッションを生成し、セッション生成通知を一意性保証情報設定管理装置１５に送信する（シーケンスＳ４）。一意性保証情報設定管理装置１５は、受信したセッション生成通知から各ＳＬＢ１３及び１４に送信すべきセッション生成通知を生成し、各ＳＬＢ１３及び１４に送信する（シーケンスＳ５ａ〜Ｓ５ｃ）。

セッションを生成したプレゼンスサーバ１１は、初回メッセージを送信したクライアント２にメッセージを送信する（シーケンスＳ６）。一方、セッション生成通知を受信した二次ＳＬＢ１４は、メッセージキューイング部４１に格納したメッセージを一意性保証情報から特定されるプレゼンスサーバ１１に転送する（シーケンスＳ３ｂ）。それにより、二次ＳＬＢ１４は転送されたメッセージの全てを同じプレゼンスサーバ１１に転送する。

一意性保証情報の登録後は、図７に示す様に、各一次ＳＬＢ１３はクライアント２から対応するメッセージを受信すると（シーケンスＳ１１ａ或いはＳ１１ｂ）、その一意性保証情報から特定されるプレゼンスサーバ１１にそのメッセージを転送する（シーケンスＳ１２ａ或いはＳ１２ｂ）。メッセージが転送されたプレゼンスサーバ１１は、クライアント２に対しサービス提供のためのメッセージを送信する（シーケンスＳ１３）。

二次ＳＬＢ１４は、プログラム（一意性保証支援プログラム）を実行することにより、上記のようなメッセージの転送を実現させる。次に図１５〜図１７に示す各フローチャートを参照して、このプログラムの実行により実現される処理について詳細に説明する。

図１５は、メッセージ受信処理のフローチャートである。この受信処理は、一次ＳＬＢ１３或いは一意性保証情報設定管理装置１５から送信されるメッセージの受信を契機に実行される。ここでは、ＭＳＧ振分部３３ｂ、キュー監視プロセス生成部４３及び第１のキュー監視プロセス４５に着目して実行する処理を抽出し、その流れを示している。一意性保証情報設定管理装置１５から送信されるメッセージとしては、セッション生成通知のみに着目している。始めに図１５を参照して、この受信処理について詳細に説明する。

先ず、ステップＳ４１では、メッセージを受信する。続くステップＳ４２では、二次ＳＬＢ１４は受信したメッセージがセッション生成通知か否か判定する。そのメッセージが図１２に示す様な構成のセッション生成通知であった場合、判定はＹＥＳとなってステップＳ４３に移行する。そうでない場合には、判定はＮＯとなってステップＳ４７に移行する。

ステップＳ４３では、二次ＳＬＢ１４は受信したセッション生成通知に格納されている一意性保証情報を割り当てた第２のキュー監視プロセス４５を生成し、メッセージキューイング部４１に格納されているメッセージの監視を開始させる。続くステップＳ４４では、二次ＳＬＢ１４は生成したキュー監視プロセス４５を登録する。次のステップＳ４５では、二次ＳＬＢ１４は受信したセッション生成通知に対応する配送状態管理情報の配送状態は通知待ちでない状態に変更する。その次に移行するステップＳ４６では、二次ＳＬＢ１４はセッション生成通知に格納されている一意性保証情報を一意性保証ＳＢ３０１の対応するプロトコル／メッセージ別一意性保証テーブル（図１４中「振り分けテーブル」と表記）３０２に格納する。その後、この受信処理を終了する。

上記ステップＳ４３及びＳ４４の処理を実行することにより、キュー監視プロセス生成部４３が実現され、キュー監視プロセス管理部４２に図１４に示すようにプロセス番号、識別ルール識別子、及びセッション識別子の組み合わせが一つ以上、格納される。上記ステップＳ４５の処理を実行することにより、一意性保証情報関連通知受付部３９によるメッセージ配送状態管理部４４に格納された内容の更新が実現される。上記ステップＳ４６の処理は、対応するプロトコル／メッセージ別処理部３７の一意性保証情報記録部３７ａによる一意性保証情報の一意性保証ＤＢ３０１への登録を実現させる。

ステップＳ４７では、二次ＳＬＢ１４は受信したメッセージが通常メッセージ、つまり一次ＳＬＢ１３を介して転送されたクライアント２からのメッセージか否か判定する。通常メッセージを受信した場合、判定はＹＥＳとなってステップＳ４９に移行する。通常メッセージでない場合、例えばセッション削除通知、或いはセッションが生成されなかった旨を示すセッション非生成通知であった場合、判定はＮＯとなってステップＳ４８に移行する。そのステップＳ４８で対応する処理を実行した後、この受信処理を終了する。

ステップＳ４９では、二次ＳＬＢ１４は通常メッセージの通信プロトコルのプロトコル／メッセージ別一意性保証テーブル３０２にヒットするエントリが有るか否か判定する。そのプロトコル／メッセージ別一意性保証テーブル３０２に通常メッセージ中のセッション識別子を有する一意性保証情報が登録されていた場合、判定はＹＥＳとなってステップＳ５０に移行し、二次ＳＬＢ１４はその一意性保証情報に従って通常メッセージを転送した後、この受信処理を終了する。通常メッセージ中のセッション識別子を有する一意性保証情報が対応するプロトコル／メッセージ別一意性保証テーブル３０２に登録されていない場合には、判定はＮＯとなってステップＳ５１に移行する。

ステップＳ５１では、二次ＳＬＢ１４は通常メッセージに対応するセッション生成通知を一意性保証情報設定管理装置（図１５中「連携制御」と表記）１５から受信するのを待っているか否か判定する。通常メッセージの受信前に、同一のセッション識別子を格納した通常メッセージ（初回メッセージ）を自律負荷分散していた場合、その初回メッセージの配送状態管理情報がメッセージ配送状態管理部４４を実現させる記憶装置内に格納されている。その配送状態管理情報中の配送状態は、受信待ちとなっている。このことから、通常メッセージに対応する配送状態管理情報が記憶され、且つ配送状態が受信待ちとなっていた場合、判定はＹＥＳとなってステップＳ５２に移行し、二次ＳＬＢ１４は通常メッセージをメッセージキューイング部４１の最後に格納した後、この受信処理を終了する。そのような配送状態管理情報が記憶されていない、或いは配送状態が受信待ちでない場合、判定はＮＯとなってステップＳ５３に移行する。

ステップＳ５３では、二次ＳＬＢ１４は第２のキュー監視プロセス４５が有るか否か判定する。第２のキュー監視プロセス４５が存在していた場合、判定はＹＥＳとなってステップＳ５２に移行し、二次ＳＬＢ１４は通常メッセージをメッセージキューイング部４１に格納する。第２のキュー監視プロセス４５が存在していない場合には、判定はＮＯとなってステップＳ５４に移行する。

ステップＳ５４への移行は、第２のキュー監視プロセス４５が存在していない状況下で初回メッセージを二次ＳＬＢ１４が受信したことを意味する。上記したように本実施例１では、第２のキュー監視プロセス４５が存在しない状況となる場合に、消滅する第２のキュー監視プロセス４５に第１のキュー監視プロセス４５を生成させるようにしている。このことから、ステップＳ５４では、二次ＳＬＢ１４は第１のキュー監視プロセス４５が有るか否か判定する。その第１のキュー監視プロセス４５が存在しない場合、判定はＮＯとなってステップＳ４８に移行し、二次ＳＬＢ１４は第１のキュー監視プロセス４５が存在しないエラーに対応するための処理を実行する。その実行後、この受信処理を終了する。第１のキュー監視プロセス４５が存在する場合には、判定はＹＥＳとなってステップＳ５５に移行し、二次ＳＬＢ１４は第１のキュー監視プロセス４５にＣＰＵ制御権を与えることにより、その監視プロセス４５を実行させる。その後、この受信処理を終了する。

図１６は、第１のキュー監視プロセス４５が実行する処理を示すフローチャートである。ここで図１６を参照して、その処理について詳細に説明する。
先ず、ステップＳ６１では、第１のキュー監視プロセス４５は自律負荷分散により通常メッセージの転送先を決定して転送する。続くステップＳ６２では、この通常メッセージの配送状態管理情報をメッセージ配送状態管理部４４に格納する。このとき、配送状態管理情報中の配送状態は受信（通知）待ちとする。その次に移行するステップＳ６３では、第１のキュー監視プロセス４５を自ら消滅させる。それにより、一連の処理を終了させる。

図１５において、ステップＳ４２、Ｓ４９、Ｓ５０、Ｓ５２、Ｓ５３及びＳ５４の判定処理は、各プロトコル／メッセージ別処理部３３のＭＳＧ振分部３３ｂを実現させる処理に相当する。このＭＳＧ振分部３３ｂにより、メッセージキューイング部４１には第２のキュー監視プロセス４５により転送すべきメッセージのみ格納される。

図１７は、第２のキュー監視プロセス４５が実行する処理を示すフローチャートである。次に図１７を参照して、その処理について詳細に説明する。第２のキュー監視プロセス４５に割り当てられた一意性保証情報は図１７中「転送ルール」と表記している。

先ず、ステップＳ７１では、第２のキュー監視プロセス４５はメッセージキューイング部４１の参照位置として先頭をセットする。次のステップＳ７２では、参照位置に格納されたメッセージが転送ルールにマッチするか否か判定する。メッセージに転送ルールと同じセッション識別子が格納されていた場合、判定はＹＥＳとなってステップＳ７３に移行する。同じセッション識別子が格納されていない場合には、判定はＮＯとなってステップＳ８０に移行する。

ステップＳ７３では、参照位置のメッセージを転送ルールに従って転送する。続くステップＳ７４では、次のメッセージが有るか否か判定する。参照位置以降にメッセージが存在する場合、判定はＹＥＳとなってステップＳ７５に移行し、参照位置を次のメッセージの位置にセットしてから、上記ステップＳ７２に戻る。メッセージキューイング部４１の全てのメッセージを参照した場合には、判定はＮＯとなってステップＳ７６に移行する。

ステップＳ７６では、第２のキュー監視プロセス４５は一意性保証情報設定管理装置（連携制御）１５からの通知待ちか否か判定する。メッセージ配送状態管理部４４に、配送状態が受信待ちの配送状態管理情報が格納されている場合、判定はＹＥＳとなってステップＳ７７に移行し、自ら消滅させる。それにより、一連の処理を終了させる。一方、配送状態が受信待ちの配送状態管理情報が格納されていない場合には、判定はＮＯとなってステップＳ７８に移行する。

ステップＳ７８では、他の第２のキュー監視プロセス４５が有るか否か判定する。他の第２のキュー監視プロセス４５が存在する場合、判定はＹＥＳとなってステップＳ７７に移行する。それにより、自らを消滅させる。他の第２のキュー監視プロセス４５が存在しない場合には、判定はＮＯとなってステップＳ７９に移行し、第１のキュー監視プロセス４５を生成させる。その後、ステップＳ７７に移行する。

上記ステップＳ７２の判定がＮＯとなって移行するステップＳ８０では、一意性保証情報設定管理装置（連携制御）１５からの通知待ちか否か判定する。メッセージ配送状態管理部４４に、配送状態が受信待ちの配送状態管理情報が格納されている場合、判定はＹＥＳとなってステップＳ７５に移行する。そのような配送状態管理情報が格納されていない場合、判定はＮＯとなってステップＳ８１に移行する。

ステップＳ８１では、他の第２のキュー監視プロセス４５が有るか否か判定する。他の第２のキュー監視プロセス４５が存在する場合、判定はＹＥＳとなってステップＳ７５に移行する。他の第２のキュー監視プロセス４５が存在しない場合には、判定はＮＯとなってステップＳ８２に移行する。

ステップＳ８２では、参照位置のメッセージを自律負荷分散により転送する。続くステップＳ８３では、このメッセージの配送状態管理情報をメッセージ配送状態管理部４４に格納する。このとき、配送状態管理情報中の配送状態は受信（通知）待ちとする。その後、ステップＳ７５に移行する。

このようにして本実施例１では、第２のキュー監視プロセス４５にも自律負荷分散を行わせるようにしている。このため、図１５において、第２のキュー監視プロセス４５が存在している状況下では自律負荷分散を行っていない通常メッセージ、つまりステップＳ５３の判定がＹＥＳとなる通常メッセージをメッセージキューイング部４１に格納している。それにより、第１のキュー監視プロセス４５による自律負荷分散は、第２のキュー監視プロセス４５により対応できないメッセージのみを対象にして行うようにしている。そのようにしている理由は、第２のキュー監視プロセス４５は、自律負荷分散を行った結果、生成させるようにしているからである。つまり、第２のキュー監視プロセス４５を生成させる契機を作る存在を必要としているからである。このことから、キュー監視プロセス生成部４３は、二次ＳＬＢ１４の起動時等の予め定めたタイミングでのみ第１のキュー監視プロセス４５を生成する。

図１８は、本実施例１を適用可能なコンピュータのハードウェア構成の一例を示す図である。ここで図１８を参照して、二次ＳＬＢ１４として使用可能なコンピュータ、言い換えれば上記一意性保証支援プログラムを実行させることで二次ＳＬＢ１４を実現可能なコンピュータの構成について具体的に説明する。

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

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

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

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

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

図３に示す構成において、例えばクライアント発メッセージ受信部３１、クライアント発メッセージ送信部３４、サーバ発メッセージ受信部３５、サーバ発メッセージ送信部３８、及び一意性保証情報関連通知受付部３９は、ネットワーク接続装置７７、ＣＰＵ７１、メモリ７２、外部記憶装置７５及びバス７８により実現される。メッセージキューイング部４１、プロセス管理部４２、及びメッセージ配送状態管理部４４は例えばメモリ７２である。例えば一意性保証ＤＢ３０１及び一意性保証情報識別ルール３０３は、外部補助記憶装置７５、或いは記録媒体Ｍに格納され、必要に応じて全て、或いは一部がメモリ７２に読み出される。例えばメッセージ識別部３２及び３６、各プロトコル／メッセージ別処理部３３及び３７、並びにキュー監視プロセス生成部４３は、ＣＰＵ７１、メモリ７２、外部記憶装置７５及びバス７８により実現される。

なお、本実施例１では、二次ＳＬＢ１４は一次ＳＬＢ１３とは別に用意しているが、これは一次ＳＬＢ１３を通信プロトコル別に設置しているからである。２つの一次ＳＬＢ１３の代わりに一つの二次ＳＬＢ１４を用いることもできる。このことから、本実施例１による一意性保証支援装置は、一次ＳＬＢ１３に搭載させても良い。

上述のように実施例１について説明したが、実施例１によれば一意性保証情報が一意性保証テーブルに登録されていない全メッセージが二次ＳＬＢ１４経由でサーバに転送されることになる。これにより、本来は二次ＳＬＢ１４を経由せずに一次ＳＬＢ１３で振分できるメッセージが二次ＳＬＢ１４を経由で処理されるため、二次ＳＬＢ１４の処理負荷が高くなってしまうという問題もある。

そこで本実施例２では、二次ＳＬＢ１４を経由せずに処理可能なメッセージについては一次ＳＬＢ１３で処理するシステムについて述べる。
実施例２の構成のほとんどは実施例１の構成と同一であるため、同一機能については同じ符号を用いてその説明を省略する。

実施例２において、一次ＳＬＢ１３は、自身で振分できるメッセージであるか、または二次ＳＬＢ１４にメッセージの振分先サーバを決めさせるかどうかの判断を次のように行う。

まず、基本的には実施例１のように二次ＳＬＢ１４にて振分先サーバを決定させる。一次ＳＬＢ１３で決定しない理由は、ある通信プロトコル用の一次ＳＬＢ１３に初回メッセージが届いてから各通信プロトコル用の一次ＳＬＢ１３に一意性保証情報が登録されるまでの間に、同じセッションの次のメッセージ（以降、「後続メッセージ」という）が別の一次ＳＬＢ１３に届いてしまうと、その一次ＳＬＢ１３はメッセージを初回の振分先サーバとは別のサーバに振り分けてしまい、一意性が保証できなくなってしまうからである。

しかし次の場合には一次ＳＬＢ１３にて振分先サーバを決定可能である。初回メッセージを受信したサーバが、セッションを生成するとともにセッション識別子を発行する場合、クライアントは初回メッセージに対する応答をサーバから受信し、その応答メッセージによりセッション識別子を知った後でないと後続メッセージを出しようがない。よって、クライアントが初回メッセージを送信してから一意性保証情報が各通信プロトコル用の一次ＳＬＢ１３に登録されるまでの間に、クライアントから後続メッセージが届くことはない。そのため、一次ＳＬＢ１３は、メッセージ中にセッション識別子がない場合、二次ＳＬＢ１４を使わず、一次ＳＬＢ１３にて振分先サーバを決定可能と判断できる。一次ＳＬＢ１３における判断に基づき、一次ＳＬＢ１３では自身で振分先サーバを決定可能な場合には自身で振分先サーバを決定し、二次ＳＬＢ１４には転送しない。これにより二次ＳＬＢ１４の処理負荷を低減することが可能である。

上述したような処理を一次ＳＬＢ１３で行うため、一次ＳＬＢ１３のプロトコル／メッセージ処理部２３（図２）は図１９に示すフローチャートのように動作する。
尚、ここでは一意性保証情報とは、実施例１と同様に、クライアントからのメッセージを転送すべきサーバに転送するための転送ルールのことで、例えばセッション識別子とそれに対応するメッセージ転送先との対を含んで構成されるものであるとする。そして、一意性保証情報は、一意性保証テーブルに登録されて管理される。

図１９において、まずＳ１９１で、一意性保証情報識別ルール２０３を参照し、セッション識別子の位置に関する情報を取得する。そしてＳ１９２で、所得した位置の情報に基づき、メッセージ中のセッション識別子を抽出する。

次に、Ｓ１９３で、メッセージ中にセッション識別子があるか否かの判断を行う。セッション識別子がある場合（Ｙ）Ｓ１９４に進み、セッション識別子がない場合（Ｎ）Ｓ１９５に進む。

Ｓ１９５では、メッセージの転送先サーバを例えばラウンドロビンなどの自律負荷分散アルゴリズムに従い決定し、Ｓ１９８に進む。Ｓ１９８では、セッション識別子と転送先サーバの対応（一意性保証情報）を一意性保証テーブル２０２に格納する。

Ｓ１９３の後、Ｓ１９４では、振分先アプリケーションの仮想ＩＰとセッション識別子をキーとして、一意性保証テーブル２０２を検索する。検索にＨｉｔした場合（Ｙ）、Ｓ１９７に進む。検索にＨｉｔしなかった場合（Ｎ）、Ｓ１９６に進む。

Ｓ１９７では、メッセージの転送先を、一意性保証テーブル２０２に登録されていると検索されたセッション識別子に対応するサーバに決定する。Ｓ１９６では、メッセージの転送先を二次ＳＬＢ１４に決定する。

尚、図１９のフロー図の各ステップにおいて、Ｓ１９１、Ｓ１９２、Ｓ１９３は、一意性保証情報識別部２３ａが行う処理であり、Ｓ１９４、Ｓ１９５、Ｓ１９６、Ｓ１９７はＭＳＧ振分部２３ｂが行う処理であり、Ｓ１９８は一意性保証情報記録部２３ｃが行う処理である。

以下、具体的に、本実施例２を用いたサービス提供システムを用いて、システム動作等についてより詳しく説明する。
図２０に、異なる複数の通信プロトコルでサービスを提供するサービス提供システムの構成例を示す。このシステムはオンライン会議システムとプレゼンスサーバシステムの二つのサービスとを含むもので、本実施例２により構成されている。

図２０に示したサービス提供システムは、プレゼンスサーバシステム２０００と、オンライン会議サーバシステム２００１と、一次ＳＬＢ２００３、二次ＳＬＢ２００４とクライアント２００２、一意性保証情報設定管理装置２００５がネットワークで接続された構成である。

図２０中の２種類のサーバシステムである、プレゼンスサーバシステム２０００およびオンライン会議サーバシステム２００１の位置づけは次の通りである。
プレゼンスサーバシステム２０００は、実施例１と同様にクライアント２００２のユーザに、知りたい相手の状態を示すプレゼンス情報を提供するサービスを行う。相手の状態とは、例えば在席か否か、電話中か否か、多忙か否か、といったものである。

プレゼンスサーバ２００６に搭載されたサービス提供用のアプリケーション（以降「アプリ＃１」と言う）は、通信プロトコルとしてＳＩＰおよびＳＯＡＰをサポートするものとする。

プレゼンスサーバシステムのアプリケーション、すなわちアプリ＃１を使用しようとするクライアント２００２は、相手先をＳＩＰ−ＵＲＩで指定する。そして、このＳＩＰ−ＵＲＩは、相手先ユーザからの口頭通知などの任意の方法により、クライアント２００２のユーザが事前に取得可能である。このため、クライアント２００２は、ある通信プロトコル（たとえばＳＩＰ）で送信したメッセージの応答を待たずに、相手先ＳＩＰ−ＵＲＩを指定した次のメッセージをＳＩＰまたはＳＯＡＰで送信することができる。

図２１に、アプリ＃１を使用する際のメッセージ形式を示す。セッション識別子は、メッセージを送信したクライアントが相手先とするクライアントのＳＩＰ−ＵＲＩであり、図２１（ａ）のＳＩＰメッセージではヘッダ中の「To」フィールドに格納され、図２１（ｂ）のＳＯＡＰメッセージではボディ中の「presentity」パラメータとして格納される。初回メッセージを受信したサーバは、セッションを生成後、一意性保証情報設定管理装置２００５経由で、各一次ＳＬＢ２００３ａ、２００３ｂの備える一意性保証テーブルに一意性保証情報の登録を行う。

また、オンライン会議サーバシステム２００１は、クライアント２００２のユーザにオンライン会議サービスを提供する。
オンライン会議サーバ２００９に搭載されたサービス提供用のアプリケーション（以降「アプリ＃２」と言う）は、通信プロトコルとしてＳＩＰ及びＳＯＡＰをサポートするものする。

アプリ＃１とは異なり、クライアント２００２はある通信プロトコル（ここではＳＯＡＰ）で会議セッション生成要求メッセージを送信し、その応答を受信して会議セッションを特定するためのセッション識別子（session-id）を受け取らないと、後続メッセージを送信することができない。具体的には、たとえば次のように動作する。まず、オンライン会議室を生成したクライアント２００２は、オンライン会議サーバ２００９に対して会議室名をパラメータとする会議セッション生成要求をＳＯＡＰで送信する。このとき、今から会議セッションを生成するため、メッセージ中のセッション識別子はnullである。次に、オンライン会議サーバ２００９は、会議セッション生成要求メッセージ受信をトリガとして、会議セッション（実体はサーバ内の呼制御インスタンス）を生成し、セッション識別子を発行する。オンライン会議サーバ２００９はさらに、一意性保証情報設定管理装置２００５経由で、各一次ＳＬＢ２００３ａ、２００３ｂに一意性保証情報の登録を行った後、クライアント２００２に対して、このセッション識別子を格納したメッセージで応答する。その後、オンライン会議サーバ２００９は、会議室名とセッション識別子の組を、会議セッション公開Ｗｅｂサーバ（以降、「Ｗｅｂサーバ」という）２００８に通知し、Ｗｅｂサーバ２００８はセッション識別子を発行した会議室名をＷｅｂ公開する。会議室に参加したいクライアント２００２は、ＳＯＡＰの応答メッセージからセッション識別子を入手するか、Ｗｅｂサーバ２００８が公開する情報を参照して目的の会議室名に対応するセッション識別子を入手する。その後、入手したセッション識別子をＳＩＰのメッセージ中に格納し（図２２に後述）、会議室参加要求メッセージとしてオンライン会議サーバ２００９に送信する。

図２２に、アプリ＃２を使用する際のメッセージ形式を示す。セッション識別子は会議セッションのsession-idであり、図２２（ａ）のＳＩＰメッセージではヘッダ中の「Join」フィールドに格納され、図２２（ｂ）のＳＯＡＰメッセージではボディ中の「session-id」パラメータとして格納される。

なお、上記２種類のサーバシステム（２００６、２００９）は、振分対象の各アプリケーションを複数のサーバに配備することで構成されている。また、一次ＳＬＢ２００３ａ、２００３ｂは、複数サーバ上に配備されたアプリ＃１、アプリ＃２をクライアント２００２に対し仮想化してみせるものとする。すなわち、たとえば、アプリ＃１について、プロトコル別に仮想IP#1_sipと仮想IP#1_soapを割り当てる。アプリ＃１にアクセスしたいクライアント２００２は、これら仮想IP宛てにメッセージを送信する。またアプリ＃２についても同様に仮想IP#2_sipと仮想IP#2_soapを割り当てる。アプリ＃２にアクセスしたいクライアントは、これら仮想IP宛てにメッセージを送信する。一次ＳＬＢ２００３ａ、２００３ｂはメッセージの宛先IPにより、宛先のアプリケーションがアプリ＃１かアプリ＃２のいずれであるかを判断する。

以下、図２０に示したシステムの動作について説明するが、次のＡ）〜Ｃ）の３つに分けて順に説明することにする。
Ａ）運用前の静的設定
Ｂ）運用中の振分動作（クライアントがアプリ＃１宛に接続するとき）
Ｃ）運用中の振分動作（クライアントがアプリ＃２宛に接続するとき）

Ａ）運用前の静的設定
まず、一次ＳＬＢ２００３において、サーバシステム毎の仮想IPを設定する。図２０に示したシステムでは、ＳＩＰ−ＳＬＢ２００３ａにおいて、アプリ＃１の仮想IPを仮想IP#1_sip, アプリ＃２の仮想IPを仮想IP#2_sipと設定し、ＳＯＡＰ−ＳＬＢ２００３ｂにおいて、アプリ＃１の仮想IPを仮想IP#1_soap、アプリ＃２の仮想IPを仮想IP#2_soapと設定することにする。

次に、一意性保証情報識別ルール２０３を設定する。図２０に示したシステムにおける一意性保証情報識別ルール２０３の一例を図２３に示す。プロトコルの種類、メッセージ分類（仮想IP）、セッション識別子の位置の情報がテーブルに登録されて管理される。この一意性保証情報識別ルール２０３により、振分先アプリケーションの仮想IPと、メッセージ中のセッション識別子の位置の関係を設定する。

更に、ＭＳＧ振分部２３ｂ内部の自律負荷分散アルゴリズムが持つ振分先候補サーバIPを設定する。この設定の一例を、図２４に示す。振分先アプリケーションの仮想IPと、振分先候補のサーバ毎IPアドレス・リストを設定する。

Ｂ）運用中の振り分け動作（アプリ＃１宛時）
allice@ps.comをセッション識別子（session-id）とする一意性保証情報が一意性保証テーブル２０２に未登録の状態において、クライアント２００２がallice@ps.comをセッション識別子（session-id）として格納したＳＩＰおよびＳＯＡＰのメッセージを、それぞれ仮想IP#1_sip, 仮想IP#1_soap宛に、ほぼ同時に送信したとする。

クライアント２００２から、セッション識別子を含んだメッセージを受信した一次ＳＬＢ２００３、すなわちＳＩＰ−ＳＬＢ２００３ａ、ＳＯＡＰ−ＳＬＢ２００３ｂのプロトコル／メッセージ別処理部２３は、図１９に示したフローに従い、次のように処理を行う。

一意性保証情報識別部２３ａは、一意性保証情報識別ルール２０３（図２３）を参照し、上記仮想IP宛てメッセージに関するセッション識別子の位置を特定して、メッセージ中のセッション識別子を抽出する。図２３に、仮想IP#1_sip宛てのメッセージでは、セッション識別子はToフィールドに存在し、仮想IP#1_soap宛てのメッセージでは、セッション識別子はpresentityフィールドに存在することが定義されている。このセッション識別子が存在する位置情報より、セッション識別子を抽出する。（ここまでで、図１９のＳ１９１、Ｓ１９２）。

次に、図１９のＳ１９３に示したように、セッション識別子が存在するか否かが判断される。この場合、セッション識別子allice@ps.comが格納されているため、Ｓ１９４の処理に進む。

Ｓ１９４では、ＭＳＢ振分部２３ｂが、仮想IPと抽出したセッション識別子をキーとして、一意性保証テーブル２０２を検索する。図２５（ａ）に、この場合の一意性保証テーブル２０２の一例を示す。一意性保証テーブル２０２は、宛先アプリケーションの仮想IP及びセッション識別子、サーバのIPアドレスを含む一意性保証情報を管理するものである。図２５（ａ）に示した一意性保証テーブル２０２には、セッション識別子allice@ps.comを含むデータがないため、未Ｈｉｔとなり、図１９のＳ１９４からＳ１９６に進み、メッセージの転送先を二次ＳＬＢ２００４に決定する。

以上のように一次ＳＬＢ２００３が動作するが、その後、二次ＳＬＢ２００４では、一次ＳＬＢ２００３から転送されたメッセージの振り分けを行う。二次ＳＬＢ２００４からメッセージを受信したプレゼンスサーバ２００６は、セッション生成後、一意性保証情報設定管理装置２００５経由で各一次ＳＬＢ２００３の一意性保証テーブル２０２に一意性保証情報の登録を行う。

以上の動作により、クライアント２００２が異なる通信プロトコルのメッセージをほぼ同時に送信する場合であっても、二次ＳＬＢ２００４を用いて一意性を保証することが可能である。

Ｃ）運用中の振り分け動作（アプリ＃２宛時）
クライアント２００２はセッション識別子をnullとした初回メッセージを仮想IP#2_soap宛てにＳＯＡＰで送信したものとする。クライアント２００２は、セッション識別子を含む応答を受け取らないと、後続メッセージを送信することができない。

クライアント２００２から、セッション識別子を含まないメッセージを受信した一次ＳＬＢ２００３、すなわち、ＳＯＡＰ−ＳＬＢ２００３ｂのプロトコル／メッセージ別処理部２３は、図１９に示したフローに従い、次のように処理を行う。

まず、一意性保証情報識別部２３ａは、一意性保証情報識別ルール２０３（図２３）を参照し、仮想IP#2_soap宛メッセージに関するセッション識別子の位置を特定して、メッセージ中のセッション識別子を抽出する。この場合、セッション識別子は格納されていないため、図１９のＳ１９１，Ｓ１９２，Ｓ１９３を経て、Ｓ１９５に進む。

次に、ＭＳＧ振分部２３ｂが何らかの自律負荷分散アルゴリズムに従い、転送先サーバを決定する（図１９のＳ１９５）。例えば、図２４に示したテーブルの仮想IP#2_soapをキーとして参照し、振分先候補サーバIPを得た後に、ラウンドロビンアルゴリズムにより転送先サーバを１つ決定する。

その後、一意性保証情報記録部２３ｃは、セッション識別子と転送先サーバの対応を、各一次ＳＬＢ２００３内の一意性保証ＤＢ２０１の一意性保証テーブル２０２に格納する（図１９のＳ１９８）。

以上の処理を行った後に、一次ＳＬＢ（ＳＯＡＰ−ＳＬＢ２００３ｂ）は、振分先として決定したオンライン会議サーバ２００９宛に、メッセージを転送する。
一次ＳＬＢ（ＳＯＡＰ−ＳＬＢ２００３ｂ）からメッセージを受信したオンライン会議サーバ２００９は、セッションを生成し、一意性保証情報設定管理装置２００５経由で各一次ＳＬＢ２００３の一意性保証テーブル２０２に、宛先アプリケーションの仮想IPと、生成したセッションのセッション識別子(0123@kaigi.comとする)と、サーバのIPアドレスと、を含む一意性保証情報の登録を行う。一意性保証情報の登録を行った場合の一意性保証テーブル２０２の一例を図２５（ｂ）に示す。（尚、図２５（ｂ）についてであるが、プロトコルやメッセージ種別によりテーブルを分けて構成してもよい。ここでは便宜上１つのテーブルにまとめて記載した。）そしてその後、セッション識別子として、0123@kaigi.comを含めた応答をクライアント２００２に返し、更にＷｅｂサーバに会議室名とセッション識別子（session-id＝0123@kaigi.com）の対を登録する。

この後、クライアント２００２は、仮想IP#2_sip宛てにセッション識別子（session-id）0123@kaigi.comとしたＳＩＰのINVITEメッセージを送信し、会議セッションに参加する。このとき、一次ＳＬＢ２００３、すなわち、ＳＩＰ−ＳＬＢ２００３ａのプロトコル／メッセージ別処理部２３は、図１９に示したフローに従い、次のように処理を行う。

まず、一意性保証情報識別部２３ａは、一意性保証情報識別ルール２０３（図２３）を参照し、仮想IP#2_sip宛てメッセージに関するセッション識別子の位置を特定して、メッセージ中のセッション識別子を抽出する。この場合、セッション識別子0123@kaigi.comが抽出されるため、図１９のＳ１９１,Ｓ１９２，Ｓ１９３を経て、Ｓ１９４に進む。

次に、ＭＳＧ振分部２３ｂが仮想IP#2_sipとセッション識別子0123@kaigi.comをキーとして一意性保証テーブル２０２を検索する（図１９のＳ１９４）。今、一意性保証テーブル２０２は図２５（ｂ）に示したようになっているから、IPアドレスが、「ＩＰアドレス＃４」のサーバがＨｉｔし、該サーバをメッセージ転送先サーバに決定する（図１９のＳ１９７）。
そして一次ＳＬＢ（ＳＩＰ−ＳＬＢ２００３ａ）は、メッセージを決定したオンライン会議サーバ２００９に転送する。

以上のように、プロトコル毎の一次ＳＬＢにて振分先サーバを決定できるメッセージについて、二次ＳＬＢを用いずに一意性保証をすることが可能となる。その為、一意性保証テーブルにセッション識別子が未登録の全てのメッセージを二次ＳＬＢに転送する場合に比べて、二次ＳＬＢを対象とする通信路のトラフィック量を軽減可能となり、また二次ＳＬＢの処理負荷も軽減することが可能となる。

以上、本発明の実施例２について詳細に説明したが、本発明は上記実施例に記載したことに限定されないことは言うまでもない。上記実施例では、複数のプロトコルを用いて提供するサービスとして、オンライン会議システムおよびプレゼンスサーバシステムを含むシステム構成について説明をしたが、他のプロトコルでサービスを提供するシステムであっても構わない。このように、本発明の趣旨を逸脱しない範囲において様々な変更が可能である。

また、以上、実施例２について詳細に説明をしたが、本実施例２を適用可能なコンピュータのハードウェア構成は、実施例１で説明した図１８と同様である。よって、詳細な説明は省略する。特に追加するとすれば、メモリ７２および外部記憶装置７５等に格納された、図１９に示したフローのように動作するプログラムは、ＣＰＵ７１によって実行され、これにより実施例２が実現される、ということである。

以上の変形例を含む実施形態に関し、更に以下の付記を開示する。
（付記１）
複数の通信プロトコルに対応した複数のサーバのなかから、端末装置から受信したメッセージを転送すべきサーバを選択する負荷分散装置による一意性保証を実現させる支援を行う一意性保証支援装置として用いられるコンピュータに、
前記負荷分散装置が前記端末装置から受信したメッセージのなかで、前記複数のサーバのなかで転送すべきサーバが未定のメッセージを取得するメッセージ取得機能と、
記憶装置に格納されている、前記メッセージが転送されたサーバで生成されるセッションの識別情報、及び該サーバに転送すべきメッセージの対応関係を示す一意性保証情報を参照して、前記メッセージ取得機能により取得したメッセージのなかで該一意性保証情報により前記転送すべきサーバが特定されるメッセージを該転送すべきサーバに転送するメッセージ転送機能と、
前記メッセージ取得機能により取得したメッセージのなかで前記メッセージ転送機能によって転送されないメッセージを転送すべきサーバを前記複数のサーバのなかから選択して、選択された転送すべきサーバに転送する自律負荷分散機能と、
前記自律負荷分散機能によりメッセージが転送されたサーバにおいて、前記セッションの生成により得られる、前記複数の通信プロトコルそれぞれの一意性保証情報を前記記憶装置に格納する情報管理機能と、
を実現させるための一意性保証支援プログラム。
（付記２）
通信ネットワークを介してサービスを提供可能なサービス提供システムにおいて、
前記サービス提供システムは、複数の通信プロトコルを連携させた前記サービスを提供可能な複数のサーバ、前記サービスを利用するユーザが使用する端末装置から受信したメッセージを前記複数のサーバのうちの一つに転送する負荷分散装置、及び前記負荷分散装置による複数の通信プロトコルに対応した一意性保証の実現を支援する一意性保証支援装置、を備え、
前記負荷分散装置は、
第１の記憶装置に格納されている、前記メッセージが転送されたサーバで生成されるセッションの識別情報、及び該サーバに転送すべきメッセージの対応関係を示す一意性保証情報を参照して、前記端末装置から受信したメッセージのなかで該一意性保証情報により転送すべきサーバが特定されるメッセージを該転送すべきサーバに転送する第１の転送手段と、
前記第１の転送手段が転送しないメッセージを前記一意性保証支援装置に転送する第２の転送手段と、
前記メッセージが転送されたサーバでの前記セッションの生成により得られる、前記複数の通信プロトコルそれぞれの一意性保証情報を前記第１の記憶装置に格納する第１の情報管理手段と、を具備し、
前記一意性保証支援装置は、
前記負荷分散装置から転送されたメッセージを受信する受信手段と、
第２の記憶装置に格納されている、前記メッセージが転送されたサーバにおいて、生成されるセッションの識別情報、及び該サーバに転送すべきメッセージの対応関係を示す一意性保証情報を参照して、前記受信手段が受信したメッセージのなかで該一意性保証情報により前記転送すべきサーバが特定されるメッセージを該転送すべきサーバに転送するメッセージ転送手段と、
前記受信手段が受信したメッセージのなかで前記メッセージ転送手段によって転送されないメッセージを転送すべきサーバを前記複数のサーバのなかから選択して、選択された転送すべきサーバに転送する自律負荷分散手段と、
前記自律負荷分散手段がメッセージを転送したサーバにおいて、前記セッションの生成により得られる、前記複数の通信プロトコルそれぞれの一意性保証情報を前記第２の記憶装置に格納する情報管理手段と、を具備し、
前記端末装置から送信されたメッセージのなかで対応する一意性保証情報が前記負荷分散装置に格納されていない対象メッセージは、前記一意性保証支援装置に転送して、前記複数のサーバのなかから転送すべきサーバを選択させ、該転送すべきサーバに全て転送させる、
ことを特徴とするサービス提供システム。
（付記３）
前記サービス提供システムは、前記一意性保証支援装置がメッセージを転送したサーバにおいて、前記セッションの生成により得られる一意性保証情報を取得し、該一意性保証情報を前記負荷分散装置、及び前記一意性保証支援装置に送信する一意性保証情報設定管理装置、を更に備え、
前記一意性保証情報設定管理装置は、前記メッセージの転送により前記セッションを生成したサーバから該メッセージの通信プロトコル分の一意性保証情報を受信し、該通信プロトコルとは異なる他の通信プロトコル分の一意性保証情報を生成することにより、複数の通信プロトコル分の一意性保証情報を前記負荷分散装置、及び前記一意性保証支援装置に通知する、
ことを特徴とする付記２記載のサービス提供システム。
（付記４）
前記一意性保証支援装置からメッセージが転送されたサーバは、該メッセージに格納されているメッセージ間の識別が可能な識別情報を用いて、該メッセージの通信プロトコル分の一意性保証情報を生成し、
前記一意性保証情報設定管理装置は、前記サーバが生成した一意性保証情報中の識別情報を用いて、前記他の通信プロトコル分の一意性保証情報を生成する、
ことを特徴とする付記３記載のサービス提供システム。
（付記５）
複数の通信プロトコルでそれぞれサービスを提供可能な複数のサーバのなかの一つに端末装置から送信されたメッセージを負荷分散装置により転送させる場合に、複数の通信プロトコル間の連携に対応した一意性保証を実現させる方法であって、
前記複数のサーバのなかで転送すべきサーバが未定の第１のメッセージを前記端末装置から前記負荷分散装置が受信した場合に、該第１のメッセージを転送すべきサーバを選択して転送する第１の転送工程と、
前記第１の転送工程により前記第１のメッセージを転送した後、該第１のメッセージと同じサーバに転送すべき第２のメッセージを前記負荷分散装置が前記端末装置から受信した場合に、該第２のメッセージを保存する保存工程と、
前記第１の転送工程により前記第１のメッセージが転送されたサーバがセッションを生成した場合に、該セッションと該セッションに対応するメッセージの対応関係を示す一意性保証情報を該セッションが対応する複数の通信プロトコル分、生成する生成工程と、
前記保存工程で保存した前記第２のメッセージが存在する場合に、前記生成工程により生成された各一意性保証情報に従って該第２のメッセージを転送する第２の転送工程と、
を含むことを特徴とする一意性保証実現方法。
（付記６）
前記端末装置は、前記複数の通信プロトコル間の連携を必要とするメッセージに同一の識別情報を格納して送信し、
前記保存工程は、前記第１のメッセージと同一の識別情報を格納したメッセージを前記第２のメッセージと認識する、
ことを特徴とする付記５記載の一意性保証実現方法。
（付記７）
複数の通信プロトコルでサービスを提供するサーバ群の中から、端末装置から受信したメッセージを転送すべきサーバを決定する負荷分散装置を構成するコンピュータによって実行されるプログラムであって、
前記受信したメッセージ中にセッション識別子が有るか否かを判断するステップと、
前記メッセージ中にセッション識別子が無いと判断された場合には、メッセージ転送先サーバを自律分散アルゴリズムにより決定するステップと、
前記メッセージ中にセッション識別子が有ると判断された場合には、該メッセージに対応する一意性保証情報が一意性保証テーブルに登録されているか否かを判断し、登録されている場合には対応する一意性保証情報に基づいてメッセージ転送先サーバを決定し、登録されていない場合には第二の負荷分散装置にメッセージを転送することを決定するステップと、
を含むことを特徴とするプログラム。
（付記８）
前記第二の負荷分散装置は、前記負荷分散装置から転送されたメッセージの転送先サーバを決定し転送し、その後、該転送したメッセージと同じサーバに転送すべきメッセージを受信した場合には、前記一意性保証テーブルに対応する一意性保証情報が登録されるまで該メッセージをキューイングする機能を備えることを特徴とする付記７記載のプログラム。
（付記９）
複数の通信プロトコルでサービスを提供するサーバ群の中から、端末装置から受信したメッセージを転送すべきサーバを決定する負荷分散装置であって、
前記受信したメッセージ中にセッション識別子が有るか否かを判断する一意性保証情報識別部と、
前記一意性保証情報識別部にて前記受信したメッセージ中にセッション識別子が無いと判断された場合には、メッセージ転送先サーバを自律分散アルゴリズムにより決定し、該一意性保証情報識別部にて前記受信したメッセージ中にセッション識別子が有ると判断された場合には、セッション識別子と前記サーバ群のいずれのサーバにメッセージを転送すべきかの対応関係を規定した一意性保証テーブルを参照し、該一意性保証テーブルに該メッセージ中のセッション識別子が有る場合には該一意性保証テーブルに基づいてメッセージ転送先サーバを決定し、該一意性保証テーブルに該メッセージ中のセッション識別子が無い場合には、第二の負荷分散装置にメッセージを転送することを決定するＭＳＧ振分部と、
を含むことを特徴とする負荷分散装置。
（付記１０）
更に、前記ＭＳＧ振分部でメッセージ転送先サーバを自律分散アルゴリズムにより決定した場合に、転送先サーバが発行するセッション識別子と該転送先サーバとの対応を前記一意性保証テーブルに登録する一意性保証情報記録部を備えることを特徴とする付記９記載の負荷分散装置。
（付記１１）
複数の通信プロトコルでサービスを提供するサーバ群の中から、端末装置から受信したメッセージを転送すべきサーバを決定する負荷分散装置におけるメッセージ転送先決定方法であって、
前記受信したメッセージ中にセッション識別子が有るか否かを判断し、
前記メッセージ中にセッション識別子が無いと判断された場合には、メッセージ転送先サーバを自律分散アルゴリズムにより決定し、
前記メッセージ中にセッション識別子が有ると判断された場合には、該メッセージに対応する一意性保証情報が一意性保証テーブルに登録されているか否かを判断し、登録されている場合には対応する一意性保証情報に基づいてメッセージ転送先サーバを決定し、登録されていない場合には第二の負荷分散装置にメッセージを転送することを決定する、
ことを特徴とするメッセージ転送先決定方法。
（付記１２）
複数の通信プロトコルでサービスを提供するサーバ群と、該サーバ群が提供するサービスを利用するユーザが使用する端末装置と、該端末装置から受信したメッセージの転送先を決定する負荷分散装置と、該負荷分散装置から転送されるメッセージを転送処理する機能を備える第二の負荷分散装置を含むサービス提供システムにおいて、
前記負荷分散装置は、
前記受信したメッセージ中にセッション識別子が有るか否かを判断する一意性保証情報識別部と、
前記一意性保証情報識別部にて前記受信したメッセージ中にセッション識別子が無いと判断された場合には、メッセージ転送先サーバを自律分散アルゴリズムにより決定し、該一意性保証情報識別部にて前記受信したメッセージ中にセッション識別子が有ると判断された場合には、セッション識別子と前記サーバ群のいずれのサーバにメッセージを転送すべきかの対応関係を規定した一意性保証テーブルを参照し、該一意性保証テーブルに該メッセージ中のセッション識別子が有る場合には該一意性保証テーブルに基づいてメッセージ転送先サーバを決定し、該一意性保証テーブルに該メッセージ中のセッション識別子が無い場合には、第二の負荷分散装置にメッセージを転送することを決定するＭＳＧ振分部と、
を含むことを特徴とするサービス提供システム。

１ プレゼンスサーバシステム
２ クライアント（端末装置）
１１ プレゼンスサーバ
１２ ＤＢサーバ
１３ 一次ＳＬＢ
１４ 二次ＳＬＢ
１５ 一意性保証情報設定管理装置
３１ クライアント発メッセージ受信部
３２、３６ メッセージ識別部
３３、３７ プロトコル／メッセージ別処理部
３４ クライアント発メッセージ送信部
３５ サーバ発メッセージ受信部
３８ サーバ発メッセージ送信部
３９ 一意性保証情報関連通知受付部
４１ メッセージキューイング部
４２ キュー監視プロセス管理部
４３ キュー監視プロセス生成部
４４ メッセージ配送状態管理部
３０１ 一意性保証ＤＢ
３０２ プロトコル／メッセージ別一意性保証テーブル
３０３ 一意性保証情報識別ルール

Claims (9)

1. 複数の通信プロトコルに対応した複数のサーバのなかから、端末装置から受信したメッセージを転送すべきサーバを選択する負荷分散装置による一意性保証を実現させる支援を行う一意性保証支援装置として用いられるコンピュータに、
   前記負荷分散装置が前記端末装置から受信したメッセージのなかで、前記複数のサーバのなかで転送すべきサーバが未定のメッセージを取得するメッセージ取得機能と、
   前記一意性保証支援装置が備える記憶装置に格納されている、前記メッセージが転送されたサーバで生成されるセッションの識別情報、及び該サーバに転送すべきメッセージの対応関係を示す一意性保証情報を参照して、前記メッセージ取得機能により取得したメッセージのなかで該一意性保証情報により前記転送すべきサーバが特定されるメッセージを該転送すべきサーバに転送するメッセージ転送機能と、
   前記メッセージ取得機能により取得したメッセージのなかで前記メッセージ転送機能によって転送されないメッセージを、転送すべきサーバを前記複数のサーバのなかから選択して、選択された転送すべきサーバに転送する自律負荷分散機能と、
   前記自律負荷分散機能によりメッセージが転送されたサーバにおける、前記セッションの生成により得られる、前記複数の通信プロトコルそれぞれの一意性保証情報を前記記憶装置に格納する情報管理機能と、
   を実現させるための一意性保証支援プログラム。
2. 通信ネットワークを介してサービスを提供可能なサービス提供システムにおいて、
   前記サービス提供システムは、複数の通信プロトコルを連携させた前記サービスを提供可能な複数のサーバ、前記サービスを利用するユーザが使用する端末装置から受信したメッセージを前記複数のサーバのうちの一つに転送する負荷分散装置、及び前記負荷分散装置による複数の通信プロトコルに対応した一意性保証の実現を支援する一意性保証支援装置、を備え、
   前記負荷分散装置は、
   第１の記憶装置に格納されている、前記メッセージが転送されたサーバで生成されるセッションの識別情報、及び該サーバに転送すべきメッセージの対応関係を示す一意性保証情報を参照して、前記端末装置から受信したメッセージのなかで該一意性保証情報により転送すべきサーバが特定されるメッセージを該転送すべきサーバに転送する第１の転送手段と、
   前記第１の転送手段が転送しないメッセージを前記一意性保証支援装置に転送する第２の転送手段と、
   前記メッセージが転送されたサーバにおいて、前記セッションの生成により得られる、前記複数の通信プロトコルそれぞれの一意性保証情報を前記第１の記憶装置に格納する第１の情報管理手段と、を具備し、
   前記一意性保証支援装置は、
   前記負荷分散装置から転送されたメッセージを受信する受信手段と、
   第２の記憶装置に格納されている、前記メッセージが転送されたサーバで生成されるセッションの識別情報、及び該サーバに転送すべきメッセージの対応関係を示す一意性保証情報を参照して、前記受信手段が受信したメッセージのなかで該一意性保証情報により前記転送すべきサーバが特定されるメッセージを、該転送すべきサーバに転送するメッセージ転送手段と、
   前記受信手段が受信したメッセージのなかで前記メッセージ転送手段により転送されないメッセージを転送すべきサーバを前記複数のサーバのなかから選択して、選択された転送すべきサーバに転送する自律負荷分散手段と、
   前記自律負荷分散手段がメッセージを転送したサーバにおいて、前記セッションの生成により得られる、前記複数の通信プロトコルそれぞれの一意性保証情報を前記第２の記憶装置に格納する情報管理手段と、を具備し、
   前記端末装置から送信されたメッセージのなかで対応する一意性保証情報が前記負荷分散装置に格納されていない対象メッセージは、前記一意性保証支援装置に転送して、前記複数のサーバのなかから転送すべきサーバを選択させ、選択された転送すべきサーバに全て転送させる、
   ことを特徴とするサービス提供システム。
3. 前記サービス提供システムは、前記一意性保証支援装置がメッセージを転送したサーバにおいて前記セッションの生成により得られる一意性保証情報を取得し、該一意性保証情報を、前記負荷分散装置及び前記一意性保証支援装置に送信する一意性保証情報設定管理装置、を更に備え、
   前記一意性保証情報設定管理装置は、前記メッセージの転送により前記セッションを生成したサーバから該メッセージの通信プロトコル分の一意性保証情報を受信し、該通信プロトコルとは異なる他の通信プロトコル分の一意性保証情報を生成することにより、複数の通信プロトコル分の一意性保証情報を、前記負荷分散装置及び前記一意性保証支援装置に通知する、
   ことを特徴とする請求項２記載のサービス提供システム。
4. 前記一意性保証支援装置からメッセージが転送されたサーバは、該メッセージに格納されているメッセージ間の識別が可能な識別情報を用いて、該メッセージの通信プロトコル分の一意性保証情報を生成し、
   前記一意性保証情報設定管理装置は、前記サーバが生成した一意性保証情報中の識別情報を用いて、前記他の通信プロトコル分の一意性保証情報を生成する、
   ことを特徴とする請求項３記載のサービス提供システム。
5. 複数の通信プロトコルでそれぞれサービスを提供可能な複数のサーバのなかの一つに端末装置から送信されたメッセージを負荷分散装置により転送させる場合に、複数の通信プロトコル間の連携に対応した一意性保証を実現させる方法であって、
   前記複数のサーバのなかで転送すべきサーバが未定の第１のメッセージを前記端末装置から前記負荷分散装置が受信した場合に、該第１のメッセージを転送すべきサーバを選択して転送する第１の転送工程と、
   前記第１の転送工程により前記第１のメッセージを転送した後、該第１のメッセージと同じサーバに転送すべき第２のメッセージを前記負荷分散装置が前記端末装置から受信した場合に、該第２のメッセージを保存する保存工程と、
   前記第１の転送工程により前記第１のメッセージが転送されたサーバがセッションを生成した場合に、該セッションと該セッションに対応するメッセージの対応関係を示す一意性保証情報を該セッションが対応する複数の通信プロトコル分、生成する生成工程と、
   前記保存工程で保存した前記第２のメッセージが存在する場合に、前記生成工程により生成された各一意性保証情報に従って該第２のメッセージを転送する第２の転送工程と、
   を含むことを特徴とする一意性保証実現方法。
6. 複数の通信プロトコルでサービスを提供するサーバ群の中から、端末装置から受信したメッセージを転送すべきサーバを決定する負荷分散装置を構成するコンピュータによって実行されるプログラムであって、
   前記受信したメッセージ中にセッション識別子が有るか否かを判断するステップと、
   前記メッセージ中にセッション識別子が無いと判断された場合には、メッセージ転送先サーバを自律負荷分散アルゴリズムにより決定し、前記メッセージ中にセッション識別子が有ると判断された場合には、該メッセージに対応する一意性保証情報が一意性保証テーブルに登録されているか否かを判断し、登録されている場合には対応する一意性保証情報に基づいてメッセージ転送先サーバを決定し、登録されていない場合には第二の負荷分散装置にメッセージを転送することを決定するステップと、
   を含むことを特徴とするプログラム。
7. 複数の通信プロトコルでサービスを提供するサーバ群の中から、端末装置から受信したメッセージを転送すべきサーバを決定する負荷分散装置であって、
   前記受信したメッセージ中にセッション識別子が有るか否かを判断する一意性保証情報識別部と、
   前記一意性保証情報識別部にて前記受信したメッセージ中にセッション識別子が無いと判断された場合には、メッセージ転送先サーバを自律負荷分散アルゴリズムにより決定し、該一意性保証情報識別部にて前記受信したメッセージ中にセッション識別子が有ると判断された場合には、セッション識別子と前記サーバ群のいずれのサーバにメッセージを転送すべきかの対応関係を規定した一意性保証テーブルを参照し、該一意性保証テーブルに該メッセージ中のセッション識別子が有る場合には該一意性保証テーブルに基づいてメッセージ転送先サーバを決定し、該一意性保証テーブルに該メッセージ中のセッション識別子が無い場合には、第二の負荷分散装置にメッセージを転送することを決定するＭＳＧ振分部と、
   を含むことを特徴とする負荷分散装置。
8. 複数の通信プロトコルでサービスを提供するサーバ群の中から、端末装置から受信したメッセージを転送すべきサーバを決定する負荷分散装置におけるメッセージ転送先決定方法であって、
   前記受信したメッセージ中にセッション識別子が有るか否かを判断し、
   前記メッセージ中にセッション識別子が無いと判断された場合には、メッセージ転送先サーバを自律負荷分散アルゴリズムにより決定し、前記メッセージ中にセッション識別子が有ると判断された場合には、該メッセージに対応する一意性保証情報が一意性保証テーブルに登録されているか否かを判断し、登録されている場合には対応する一意性保証情報に基づいてメッセージ転送先サーバを決定し、登録されていない場合には第二の負荷分散装置にメッセージを転送することを決定する、
   ことを特徴とするメッセージ転送先決定方法。
9. 複数の通信プロトコルでサービスを提供するサーバ群と、該サーバ群が提供するサービスを利用するユーザが使用する端末装置と、該端末装置から受信したメッセージの転送先を決定する負荷分散装置と、該負荷分散装置から転送されるメッセージを転送処理する機能を備える第二の負荷分散装置を含むサービス提供システムにおいて、
   前記負荷分散装置は、
   前記受信したメッセージ中にセッション識別子が有るか否かを判断する一意性保証情報識別部と、
   前記一意性保証情報識別部にて前記受信したメッセージ中にセッション識別子が無いと判断された場合には、メッセージ転送先サーバを自律負荷分散アルゴリズムにより決定し、該一意性保証情報識別部にて前記受信したメッセージ中にセッション識別子が有ると判断された場合には、セッション識別子と前記サーバ群のいずれのサーバにメッセージを転送すべきかの対応関係を規定した一意性保証テーブルを参照し、該一意性保証テーブルに該メッセージ中のセッション識別子が有る場合には該一意性保証テーブルに基づいてメッセージ転送先サーバを決定し、該一意性保証テーブルに該メッセージ中のセッション識別子が無い場合には、第二の負荷分散装置にメッセージを転送することを決定するＭＳＧ振分部と、
   を含むことを特徴とするサービス提供システム。