JP2010009218A - サービスバス連携方法及びサービスバス - Google Patents

Abstract

【課題】サービスバスで、分散配置が可能となることを目的とする。
【解決手段】追加するサービスバスに接続先である既存のサービスバスのノード識別子と位置を入力して、追加するサービスバスにおける自サービスバス及び隣接サービスバスの識別子と位置を保存するバスノードテーブルに既存のサービスバスのノード識別子と位置を登録し、追加するサービスバスから既存のサービスバスにバスノードテーブル更新通知を行い、バスノードテーブル更新通知により既存のサービスバスのバスノードテーブルに追加するサービスバスのノード識別子と位置を登録する。
【選択図】図４

Description

本発明は、サービスバスを連携する方法及びサービスバスに関する。

ある業務システムを構築する場合、従来は１台のサーバに全ての業務ロジックを実装することで実現してきたが、この方式で実現した場合、ソフトウェアの有効活用がほぼ不可能であり、ソフトウェア資産を利用しての他システムの構築が困難である。

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

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

図１にサービスバスの概念を示す。同図中、アプリケーション１，２からサービス３，４にアクセスしようとした場合、アプリケーション１，２は自分のアクセスしたいプロトコルやデータ形式でサービスバス５にだけアクセスすればよく、サービス３，４のプロトコルや位置を知らなくて良いため、効率的にアプリケーション１，２が開発できる。

サービスバス５は、プロトコル変換機能、データ変換機能と、サービスバス内の共通プロトコル通信を行っており、これらの機能を実現している。

また、サービスバスは、サービスアクセスの形態により、図２（Ａ）に示すサービスに動作する契機を与えるもの（着信先指定起動型）、図２（Ｂ）に示す複数のサービス動作に同時に契機を与えるもの（ブロードキャスト型）、図２（Ｃ）に示すサービスの動作結果を受取るもの（読込型）などをサポートでき、アプリケーションの作りやすさを追求する基盤として機能する。

図３に、従来のサービスバスの一例の構成図を示す。サービスバス１０には、アプリケーション１１とサービス１２，１３を接続するために、アプリケーション受付エンドポイントデータ１５ａ，１５ｂを設定する必要がある。

アプリケーション受付エンドポイントとは、アプリケーションを特定のサービスに接続するための接続ポイントであり、アプリケーション毎に設定する必要がある。アプリケーション受付エンドポイントデータ１５ａ，１５ｂには、アプリケーション１１が使用しているプロトコル、アクセス先のサービス（ルーティング先）、サービスのタイプ（起動型、読込型等）、アプリケーション１１の入出力パラメータからサービスへアクセスするための入出力パラメータへと変換するデータ等が格納されている。

一方、サービスバス１０からサービス１２，１３にアクセスするための設定データとして、サービスエンドポイントデータ１６ａ，１６ｂも設定する必要がある。これはサービスバス１０がサービス１２，１３へ接続するための接続ポイントであり、サービス毎に設定する必要がある。サービスエンドポイントデータには、サービスが使用するプロトコル、タイプ、入出力パラメータが設定されている。

アプリケーション１１がサービス１３にアクセスする場合、アプリケーション１１用のサービスＢの受付エンドポイントデータ１５ｂを指定してアクセスする。アプリケーション受付エンドポイントデータで指定されたプロトコルスタック１７ｂが用意されており、そこでオーダを受付けると、データ形式変換部１８ｂが受付エンドポイントデータ１５ｂにある入力パラメータ変換のためのデータを参照してデータ変換を行い、ルーティング先（この場合サービス１３）を参照して、サービス受付部１９に依頼を出す。

サービス受付部１９では、サービスエンドポイントデータ１６ｂを参照し、サービス１３の宛先（ＩＰアドレス等）を決定し、指定されたプロトコルスタック２０ｂに入力パラメータを送信することにより、サービス１３にオーダが送出される。

ところで、複数のサービスソフトをサービスバスで接続する構成は従来から知られている（特許文献１参照）。
特開２００３−２７４０６８号公報

図３に示すサービスバスは、１台の物理的なサーバで動作されることを前提としている。しかし、サービスバスに接続されるアプリケーションやサービスが増えてくると、サーバの処理能力を超えるアクセスがあった場合、アクセス規制などを行う必要があり、運用性が悪くなる。

こうなった場合、複数のサービスバスに分散してアプリケーションやサービスを登録する方法がある。しかし、従来のサービスバスでは分散配置のための機構がないという問題があった。また、共通プロトコル通信をサーバ間で行えるようにするとしても、保守を行う立場から見ると、エンドポイント設定のデータが増えることにより保守が煩雑になるという問題があった。

開示のサービスバスは、分散配置が可能となる方法を提供することを目的とする。

開示の一実施態様によるサービスバス連携方法は、複数のサービスバスを連携させるサービスバス連携方法において、
追加するサービスバスに接続先である既存のサービスバスのノード識別子と位置を入力して、前記追加するサービスバスにおける自サービスバス及び隣接サービスバスの識別子と位置を保存するバスノードテーブルに前記既存のサービスバスのノード識別子と位置を登録し、
前記追加するサービスバスから前記既存のサービスバスにバスノードテーブル更新通知を行い、
前記バスノードテーブル更新通知により前記既存のサービスバスのバスノードテーブルに前記追加するサービスバスのノード識別子と位置を登録する。

好ましくは、前記バスノードテーブル更新通知により前記既存のサービスバスにおけるサービスにアクセスするためのサービスバス識別子とサービス識別子とホップ数を保存するサービスルートテーブルを読み出して前記追加するサービスバスに送信し、
前記追加するサービスバスで受信した前記既存のサービスバスのバスノードテーブルに基づいて前記追加するサービスバスのサービスルートテーブルの更新を行う。

開示の一実施態様によるサービスバスは、複数のサービスバスを連携させるサービスバスシステムのサービスバスにおいて、
外部端末から入力される接続先である既存のサービスバスのノード識別子と位置を、自サービスバス及び隣接サービスバスの識別子と位置を保存するバスノードテーブルに登録する第１登録手段と、
前記既存のサービスバスにバスノードテーブル更新通知を行う更新通知手段と、
受信した前記バスノードテーブル更新通知により前記バスノードテーブルに隣接する他のサービスバスのノード識別子と位置を登録する第２登録手段と、を有する。

開示のサービスバスによれば、サービスバスの分散配置が可能となる。

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

＜サービスバスの構成＞
図４は、サービスバスシステムの一実施形態の構成図を示す。同図中、サービスバス（サービスバスが動作している物理的なサーバを「ノード」と呼ぶ。）３０は、オーダ受付部３１，エンドポイントデータ３２，プロトコルスタック３３の他に、サービスバス登録部３４，バスノードテーブル３５，サービスルートテーブル３６，サービス通知部３７を有している。サービス通知部３７はメモリ３７ａを有している。ここで、アプリケーション３８はオーダ受付部３１，プロトコルスタック３３に接続され、保守端末３９はサービスバス登録部３４に接続される。

同様に、サービスバス（ノード）４０は、オーダ受付部４１，エンドポイントデータ４２，プロトコルスタック４３の他に、サービスバス登録部４４，バスノードテーブル４５，サービスルートテーブル４６，サービス通知部４７を有している。サービス通知部４７はメモリ４７ａを有している。サービス４８はオーダ受付部４１，プロトコルスタック４３に接続され、保守端末４９はサービスバス登録部４４に接続される。

ここで、保守者は、新規に設立したサービスバス３０に対して、隣接するサービスバス４０の登録を行うだけで済むようにしている。なお、「隣接するサービスバス」とは、「隣接して接続されているサービスバス」という意味である。

