JP2013157748A - サービスバスシステム、サービスバス装置及び接続一意性保証方法 - Google Patents

Abstract

【課題】サービスバスシステムにおいて、接続情報データベースのアクセスを削減する。
【解決手段】クライアントに接続される複数の第１装置と、サービスを実行する複数の第２装置との間を複数のサービスバス装置のいずれかを用いて接続するサービスバスシステムにおいて、第１装置と第２装置との間をセッションの最初のシーケンスで接続する際に、セッションと同一セッション内の２番目以降のシーケンスで第１装置と第２装置との間を接続する１つ以上の他のサービスバス装置を予測し、予測された他のサービスバス装置に送信し、他のサービスバス装置から送信されたセッションの第１装置と第２装置との接続情報を保持し、同一セッション内の２番目以降のシーケンスを受信したサービスバス装置にセッションの第１装置と第２装置との接続情報があれば、該接続情報を用いて２番目以降のシーケンスで第１装置と第２装置との間を接続する。
【選択図】図６

Description

本発明は、サービスバスシステム、サービスバス装置及び接続一意性保証方法に関する。

ある業務システムを構築する際のソフトウェア資産を有効活用するために、ＳＯＡ（Ｓｅｒｖｉｃｅ−Ｏｒｉｅｎｔｅｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）という概念がある。ＳＯＡは、ビジネスプロセスの構成単位に合わせて構築され整理されたソフトウェア部品や機能をネットワーク上に公開（これを「アプリケーション」と呼ぶ）し、これらを相互に連携させることにより、柔軟なエンタープライズ・システム、企業間ビジネスプロセス実行システムを構築しようというシステムアーキテクチャのことである。

更に、ＳＯＡで公開されたソフトウェア部品を効率良く繋ぐための基盤として、ＥＳＢ（Ｅｎｔｅｒｐｒｉｓｅ Ｓｅｒｖｉｃｅ Ｂｕｓ）に代表されるサービスバスという概念がある。ＳＯＡの概念では、サービス化されたソフトウェア資産にアクセスするために、アクセス元のエンタープライズ・システム等のシナリオからアクセス先のプロトコルやＩＰアドレス等の位置を把握しておく必要があり、これを行うものがサービスバスである。

図１にサービスバスの概念を示す。図１において、シナリオ１，２はネットワークを介してサービスバス５に接続され、また、アプリケーション３，４はネットワークを介してサービスバス５に接続されている。シナリオ１，２からアプリケーション３，４にアクセスしようとした場合、シナリオ１，２は自分のアクセスしたいプロトコルやデータ形式でサービスバス５にアクセスするだけで良く、アプリケーション３，４のプロトコルや位置を知らなくて良いため、効率的にシナリオ１，２を開発できる。サービスバス５は、プロトコル変換機能、データ変換機能を有し、サービスバス内の共通プロトコル通信を行うことで、上記の機能を実現している。

図２にネットワークサービスを行うサービスバスシステムの一例の構成図を示す。サービスバスシステム１０はサービスシナリオ１１ａ〜１１ｃと、ロードバランサ１２と、サービスバス１３−１〜１３−ｎと、アプリケーション１４ａ〜１４ｄを有している。サービスシナリオ１１ａ〜１１ｃは例えばネットワーク電話帳サービス、音声翻訳サービス、声の宅配サービスなどである。アプリケーション１４ａ〜１４ｄは例えば位置情報アプリケーション、翻訳アプリケーション、３ＰＣＣ（３ｒｄ Ｐａｒｔｙ Ｃａｌｌ Ｃｏｎｔｒｏｌ）アプリケーション、グループウェアなどである。

サービスバスシステム１０は各サービスシナリオ１１ａ〜１１ｃからサービスバス１３−１〜１３−ｎを経由してバックエンドのアプリケーション１４ａ〜１４ｄを連携させて、サービスシナリオ１１ａ〜１１ｃに接続したユーザ機器１５ａ，１５ｂ，１５ｃ等にサービスの提供を行う。このような構成で実現されるサービスバスシステム１０においては、性能分散のためサービスバス１３−１〜１３−ｎは数台〜数千台程度が分散配置され、ロードバランサ１２によって接続単位でサービスバス１３−１〜１３−ｎへの振り分けが発生する。

ここで、図３に示すように、サービスシナリオ１１ａとアプリケーション１４ａ−１との間のセッションでは、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）等のプロトコルが状態遷移を持つために１つのセッションで複数シーケンスが発生する場合がある。すなわち、第１シーケンスはサービスシナリオ１１ａからアプリケーション１４ａ−１への初回リクエストであり、ロードバランサ１２によりサービスバス１３−１が選択されている。第２シーケンスはアプリケーション１４ａ−１からサービスシナリオ１１ａへの応答あり、ロードバランサ１２によりサービスバス１３−２が選択されている。第３シーケンスはサービスシナリオ１１ａからアプリケーション１４ａ−１への追加リクエストあり、ロードバランサ１２によりサービスバス１３−３が選択されている。第４シーケンスはアプリケーション１４ａ−１からサービスシナリオ１１ａへの応答あり、ロードバランサ１２によりサービスバス１３−４が選択されている。

このような同一セッション内の各シーケンスではサービスシナリオとアプリケーションの接続の一意性を保証する必要がある。従来は同一セッション内の接続一意性保証を行う場合、サービスバス１３−１〜１３−ｎに共通の接続情報データベース１６を設け、サービスバス１３−１〜１３−ｎ間で、接続情報データベース１６により同一セッションの接続情報を共有している。

すなわち、各サービスバス１３−１〜１３−ｎはサービスシナリオ１１ａ〜１１ｃからセッション開始の要求があると、セッションＩＤと、要求を行ったサービスシナリオの装置情報と、要求を処理するアプリケーションの装置情報を、接続情報として接続情報データベース１６に登録する。その後、各サービスバス１３−１〜１３−ｎでアプリケーションから応答などを受信したとき、又は、サービスシナリオからの要求等を受信したとき、サービスバス１３−１〜１３−ｎは受信した応答や要求のセッションＩＤを用いて接続情報データベース１６を検索して接続情報を読み出し、この接続情報から当該応答や要求の送信先のアプリケーションやサービスシナリオを決定する。