保守端末３９から隣接ノード登録（サービスバス登録）を行うと、サービス通知部３７，４７を介して、隣接サービスバス４０に必要情報が送信される仕組みである。また、従来、保守者が行っていたエンドポイントデータ３２，４２の登録は、保守者が行うのではなく、アプリケーション（又はサービス）３８が行う（サービス登録）。なお、サービスは、広義にアプリケーションを含むものとする。これにより、サービスバス設定の保守手順の簡略化を図る。

また、サービス通知部３７，４７を設け、バスノードテーブル３５，サービスルートテーブル３６を参照、更新しながら、サービスバス３０，４０間の通信を行う。サービス通知部３７，４７は、各サービスバス３０，４０がどのようなトポロジで接続されているのか、どのノードにどのようなサービスが登録されているのか等の把握を行い、アプリケーションが他ノードのサービスにアクセスした場合にルーティングを行う基となるデータの交換を行う。

また、実際に他ノードのサービスにアクセス（サービスアクセス）した場合のオーダもサービス通知部３７，４７が送受信する。これにより、複数のサービスバスの連携を可能とする。

＜サービスバス登録＞
図５にサービスバス登録の動作概要を示す。保守端末３９からサービスバス３０に隣接するサービスバス４０のノードＩＤとその位置（ＩＰアドレス）が入力されると、サービスバス登録部３４がそのオーダを受付け、バスノードテーブル３５を参照して、要求されたサービスバス４０が登録されているかどうかを確認する。登録されていないことを確認すると、サービス通知部３７に隣接サービスバス４０への情報通知依頼を出す。

すると、サービス通知部３７は、バスノードテーブル３５を更新すると同時に、隣接サービスバス４０に対して、サービスバス３０が追加されたことを通知するバスノードテーブル更新通知を出力し、要求元ノードＩＤ（この例では「＃１」）と、要求元位置のＩＰアドレスを追加して隣接サービスバス４０に送信する。その応答として、隣接サービスバス４０から隣接サービスバス４０が持つサービスルートテーブル４６を受取り、自サービスバス３０のサービスルートテーブル３６を更新する。

バスノードテーブル３５は、自サービスバス３０を含む隣接サービスバス４０のノードＩＤと位置を保存している。サービスルートテーブル３６は、サービスへアクセスするために、どのノードにアクセスしたら、何ホップ（中継ノードの数）で到着できるかを管理している。

図５では、バスノードテーブル３５から、ノードＩＤ＝＃１は自ノードであり、ノードＩＤ＝＃２はＩＰアドレスが（１０．２０．３０．２）のノードであることが分かる。サービスルートテーブル３６から、サービスＩＤ＝Ａは、ノードＩＤ＝＃１（自ノード）にあり、当然、ホップ数が０で到達できるところにあることが分かる。サービスＩＤ＝Ｃへは、ノードＩＤ＝＃２にアクセスすれば、ホップ数１で到達できるところにあることが分かる。

図６は、サービスバス登録処理のフローチャートを示す。保守者からサービスバス３０の登録が行われると、サービスバス登録部３４経由で、サービス通知部３７のサービスバス登録処理受付け（ステップＳ１）が起動される。

まず、その登録が自ノード（ｌｏｃａｌ）であるか、隣接ノード（自ノードに接続されている他ノード）であるか判断し（ステップＳ２）、自ノードであればバスノードテーブル３５だけを更新して（ステップＳ３）、応答をサービスバス登録部３４に返却する（ステップＳ４）。

隣接サービスバス４０の登録であれば、自ノードの場合と同様にバスノードテーブル３５を更新し（ステップＳ５）、その後、バスノードテーブル更新通知の要求を登録した隣接サービスバス４０に送信する（ステップＳ６）。この要求には、要求元ノードＩＤ＝＃１と要求元位置のＩＰアドレス（１０．２０．３０．１）が設定される。

隣接サービスバス４０がその要求をサービス通知部４７で受け（ステップＳ７）、バスノードテーブル４５を更新する（ステップＳ８）。つまり、要求元ノードＩＤ＝＃１と要求元位置のＩＰアドレス（１０．２０．３０．１）をバスノードテーブル４５に書き込む。その後、サービスバス４０のサービスルートテーブル４６が読み出され（ステップＳ９）、サービスバス３０への応答として送信される（ステップＳ１０）。

サービスバス３０では、サービスバス４０のサービスルートテーブル４６を受取ると（ステップＳ１１）、サービスバス３０のサービスルートテーブル３６の更新処理が行われる（ステップＳ１２）。

図７は、サービスルートテーブル更新処理のフローチャートを示す。まず、隣接サービスバス４０からサービスルートテーブル４６を受取る（ステップＳ２１）。隣接サービスバス４０から受取るサービスルートテーブル４６は、図８（Ａ）に示すように、サービスＩＤとホップ数が複数記載されている形である。

サービスバス３０では、全てのホップ数に＋１の演算を行い（ステップＳ２２）、図８（Ｂ）に示す値を得る。その後、サービスバス３０のサービスルートテーブル３６を参照し（ステップＳ２３）、比較・判断を行ったのち、サービスバス３０のサービスルートテーブル３６を更新する。

初回の隣接ノード登録であれば、サービスバス３０のサービスルートテーブル３６には何も登録されていない状態なので、受取ったものをサービスバス３０のサービスルートテーブル３６に書き込めば良いが、既にサービスバス３０にサービスルートテーブル３６が設定されている場合は、判断ロジックに従い、サービスバス３０のサービスルートテーブ３６ルを書き換える。

判断ロジックは、まず、自サービスバス３０に登録されているサービスかどうかを判定する（ステップＳ２４）。図８（Ｃ）に示すサービスバスサービスバス３０の既存サービスルートテーブル３６では、ノードＩＤが「＃１」のサービスＩＤ＝Ａに関しては、書き換えを行わない。

次に、既に登録済のサービスかどうかを判定する（ステップＳ２５）。今回はサービスバス４０からの応答であるため、図８（Ｃ）に示すサービスバスサービスバス３０の既存サービスルートテーブル３６のうち、ノードＩＤが「＃２」のものに注目する。ノードＩＤが「＃２」となっているもののうち、サービスＩＤ＝Ｂはホップ数２で登録されており、図８（Ｂ）に記載されているサービスＩＤ＝Ｂで、ホップ数が２と一致する。このようなサービスに関しては更新を行わない（ステップＳ２６，Ｓ２７）。

次に、図８（Ｃ）に示すサービスバスサービスバス３０の既存サービスルートテーブル３６では、同一のサービスＩＤが無限に増えるのを防ぐため、同一サービスＩＤをいくつ持てるかの上限を設けている（ステップＳ２６）。ここでは、上限値を２として説明する。

図８（Ｃ）でサービスＩＤ＝Ｃに注目すると、まだ１つしか登録されていない。図８（Ｂ）に記載されているサービスＩＤ＝Ｃは、追加される形で登録される（ステップＳ２８）。また、サービスＩＤ＝Ｄの場合、図８（Ｃ）に示すサービスバスサービスバス３０の既存サービスルートテーブル３６では、ノードＩＤ＝＃３がホップ数１、ノードＩＤ＝＃４がホップ数３で既に登録されており、サービスＩＤ登録の上限数（最大）は２である。

この場合、既存ホップ数と入力されたＤのホップ数を比較し（ステップＳ２７）、入力された方がホップ数が少なければ上書き更新を行う（ステップＳ２８）。図８（Ｂ）のサービスＩＤが「Ｄ」のものは、ホップ数２であり、図８（Ｃ）に示すサービスバスサービスバス３０の既存サービスルートテーブル３６のノードＩＤ＝＃４の場合のホップ数３と比べて小さい。よって、このレコードを書き換える。

一方、図８（Ｃ）におけるサービスＩＤ＝Ｆに注目すると、サービスＩＤ＝Ｄと同様に同一サービスＩＤの上限値である２つ登録されており、図８（Ｂ）の「Ｆ」のホップ数４と比較すると、図８（Ｃ）に示すサービスバスサービスバス３０の既存サービスルートテーブル３６はノードＩＤ＝＃３がホップ数１で、ノードＩＤ＝＃４がホップ数２なので、この場合更新は行われない。

以上のように、サービスルートテーブル更新が行われるものは、ノードＩＤが隣接のもの「＃２」で、書き換えられる。最終的に図８（Ｄ）のサービスバスサービスバス３０の更新後のサービスルートテーブル３６に示すように書き換えられる。

図６に戻って説明するに、サービスバス３０のサービスルートテーブル３６の更新処理が終わると、バスノードテーブルを参照し、今回更新した隣接サービスバス４０以外に隣接ノードがなければ処理を終了する（ステップＳ１３，Ｓ４）。

サービスバス４０以外の隣接ノードが存在すれば、サービスバス４０以外の隣接ノード全てに対して、今回更新したサービスルートテーブル３６のレコードを送信する（ステップＳ１４）。図８（Ｄ）の例では、３レコード更新したので３レコードを送信する。この更新したサービスルートテーブル３６の送信処理は、サービス登録で詳しく説明する。

＜サービス登録＞
図９にサービス登録の動作概要を示す。サービスとアプリケーションとがサービスバスを利用して通信を行う場合、どちらもサービスバスに対してサービス登録を行う必要がある。

サービス４８がサービス登録を行う場合、サービスＩＤ、サービスが動作するサーバ３０の位置（ＩＰアドレス）、サービスタイプ（起動型サービス／読込型サービス／アプリケーション）、プロトコル、入力パラメータ、出力パラメータをデータとしてサービスバス４０（又は３０）に登録する。

アプリケーション３８がサービス登録を行う場合、サービスＩＤ、サービスが動作するサーバの位置（ＩＰアドレス）、サービスタイプ（例えばアプリケーション）、プロトコルをサービスバス３０（又は４０）に登録する。

以下、サービスバス３０にサービス登録を行う場合について説明する。サービスバス３０では、オーダ受付部３１がサービス登録要求を受付け、エンドポイントデータ３２内のサービスエントリテーブル３２ａを参照して自サービスバス３０に登録を要求されたサービスがないことを確認し、サービス通知部３７に処理を渡す。

サービス通知部３７では、エンドポイントデータ３２の更新を行い、バスノードテーブル３５とサービスルートテーブル３６を参照しながら、登録されたサービスを他のサービスバス４０へ通知を行う。

エンドポイントデータ３２は、サービスエントリテーブル３２ａ、入力パラメータテーブル３２ｂ、出力パラメータテーブル３２ｃを有する。サービスエントリテーブル３２ａは、自サービスバスにどのようなサービスが登録されているかを保持するテーブルであり、サービス登録時に渡されたサービスＩＤ、サービスが動作する位置（ＩＰアドレス）、サービスタイプ、プロトコルをサービスやアプリケーションそれぞれを１レコードとして保持する。

入力パラメータテーブル３２ｂは、サービスにアクセスする時に渡すパラメータを保持するテーブルであり、サービス登録時に渡されたサービスＩＤ、パラメータ名と型、その有効値を全ての入力パラメータに対して保持している。

出力パラメータテーブル３２ｃは、サービスにアクセスがあり、サービスが処理を行った後、要求元に対して返却するパラメータを保持するテーブルであり、保持するデータは入力パラメータテーブルのそれと同様である。

図１０は、サービス登録処理のフローチャートを示す。オーダ受付部３１からサービス通知部３７に対し、サービス登録時にサービスから渡されたデータ（サービスＩＤ、サービスが動作するサーバの位置であるＩＰアドレス、サービスタイプ、プロトコル、入力パラメータ、出力パラメータ）が渡される（ステップＳ３１）。まず、渡されたデータの中から、サービスＩＤ、位置、タイプ、プロトコルを抽出してサービスエントリテーブル３２ａに書き込む（ステップＳ３２）。

次に、タイプがアプリケーションの場合はここで処理を終えるが、それ以外の場合（ステップＳ３３）、つまり、起動型サービス又は読込型サービスの場合には渡されたデータの中から、入力パラメータ、出力パラメータを抽出して、それぞれ入力パラメータテーブル３２ｂ、出力パラメータテーブル３２ｃに書き込む（ステップＳ３４）。

次に、サービスルートテーブル３６の更新を行う（ステップＳ３５）。サービスルートテーブル３６は、ノードＩＤ、サービスＩＤ、ホップ数を要素として持つが、ノードＩＤは自ノードのＩＤ、サービスＩＤは登録されたサービスＩＤ、ホップ数は自ノードなので０が設定され、レコード追加される。

ここまでの処理が完了した時点で、隣接ノードがない場合は処理を完了するが、隣接ノードがある場合（ステップＳ３６）、全ての隣接ノードに対して、サービスルートテーブル更新を通知するため、自ノード（要求元）のノードＩＤ、追加したサービス（更新分）のサービスＩＤとホップ数を通知する（ステップＳ３７）。

隣接サービスバス４０はサービスルートテーブル更新通知を受取ると（ステップＳ３８）、図７に示すサービスルートテーブル更新処理に従い、サービスバス４０のサービスルートテーブル４６の更新が行われる（ステップＳ３９）。

ここで、何も更新が行われなかった場合（ステップＳ４０）、サービスバス４０が保持している全てのサービスルートテーブル４６（サービスＩＤとホップ数）を自ノードのノードＩＤ「＃２」と共に、サービスバス３０に対して返却する（ステップＳ４３）。これは、アプリケーションが他の遠隔サービスバスが保有しているサービスにアクセスする場合にどのノードにアクセスしたら良いかの判断に使用される。詳細についてはサービスアクセスにおいて後述する。

一方、サービスルートテーブル４６の更新を行った場合、サービスバス４０に隣接ノードがあれば（ステップＳ４１）、サービスルートテーブル更新を通知するため、自ノード（要求元）のノードＩＤ、追加したサービス（更新分）のサービスＩＤとホップ数を、サービスバス４０の隣接ノードに対して送信する（ステップＳ４２）。このとき通知される情報は、サービスバス３０がサービスバス４０に通知した情報と同じ項目であるが、要求元ノードＩＤは、サービスバス４０となるし、ホップ数も＋１されている。ただし、例外として、通知が無限循環を防ぐために、要求元のサービスバス３０に対しては送信しない。図１０では、ノード「＃３」とノード「＃４」に対してのみ通知を行う。

ノード「＃３」やノード「＃４」においても、サービスバス４０と同じ処理を行うことになる。これを繰り返すことにより、ネットワーク全体にサービスが新たに追加されたことが通知できる。

隣接ノード「＃３，＃４」に対してサービスルートテーブル更新通知が完了すると、要求元のサービスバス３０に対してサービスバス４０が今回更新を行わなかったサービスルートテーブル３６のレコード全て（保持分）を送る（ステップＳ４３）。その応答をサービスバス３０が受取ると、サービスサービスバス４０の処理と同様に、サービスバス３０のサービスルートテーブル更新処理が行われる（ステップＳ４４）。

＜サービスアクセス＞
アプリケーションがサービスにアクセスするには、アプリケーションとサービスが共にサービスバスのサービス登録を行っていることを前提としている。また、アプリケーションが、どこサービスバスに接続されているサービスにどのようなアクセスルートで通信するのかを確立のために、アプリケーションは、アクセス開始要求を行って、アクセスルートを確立した後に、実際にアクセスを実行するステップを踏むことになる。

図１１にアプリケーションがサービスにアクセスするためのルート確立を行うアクセス開始動作の概要を示す。