ところで、追加するサービスバスに接続先である既存のサービスバスのノード識別子と位置を入力して、追加するサービスバスにおける自サービスバス及び隣接サービスバスの識別子と位置を保存するバスノードテーブルに既存のサービスバスのノード識別子と位置を登録する。そして、追加するサービスバスから既存のサービスバスにバスノードテーブル更新通知を行い、バスノードテーブル更新通知により既存のサービスバスのバスノードテーブルに追加するサービスバスのノード識別子と位置を登録する。これにより、複数サービスバスの連携を可能とする技術が提案されている（例えば特許文献１参照）。

また、優先度情報記憶手段がクライアントからの新規セッションの接続要求に応答して振分先サーバが該新規セッション毎に割り当てるセッション識別子に対し優先度情報を対応付けて記憶すると共に各優先度情報に対応した通信品質を記憶する。そして、転送手段が該クライアント又は該サーバからパケットを受信したとき、該パケットを該優先度情報に基づく通信品質で転送することで、サービス提供者の希望に応じたクライアントに対する優先制御を可能にする技術が提案されている（例えば特許文献２参照）。

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

サービスバス自体は分散構成をとっているにも拘わらず接続一意性保証のために、接続情報データベース１６のアクセスに局所集中が発生する。サービストラヒック及びサービスバス１３−１〜１３−ｎの台数規模が小さい場合は、接続情報データベース１６の登録及び検索の負荷は全体に対して小さいと考えられる。しかし、サーバ規模が数百台〜数千台程度の超大規模構成になると接続情報が膨大な数となる。したがって、接続情報データベース１６に対し数百台〜数千台のサービスバスが接続情報を登録し、また、接続情報を検索するため、接続情報データベース１６を検索するためのトラヒックが輻輳し、接続情報データベース１６検索のオーバヘッドが増大するため、システム全体の性能に対してボトルネックとなるという問題があった。

例えば数百台のサービスバス１３−１〜１３−ｎそれぞれが１秒に１トランザクションを処理するとすれば、接続情報の登録及び検索を含め最大で１秒間に数百〜数千回、接続情報データベース１６をアクセスする。接続情報データベース１６に一定期間（数時間〜数日）だけ接続情報を保持するものとすれば、１時間あたりでも数百万オーダーのデータ量となり、検索に要するオーバヘッドが膨大になる。

開示のサービスバスシステムは、接続情報データベースのアクセスを削減することを目的とする。

開示の一実施形態によるサービスバスシステムは、クライアントに接続される複数の第１装置と、サービスを実行する複数の第２装置との間を複数のサービスバス装置のいずれかを用いて接続するサービスバスシステムにおいて、
前記第１装置と前記第２装置との間をセッションの最初のシーケンスで接続する際に、前記セッションと同一セッション内の２番目以降のシーケンスで前記第１装置と前記第２装置との間を接続する１つ以上の他のサービスバス装置を予測する予測手段と、
前記セッションの前記第１装置と前記第２装置との接続情報を前記予測手段で予測された前記１つ以上の他のサービスバス装置に送信する送信手段と、
他のサービスバス装置の前記送信手段から送信された前記セッションの前記第１装置と前記第２装置との接続情報を保持する記憶手段と、
前記同一セッション内の２番目以降のシーケンスを受信したサービスバス装置の前記記憶手段に前記セッションの前記第１装置と前記第２装置との接続情報があれば、前記記憶手段の接続情報を用いて前記２番目以降のシーケンスで前記第１装置と前記第２装置との間を接続する接続手段と、を有する

本実施形態によれば、接続情報データベースのアクセスを削減することができる。

サービスバスの概念を示す図である。 サービスバスシステムの一例の構成図である。 接続一意性保証を説明するための図である。 サービスバスシステムの一実施形態のハードウェア構成図である。 サービスバス装置の一実施形態の機能構成図である。 接続情報のデータ構造の一実施形態を示す図である。 バスリストのデータ構造の一実施形態を示す図である。 サービスログのデータ構造の一実施形態を示す図である。 装置間メッセージのデータ構造の一実施形態を示す図である。 選択予測処理の一実施形態のフローチャートである。 接続一意性保証動作を説明するための図である。 サービスバス数予測処理の一実施形態のフローチャートである。 静的負荷分散予測を説明するための図である。 動的負荷分散予測を説明するための図である。 動的負荷分散予測を説明するための図である。 動的負荷分散予測の動作シーケンスである。

以下、図面に基づいて実施形態を説明する。

＜サービスバスシステムのハードウェア構成＞
図４はネットワークサービスを行うサービスバスシステムの一実施形態のハードウェア構成図を示す。図４において、サービスバスシステム２０は、サービスシナリオ実行装置２１−１〜２１−ｉと、ロードバランサ２２と、サービスバス装置２３−１〜１３−ｎと、アプリケーション実行装置２４−１〜２４−ｊと、接続情報データベース装置２６と、バス負荷監視装置２７を有している。なお、サービスシナリオ実行装置２１−１〜２１−ｉは第１装置の一例であり、アプリケーション実行装置２４−１〜２４−ｊは第２装置の一例である。

サービスシナリオ実行装置２１−１〜２１−ｉそれぞれは、ハードウェア構成として、通信装置３１、ＣＰＵ３２、メモリ３３、補助記憶装置３４、電源部３５を有している。通信装置３１は図示しないネットワークを介してサービスクライアントとしてのユーザ端末２８，２９に接続されると共に、ロードバランサ２２、サービスバス装置２３−１〜１３−ｎそれぞれの通信装置と接続される。ＣＰＵ３２はメモリ３３又は補助記憶装置３４に格納されているプログラムを実行することで、例えばネットワーク電話帳サービス、音声翻訳サービス、声の宅配サービスなどのサービスシナリオを実行する。また、電源部３５はサービスシナリオ実行装置の各部に電源を供給する。

ロードバランサ２２は、ハードウェア構成として、通信装置４１、ＣＰＵ４２、メモリ４３、補助記憶装置４４、電源部４５を有している。通信装置４１はサービスシナリオ実行装置２１−１〜２１−ｉ、サービスバス装置２３−１〜１３−ｎ、アプリケーション実行装置２４−１〜２４−ｊそれぞれの通信装置と接続される。ＣＰＵ４２はメモリ４３又は補助記憶装置４４に格納されているプログラムを実行することで、サービスシナリオ実行装置２１−１〜２１−ｉ又はアプリケーション実行装置２４−１〜２４−ｊのいずれかから受信した要求又は応答をサービスバス装置２３−１〜１３−ｎに割り振ってサービスバス装置２３−１〜１３−ｎの負荷を分散させる処理を実行する。また、電源部４５はロードバランサの各部に電源を供給する。