アプリケーション３８はアクセス開始要求をサービスバス３０に送る。このとき、アプリケーション３８からは、要求元のサービスＩＤと、アクセス先のサービスＩＤをデータとして通知する。オーダ受付部３１でこの要求の受付を行い、受取った要求元サービスＩＤとサービスバス３０が保有しているサービスエントリテーブル３２ａから、要求元のサービス（アプリケーション３８）がこのサービスバス３０に登録されているものかどうかの判断を行う。もし登録されていないものであれば、要求は受付けられない。

サービスバス３０に登録されているアプリケーション３８からの要求であれば、サービス通知部３７に対してアクセス開始の通知を渡し、サービス通知部３７が他のノード（例えば４０）のサービス通知部４７と通信を行って、アクセスルートの確立を行う。詳細は後述する。

アクセスルートの確立が完了すると、サービス通知部３７のメモリ３７ａはルート情報を保持することになる。ルート情報は、要求元サービスＩＤとアクセス先サービスＩＤをキーとして、どのノードを通過するかを順番に記した複数のノードＩＤを要素として持つ。

図１２は、アクセス開始処理のフローチャートを示す。サービスバス３０に接続されているアプリケーション３８からのアクセス開始要求をオーダ受付部３１が受取り、サービス通知部３７がアクセス開始処理を行う（ステップＳ５１）。

まず、サービスルートテーブル３６を参照して（ステップＳ５２）、アクセス先のサービスＩＤが自ノードに接続されているサービスかどうかを判定する（ステップＳ５３）。これは、ホップ数が０かどうかで判定する。また、アクセス先サービスＩＤが他ノードである場合には、サービスルートテーブル３６のノードＩＤをキーとして、バスノードテーブル３５の同じノードＩＤを参照し、該当ノードの位置も取得しておく。

次に、アクセス先が自ノードか他ノードかで処理が分かれる。アクセス先が自ノードの場合、ルート情報としてノードＩＤに自ノードのみが書き込まれ、メモリ３７ａに保存しておく（ステップＳ５４）。更に、サービスエントリテーブル３２ａを参照し、アクセス先サービスの位置、タイプ、プロトコルを取得する。入力パラメータテーブル３２ｂ、出力パラメータテーブル３２ｃを参照し、アクセス先サービスの入出力情報も取得する。読み出した情報は、サービス通知部３７のメモリ３７ａに保存（キャッシュ作成）しておく（ステップＳ５５）。

これは、実際にアクセス実行を行った際、データベースにアクセスをしないで、高速に処理を行うためである。ここまで実施すると、オーダ受付部３１に対して処理結果が返送され、自ノードに登録されているサービスへのアクセス開始処理が終了する。

一方、アクセス先が他ノードの場合、サービスルートテーブル３６を参照して、最初は最も少ないホップ数で到達できるノード（図１１，図１２の例ではサービスバス４０）に対してアクセス開始要求を出す（ステップＳ５６）。この他ノードへのアクセス開始要求のデータとして、ルート情報を通知する。ルート情報には、要求元サービスＩＤ（Ａ）、アクセス先サービスＩＤ（Ｂ）と、最初の隣接ノードへの送信時は自ノードのノードＩＤ＝＃２のみが設定されている。

このアクセス開始要求をサービスバス４０のサービス通知部４７が受取ると（ステップＳ５７）、サービスバス３０と同じようにサービスルートテーブル４６を参照して（ステップＳ５８）、自サービスバス４０に接続されているサービスかを判定する（ステップＳ５９）。

判定の結果、他ノードにあるサービスの場合は、サービスバス３０と同様に初回は最小ホップ数で到達できるノードＩＤ＝＃３に対して、ルート情報と共にアクセス開始要求を出す（ステップＳ６０）。このときのルート情報のノードＩＤには、「＃１」と「＃２」が記載されている。

一方、自ノードに接続されているサービスであると判定された場合は、サービスバス３０で自ノードにサービスが接続されている場合と同様に、サービスエントリテーブルを参照し、サービスエントリ情報（アクセス先サービスの位置、タイプ、プロトコル）を取得する。入力パラメータテーブル、出力パラメータテーブルを参照し、アクセス先サービスの入出力情報も取得する（ステップＳ６１）。そして、ルート情報をメモリ４７ａ上に保存する（ステップＳ６２）。

サービスバス３０の自ノード接続サービスとは異なり、ルート情報のノードＩＤには「＃１」と「＃２」が記載されて書き込まれる。そして、これら収集したサービスエントリ情報、入出力パラメータ情報、ルート情報を要求元のノードＩＤ＝＃１のサービスバス３０に送信する（ステップＳ６３）。

サービスバス３０でこれらの応答情報を受取ると（ステップＳ６４）、処理が正常に終了したかを判定し（ステップＳ６４）、異常終了していた場合には、２番目にホップ数の少ないルートで到達できる隣接ノードに対してアクセス開始要求を出し（ステップＳ５６）、サービスバス４０で説明した処理と同じ処理が隣接ノードで行われる。

処理が正常終了していた場合は、自ノードにサービスが接続されている場合と同様に、サービスバス４０から受取ったルート情報をメモリ３７ａに書き込み（ステップＳ５４）、サービスバス４０から受取った入出力パラメータ情報のキャッシュも作成する（ステップＳ５５）。ここまで完了すると、オーダ受付部３１に対して処理結果が返送される。

なお、サービスバス４０でノード「＃３」からの応答情報を受取った場合（ステップＳ６６）、サービスバス３０と同様に、処理が正常に終了したかを判定し（ステップＳ６７）、異常終了していた場合には、ステップＳ６０に進み、処理が正常終了していた場合は、ステップＳ６２に進む。

なお、オーダ受付部３１は、アプリケーション３８に対して応答を返却するが、このとき、アクセス先サービスのタイプと、入出力パラメータ情報をデータとして送る。こうすることにより、実際にサービスへのアクセスをアプリケーションが行う時に、どのようなパラメータを渡し、どのような情報が処理結果として返却されるかを知ることができる。こうして、アプリケーションからサービスまでのサービスバスを経由したルートが確立できる。

図１３は、ルート確立後にアプリケーションが実際にサービスにアクセスを行った場合のアクセス実行動作の概要を示す。

アプリケーション３８は、自分の使いたいプロトコルで、サービスへのアクセス実行要求をサービスバス３０に対して行う。そうすると、サービスバス３０では、予め用意してあるプロトコルスタック３３でそれを受信し、オーダをサービス通知部３７に送る。

なお、アプリケーション３８からは、アクセス開始時に、要求元サービスＩＤ、アクセス先サービスＩＤに加えて、サービスに入力するための入力パラメータを渡す。この入力パラメータは、アクセス開始時にサービスバス３０からの応答による入力パラメータ情報から分かる。

サービスバス３０の中のサービス通知部３７がアクセス実行要求を受けると、メモリ３７ａのルート情報を参照しながら１つ又は複数のサービスバス３０（，４０）を経由して、入力パラメータをアクセス先のサービス４８が接続されているサービスバス（例えば４０）まで届ける。

このサービスバス４０のサービス通知部４７がアクセス実行要求を受けると、サービスエントリテーブル４２ａを参照して、アクセス先サービスが使用しているプロトコルスタック４３に依頼してサービス４８が動作しているサービスバス４０までオーダを届ける。

図１４は、アクセス実行処理のフローチャートを示す。アプリケーション３８からオーダを受取ったプロトコルスタック３３からサービス通知部３７でアクセス実行要求を受付けると（ステップＳ７１）、アプリケーション３８から渡された入力パラメータと、サービス通知部３７内の入力パラメータ情報キャッシュを比較し（ステップＳ７２）、不正なパラメータであった場合は、要求を受付けない。ここで、入力パラメータのチェックをしているのは、不正なオーダがサービスバス３０，４０間に流通し、ネットワーク負荷を上げてしまうことを防止するためである。