サービスバス装置２３−１〜１３−ｎは、ハードウェア構成として、通信装置５１、ＣＰＵ５２、メモリ５３、補助記憶装置５４、電源部５５を有している。通信装置５１はサービスシナリオ実行装置２１−１〜２１−ｉ、ロードバランサ２２それぞれの通信装置と接続されており、接続情報送信部９３，接続情報受信部９４，接続情報フィードバック部９６としての機能を有する。ＣＰＵ４２はメモリ５３又は補助記憶装置５４に格納されているプログラムを実行することで、サービスバス装置選択予測部９１，一意接続実施部９５，予測精度操作部９７として機能すると共に、プロトコル変換処理、データ変換処理、共通プロトコル通信処理などを実行する。メモリ５３には接続情報キャッシュ９２が設けられ、補助記憶装置５４にはバスリスト９８とサービスログ９９が設けられ、この他にサービスバスデフォルト設定データが格納される。また、電源部５５はサービスバス装置の各部に電源を供給する。

アプリケーション実行装置２４−１〜２４−ｊは、ハードウェア構成として、通信装置６１、ＣＰＵ６２、メモリ６３、補助記憶装置６４、電源部６５を有している。通信装置６１はサービスバス装置２３−１〜１３−ｎ、ロードバランサ２２それぞれの通信装置と接続される。また、通信装置６１は外部装置６６等にも接続される。ＣＰＵ６２はメモリ６３又は補助記憶装置６４に格納されているアプリケーションプログラムを実行することで、位置情報処理、翻訳処理、３ＰＣＣ処理、グループウェア処理などを実行する。また、電源部６５はサービスバス装置の各部に電源を供給する。

接続情報データベース装置２６は、ハードウェア構成として、通信装置７１、ＣＰＵ７２、メモリ７３、補助記憶装置７４、電源部７５を有している。通信装置７１はサービスバス装置２３−１〜１３−ｎそれぞれの通信装置と接続される。ＣＰＵ７２はメモリ７３又は補助記憶装置７４に格納されているプログラムを実行することで、接続情報データベースの登録、検索、更新等の処理を実行する。接続情報は補助記憶装置７４に格納される。また、電源部７５は接続情報データベース装置の各部に電源を供給する。

バス負荷監視装置２７は、ハードウェア構成として、通信装置８１、ＣＰＵ８２、メモリ８３、補助記憶装置８４、電源部８５を有している。通信装置８１はサービスバス装置２３−１〜１３−ｎそれぞれの通信装置と接続される。ＣＰＵ８２はメモリ８３又は補助記憶装置８４に格納されているプログラムを実行することで、サービスバス装置２３−１〜１３−ｎそれぞれの負荷を監視する処理を実行する。また、電源部８５は接続情報データベース装置の各部に電源を供給する。

＜サービスバス装置の機能構成＞
図５はサービスバス装置の一実施形態の機能構成図を示す。図５において、サービスバス装置９０内のサービスバス装置選択予測部９１は、ロードバランサ２２から受け取った接続要求のリクエスト識別子が接続情報キャッシュ９２と接続情報データベース装置２６のいずれにも登録されていない場合は初回の要求と判定し、サービスバス装置選択予測を行う。すなわち、サービスバス装置選択予測部９１はサービスシナリオ実行装置とアプリケーション実行装置の接続時に、セッション内にマルチシーケンスがあり、接続情報を接続情報データベース装置２６に格納する必要があれば、当該セッションで選択されるサービスバス装置を全て予測する。サービスバス装置選択予測部９１は選択予測候補の複数のサービスバス装置を決定後、そのサービスバス装置のリストを接続情報送信部９３に渡す。

接続情報送信部９３はサービスバス装置選択予測部９１より受信したサービスバス装置のリストから実際のサービスバス装置の接続先アドレスを求め、それらのサービスバス装置に対して該当セッションの接続情報として、リクエスト識別子（リクエストＩＤ）、サービスシナリオ実行装置アドレス、アプリケーション実行装置アドレスを送信する。

接続情報受信部９４は他のサービスバス装置の接続情報送信部９３から送信されたセッションの接続情報であるリクエスト識別子、サービスシナリオ実行装置アドレス、アプリケーション実行装置アドレス、当該接続情報送信元のサービスバス装置番号を更新日付と共に、メモリ５３に設けた接続情報キャッシュ９２に保存する。また、接続情報のキャッシュ保存時にキャッシュ有効性チェックのため、各キャッシュレコードの最終更新日付をチェックし、サービス単位で設定した有効時間を超えていれば、そのキャッシュレコードを削除する。

一意接続実施部９５はロードバランサ２２から受け取った要求と接続情報キャッシュ９２のリクエスト識別子を比較し、一致していれば接続情報キャッシュ９２に保存されている接続情報のアプリケーション実行装置アドレスを接続先とし、該当アプリケーション実行装置に対して要求を行う。同様に、一意接続実施部９５はアプリケーション実行装置２４−１〜２４−ｊから受け取った応答と接続情報キャッシュ９２のリクエスト識別子を比較し、一致していれば接続情報キャッシュ９２に保存されている接続情報のサービスシナリオ実行装置アドレスを接続先とし、該当サービスシナリオ実行装置に対して応答を行う。

一方、接続情報キャッシュ９２に要求のリクエスト識別子のレコードがない場合、一意接続実施部９５は接続情報データベース装置２６を検索して接続情報を取得し、取得した接続情報を接続情報キャッシュ９２に格納する。そして、該当アプリケーション実行装置に対して要求を行う。同様に、一意接続実施部９５は接続情報キャッシュ９２に応答のリクエスト識別子のレコードがない場合、一意接続実施部９５は接続情報データベース装置２６を検索して接続情報を取得し、取得した接続情報を接続情報キャッシュ９２に格納する。そして、該当サービスシナリオ実行装置に対して応答を行う。

また、一意接続実施部９５は接続情報キャッシュ９２に対するキャッシュヒットの合否を、リクエスト識別子、要求／応答種別、自サービスバス番号と共に、接続情報フィードバック部９６に通知する。

接続情報フィードバック部９６は一意接続実施部９５から受信したリクエスト識別子で接続情報キャッシュ９２を検索して接続情報送信元のサービスバス装置番号を抽出し、当該接続情報送信元のサービスバス装置の予測精度操作部９７にキャッシュヒットの合否と要求／応答種別を含む接続フィードバック情報を送信する。