次に、アプリケーション３８から受取った要求元サービスＩＤ、アクセス先サービスＩＤから、サービス通知部３７のメモリ３７ａ上に持つルート情報を読込み、アクセス先までのルート（ノードＩＤ）を取得するのと同時に、バスノードテーブル３５を参照して、隣接のノードＩＤの位置（ＩＰアドレス）も取得する（ステップＳ７３）。

ここで、アクセス先が自サービスバス３０のサービスであれば（ステップＳ７４）、自サービスバス３０のサービスエントリテーブル３２ａに登録されているアクセスサービスの位置（ＩＰアドレス）、タイプ、プロトコルを読出し、アプリケーションが指定してきた入力パラメータ、位置と共に、サービスエントリテーブル３２ａから読み出したプロトコルのプロトコルスタック３３に依頼をかけると、プロトコルスタック３３がサービスに入力パラメータと共にアクセスする（ステップＳ７５）。

一方、アクセス先のサービスが他ノードにある場合、ルート情報に従い次のサービスバス４０に対してアクセス実行処理を送信する。この時に送信するデータは、アプリケーション３８から指定された要求元サービスＩＤ、アクセス先サービスＩＤ、入力情報である。

次のサービスバス４０のサービス通知部４７がアクセス実行処理を受付けると（ステップＳ７６）、サービスバス３０の時と同様に、メモリ４７ａ上のルート情報と受取った要求元サービスＩＤ、アクセス先サービスＩＤから、アクセス先が自ノードに接続されているか、他ノードかを判定する（ステップＳ７７，Ｓ７８）。

他ノードであれば、サービスバス３０と同様に次のノード「＃３」にアクセス実行処理を送信する。自サービスバス４０に接続されている場合、サービスバス３０での自ノードに接続されたサービスの場合と同様の処理が行われ（ステップＳ７９）、プロトコルスタック４３に依頼してサービス４８からの処理結果応答を受取る（ステップＳ８０）。

処理結果は、再度ルート情報を参照し（ステップＳ８１）、今後は要求時とは逆のルートを辿る形で要求元のサービスバス３０に応答結果を送信する（ステップＳ８２）。

この時の応答には、出力パラメータで指定してある情報が返却され、最終的に、アプリケーション３８が接続されているサービスバス３０まで応答が返ってきたら（ステップＳ８３）、サービスエントリテーブル３２ａを参照して（ステップＳ８４）、アプリケーション３８が使用しているプロトコルスタック３３に依頼をかけて（ステップＳ８５）、出力情報（応答結果）と共に、アプリケーションに応答が返却される。

このようにして、アプリケーション３８から複数のサービスバス３０，４０を経由してサービス４８にアクセスすることが可能になる。

＜複数サービスバス連携＞
図１５に、複数サービスバスが連携した実施形態を示す。この実施形態では、ノードＩＤ＝＃１のサービスバス３０とノードＩＤ＝＃２のサービスバス４０が既に接続されていて、サービスバス３０には、サービスＩＤ＝Ａのアプリケーション７１とサービスＩＤ＝Ｂのサービス７２が接続され、サービスバス４０には、サービスＩＤ＝Ｃのサービス７３とサービスＩＤ＝Ｄのサービス７４がそれぞれ接続されている。

この構成に、新たにノードＩＤ＝＃３のサービスバス６０を接続し、更に、サービスバス６０にサービスＩＤ＝Ｅのサービス７５を接続し、更に、アプリケーション７１からサービス７３にアクセスする実施形態を説明する。

サービスバス３０と４０は、既に接続さているので、図示したように、バスノードテーブル３５，４５、サービスルートテーブル３６，４６、サービスエントリテーブル３２ａ，４２ａは作成されているものとする。

＜サービスバスの登録＞
新規にサービスバス６０の設定を行い、サービスバス６０からサービスバス３０とサービスバス４０への接続設定について図１６及び図１７を用いて説明する。

図１６は、追加のサービスバス６０を既存のサービスバス３０に接続するシーケンスを示す。シーケンスは既に自サービスバス６０のサービスバス登録は完了しており、サービスバス３０の追加を行うところから開始されている。

サービスバス６０はサービスバス３０の登録要求を受けると、サービスバス６０のバスノードテーブルに保守者により入力されたサービスバス３０の位置をレコード追加した後（ステップＳ９１）、隣接ノードであるサービスバス３０に対してバスノードテーブルの更新通知を出す（ステップＳ９２）。このとき、要求ノードＩＤ＝＃３と要求元位置（１０．２０．３０．３）をデータとして渡す。

サービスバス３０がその通知を受取ると、バスノードテーブル３５に受取った情報を追加し、サービスバス３０の保有しているサービスルートテーブル３６をサービスバス６０に送り返す（ステップＳ９３）。

サービスバス６０では、図７に示すサービスルートテーブル更新処理に従って、サービスルートテーブルに何も設定されていないサービスバス６０は、受取ったホップ数に＋１した上で、ノードＩＤを「＃１」として、全ての情報をサービスルートテーブルに書き込む（ステップＳ９４）。

図１７は、更に、追加のサービスバス６０を既存のサービスバス４０に接続するシーケンスを示す。サービスノードテーブルを更新し（ステップＳ９５）、サービスバス４０に対してバスノードテーブル更新通知を出す（ステップＳ９６）。サービスバス４０のサービスルートテーブル４６をサービスバス６０に送信し（ステップＳ９７）、サービスバス６０が受取るまではサービスバス３０を追加した場合と同じ動作である。

すなわち、図７に示すサービスルートテーブル更新処理に従って、受取ったサービスノードテーブルのホップ数に＋１した後、サービスバス６０が既に持っているサービスノードテーブルを読出し、ステップＳ２４の「自サービスバスノードのサービスか？」はＮＯ、ステップＳ２５の「既に登録済みのサービスか？」はＮＯ、ステップＳ２７の「既存ホップ数≧入力されたホップ数」はサービス７２はＮＯであるが、ステップＳ２６の「同一サービスＩＤ数が最大を超えているか？」はＮＯ（ここでは最大数２としている）であるので、全てのレコードをサービスノードテーブルに追加書き込みする。

ここからは、サービスバス３０を追加した時と状況が異なり、図６におけるステップＳ１３の「他のサービスバスノードがあるか？」は、サービスバス３０があるのでＹＥＳとなるので、今回追加したサービスルートテーブルをサービスバス３０に対して送信する（ステップＳ９８）。

サービスバス３０はサービスルートテーブル更新通知を受取ると、図１０に示すサービス登録処理に従い、サービスバス３０のサービスルートテーブル３６を更新する（ステップＳ９９）。更新に際しては、図７に示すサービスルートテーブル更新処理に従う。今回の場合、サービスＩＤ＝Ｂは、サービスバス３０にとっては、自ノードのサービスなので追加されない。それ以外のサービスＩＤ＝Ｃ、サービスＩＤ＝Ｄに関しては、更新条件に合致するので、ホップ数を＋１した後にサービスバス３０のサービスルートテーブル３６に追加される。

従って、図１０のステップＳ４０では、「更新したか？」はＹＥＳとなり、更に、ステップＳ４１の「要求元以外の隣接サービスバスノードがあるか？」に対しても、サービスバス４０があるのでＹＥＳとなる。

よって、今回サービスバス３０のサービスルートテーブル３６に追加した分をサービスバス４０に送信することになり、サービスバス４０でもサービスバス３０と同様に、サービスルートテーブル３６の更新が行われる。

また、サービスバス３０からサービスバス６０に対する応答として、サービスバス３０のサービスルートテーブル３６のうち、今回更新していないもの（保持分）を送ることになる（ステップＳ９９）。サービスバス３０の保持分は、サービスＩＤ＝Ｂでホップ数０、サービスＩＤ＝Ｃでホップ数１、サービスＩＤ＝Ｄでホップ数１である。

サービスバス６０では、これらのホップ数に＋１して、既存のサービスルートテーブル３６と比較する。この場合、既に登録されているものと一致するので、図７のステップＳ２５の「既に登録済みのサービスか？」がＹＥＳとなるので、更新は行われず、また、サービスバス３０から隣接ノードへのサービスルートテーブル更新通知は行われない。これで図１０のステップＳ４２のサービスルートテーブル送信（更新分のみ）が終了する（ステップＳ１００）。

次に、サービスバス６０はサービスルートテーブル送信（保持分のみ）をサービスバス４０に対して送り返す処理を行う（ステップＳ１０１）。ここでのサービスバス６０の保持分は、サービスＩＤ＝Ｂでホップ数１、サービスＩＤ＝Ｃでホップ数２、サービスＩＤ＝Ｄでホップ数２である。

サービスバス４０がこれを受取ると、サービス７３，７４は自ノードのサービスなので追加されない。サービスＩＤ＝Ｂでホップ数１のみ、サービスバス４０でホップ数＋１されて追加更新される。サービスバス４０から同様に保持分をサービスバス６０に送り返すが、これらは既にサービスバス６０で登録されているものなので、更新は行われない（ステップＳ１０２）。

これらを繰り返すことによって、全てのサービスバスが自律で、サービスがどこにあるのかを把握できるようになる。

＜サービスの登録＞
図１８は、サービスバス６０にサービス７５を登録するシーケンスを示す。サービスを行っているサーバから、サービスバス６０がサービス追加オーダを受取ると、図１０に示すサービス登録処理に従い、サービスエントリテーブルにサービスＥの情報が追加され（ステップＳ１１０）、タイプが起動型のサービスなので、続いて入力パラメータテーブル、出力パラメータテーブルが追加更新される（ステップＳ１１１）。

更に、サービスルートテーブルにサービスＩＤ＝Ｅをホップ数０として追加登録すると、後は、サービスバスの登録と同様の手順で、追加分のサービスルートテーブルを隣接ノード（３０と４０）に対して送信する（ステップＳ１１２）。

サービスバス３０とサービスバス４０でも同様の論理で、送られて来たサービスルートテーブル３６，４６を更新し、保持分を要求元に送り返すことを繰り返す。この手順で行うことにより、全てのサービスバスに対して、サービスＥが追加されたことが通知される。

＜サービスへのアクセス＞
図１９は、アプリケーション７１からサービス７３にサービスアクセスを行うシーケンスを示す。アプリケーション７１は、まず、アクセス開始要求をサービスバス３０に送信する（ステップＳ１２０）。図１２のアクセス開始処理に従い、サービスバス３０のサービスルートテーブル３６にサービス７３はホップ数０で存在していないので、他ノードのサービスであることが分かる（ステップＳ１２１）。

すると、ホップ数１で到達できるサービスバス４０にアクセスすることを決定する。そして、サービスバス３０からサービスバス４０に対してアクセス開始要求が送信される（ステップＳ１２２）。この時に送信されるデータは、要求元サービスＩＤ＝Ａ、アクセス先サービスＩＤ＝Ｃ、ルート情報＝＃１である。

サービスバス４０においても、図１２のアクセス開始処理に従い、サービスバス４０のサービスルートテーブル４６にサービス７３はホップ数０で存在しているので、自ノードのサービスであると判定できる。すると、サービスエントリデータテーブル、入力パラメータテーブル、出力パラメータテーブルを参照して、サービス７３の情報を取得する（ステップＳ１２３）。

次に、受取ったルート情報（サービスバス３０のみ）に、自ノード（サービスバス４０）を加えた形で、ルート情報をメモリ４７ａに保存する（ステップＳ１２４）。ここまで完了したら、サービスエントリ情報、入出力パラメータ情報、ルート情報をサービスバス３０に返却する。

サービスバス３０では、受取ったルート情報をメモリ３７ａに保存し、更に、入出力パラメータ情報もメモリ３７ａに保存してキャッシュを作成し（ステップＳ１２５，Ｓ１２６）、アプリケーション７１に対して応答を返却する。サービスＡに応答を返却する際に、要求元サービスＩＤ＝Ａ、アクセス先サービスＩＤ＝Ｃ、サービスタイプ＝起動型、入力パラメータ＝Ｐ１，Ｐ２，…、出力パラメータ＝Ｏ１，Ｏ２，…をデータとして渡す。

次に、アプリケーション７１がサービス７３へのアクセス実行を行う（ステップＳ１２７）。アプリケーション７１は、サービスバス３０に対してアクセス実行要求を出す。このときのデータは、要求元サービスＩＤ＝Ａ、アクセス先サービスＩＤ＝Ｃ、入力パラメータ＝Ｐ１＝ＸＸ，Ｐ２＝ＸＸ…である。

サービスバス３０では、アクセス実行要求を受取ると図１４のアクセス実行処理に従い、入力パラメータのキャッシュとアプリケーション７１が送信してきた入力パラメータの比較を行った後、メモリ３７ａ上のルート情報を参照して、隣接するサービスバス４０にアクセス開始要求を出す（ステップＳ１２９）。この情報もアプリケーション７１がサービスバス３０に送信したデータと同じく、要求元サービスＩＤ＝Ａ、アクセス先サービスＩＤ＝Ｃ、入力パラメータ＝Ｐ１＝ＸＸ，Ｐ２＝ＸＸ…を送信する。

サービスバス４０は、この情報を受取ると図１４のアクセス実行処理に従い、メモリ上のルート情報を参照し、自ノードのサービスへのアクセスであることが判定できるため、サービスエントリテーブル４２ａを参照して、サービス７３が使用するＳＭＴＰのプロトコルスタック４３に対してサービス７３の位置（１０．２０．３０．２１）と入力パラメータ＝Ｐ１＝ＸＸ，Ｐ２＝ＸＸ…を渡す（ステップＳ１３０）。

これにより、プロトコルスタック４３は、サービス７３に入力パラメータ＝Ｐ１＝ＸＸ，Ｐ２＝ＸＸ…を届ける（ステップＳ１３１）。プロトコルスタック４３は、サービス７３からの出力パラメータ＝Ｏ１＝ＸＸ，Ｏ２＝ＸＸ…を受取り（ステップＳ１３２）、サービスバス４０のメモリ４７ａ上のルート情報から、逆方向のサービスバス３０に処理結果を返却する（ステップＳ１３３）。

サービスバス３０では、サービスバス４０と同様に、サービスエントリテーブル３２ａを参照し、アプリケーション７１が使用するＳＯＡＰのプロトコルスタック３３に対して応答依頼を出し、アプリケーション７１に出力パラメータ＝Ｏ１＝ＸＸ，Ｏ２＝ＸＸ…が届けられる（ステップＳ１３４）。こうして、アプリケーション７１からサービス７３へのアクセスが完了する。

従来のサービスバスでは、保守者がサービス毎のエンドポイントデータ登録を行い、かつ、アプリケーションとアプリケーションが接続サービスの組合せ毎にエンドポイントデータ３２登録が必要であった。これは、１０（通り）のサービスが接続するサービスバスでは、１０のエンドポイントデータ登録が必要になり、更に、アプリケーションを１０（通り）接続して、各アプリケーションが１０のサービス全てに接続しようとすると、１０×１０＝１００個のエンドポイントデータの登録が必要であることを意味する。

アプリケーションやサービスが１０くらいならまだ良いかもしれないが、１００や１０００のアプリケーションやサービスを扱うとなると、その２乗の保守手順が必要になり、とても管理しきれない。

上記実施形態では、エンドポイントデータの登録は、各アプリケーションやサービスが自律で行うことが可能となるため、エンドポイント登録に関する保守手順は不要になる。保守者は、サービスバスノードの登録を行い、接続させる隣接ノードの登録のみを行えば良いので、アプリケーションやサービスの数に依存することなく、管理するサービスのネットワークトポロジ（サーバ接続構成）のみを管理するだけで良く、従来に比較して保守手順を軽減できる。