予測精度操作部９７は他のサービスバス装置の接続情報フィードバック部９６から受信した接続フィードバック情報を基に、バスリスト９８とサービスログ９９のデータを登録及び更新する。

バスリスト９８はサービスバス装置選択予測部９１で予測を行ったセッションで実際に使用されたサービスバス装置のサービスバス番号毎に、セッション属性として予測ヒット回数、接続時間帯、サービス累積接続数、負荷状態などを登録及び更新されている。

サービスログ９９は予測を行ったサービスセッション毎に、実際に使用されたサービスバス装置の数、セッション確定の有無、最終更新日時などのセッション属性を登録及び更新される。

＜接続情報のデータ構造＞
図６に接続情報キャッシュ９２と接続情報データベース装置２６に保持する接続情報のデータ構造の一実施形態を示す。サービス番号のフィールドにはサービス毎の通番が格納され、リクエスト識別子（リクエストＩＤ）のフィールドにはサービス番号＋アプリ識別子＋セッション識別子＋通番で一意に決まる識別子が格納される。サービスシナリオノードのフィールドにはＵＲＬ形式（プロトコル＋アドレス）で表現され、ＩＰヘッダ及びポートなどから生成されたサービスシナリオ実行装置アドレスが格納される。アプリノードのフィールドにはＵＲＬ形式で表現され、サービスバスが自前で解決又は生成したアプリケーション実行装置アドレスが格納される。最終更新日時のフィールドにはレコード削除時に使用する最終更新日時が格納される。予測合否通知先のフィールドには接続処理を行った際にキャッシュヒット／未ヒットを通知するために初回接続処理を行ったサービスバス装置のＩＰアドレスまたはホスト名が格納される。

＜バスリスト＞
図７にバスリスト９８のデータ構造の一実施形態を示す。サービスバス番号のフィールドにはサービスバス装置の分散規則によって決まるサービスバス番号が格納される。アドレスのフィールドにはサービスバス装置のＩＰアドレス又はホスト名が格納される。時間帯１（重み付け値），時間帯２（重み付け値），サービス１（重み付け値），サービス２（重み付け値）…の重みフィールドには次選択バスの予測合否に応じて操作される重み付け値がサービスバス装置の選択予測論理毎に格納される。重み付け値は時間帯による選択頻度の偏り、サービスによる偏りなどに応じて定義されている。

＜サービスログ＞
図８にサービスログ９９のデータ構造の一実施形態を示す。サービス番号のフィールドにはサービス毎の通番が格納される。アプリ番号のフィールドにはアプリケーション毎に一意に決まる識別子が格納される。セッション識別子のフィールドにはサービスシナリオ実行装置とアプリケーション実行装置とのペアの識別子が格納される。

使用サービスバス数のフィールドにはリクエスト識別子当たりで使用されたサービスバス装置の数が格納される。セッション確定フラグのフィールドにはリクエスト識別子のシーケンスが終了したかどうか、すなわち使用サービスバス数が確定したかどうかを示すフラグが格納されている。最終更新日時のフィールドにはレコード削除又はリフレッシュ時に使用される最終更新日時が格納されている。

＜サービスバスデフォルト設定データ＞
ファイル等に保持する離散定義データであるサービスバスデフォルト設定データについて説明する。このサービスバスデフォルト設定データは各サービスバス装置の補助記憶装置５４に格納される。

デフォルト予測バス数は、デフォルトでいくつのサービスバスを予測するかを規定する。接続情報有効期間は、接続情報データベース装置２６及び接続情報キャッシュ９２それぞれの接続情報に対するサービス番号毎の有効生存時間を規定する。予測バス補正値は、サービス番号とセッション識別子で特定されるサービスセッション毎のサービスバス装置数の補正値を規定する。重み加算条件は、バスリスト９８の重みフィールド毎に加算する補正値を規定する。重み推定比率は、バスリスト９８の各重みフィールドの値に対する比率比率を規定する。

＜装置間メッセージ＞
図９（Ａ），（Ｂ），（Ｃ）に装置間メッセージのデータ構造の一実施形態を示す。図９（Ａ）にサービスバス装置間で送受信する接続情報のデータ構造を示す。接続情報メッセージは、リクエスト識別子（リクエストＩＤ）と、サービスシナリオ実行装置アドレス（サービスシナリオＵＲＬ）、アプリケーション実行装置アドレス（アプリＵＲＬ）、合否結果通知先つまり当該接続情報の送信元のアドレスを含んでいる。

図９（Ｂ）にサービスバス装置間で送受信する接続フィードバック情報のデータ構造を示す。接続フィードバック情報は、リクエスト識別子（リクエストＩＤ）と、要求／応答種別（０：要求時、１：応答時）と、自サービスバス装置番号、合否結果（１：キャッシュヒット、１以外：キャッシュ未ヒット）を含んでいる。

図９（Ｃ）にサービスバス装置とバス負荷監視装置２７間で送受信する負荷状態情報のデータ構造を示す。負荷状態情報はサービスバス装置を特定するためのサービスバス装置番号と、収集日時と、当該サービスバス装置のＣＰＵ負荷と、使用中のバスセッション数を含んでいる。

＜サービスバス装置のフローチャート＞
図１０はサービスバス装置９０が実行する選択予測処理の一実施形態のフローチャートを示す。図１０において、ステップＳ１でサービスバス装置９０は外部から信号を受信する。ステップＳ２でサービスバス装置９０は受信した信号が、他のサービスバス装置からの接続フィードバック情報か、ロードバランサ２２を介しての要求又は応答か、他のサービスバス装置からの接続情報かを判別する。

受信した信号がロードバランサ２２から供給される要求（サービスシナリオ実行装置から）又は応答（又はアプリケーション実行装置から）である場合には、ステップＳ３でサービスバス装置選択予測部９１は要求又は応答のリクエスト識別子が接続情報キャッシュ９２にあるか否かをチェックする。ステップＳ４の判別でリクエスト識別子が接続情報キャッシュ９２にない場合には、ステップＳ５でサービスバス装置選択予測部９１は要求又は応答のリクエスト識別子が接続情報データベース装置２６にあるか否かをチェックする。ステップＳ６の判別でリクエスト識別子が接続情報データベース装置２６にない場合には、セッション初回接続要求と判定してステップＳ７に進む。