また、従来のサービスバスでは、複数サービスバスの連携が不可能であったため、アプリケーション数やサービス数が増え、アクセス頻度が大きくなると、サーバ処理能力を超えてしまうので、複数のサーバを用意して負荷分散させるためには、サービスやアプリケーションを少数に分割してサーバに接続させる方法しかできなかった。

このようにした場合でも、１台のサーバに収容できるサービスは限られてくるので、運用形態（使うサービスを限定したアプリケーションを集める等）の違うサーバ複数を用意して分割しておくしかなかった。

上記実施形態により、複数サービスバスの連携が可能となったことで、１台に収容可能なサービス数やアプリケーション数を超えた場合には、更に１台のサービスバスを用意し、新規のサービスやアプリケーションを新規のサービスバスにだけ接続させることができ、サービスやアプリケーションの追加を容易に実施できる。更に、ビジネス的な効果としては、従来別々の事業者が運用していたサービスバスを他事業者に公開してサービスを利用できることが可能となり、事業者間でアクセスできなかったサービスに今までと同じプラットフォームからアクセスできる。こうなると、利用料を事業者間で支払うことによる新たなビジネスが生まれることになる。
（付記１）
複数のサービスバスを連携させるサービスバス連携方法において、
追加するサービスバスに接続先である既存のサービスバスのノード識別子と位置を入力して、前記追加するサービスバスにおける自サービスバス及び隣接サービスバスの識別子と位置を保存するバスノードテーブルに前記既存のサービスバスのノード識別子と位置を登録し、
前記追加するサービスバスから前記既存のサービスバスにバスノードテーブル更新通知を行い、
前記バスノードテーブル更新通知により前記既存のサービスバスのバスノードテーブルに前記追加するサービスバスのノード識別子と位置を登録する
ことを特徴とするサービスバス連携方法。
（付記２）
付記１記載のサービスバス連携方法において、
前記バスノードテーブル更新通知により前記既存のサービスバスにおけるサービスにアクセスするためのサービスバス識別子とサービス識別子とホップ数を保存するサービスルートテーブルを読み出して前記追加するサービスバスに送信し、
前記追加するサービスバスで受信した前記既存のサービスバスのバスノードテーブルに基づいて前記追加するサービスバスのサービスルートテーブルの更新を行う
ことを特徴とするサービスバス連携方法。
（付記３）
付記２記載のサービスバス連携方法において、
任意のサービスバスに登録するサービスのサービス識別子と位置と入出力情報を入力して、前記任意のサービスバスのエンドポイントデータに前記登録するサービスのサービス識別子と位置と入出力情報を登録し、
前記任意のサービスバスのサービスルートテーブルに前記任意のサービスバスのノード識別子と前記登録するサービスのサービス識別子とホップ数を登録し、
前記サービスを登録した前記任意のサービスバスのサービスルートテーブルを隣接するサービスバスに送信し、
前記隣接するサービスバスのサービスルートテーブルに前記任意のサービスバスから送信されたサービスルートテーブルにより更新し、
前記隣接するサービスバスのサービスルートテーブルを前記任意のサービスバスに送信し、
前記任意のサービスバスのサービスルートテーブルを受信した前記隣接するサービスバスのサービスルートテーブルにより更新する
ことを特徴とするサービスバス連携方法。
（付記４）
付記３記載のサービスバス連携方法において、
前記隣接するサービスバスの更新したサービスルートテーブルを前記隣接するサービスバスに更に隣接するサービスバスに送信する、
ことを特徴とするサービスバス連携方法。
（付記５）
付記３記載のサービスバス連携方法において、
前記任意のサービスバスは、前記任意のサービスバスのサービスルートテーブルの更新分を前記隣接するサービスバスに送信し、
前記隣接するサービスバスは、前記隣接するサービスバスのサービスルートテーブルの全てを前記任意のサービスバスに送信する
ことを特徴とするサービスバス連携方法。
（付記６）
付記２又は３記載のサービスバス連携方法において、
前記サービスルートテーブルの更新は、サービス識別子が同一のものについて、自サービスバスのサービスルートテーブルのホップ数が、隣接したサービスバスから受信したサービスルートテーブルのホップ数に１を加算した値以上の場合に行う
ことを特徴とするサービスバス連携方法。
（付記７）
付記２乃至６のいずれか１項記載のサービスバス連携方法において、
アプリケーションからサービスに対するアクセス開始を入力して、前記アプリケーションが接続されたサービスバスから前記サービスが接続されたサービスバスまで隣接するサービスバスにアクセス開始要求を順に送信し、
前記アクセス開始要求の応答により、前記アプリケーションが接続されたサービスバスから前記サービスが接続されているサービスバスまでの隣接する全てのサービスバスのノード識別子をルート情報として得る
ことを特徴とするサービスバス連携方法。
（付記８）
付記７記載のサービスバス連携方法において、
前記サービスが接続されているサービスバスに格納されているエンドポイントデータから前記サービスに対応する入出力情報を得て、前記アクセス開始要求の応答として前記アプリケーションに通知する
ことを特徴とするサービスバス連携方法。
（付記９）
付記８記載のサービスバス連携方法において、
前記アプリケーションからサービスに対するアクセス実行を入力して、前記アプリケーションが接続されたサービスバスで前記ルート情報を用いて前記サービスバスまでアクセス実行要求を送信する
ことを特徴とするサービスバス連携方法。
（付記１０）
複数のサービスバスを連携させるサービスバスシステムのサービスバスにおいて、
外部端末から入力される接続先である既存のサービスバスのノード識別子と位置を、自サービスバス及び隣接サービスバスの識別子と位置を保存するバスノードテーブルに登録する第１登録手段と、
前記既存のサービスバスにバスノードテーブル更新通知を行う更新通知手段と、
受信した前記バスノードテーブル更新通知により前記バスノードテーブルに隣接する他のサービスバスのノード識別子と位置を登録する第２登録手段と、
を有することを特徴とするサービスバス。
（付記１１）
付記１０記載のサービスバスにおいて、
受信した前記バスノードテーブル更新通知によりサービスにアクセスするためのサービスバス識別子とサービス識別子とホップ数を保存するサービスルートテーブルを読み出して前記前記バスノードテーブル更新通知を送信したサービスバスに送信する第１送信手段と、
受信した前記サービスルートテーブルに基づいて自サービスバスのサービスルートテーブルを更新する第１更新手段と、
を有することを特徴とするサービスバス。
（付記１２）
付記１１記載のサービスバスにおいて、
任意のサービスバスに登録するサービスのサービス識別子と位置と入出力情報を入力して、前記任意のサービスバスのエンドポイントデータに前記登録するサービスのサービス識別子と位置と入出力情報を登録する第３登録手段と、
前記任意のサービスバスのサービスルートテーブルに前記任意のサービスバスのノード識別子と前記登録するサービスのサービス識別子とホップ数を登録する第４登録手段と、
前記サービスを登録した前記任意のサービスバスのサービスルートテーブルを隣接するサービスバスに送信する第２送信手段と、
前記隣接するサービスバスのサービスルートテーブルに前記任意のサービスバスから送信されたサービスルートテーブルにより更新する第２更新手段と、
前記隣接するサービスバスのサービスルートテーブルを前記任意のサービスバスに送信する第３送信手段と、
前記任意のサービスバスのサービスルートテーブルを受信した前記隣接するサービスバスのサービスルートテーブルにより更新する第３更新手段と、
を有することを特徴とするサービスバス。
（付記１３）
付記１２記載のサービスバスにおいて、
前記隣接するサービスバスの更新したサービスルートテーブルを前記隣接するサービスバスに更に隣接する他のサービスバスに送信する第４送信手段を
有することを特徴とするサービスバス。
（付記１４）
付記１３記載のサービスバスにおいて、
前記第３送信手段は、前記隣接するサービスバスのサービスルートテーブルの全てを前記任意のサービスバスに送信し、
前記第４送信手段は、前記隣接するサービスバスのサービスルートテーブルの更新分を前記更に隣接する他のサービスバスに送信する
ことを特徴とするサービスバス。
（付記１５）
付記１１記載のサービスバスにおいて、
前記第１更新手段は、サービス識別子が同一のものについて、自サービスバスのサービスルートテーブルのホップ数が、隣接したサービスバスから受信したサービスルートテーブルのホップ数に１を加算した値以上の場合に行う
ことを特徴とするサービスバス。
（付記１６）
付記１２記載のサービスバスにおいて、
前記第２更新手段は、サービス識別子が同一のものについて、自サービスバスのサービスルートテーブルのホップ数が、隣接したサービスバスから受信したサービスルートテーブルのホップ数に１を加算した値以上の場合に行う
ことを特徴とするサービスバス。
（付記１７）
付記１５記載のサービスバスにおいて、
前記第１更新手段は、隣接したサービスバスから受信したサービスルートテーブルのホップ数に１を加算した値が予め設定された上限数未満の場合に行う
ことを特徴とするサービスバス。
（付記１８）
付記１６記載のサービスバスにおいて、
前記第２更新手段は、隣接したサービスバスから受信したサービスルートテーブルのホップ数に１を加算した値が予め設定された上限数未満の場合に行う
ことを特徴とするサービスバス。
（付記１９）
付記６記載のサービスバス連携方法において、
前記サービスルートテーブルの更新は、隣接したサービスバスから受信したサービスルートテーブルのホップ数に１を加算した値が予め設定された上限数未満の場合に行う
ことを特徴とするサービスバス連携方法。

サービスバスの概念を示す図である。 サービスアクセスの形態を説明するための図である。 従来のサービスバスの一例の構成図である。 サービスバスシステムの一実施形態の構成図である。 サービスバス登録の動作概要を示す図である。 サービスバス登録処理のフローチャートである。 サービスルートテーブル更新処理のフローチャートである。 サービスルートテーブルの様子を示す図である。 サービス登録の動作概要を示す図である。 サービス登録処理のフローチャートである。 アクセス開始動作の概要を示す図である。 アクセス開始処理のフローチャートである。 アクセス実行動作の概要を示す図である。 アクセス実行処理のフローチャートである。 複数サービスバスが連携した実施形態を示す図である。 ノード新規追加のシーケンスである。 ノード追加のシーケンスである。 サービス登録のシーケンスである。 サービスアクセスのシーケンスである。

符号の説明

３０，４０ サービスバス（ノード）
３１，４１ オーダ受付部
３２，４２ エンドポイントデータ
３３，４３ プロトコルスタック
３４，４４ サービスバス登録部
３５，４５ バスノードテーブル
３６，４６ サービスルートテーブル
３７，４７ サービス通知部
３８ アプリケーション
３９，４９ 保守端末
４８ サービス

Claims (10)

1. 複数のサービスバスを連携させるサービスバス連携方法において、
   追加するサービスバスに接続先である既存のサービスバスのノード識別子と位置を入力して、前記追加するサービスバスにおける自サービスバス及び隣接サービスバスの識別子と位置を保存するバスノードテーブルに前記既存のサービスバスのノード識別子と位置を登録し、
   前記追加するサービスバスから前記既存のサービスバスにバスノードテーブル更新通知を行い、
   前記バスノードテーブル更新通知により前記既存のサービスバスのバスノードテーブルに前記追加するサービスバスのノード識別子と位置を登録する
   ことを特徴とするサービスバス連携方法。
2. 請求項１記載のサービスバス連携方法において、
   前記バスノードテーブル更新通知により前記既存のサービスバスにおけるサービスにアクセスするためのサービスバス識別子とサービス識別子とホップ数を保存するサービスルートテーブルを読み出して前記追加するサービスバスに送信し、
   前記追加するサービスバスで受信した前記既存のサービスバスのバスノードテーブルに基づいて前記追加するサービスバスのサービスルートテーブルの更新を行う
   ことを特徴とするサービスバス連携方法。
3. 請求項２記載のサービスバス連携方法において、
   任意のサービスバスに登録するサービスのサービス識別子と位置と入出力情報を入力して、前記任意のサービスバスのエンドポイントデータに前記登録するサービスのサービス識別子と位置と入出力情報を登録し、
   前記任意のサービスバスのサービスルートテーブルに前記任意のサービスバスのノード識別子と前記登録するサービスのサービス識別子とホップ数を登録し、
   前記サービスを登録した前記任意のサービスバスのサービスルートテーブルを隣接するサービスバスに送信し、
   前記隣接するサービスバスのサービスルートテーブルに前記任意のサービスバスから送信されたサービスルートテーブルにより更新し、
   前記隣接するサービスバスのサービスルートテーブルを前記任意のサービスバスに送信し、
   前記任意のサービスバスのサービスルートテーブルを受信した前記隣接するサービスバスのサービスルートテーブルにより更新する
   ことを特徴とするサービスバス連携方法。
4. 請求項３記載のサービスバス連携方法において、
   前記隣接するサービスバスの更新したサービスルートテーブルを前記隣接するサービスバスに更に隣接する他のサービスバスに送信する、
   ことを特徴とするサービスバス連携方法。
5. 請求項４記載のサービスバス連携方法において、
   前記隣接するサービスバスは、前記隣接するサービスバスのサービスルートテーブルの全てを前記任意のサービスバスに送信し、前記隣接するサービスバスのサービスルートテーブルの更新分を前記更に隣接する他のサービスバスに送信する
   ことを特徴とするサービスバス連携方法。
6. 請求項２又は３記載のサービスバス連携方法において、
   前記サービスルートテーブルの更新は、サービス識別子が同一のものについて、自サービスバスのサービスルートテーブルのホップ数が、隣接したサービスバスから受信したサービスルートテーブルのホップ数に１を加算した値以上の場合に行う
   ことを特徴とするサービスバス連携方法。
7. 請求項２乃至６のいずれか１項記載のサービスバス連携方法において、
   アプリケーションからサービスに対するアクセス開始を入力して、前記アプリケーションが接続されたサービスバスから前記サービスが接続されたサービスバスまで隣接するサービスバスにアクセス開始要求を順に送信し、
   前記アクセス開始要求の応答により、前記アプリケーションが接続されたサービスバスから前記サービスが接続されているサービスバスまでの隣接する全てのサービスバスのノード識別子をルート情報として得る
   ことを特徴とするサービスバス連携方法。
8. 請求項７記載のサービスバス連携方法において、
   前記サービスが接続されているサービスバスに格納されているエンドポイントデータから前記サービスに対応する入出力情報を得て、前記アクセス開始要求の応答として前記アプリケーションに通知する
   ことを特徴とするサービスバス連携方法。
9. 請求項８記載のサービスバス連携方法において、
   前記アプリケーションからサービスに対するアクセス実行を入力して、前記アプリケーションが接続されたサービスバスで前記ルート情報を用いて前記サービスバスまでアクセス実行要求を送信する
   ことを特徴とするサービスバス連携方法。
10. 複数のサービスバスを連携させるサービスバスシステムのサービスバスにおいて、
    外部端末から入力される接続先である既存のサービスバスのノード識別子と位置を、自サービスバス及び隣接サービスバスの識別子と位置を保存するバスノードテーブルに登録する第１登録手段と、
    前記既存のサービスバスにバスノードテーブル更新通知を行う更新通知手段と、
    受信した前記バスノードテーブル更新通知により前記バスノードテーブルに隣接する他のサービスバスのノード識別子と位置を登録する第２登録手段と、
    を有することを特徴とするサービスバス。

Images