ステップＳ７でサービスバス装置選択予測部９１は初回接続要求を解析してアプリケーション実行装置（又はサービスシナリオ実行装置）を抽出する。これは既存の処理である。また、ステップＳ８でサービスバス装置選択予測部９１は抽出したアプリケーション実行装置（又はサービスシナリオ実行装置）をリクエスト識別子と共に接続情報キャッシュ９２に登録する。また、ステップＳ９でサービスバス装置選択予測部９１は抽出したアプリケーション実行装置（又はサービスシナリオ実行装置）をリクエスト識別子と共に接続情報データベース装置２６に登録する。これは既存の処理である。

次に、ステップＳ１０でサービスバス装置選択予測部９１は当該セッションで選択されるサービスバス装置を全て予測して、選択予測候補の複数のサービスバス装置のリストを接続情報送信部９３に渡す。ステップＳ１１で接続情報送信部９３はサービスバス装置選択予測部９１からのサービスバス装置のリストから実際のサービスバス装置の接続先アドレスを求め、それらのサービスバス装置に対して該当セッションの接続情報としてリクエスト識別子、サービスシナリオ実行装置アドレス、アプリケーション実行装置アドレスを送信する。その後、ステップＳ１２で一意接続実施部９５はステップＳ７で抽出したアプリケーション実行装置に対して接続要求を行って、この処理を終了する。これは既存の処理である。

ステップＳ４の判別でリクエスト識別子が接続情報キャッシュ９２にある場合には、ステップＳ１３で接続情報フィードバック部９６は接続フィードバック情報に「キャッシュヒットあり」を設定してステップＳ１５に進む。また、ステップＳ６の判別でリクエスト識別子が接続情報データベース装置２６にある場合には、ステップＳ１４で接続フィードバック情報に「キャッシュヒットなし」を設定してステップＳ１５に進む。

ステップＳ１５で接続情報フィードバック部９６はステップＳ１で受信した要求又は応答のリクエスト識別子で接続情報キャッシュ９２を検索して接続情報送信元のサービスバス装置番号を抽出し、当該接続情報送信元のサービスバス装置に接続フィードバック情報を送信する。その後、ステップＳ１６で一意接続実施部９５はステップＳ７で抽出したアプリケーション実行装置（又はサービスシナリオ実行装置）に対して要求又は応答を行って、この処理を終了する。これは既存の処理である。

一方、ステップＳ２で受信した信号が他のサービスバス装置からの接続フィードバック情報である場合には、ステップＳ１７で予測精度操作部９７は他のサービスバス装置から受信した接続フィードバック情報を基に、バスリスト９８とサービスログ９９のデータを登録及び更新する。

更に、ステップＳ２で受信した信号が他のサービスバス装置からの接続情報である場合には、ステップＳ１８で接続情報受信部９４は接続情報を更新日付と共に、メモリ５３に設けた接続情報キャッシュ９２に保存して、この処理を終了する。

＜サービスバスシステムの動作＞
図１１を用いてサービスバスシステムにおける接続一意性保証動作を説明する。本実施形態では、各サービスバス装置２３−１〜１３−ｎが、サービスシナリオ実行装置２１−１〜２１−ｉとアプリケーション実行装置２４−１〜２４−ｊとの間をセッションの最初のシーケンスで接続する際に、サービスシナリオ実行装置２１−１〜２１−ｉとアプリケーション実行装置２４−１〜２４−ｊとの接続情報を接続情報データベース装置２６に登録するタイミングで、同一セッションの次シーケンスで振り分けが予測される複数のサービスバス装置に対して当該接続情報を送信する。

図１１では、セッションの第１シーケンスはサービスシナリオ２１−１からアプリケーション２４−１への初回リクエストであり、ロードバランサ２２によりサービスバス２３−１が選択されている。第２シーケンスはアプリケーション２４−１からサービスシナリオ２１−１の応答であり、ロードバランサ２２によりサービスバス２３−４が選択されている。なお、第２シーケンスのアプリケーション２４−１からサービスシナリオ２１−１の応答は、ロードバランサ２２とは別のロードバランサにより選択するものであっても良い。この場合、別のロードバランサはロードバランサ２２と同様の振り分け論理でサービスバスの振り分けを行う。

サービスシナリオ実行装置２１−１とアプリケーション実行装置２４−１との接続情報をサービスバス装置２３−１が接続情報データベース装置２６に登録するセッションの第１シーケンスのタイミングで、サービスバス装置２３−１は同一セッションの次シーケンスで振り分けが予測される複数のサービスバス装置２３−２，２３−３，２３−４に対して当該接続情報を送信する。

当該接続情報を受信したサービスバス装置２３−２，２３−３，２３−４ではメモリ５３の接続情報キャッシュ９２に当該接続情報を保持する。次シーケンス以降で当該接続情報を保持しているサービスバス装置２３−２，２３−３，２３−４に同一セッションのシーケンスが振り分けられた場合、つまり予測がヒットつまり当たった場合、予測がヒットした当該サービスバス装置は接続情報データベース装置２６へのアクセスは行う必要がない。これにより接続情報データベース装置２６へのアクセスを減らすことができる。

接続情報を送信されなかったサービスバス装置２３−５に同一セッションのシーケンスが振り分られた場合、つまり予測がヒットしなかった場合、当該サービスバス装置２３−５は従来どおり接続情報データベース装置２６へのアクセスを行って接続情報を取得することで接続一意性保証を行う。

＜サービスバス数予測処理のフローチャート＞
図１２はサービスバス装置選択予測部９１が実行するサービスバス数予測処理の一実施形態のフローチャートを示す。この処理は、ロードバランサ２２によってセッションの各シーケンスで選択されるサービスバス装置を、セッションの第１シーケンスでサービスバス装置選択予測部９１が予測してリスト化する際に実行される。

図１２において、ステップＳ２１でサービスバス装置選択予測部９１はサービスログ９９をサービス番号で参照して使用サービスバス数が格納されているか否かを判別する。使用サービスバス数を取得できた場合にはステップＳ２２でサービスバス装置選択予測部９１は取得した使用サービスバス数を予測パス数と決定する。使用サービスバス数を取得できない場合、ステップＳ２３でサービスバス装置選択予測部９１は補助記憶装置５４にか苦悩されているサービスバスデフォルト設定データにデフォルト予測バス数が規定されているか否かを判別する。デフォルト予測バス数が規定されていれば、ステップＳ２４でサービスバス装置選択予測部９１は規定されている当該デフォルト予測バス数を予測パス数と決定する。デフォルト予測バス数が規定されていなければステップＳ２５でサービスバス装置選択予測部９１はこのサービスバス数予測処理を終了する。

ステップＳ２２又はＳ２４の実行後、ステップＳ２６でサービスバス装置選択予測部９１はサービスバスデフォルト設定データに当該サービスセッションに対するサービスバス装置数の補正係数つまり予測バス補正値が規定されているか否かを判別し、補正係数が規定されている場合すなわち補正係数が０を超える場合にのみ、ステップＳ２２又はＳ２４で決定した予測パス数を上記補正係数により補正して、このサービスバス数予測処理を終了する。

＜サービスバス装置予測＞
サービスバス選択予測部９１は、ロードバランサ２２の振り分け論理に対応した選択予測処理で、予測バス数分のサービスバス装置番号を抽出する。ロードバランサ２２の振り分け論理は、ラウンドロビンを用いた静的負荷分散と、最少負荷ノード選択など環境依存振り分けの動的負荷分散の２系列を想定し、サービスバス選択予測部９１は静的負荷分散と動的負荷分散それぞれに対応した選択予測論理とする。また、これら２系列の選択予測論理の切替えと、２系列の選択予測論理の論理積又は論理和による組み合わせを可能とする。なお、上記サービスバス装置の予測はセッションの初回で接続したサービスバス装置でのみ行う。

＜静的負荷分散予測＞
ラウンドロビン振り分けに対応した静的負荷分散予測について説明する。ラウンドロビン方式の場合，サービスバス装置は固定順序で振り分けられるため、予めサービスバス装置の選択順序リストを作成することができる。図１３に示す作成したサービスバス装置の選択順序リスト１０１は例えば補助記憶装置５４に保持しておく。サービスバス選択予測部９１はサービスバス装置の選択順序リスト１０１のうち、自サービスバス装置番号から順に予測バス数分のサービスバス装置番号を一括して抽出し、図１３に示すバスリスト９８に登録する。ここで、例えば任意のサービスのセッションシーケンスが要求と応答を合わせて１０シーケンスだった場合、サービスバス装置選択順序リストの自サービスバス番号を検索し、そこから１０個のサービスバス番号を取得する。

＜動的負荷分散予測１＞
ロードバランサ２２の振り分けが、時間帯、使用サービスの偏りなどによって振り分けパターンが想定できる場合、それらの振り分けパターンをサービスバス装置が学習することで、バス選択確率を推定することができる。

予測精度操作部９７において、使用されたサービスバス装置からの接続フィードバック情報を受信すると、図１４に示すサービスバスデフォルト設定データ１０２から、重み加算条件つまりバスリスト９８の重みフィールド毎に加算する補正値を抽出し、バスリスト９８の時間帯１，２、サービス１，２などに対応する各重みフィールドの実績値に抽出した補正値を加算する。

サービスバス装置選択予測部９１でバス選択をする場合には、サービスバスデフォルト設定データ１０２から重み推定比率を抽出し、各重みフィールドの補正後の実績値に重み推定比率を乗算して総和を求めて優先度とし、優先度の高いものから順にバスリスト９８から抽出して行く。

図１４に示す例では、接続フィードバック情報の受信により時間帯１、サービス２で使用されたサービスバス装置に対して、バスリスト９８の各重みフィールドの実績値に、サービスバスデフォルト設定データの各該当フィールドに指定された予測バス補正値（例えば１００）を加算する。

次ぎに、同じ時間帯、同じサービスで接続要求があった場合、サービスバス装置選択予測部９１では、この重み情報を総合して、（１）式により優先度を評価する。

優先度＝時間帯１の実績値×時間帯１の重み推定比率
＋サービス２の実績値×サービス２の重み推定比率］ …（１）
時間帯１の重み推定比率は例えば０．６であり、サービス２の重み推定比率は例えば０．３である。（１）式によりサービスバス装置自体の優先度を評価し、優先度の高いものからサービスバス数予測処理で決定したバス数分を選択する。

＜動的負荷分散予測２＞
ロードバランサ２２が各サービスバス装置の負荷を監視して負荷分散を行う場合、振り分け対象のサービスバス装置上の配備された監視エージェントプログラムによって定期的にＣＰＵ負荷や接続中セッション数などのノード状態の配信を受け、サービスバス装置に応じて振り分けを決定する。

このため、ロードバランサ２２と同等の論理を各サービスバス装置２３−１〜２３−ｎに配備することにより、バス選択予測精度を上げることができる。図１５の機能構成図と図１６の動作シーケンスに示すように、サービスバス装置２３−１〜２３−ｎから独立したバス負荷監視装置２７により、一定時間間隔で全サービスバス装置２３−１〜２３−ｎの監視エージェントプログラム１００を経由してＣＰＵ負荷や接続中セッション数などの負荷状態を収集する（図１６のシーケンスＳＱ１）。

その情報を基にバス負荷監視装置２７は優先的に選択可能なサービスバス装置を全て抽出する（図１６のＳＱ２）。この後、バス負荷監視装置２７から抽出した選択可能なサービスバス装置の情報をブロードキャストで全サービスバス装置２３−１〜２３−ｎに通知する。各サービスバス装置２３−１〜２３−ｎの予測精度操作部９７では、それらのデータでバスリスト９８の更新を行う（図１６のＳＱ３）。

この場合、ノード監視間隔、ブロードキャスト送信間隔、ＣＰＵ負荷率と接続セッション数の選択可能バス閾値、抽出バス最大数などの基本定数は設定定義ファイルなどとしてバス負荷監視装置２７に定義しておく。基本的にロードバランサ２２の振り分け条件を近似的にエミュレートするため、サービスバス装置負荷監視条件をロードバランサ２２の監視条件に近づけるほど、精度の高いサービスバス装置選択予測が行える。

なお、接続情報データベース装置２６を複数台に分散して設置し、１台当たりの負荷を分散させることが考えられる。データベースの振り分け論理としては、ユーザＩＤ，サービスバス装置番号単位などの固定振り分け、リクエスト識別子などをキーにしてハッシュ関数による数値化でデータベース番号を決定するハッシュ振り分けなどがある。しかし、データベースの負荷分散の均一性が保証されていないため、データベースの局所的なアクセスがボトルネックとなる。また、データベースの性能によっては、接続情報データベース装置２６を数十台〜数百台に分散することが必要となり、ハードウェア及びソフトウェアの導入、開発、保守のコストが膨れ上がる。

これに対し、本実施形態によれば、接続情報データベース装置２６を複数台に分散する必要がなく、上記のデータベースの局所的なアクセスがボトルネックとなることはなく、コストの上昇もあり得ない。
（付記１）
クライアントに接続される複数の第１装置と、サービスを実行する複数の第２装置との間を複数のサービスバス装置のいずれかを用いて接続するサービスバスシステムにおいて、
前記第１装置と前記第２装置との間をセッションの最初のシーケンスで接続する際に、前記セッションと同一セッション内の２番目以降のシーケンスで前記第１装置と前記第２装置との間を接続する１つ以上の他のサービスバス装置を予測する予測手段と、
前記セッションの前記第１装置と前記第２装置との接続情報を前記予測手段で予測された前記１つ以上の他のサービスバス装置に送信する送信手段と、
他のサービスバス装置の前記送信手段から送信された前記セッションの前記第１装置と前記第２装置との接続情報を保持する記憶手段と、
前記同一セッション内の２番目以降のシーケンスを受信したサービスバス装置の前記記憶手段に前記セッションの前記第１装置と前記第２装置との接続情報があれば、前記記憶手段の接続情報を用いて前記２番目以降のシーケンスで前記第１装置と前記第２装置との間を接続する接続手段と、
を有することを特徴とするサービスバスシステム。
（付記２）
付記１記載のサービスバスシステムにおいて、
前記同一セッション内の２番目以降のシーケンスを受信したサービスバス装置の前記記憶手段に前記セッションの前記第１装置と前記第２装置との接続情報があったとき、前記記憶手段に保持している接続情報の送信元のサービスバス装置に対し予測が当たった旨のフィードバック情報を送信するフィードバック手段と、
他のサービスバス装置の前記フィードバック手段から送信されたフィードバック情報の受信に応じて、前記予測手段で予測に用いる値を補正する補正手段と、
を有することを特徴とするサービスバスシステム。
（付記３）
付記１記載のサービスバスシステムにおいて、
前記予測手段は、前記複数のサービスバス装置から固定順序で前記１つ以上の他のサービスバス装置を予測する、
ことを特徴とするサービスバスシステム。
（付記４）
付記１記載のサービスバスシステムにおいて、
前記予測手段は、前記複数のサービスバス装置それぞれの動作状態に応じて前記１つ以上の他のサービスバス装置を予測する、
ことを特徴とするサービスバスシステム。
（付記５）
クライアントに接続される複数の第１装置と、サービスを実行する複数の第２装置との間を複数のサービスバス装置のいずれかを用いて接続するサービスバスシステムのサービスバス装置において、
前記第１装置と前記第２装置との間をセッションの最初のシーケンスで接続する際に、前記セッションと同一セッション内の２番目以降のシーケンスで前記第１装置と前記第２装置との間を接続する１つ以上の他のサービスバス装置を予測する予測手段と、
前記セッションの前記第１装置と前記第２装置との接続情報を前記予測手段で予測された前記１つ以上の他のサービスバス装置に送信する送信手段と、
他のサービスバス装置の前記送信手段から送信された前記セッションの前記第１装置と前記第２装置との接続情報を保持する記憶手段と、
前記同一セッション内の２番目以降のシーケンスを受信したサービスバス装置の前記記憶手段に前記セッションの前記第１装置と前記第２装置との接続情報があれば、前記記憶手段の接続情報を用いて前記２番目以降のシーケンスで前記第１装置と前記第２装置との間を接続する接続手段と、
を有することを特徴とするサービスバス装置。
（付記６）
付記５記載のサービスバス装置において、
前記同一セッション内の２番目以降のシーケンスを受信したサービスバス装置の前記記憶手段に前記セッションの前記第１装置と前記第２装置との接続情報があったとき、前記記憶手段に保持している接続情報の送信元のサービスバス装置に対し予測が当たった旨のフィードバック情報を送信するフィードバック手段と、
他のサービスバス装置の前記フィードバック手段から送信されたフィードバック情報の受信に応じて、前記予測手段で予測に用いる値を補正する補正手段と、
を有することを特徴とするサービスバス装置。
（付記７）
付記５記載のサービスバス装置において、
前記予測手段は、前記複数のサービスバス装置から固定順序で前記１つ以上の他のサービスバス装置を予測する、
ことを特徴とするサービスバス装置。
（付記８）
付記５記載のサービスバス装置において、
前記予測手段は、前記複数のサービスバス装置それぞれの動作状態に応じて前記１つ以上の他のサービスバス装置を予測する、
ことを特徴とするサービスバス装置。
（付記９）
クライアントに接続される複数の第１装置と、サービスを実行する複数の第２装置との間を複数のサービスバス装置のいずれかを用いて接続するサービスバスシステムの接続一意性保証方法において、
前記第１装置と前記第２装置との間をセッションの最初のシーケンスで接続する際に、前記セッションと同一セッション内の２番目以降のシーケンスで前記第１装置と前記第２装置との間を接続する１つ以上の他のサービスバス装置を予測し、
前記セッションの前記第１装置と前記第２装置との接続情報を前記予測手段で予測された前記１つ以上の他のサービスバス装置に送信し、
他のサービスバス装置の前記送信手段から送信された前記セッションの前記第１装置と前記第２装置との接続情報を保持し、
前記同一セッション内の２番目以降のシーケンスを受信したサービスバス装置の前記記憶手段に前記セッションの前記第１装置と前記第２装置との接続情報があれば、前記記憶手段の接続情報を用いて前記２番目以降のシーケンスで前記第１装置と前記第２装置との間を接続する、
ことを特徴とする接続一意性保証方法。
（付記１０）
付記９記載の接続一意性保証方法において、
前記同一セッション内の２番目以降のシーケンスを受信したサービスバス装置の前記記憶手段に前記セッションの前記第１装置と前記第２装置との接続情報があったとき、前記記憶手段に保持している接続情報の送信元のサービスバス装置に対し予測が当たった旨のフィードバック情報を送信し、
他のサービスバス装置から送信されたフィードバック情報の受信に応じて、前記１つ以上の他のサービスバス装置を予測する際に用いる値を補正する、
ことを特徴とする接続一意性保証方法。
（付記１１）
付記９記載の接続一意性保証方法において、
前記複数のサービスバス装置から固定順序で前記１つ以上の他のサービスバス装置を予測する、
ことを特徴とする接続一意性保証方法。
（付記１２）
付記９記載の接続一意性保証方法において、
前記予測手段は、前記複数のサービスバス装置それぞれの動作状態に応じて前記１つ以上の他のサービスバス装置を予測する、
ことを特徴とする接続一意性保証方法。

２０ サービスバスシステム
２１−１〜２１−ｉ サービスシナリオ実行装置
２２ ロードバランサ
２３−１〜１３−ｎ，９０ サービスバス装置
２４−１〜２４−ｊ アプリケーション実行装置
２６ 接続情報データベース装置
２７ バス負荷監視装置
３１，４１，５１，６１，７１，８１ 通信装置
３２，４２，５２，６２，７２，８２ ＣＰＵ
３３，４３，５３，６３，７３，８３ メモリ
３４，４４，５４，６４，７４，８４ 補助記憶装置
３５，４５，５５，６５，７５，８５ 電源部
２８，２９ ユーザ端末
９１ サービスバス装置選択予測部
９２ 接続情報キャッシュ
９３ 接続情報送信部
９４ 接続情報受信部
９５ 一意接続実施部
９６ 接続情報フィードバック部
９７ 予測精度操作部
９８ バスリスト
９９ サービスログ

Claims (8)

1. クライアントに接続される複数の第１装置と、サービスを実行する複数の第２装置との間を複数のサービスバス装置のいずれかを用いて接続するサービスバスシステムにおいて、
   前記第１装置と前記第２装置との間をセッションの最初のシーケンスで接続する際に、前記セッションと同一セッション内の２番目以降のシーケンスで前記第１装置と前記第２装置との間を接続する１つ以上の他のサービスバス装置を予測する予測手段と、
   前記セッションの前記第１装置と前記第２装置との接続情報を前記予測手段で予測された前記１つ以上の他のサービスバス装置に送信する送信手段と、
   他のサービスバス装置の前記送信手段から送信された前記セッションの前記第１装置と前記第２装置との接続情報を保持する記憶手段と、
   前記同一セッション内の２番目以降のシーケンスを受信したサービスバス装置の前記記憶手段に前記セッションの前記第１装置と前記第２装置との接続情報があれば、前記記憶手段の接続情報を用いて前記２番目以降のシーケンスで前記第１装置と前記第２装置との間を接続する接続手段と、
   を有することを特徴とするサービスバスシステム。
2. 請求項１記載のサービスバスシステムにおいて、
   前記同一セッション内の２番目以降のシーケンスを受信したサービスバス装置の前記記憶手段に前記セッションの前記第１装置と前記第２装置との接続情報があったとき、前記記憶手段に保持している接続情報の送信元のサービスバス装置に対し予測が当たった旨のフィードバック情報を送信するフィードバック手段と、
   他のサービスバス装置の前記フィードバック手段から送信されたフィードバック情報の受信に応じて、前記予測手段で予測に用いる値を補正する補正手段と、
   を有することを特徴とするサービスバスシステム。
3. 請求項１記載のサービスバスシステムにおいて、
   前記予測手段は、前記複数のサービスバス装置から固定順序で前記１つ以上の他のサービスバス装置を予測する、
   ことを特徴とするサービスバスシステム。
4. 請求項１記載のサービスバスシステムにおいて、
   前記予測手段は、前記複数のサービスバス装置それぞれの動作状態に応じて前記１つ以上の他のサービスバス装置を予測する、
   ことを特徴とするサービスバスシステム。
5. クライアントに接続される複数の第１装置と、サービスを実行する複数の第２装置との間を複数のサービスバス装置のいずれかを用いて接続するサービスバスシステムのサービスバス装置において、
   前記第１装置と前記第２装置との間をセッションの最初のシーケンスで接続する際に、前記セッションと同一セッション内の２番目以降のシーケンスで前記第１装置と前記第２装置との間を接続する１つ以上の他のサービスバス装置を予測する予測手段と、
   前記セッションの前記第１装置と前記第２装置との接続情報を前記予測手段で予測された前記１つ以上の他のサービスバス装置に送信する送信手段と、
   他のサービスバス装置の前記送信手段から送信された前記セッションの前記第１装置と前記第２装置との接続情報を保持する記憶手段と、
   前記同一セッション内の２番目以降のシーケンスを受信したサービスバス装置の前記記憶手段に前記セッションの前記第１装置と前記第２装置との接続情報があれば、前記記憶手段の接続情報を用いて前記２番目以降のシーケンスで前記第１装置と前記第２装置との間を接続する接続手段と、
   を有することを特徴とするサービスバス装置。
6. 請求項５記載のサービスバス装置において、
   前記同一セッション内の２番目以降のシーケンスを受信したサービスバス装置の前記記憶手段に前記セッションの前記第１装置と前記第２装置との接続情報があったとき、前記記憶手段に保持している接続情報の送信元のサービスバス装置に対し予測が当たった旨のフィードバック情報を送信するフィードバック手段と、
   他のサービスバス装置の前記フィードバック手段から送信されたフィードバック情報の受信に応じて、前記予測手段で予測に用いる値を補正する補正手段と、
   を有することを特徴とするサービスバス装置。
7. クライアントに接続される複数の第１装置と、サービスを実行する複数の第２装置との間を複数のサービスバス装置のいずれかを用いて接続するサービスバスシステムの接続一意性保証方法において、
   前記第１装置と前記第２装置との間をセッションの最初のシーケンスで接続する際に、前記セッションと同一セッション内の２番目以降のシーケンスで前記第１装置と前記第２装置との間を接続する１つ以上の他のサービスバス装置を予測し、
   前記セッションの前記第１装置と前記第２装置との接続情報を前記予測手段で予測された前記１つ以上の他のサービスバス装置に送信し、
   他のサービスバス装置の前記送信手段から送信された前記セッションの前記第１装置と前記第２装置との接続情報を保持し、
   前記同一セッション内の２番目以降のシーケンスを受信したサービスバス装置の前記記憶手段に前記セッションの前記第１装置と前記第２装置との接続情報があれば、前記記憶手段の接続情報を用いて前記２番目以降のシーケンスで前記第１装置と前記第２装置との間を接続する、
   ことを特徴とする接続一意性保証方法。
8. 請求項７記載の接続一意性保証方法において、
   前記同一セッション内の２番目以降のシーケンスを受信したサービスバス装置の前記記憶手段に前記セッションの前記第１装置と前記第２装置との接続情報があったとき、前記記憶手段に保持している接続情報の送信元のサービスバス装置に対し予測が当たった旨のフィードバック情報を送信し、
   他のサービスバス装置から送信されたフィードバック情報の受信に応じて、前記１つ以上の他のサービスバス装置を予測する際に用いる値を補正する、
   ことを特徴とする接続一意性保証方法。

Images