(57)【要約】【課題】サービス連携によりＢＰを処理するシステムにおいて、短時間で大量のＢＰを処理すること。【解決手段】サービスノード２の送信先問合せ部２２は、サービス処理部２１の実行結果をもとに、次のサービス呼び出しのためのサービス実行要求８３の送信先となるサービスノード２を問い合わせる旨の送信先問合せ要求８１を作成してＢＰノード１に送信し、ＢＰノード１の送信先決定部１１は、受信した送信先問合せ要求８１に含まれる遷移前状態と、実行結果と、の組を検索キーとして、送信先決定テーブル１２を検索し、検索された遷移後状態のサービスノード２を送信先として決定し、サービスノード２のサービス呼出部２３は、決定した送信先のサービスノード２に対して、サービス実行要求８３を送信する。【選択図】図１
2010002963.tif 000002
【特許請求の範囲】
【請求項１】
各状態とその状態間の遷移として表現されるＢＰ（Business Process）を管理するＢＰノードと、ＢＰを構成するサービス呼び出しを受け付けてサービスを実行する複数台のサービスノードと、をネットワークで接続することにより構成されるサービス連携システムにおいて、ＢＰで規定される順にサービス呼び出しを行うサービス連携方法であって、
前記ＢＰノードは、送信先決定部と、応答通知部と、を有するとともに、送信先決定用データを記憶手段に格納し、
前記ＢＰノードの前記送信先決定用データには、所定のサービス呼び出しを示す遷移前状態と、前記所定のサービス呼び出しにおけるサービス処理部の実行結果と、前記所定のサービス呼び出しの次のサービス呼び出しを示す遷移後状態と、がエントリとして対応づけて格納され、
前記サービスノードは、前記サービス処理部と、送信先問合せ部と、サービス呼出部と、を有し、
前記サービスノードの前記サービス処理部は、サービス呼び出しのための第１サービス実行要求を受け付けると、その第１サービス実行要求に含まれるデータをもとにサービスを実行し、
前記サービスノードの前記送信先問合せ部は、前記サービス処理部の実行結果をもとに、次のサービス呼び出しのための第２サービス実行要求の送信先となる前記サービスノードを問い合わせる旨の送信先問合せ要求を作成して前記ＢＰノードに送信し、
前記ＢＰノードの前記送信先決定部は、受信した前記送信先問合せ要求に含まれる遷移前状態と、実行結果と、の組を検索キーとして、前記送信先決定用データを検索し、その検索キーを含むエントリの遷移後状態におけるサービス呼び出しの相手となる前記サービスノードを送信先として決定し、
前記ＢＰノードの前記応答通知部は、前記送信先決定部が決定した送信先を含む送信先応答通知を、前記サービスノードに送信し、
前記サービスノードの前記サービス呼出部は、受信した前記送信先応答通知で指定される送信先の前記サービスノードに対して、前記第２サービス実行要求を送信することを特徴とする
サービス連携方法。
【請求項２】
前記ＢＰノードは、さらに、前記ＢＰノードの通信履歴を示すアクセスログを記憶手段に格納し、
前記ＢＰノードは、
受信した前記送信先問合せ要求と、その送信先問合せ要求の受信時刻を示すタイムスタンプと、その送信先問合せ要求で指定されるＢＰの処理通番と、その送信先問合せ要求への応答となる前記送信先応答通知と、を対応づけて、前記アクセスログに格納し、
前記アクセスログに格納されるデータの中から、同じＢＰの処理通番のデータを、タイムスタンプに従って整列させるトレースデータを抽出することを特徴とする
請求項１に記載のサービス連携方法。
【請求項３】
前記サービスノードは、過去に送信した前記送信先問合せ要求と、その応答である前記送信先応答通知と、の組を対応づけてアクセスキャッシュとして記憶手段に格納し、
前記送信先問合せ部は、作成した前記送信先問合せ要求を検索キーとして前記アクセスキャッシュを検索し、その検索キーを含むエントリが発見されたときには、その発見されたエントリの前記送信先応答通知を、前記ＢＰノードから受信する前記送信先応答通知の代わりとし、前記ＢＰノードへの前記送信先問合せ要求の送信を省略することを特徴とする
請求項１または請求項２に記載のサービス連携方法。
【請求項４】
前記各サービスノードは、共有ストレージと接続され、
前記各サービスノードのうちの第１サービスノードの前記送信先問合せ部は、作成する前記送信先問合せ要求において、前記送信先応答通知の送信先を、前記各サービスノードのうちの前記送信先決定部が決定した第２サービスノードとして指定し、
前記ＢＰノードの前記応答通知部は、受信した前記送信先問合せ要求の指定に従って、前記第２サービスノードへ前記送信先応答通知を送信し、
前記第１サービスノードの前記サービス呼出部は、前記第２サービス実行要求を前記共有ストレージに書き込み、
前記第２サービスノードは、前記送信先応答通知を受信すると、前記共有ストレージから前記第２サービス実行要求を読み取ることを特徴とする
請求項１ないし請求項３のいずれか１項に記載のサービス連携方法。
【請求項５】
前記サービス連携システムには、複数台の前記ＢＰノード、および、それらの前記ＢＰノードと接続されるロードバランサが用いられ、その複数台の前記ＢＰノードの前記送信先決定用データには、互いに同じ内容の前記送信先決定用データのエントリが格納され、
前記ロードバランサは、前記送信先問合せ部から送信される前記送信先問合せ要求を受信すると、複数台の前記ＢＰノードから負荷の軽い前記ＢＰノードを選択して、受信した前記送信先問合せ要求を転送することを特徴とする
請求項１ないし請求項４のいずれか１項に記載のサービス連携方法。
【請求項６】
ＢＰを構成するサービス呼び出しが複数に分岐して並列処理されるときには、前記ＢＰノードの前記送信先決定用データには、１つの遷移前状態と、１つの実行結果と、並列処理される複数の遷移後状態と、がエントリとして対応づけて格納され、
前記サービスノードの前記サービス呼出部は、受信した前記送信先応答通知に含まれる送信先が複数の前記サービスノードであるときには、その複数の前記サービスノードに対して、それぞれ第２サービス実行要求を並列に送信することを特徴とする
請求項１ないし請求項５のいずれか１項に記載のサービス連携方法。
【請求項７】
請求項１ないし請求項６のいずれか１項に記載のサービス連携方法を、コンピュータである前記ＢＰノードおよび前記サービスノードにそれぞれ実行させるためのサービス連携プログラム。
【請求項８】
各状態とその状態間の遷移として表現されるＢＰ（Business Process）を管理するＢＰノードと、ＢＰを構成するサービス呼び出しを受け付けてサービスを実行する複数台のサービスノードと、をネットワークで接続することにより構成されるサービス連携システムに用いられる前記ＢＰノードであって、
前記ＢＰノードは、送信先決定部と、応答通知部と、を有するとともに、送信先決定用データを記憶手段に格納し、
前記送信先決定用データには、所定のサービス呼び出しを示す遷移前状態と、前記所定のサービス呼び出しにおけるサービス処理部の実行結果と、前記所定のサービス呼び出しの次のサービス呼び出しを示す遷移後状態と、がエントリとして対応づけて格納され、
前記送信先決定部は、前記サービスノードから受信した送信先問合せ要求に含まれる、受信相手の前記サービスノードが実行するサービス呼び出しを示す遷移前状態と、受信相手の前記サービスノードによるサービス呼び出しの実行結果と、の組を検索キーとして、前記送信先決定用データを検索し、その検索キーを含むエントリの遷移後状態におけるサービス呼び出しの相手となる前記サービスノードを送信先として決定し、
前記ＢＰノードの前記応答通知部は、前記送信先決定部が決定した送信先を含む送信先応答通知を、前記サービスノードに送信することにより、次のサービス呼び出しを示すサービス実行要求を、決定した送信先の前記サービスノードに対して送信させることを特徴とする
ＢＰノード。
【請求項９】
請求項８に記載のＢＰノード、および、複数台の前記サービスノードを前記ネットワークで接続することにより構成されることを特徴とする
サービス連携システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サービス連携方法、サービス連携プログラム、ＢＰノード、および、サービス連携システムに関する。
【背景技術】
【０００２】
近年、ＳＯＡ（Service Oriented Architecture）の普及により、サービス呼び出しのインタフェースが規格化されたサービスが増加し、サービス呼び出しが容易になった。サービス呼び出しとは、サービスを実施するためのプログラムを実行するコンピュータであるサービスノードに対する、サービスの実施を依頼することである。
【０００３】
そこで、所定の業務の流れを示すＢＰ（Business Process）を個々のサービス呼び出しに分離し、それらのサービス呼び出しを複数台のサービスノードに分散して実行させることにより、ＢＰを実行する形態のサービス連携（協調）システムが増加している。
【０００４】
サービス連携を実現する際に、あるサービスの実行結果（プロセス状態情報）が、別のサービスの実行に必要になることもある。そのときには、あるサービスノードから別のサービスノードへのプロセス状態情報の送信が必要となる。
【０００５】
特許文献１には、サービスノード間のプロセス状態情報のやりとりを仲介する情報共有装置をサービスノードとは別に設け、その情報共有装置に対するサービスノードのデータアクセスに排他制御を導入することにより、プロセス状態情報のやりとりを実現する旨が記載されている。
【特許文献１】特開２００７−２１３６０３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
サービス連携システムの代表的な性能指標として、単位時間あたりに処理可能なＢＰの量（いわゆるスループット）が挙げられる。スループットが高いシステムでは、短時間で大量のＢＰ（トラフィック）を処理することができるため、スループットの向上は、サービス連携システムに対して求められている。
【０００７】
特許文献１に記載された情報共有装置を用いる方式では、サービスノード間でのプロセス状態情報のアクセス衝突を避けるために、排他制御を行う必要があった。このため、この排他処理による負荷が発生してしまい、この負荷がサービス連携システム全体でのボトルネック（弱点）となる。その結果、サービス連携システムのスループットを充分に向上することができなかった。
【０００８】
そこで、本発明は、前記した課題を解決し、サービス連携によりＢＰを処理するシステムにおいて、短時間で大量のＢＰを処理することを、主な目的とする。
【課題を解決するための手段】
【０００９】
前記課題を解決するため、本発明は、各状態とその状態間の遷移として表現されるＢＰ（Business Process）を管理するＢＰノードと、ＢＰを構成するサービス呼び出しを受け付けてサービスを実行する複数台のサービスノードと、をネットワークで接続することにより構成されるサービス連携システムにおいて、ＢＰで規定される順にサービス呼び出しを行うサービス連携方法であって、
前記ＢＰノードが、送信先決定部と、応答通知部と、を有するとともに、送信先決定用データを記憶手段に格納し、
前記ＢＰノードの前記送信先決定用データには、所定のサービス呼び出しを示す遷移前状態と、前記所定のサービス呼び出しにおけるサービス処理部の実行結果と、前記所定のサービス呼び出しの次のサービス呼び出しを示す遷移後状態と、がエントリとして対応づけて格納され、
前記サービスノードが、前記サービス処理部と、送信先問合せ部と、を有し、
前記サービスノードの前記サービス処理部が、サービス呼び出しのための第１サービス実行要求を受け付けると、その第１サービス実行要求に含まれるデータをもとにサービスを実行し、
前記サービスノードの前記送信先問合せ部が、前記サービス処理部の実行結果をもとに、次のサービス呼び出しのための第２サービス実行要求の送信先となる前記サービスノードを問い合わせる旨の送信先問合せ要求を作成して前記ＢＰノードに送信し、
前記ＢＰノードの前記送信先決定部が、受信した前記送信先問合せ要求に含まれる遷移前状態と、実行結果と、の組を検索キーとして、前記送信先決定用データを検索し、その検索キーを含むエントリの遷移後状態におけるサービス呼び出しの相手となる前記サービスノードを送信先として決定し、
前記ＢＰノードの前記応答通知部が、前記送信先決定部が決定した送信先を含む送信先応答通知を、前記サービスノードに送信し、
前記サービスノードが、受信した前記送信先応答通知で指定される送信先の前記サービスノードに対して、前記第２サービス実行要求を送信することを特徴とする。
その他の手段は、後記する。
【発明の効果】
【００１０】
本発明によれば、サービス連携によりＢＰを処理するシステムにおいて、短時間で大量のＢＰを処理することが可能となった。
【発明を実施するための最良の形態】
【００１１】
以下、本発明の一実施形態を、図面を参照して説明する。
【００１２】
図１は、サービス実行システムの一例を示す構成図である。サービス実行システムは、ＢＰノード１と、１台以上（図１では３台を例示）のサービスノード２と、をネットワーク９で接続することにより構成される。ＢＰノード１は、送信先決定部１１と、送信先決定テーブル１２と、応答通知部１４と、を有する。サービスノード２は、サービス処理部２１と、送信先問合せ部２２と、サービス呼出部２３を有する。これらの各構成要素の詳細は図２以降で説明することとし、以下の図１の説明では、本システムの全体的な概要を説明する。
【００１３】
サービスノード２ａは、取引先のクライアント端末（図示省略）などからサービス実行要求８３を受信すると、自身が担当するサービスＡを実施するためのサービス処理部２１を起動する。サービス実行要求８３とは、サービス処理部２１がサービスを実施するために必要な入力パラメータを含む要求メッセージである。
【００１４】
サービスノード２ａの送信先問合せ部２２は、サービス処理部２１の処理結果、および、受信したサービス実行要求８３をもとに、送信先問合せ要求８１を作成し、ＢＰノード１の応答通知部１４に送信する。送信先問合せ要求８１とは、サービスノード２ａが他のサービスノード２と連携するときに、次にサービス実行要求８３を送信する送信先（ここでは、サービスノード２ｂ）を問い合わせる旨の要求メッセージである。
【００１５】
ＢＰノード１の応答通知部１４は、送信先問合せ要求８１を受信すると、その送信先問合せ要求８１に含まれる送信先の手がかりとなるデータを送信先決定部１１に通知して、送信先の決定を依頼する。送信先決定部１１は、通知されたデータと、送信先決定テーブル１２に格納されているデータとを照合することにより、送信先を決定する。送信先決定部１１は、決定された送信先を通知するための送信先応答通知８２を作成して、送信先問合せ部２２に返信する。
【００１６】
サービスノード２ａの送信先問合せ部２２は、受信した送信先応答通知８２に含まれる送信先を参照することにより、次にサービス実行要求８３を送信する送信先が、サービスノード２ｂであることを認識する。そして、サービスノード２ａは、サービス処理部２１の処理結果、および、受信したサービス実行要求８３をもとに、サービス呼出部２３でサービスノード２ｂへのサービス実行要求８３を作成し、サービスノード２ｂに送信する。
【００１７】
以上説明したように、サービスノード２ａからサービスノード２ｂへのサービス連携が、ＢＰノード１による送信先（連携先）の決定処理により、円滑に実行される。同様に、サービスＢを実施するためのサービスノード２ｂから、サービスＣを実施するためのサービスノード２ｃへのサービス連携も、ＢＰノード１が送信先（連携先）を決定することにより、実現される。
【００１８】
以下、サービス実行システムにおいてやりとりされる各メッセージについて、表を参照して説明する。図１の破線矢印で示す送信先問合せ要求８１および送信先応答通知８２は、それぞれシンプルな固定フォーマットのメッセージであるため、細い線で表記した。
一方、図１の実線矢印で示すサービス実行要求８３は、サービスに関する詳細な情報を含む可変フォーマットのメッセージであるため、メッセージ量が多いことにより、太い線で表記した。
【００１９】
【表１】
2010002963.tif 000003
【００２０】
表１に示す送信先問合せ要求８１は、サービスノード２ａからＢＰノード１に送信されるメッセージである。送信先問合せ要求８１は、ＢＰ名と、処理通番と、遷移前状態と、サービス実行結果と、問合せ応答先と、を含めて構成される。
ＢＰ名は、今回のサービス連携の対象となるＢＰの名称である。同じサービス処理を行うとしても、ＢＰ名が異なる場合は、次のサービス処理を示す送信先（連携先）が異なることもある。
処理通番は、ＢＰ名で指定されるＢＰを実施するための処理を単位として、他の処理と区別するために採番される通番である。
遷移前状態は、送信先問合せ要求８１の送信時における、ＢＰ内の状態を示す。
サービス実行結果は、送信先問合せ要求８１を作成するサービスノード２における、サービス処理部２１の処理結果を示す。
問合せ応答先は、この送信先問合せ要求８１を受け取ったＢＰノード１に対して、送信先応答通知８２の応答先を指定する。具体的には、応答先として「問合せ要求元」または「送信先」のいずれかが指定される。なお、図１においては、３つの送信先問合せ要求８１が全て「問合せ要求元」へと応答されるので、送信先問合せ要求８１ごとの指定が不要となり、この「問合せ応答先」を省略してもよい。
【００２１】
【表２】
2010002963.tif 000004
【００２２】
表２に示す送信先応答通知８２は、送信先問合せ要求８１を受信したＢＰノード１からサービスノード２ａに返信されるメッセージである。送信先応答通知８２は、ＢＰ名と、処理通番と、遷移後状態と、送信先と、データタイプと、を含めて構成される。
ＢＰ名と、処理通番とは、送信先問合せ要求８１で指定される値をそのまま代入する。なお、送信先問合せ要求８１の処理通番が（空欄）のときには、ＢＰノード１が既に採番した番号と異なるユニークな番号を処理通番として採番する。
遷移後状態は、送信先問合せ要求８１の遷移前状態からみて、次に遷移するＢＰ内の状態を示す。
送信先は、送信先決定部１１により決定されたサービスノード２が指定される。
データタイプは、送信先に送信する予定のサービス実行要求８３のデータ形式を特定するための情報を示す。送信先応答通知８２を受信したサービスノード２は、データタイプに適合する形式でサービス実行要求８３を作成する。
【００２３】
【表３】
2010002963.tif 000005
【００２４】
表３に示すサービス実行要求８３は、送信先応答通知８２を受信したサービスノード２ａからサービスノード２ｂに送信されるメッセージである。サービス実行要求８３は、ヘッダ部と、データ部とを含めて構成される。ヘッダ部は、ＢＰ名と、処理通番と、遷移前状態と、遷移後状態と、送信先と、データタイプと、を含めて構成される。
ＢＰ名と、処理通番と、遷移前状態には、送信先問合せ要求８１で指定された値を代入する。
遷移後状態と、送信先と、データタイプには、送信先応答通知８２で指定された値を代入する。
【００２５】
サービス実行要求８３のデータ部は、注文対象の商品に関する情報（商品コード、品名、単価）と、注文量に関する情報（商品の数量およびその数量に応じた金額）と、発注者に関する情報（発注者コード、発注者名、発注日）と、納入に関する情報（分割納入可否、最終納期）と、を含む。このデータ部のデータ形式は、ヘッダ部のデータタイプ（在庫確認指示）により規定される。
【００２６】
図２は、図１に示したサービス実行システムを構成する各装置の詳細を示す構成図である。
【００２７】
図２の各装置（ＢＰノード１およびサービスノード２）は、それぞれＣＰＵ（Central Processing Unit）９１と、メモリ９２と、Ｉ／Ｏデバイス９４と、ハードディスク９７と、を少なくとも備えるコンピュータとして構成される。
ＣＰＵ９１は、メモリ９２上の各処理部のプログラムを実行することで、演算処理機能を実現する。
メモリ９２は、ＲＡＭ（Random Access Memory）などにより構成される。メモリ９２は、他装置との通信処理を制御するための通信処理部９５と、各処理部（送信先決定部１１、応答通知部１４、サービス処理部２１、送信先問合せ部２２、サービス呼出部２３）のプログラムとそれらを動作させるためのＯＳ（Operating System）９３と、そのプログラムがアクセスする各データ（送信先決定テーブル１２）と、をハードディスク９７から読み取って記録するとともに、ＣＰＵ９１に実行させるために読み取らせる。
Ｉ／Ｏデバイス９４は、コンソール９６と接続し、このコンソール９６を介してユーザとのやりとり（データ入出力）を実行する。
ハードディスク９７は、プログラムがアクセスする各データ（アクセスログ１３、アクセスキャッシュ２４）を不揮発性の記憶媒体に記憶する。
【００２８】
ＢＰノード１は、送信先決定部１１と、送信先決定テーブル１２と、アクセスログ１３と、応答通知部１４と、を有する。
サービスノード２は、サービス処理部２１と、送信先問合せ部２２と、サービス呼出部２３と、アクセスキャッシュ２４と、を有する。
以下、各構成要素の詳細を説明する。
【００２９】
【表４】
2010002963.tif 000006
【００３０】
表４に示す送信先決定テーブル１２は、ＢＰごとにそのＢＰ内の状態遷移に着目して作成されるテーブルである。送信先決定テーブル１２は、遷移前状態と、サービス実行結果と、送信先応答通知（遷移後状態、送信先、データタイプ）と、を対応づけて構成する。
遷移前状態、および、サービス実行結果は、送信先問合せ要求８１で指定されるデータである。
送信先応答通知（遷移後状態、送信先、データタイプ）は、送信先応答通知８２で指定されるデータである。
以下、送信先決定テーブル１２が作成される過程を説明する。
【００３１】
図３は、図１のサービス実行システムが実行するＢＰの一例を示すフローチャートである。このフローチャートは、受注を受け付けて在庫を確認し出荷指示書を印刷する旨のＢＰを示す。
【００３２】
サービスノード２ａは、サービスＡ処理として取引先のクライアント端末から送信された注文伝票（サービス実行要求８３）を受信すると、サービスノード２ａのサービス処理部２１が、サービスＡ処理（注文受付）を実行する（Ｓ１１）。そして、サービス処理部２１は、サービスＡ処理の結果を判定し（Ｓ１２）、「成功＆少量注文」ならＳ１５へ、「成功＆大量注文」ならＳ１３へ、「失敗」なら「異常終了」へ、それぞれ処理を移行する。
【００３３】
Ｓ１２で「成功＆大量注文」の場合、サービスノード２ｂは、サービスノード２ａから送信された在庫確認指示（サービス実行要求８３）を受信すると、サービスノード２ｂのサービス処理部２１が、サービスＢ処理（在庫確認）を実行する（Ｓ１３）。そして、サービス処理部２１は、サービスＢ処理の結果を判定し（Ｓ１４）、「成功」ならＳ１５へ、「失敗」なら「異常終了」へ、それぞれ処理を移行する。
【００３４】
Ｓ１２で「成功＆少量注文」の場合、または、Ｓ１４で「成功」の場合、サービスノード２ｃは、サービスノード２ｂから送信された出荷指示（サービス実行要求８３）を受信すると、サービスノード２ｃのサービス処理部２１が、サービスＣ処理（出荷）を実行する（Ｓ１３）。具体的には、サービスノード２ｃは、出荷指示に記載された内容を、紙面に出荷指示書として印刷する。そして、サービス処理部２１は、サービスＣ処理の結果を判定し（Ｓ１６）、「成功」なら「正常終了」へ、「失敗」なら「異常終了」へ、それぞれ処理を移行する。
【００３５】
「正常終了」および「異常終了」に処理が移行すると、サービスノード２のコンソール９６上に処理結果に応じたメッセージを表示する。「異常終了」の場合、そのコンソール９６のオペレータがエラー要因を取り除いてから、各サービス処理を続行してもよい。
【００３６】
図４は、図３のＢＰから作成されるＢＰの状態遷移図である。図４の状態遷移図は、楕円で示す各状態と、各状態間を矢印で接続する遷移と、の組み合わせにより表現される。
【００３７】
図４の状態は、サービス呼び出しアクティビティを示す状態（「サービスＡ処理」、「サービスＢ処理」、「サービスＣ処理」）と、ＢＰの処理結果を示す状態（「正常終了」、「異常終了」）とに分類できる。
よって、図３のフローチャートから、サービス呼び出しアクティビティ（Ｓ１１，Ｓ１３，Ｓ１５）および終了端子（「正常終了」、「異常終了」）を検出することにより、ＢＰの各状態を抽出することができる。
【００３８】
図４の各遷移には、遷移条件と、遷移処理とが対応づけられている。遷移条件とは、対応する遷移が発生するための条件である。遷移処理とは、対応する遷移が発生する際に実行される処理内容を示す。
よって、図３のフローチャートから、サービス呼び出しアクティビティの後に行われる判定処理（Ｓ１２，Ｓ１４，Ｓ１６）に着目し、各判定処理の判定結果値（例えば、成功）を遷移条件とし、かつ、その判定処理の次にサービス呼び出しアクティビティが行われるときには、そのサービス呼び出しを行うための指示を遷移処理とすることで、ＢＰの各遷移を抽出することができる。一方、判定処理の次に終了端子が存在するときには、遷移処理は「なし」とする。
【００３９】
表４に戻り、送信先決定テーブル１２は、図４の状態遷移図と等価な情報であり、ＢＰを、各状態とその状態間の遷移で表現するデータ構造である。つまり、表形式で示す送信先決定テーブル１２と、状態遷移図で示す図４のＢＰとは、ともに、送信先決定用データとなる。なぜなら、同じオートマトンは、表形式でも、状態遷移図でも表現できるからである。なお、表４の送信先決定テーブル１２のレコードが含む対応情報「遷移前状態、実行結果、および、遷移後状態」は、遷移前状態および実行結果から遷移後状態を特定するためのエントリの一例である。
例えば、図４の状態遷移図において、状態「サービスＡ処理」から、状態「サービスＢ処理」への遷移として、遷移条件「成功＆大量注文」および遷移処理「在庫確認指示」が示されている。同様に、表４の遷移前状態「サービスＡ処理」のサービス実行結果「成功＆大量注文」は、遷移後状態「サービスＢ処理」、送信先「サービスＢ」、データタイプ「在庫確認指示」に対応づけられている。
なお、表３に示すサービス実行要求８３は、ここで説明した状態「サービスＡ処理」から状態「サービスＢ処理」への遷移における「在庫確認指示」の具体的な内容を示している。
【００４０】
【表５】
2010002963.tif 000007
【００４１】
表５に示すサービス実行要求８３は、表４における状態「サービスＡ処理」から状態「サービスＣ処理」への遷移における「出荷指示」の具体的な内容を示している。この「出荷指示」では、受け付けた注文が「少量注文」なので、納期回数が１回（一括納入）となっている。表５におけるデータ部の形式は、表３と同様である。
【００４２】
【表６】
2010002963.tif 000008
【００４３】
表６に示すサービス実行要求８３は、表４における状態「サービスＢ処理」から状態「サービスＣ処理」への遷移における「出荷指示」の具体的な内容を示している。この「出荷指示」では、受け付けた注文が「大量注文」なので、納期回数が２回（分割納入）となっている。表６におけるデータ部の形式は、表３と同様である。
【００４４】
以上、送信先決定テーブル１２が作成される過程を説明した。この送信先決定テーブル１２の作成処理は、コンピュータ（ＢＰノード１など）が行う自動処理としてもよいし、人間が手作業で送信先決定テーブル１２を作成し、ＢＰノード１に対して作成結果の送信先決定テーブル１２をデータ入力することとしてもよい。
【００４５】
図２の送信先決定部１１は、送信先問合せ要求８１と、その送信先問合せ要求８１で指定されるＢＰ名の送信先決定テーブル１２とを照合することにより、送信先応答通知８２に記載される送信先を決定する。
具体的には、送信先決定部１１は、送信先問合せ要求８１に含まれる「遷移前状態」および「サービス実行結果」の組を検索キーとして、送信先決定テーブル１２から該当する（検索キーを含む）レコードを検索する。そして、送信先決定部１１は、検索されたレコード内の送信先応答通知（遷移後状態、送信先、データタイプ）を、応答するための送信先応答通知８２に含ませる。つまり、送信先決定部１１は、検索されたレコード内の「送信先」を、サービス実行要求８３の送信先となるサービスノード２の特定情報として決定する。
【００４６】
サービスノード２の応答通知部１４は、送信先決定部１１により決定された送信先決定テーブル１２内の送信先応答通知の内容をもとに、送信先応答通知８２を作成し、サービスノード２の送信先決定部１１へと送信（問合せ応答）する。ここで、送信先応答通知８２の問合せ応答先は、送信先問合せ要求８１の「問合せ応答先」において指定されたサービスノード２である。なお、問合せ応答先が「送信先」であっても、送信先決定部１１が送信先「なし」と決定したときには、代わりに「問合せ要求元」が「問合せ応答先」となる。
【００４７】
【表７】
2010002963.tif 000009
【００４８】
表７に示すＢＰノード１のアクセスログ１３は、タイムスタンプと、ＢＰ名と、処理通番と、遷移前状態と、サービス実行結果と、問合せ応答先と、遷移後状態と、送信先と、データタイプと、が対応づけて構成される。このアクセスログ１３は、受信された送信先問合せ要求８１、および、その返答として送信する送信先応答通知８２を対応づけて記録するものである。
タイムスタンプは、受信した送信先問合せ要求８１の受信時刻を示す。なお、タイムスタンプを記録するためには、各ＢＰノード１が内蔵する時計の時刻を、ＮＴＰ（Network Time Protocol）などで互いに合わせておくことが必要である。
遷移前状態と、サービス実行結果と、問合せ応答先とは、送信先問合せ要求８１で指定されるデータである。
遷移後状態と、送信先と、データタイプとは、対応する送信先応答通知８２で指定されるデータである。
【００４９】
アクセスログ１３は、ＢＰの処理状況をトレースするために記録される。ＢＰノード１が実行するトレース処理とは、具体的には、ＢＰ名および処理通番の組が等しいレコードをすべて収集し、タイムスタンプの順に並べるトレースデータを作成する処理である。これにより、アクセスログ１３から一連のＢＰ処理におけるサービス連携の振る舞いを一括で把握することができ、各処理ステップでの処理結果や状態遷移の状況を追跡することができる。
【００５０】
サービスノード２のサービス処理部２１は、受信したサービス実行要求８３をもとに、ＢＰを実現するためのサービスを処理する。このサービス処理部２１は、１台のサービスノード２に対して１つのサービス処理部２１を有する専用装置の形態としてもよいし、１台のサービスノード２に対して複数のサービス処理部２１を有する兼用装置の形態としてもよい。
【００５１】
アクセスキャッシュ２４は、送信先問合せ部２２が送信する送信先問合せ要求８１と、その応答である送信先応答通知８２と、を対応づけて格納するデータであり、送信先決定テーブル１２と同じデータ形式で、その少なくとも一部が格納される。
【００５２】
以上、図２の各構成要素の詳細を説明した。なお、アクセスログ１３およびアクセスキャッシュ２４は、サービス連携を実現する際の付加的な機能を実現するための構成要素であるので、必ず備えている必要があるものではなく、適宜省略が可能である。
【００５３】
図５は、図３のＢＰに沿って、図１のサービス実行システムが実行するサービス連携処理を示すフローチャートである。
【００５４】
サービスノード２ａは、取引先のクライアント端末（図示省略）などからサービス実行要求８３を受信する（Ｓ１０１）と、自身が担当するサービスＡ（注文受付）を実施するためのサービス処理部２１を起動する（Ｓ１０２）。
サービスノード２ａの送信先問合せ部２２は、サービスＡの実行結果（成功＆大量注文）をもとに送信先問合せ要求８１を作成してＢＰノード１の応答通知部１４に送信することで、送信先の問合せを実行する（Ｓ１０３）。
ＢＰノード１の応答通知部１４は、送信先問合せ要求８１を受信すると、送信先決定部１１に対して送信先決定テーブル１２を検索させることにより、送信先（ここでは、サービスＢを処理するサービスノード２ｂ）を決定する（Ｓ１３１）。応答通知部１４は、決定した送信先を含む送信先応答通知８２を作成し、サービスノード２ａに返信する。
サービスノード２ａのサービス呼出部２３は、受信した送信先応答通知８２で指定される送信先（サービスノード２ｂ）およびデータタイプ（在庫確認指示）をもとに、送信先へのサービス実行要求８３を作成し、送信先へ送信する（Ｓ１０４）。
【００５５】
サービスノード２ｂは、サービスノード２ａからサービス実行要求８３を受信する（Ｓ１１１）と、自身が担当するサービスＢ（在庫確認）を実施するためのサービス処理部２１を起動する（Ｓ１１２）。
サービスノード２ｂの送信先問合せ部２２は、サービスＢの実行結果（成功）をもとに送信先問合せ要求８１を作成してＢＰノード１の応答通知部１４に送信することで、送信先の問合せを実行する（Ｓ１１３）。
ＢＰノード１の応答通知部１４は、送信先問合せ要求８１を受信すると、送信先決定部１１に対して送信先決定テーブル１２を検索させることにより、送信先（ここでは、サービスＣを処理するサービスノード２ｃ）を決定する（Ｓ１３２）。応答通知部１４は、決定した送信先を含む送信先応答通知８２を作成し、サービスノード２ｂに返信する。
サービスノード２ｂのサービス呼出部２３は、受信した送信先応答通知８２で指定される送信先（サービスノード２ｃ）およびデータタイプ（出荷指示）をもとに、送信先へのサービス実行要求８３を作成し、送信先へ送信する（Ｓ１１４）。
【００５６】
サービスノード２ｃは、サービスノード２ｂからサービス実行要求８３を受信する（Ｓ１２１）と、自身が担当するサービスＣ（出荷）を実施するためのサービス処理部２１を起動する（Ｓ１２２）。
サービスノード２ｃの送信先問合せ部２２は、サービスＣの実行結果（成功）をもとに送信先問合せ要求８１を作成してＢＰノード１の応答通知部１４に送信することで、送信先の問合せを実行する（Ｓ１２３）。
ＢＰノード１の応答通知部１４は、送信先問合せ要求８１を受信すると、送信先決定部１１に対して送信先決定テーブル１２を検索させることにより、送信先（ここでは、正常終了なので「なし」）を決定する（Ｓ１３３）。応答通知部１４は、決定した送信先を含む送信先応答通知８２を作成し、サービスノード２ｃに返信する。
サービスノード２ｃのサービス呼出部２３は、受信した送信先応答通知８２で指定される送信先が「なし」なので、次のサービス実行要求８３を作成せず、処理を終了する。
【００５７】
図６は、図５の処理において、各装置に着目した処理を示すフローチャートである。
【００５８】
図６（ａ）は、ＢＰノード１の処理を示すフローチャートである。このフローチャートの１回分の処理が、図５の送信先決定処理（Ｓ１３１，Ｓ１３２，Ｓ１３３）のうちの１回分の処理に相当する。
応答通知部１４は、送信先問合せ要求８１を受信すると（Ｓ３１）、その送信先問合せ要求８１の処理通番に値が記載されているか否かを判定する（Ｓ３２）。Ｓ１３２，Ｓ１３３などで処理通番があるとき（Ｓ３２，Ｙｅｓ）にはＳ３４へ、Ｓ１３１などで処理通番がないとき（Ｓ３２，Ｎｏ）にはＳ３３へ、それぞれ移行する。
ＢＰノード１は、処理通番がないとき（Ｓ３２，Ｎｏ）には、新たにユニークな処理通番を採番する（Ｓ３３）。
送信先決定部１１は、送信先決定テーブル１２を参照して、送信先問合せ要求８１で指定された状況に対応する送信先を決定する（Ｓ３４）。
応答通知部１４は、決定された送信先を含む送信先応答通知８２を作成し、サービスノード２へ送信する。なお、Ｓ３３で採番された処理通番は、送信先応答通知８２に記載される。
【００５９】
図６（ｂ）は、サービスノード２の処理を示すフローチャートである。図５では、図６（ｂ）のフローチャートの３回分の処理が、実行される。
サービスノード２は、サービス実行要求８３を受信する（Ｓ４１）と、サービス処理部２１を起動して、自身が担当するサービス処理を実行する（Ｓ４２）。
送信先問合せ部２２は、Ｓ４２の実行結果をもとに送信先問合せ要求８１を作成してＢＰノード１の応答通知部１４に送信することで、送信先の問合せを実行する（Ｓ４３）。
送信先問合せ部２２は、Ｓ４３への応答として受信した送信先応答通知８２を参照し、その中に送信先が指定されているか否かを判定する（Ｓ４４）。送信先があるとき（Ｓ４４，Ｙｅｓ）には、Ｓ４５へ処理を移行し、送信先がないとき（Ｓ４４，Ｎｏ）には、処理を終了する。
送信先があるとき（Ｓ４４，Ｙｅｓ）、サービスノード２のサービス呼出部２３は、受信した送信先応答通知８２で指定される送信先およびデータタイプをもとに、送信先へのサービス実行要求８３を作成し、送信先へ送信する（Ｓ４５）。
【００６０】
以上説明した本実施形態は、以下のようにその趣旨を逸脱しない範囲で広く変形実施することができる。
【００６１】
図７は、サービス実行システムの別の一例（アクセスキャッシュ２４を活用する形態）を示す構成図である。図７と図１との違いは、送信先問合せ要求８１および送信先応答通知８２の送受信を毎回実行するか（図１）、否か（図７）である点と、サービスノード２内にアクセスキャッシュ２４を備えているか（図７）、必須とはしないか（図１）である点である。
【００６２】
図７の各サービスノード２は、アクセスキャッシュ２４を備えている。アクセスキャッシュ２４は、ＢＰノード１が保持している送信先決定テーブル１２の少なくとも一部を、自ノードのメモリ上にキャッシュ（一時的に保持）するデータである。そして、サービスノード２は、既に自ノードが過去に送受信した送信先問合せ要求８１および送信先応答通知８２の組をアクセスキャッシュ２４から参照することにより、サービスノード２内のローカル処理で送信先問合せ要求８１に対応する送信先応答通知８２を取得することができる。
【００６３】
なお、図７においては、３台のサービスノード２のうちの２台分のサービスノード２が、アクセスキャッシュ２４にヒットしたことにより、ＢＰノード１との通信処理を省略している。ヒットしなかったサービスノード２ｂは、今回通信処理によって取得した送信先問合せ要求８１および送信先応答通知８２の組をアクセスキャッシュ２４に格納することにより、次回以降の同じ内容の通信処理を省略できる。
【００６４】
これにより、各サービスノード２は、同じ内容の送信先問合せ要求８１を２回以上ＢＰノード１に送信する必要がなくなるため、サービスノード２とＢＰノード１との間の通信回数を大幅に削減し、１件あたりのＢＰ処理時間を短縮することができる。
このようにアクセスキャッシュ２４を活用する形態は、特に、膨大な件数の注文を非常に高速に処理しなければならない場合に、有効である。
【００６５】
図８は、図３のＢＰに沿って、図７のサービス実行システムが実行するサービス連携処理を示すフローチャートである。
【００６６】
図８と図５との違いは、送信先の問合せ処理（Ｓ１０３，Ｓ１１３，Ｓ１２３）を毎回実行する図５に比べ、アクセスキャッシュ２４への送信先の検索（Ｓ１０３ｂ，Ｓ１２３ｂ）により、送信先の問合せ処理を省略している図８は、通信回数が削減できている点にある。
【００６７】
なお、ＢＰの変更（新規追加や削除も含める）に伴う送信先決定テーブル１２の更新により、送信先決定テーブル１２の内容と、アクセスキャッシュ２４の内容とが不一致となる事態が考えられる。そのため、ＢＰノード１は、送信先決定テーブル１２の内容が更新されたときに、サービスノード２へと更新内容を通知し、サービスノード２のアクセスキャッシュ２４の内容を最新の内容に保つこととしてもよい。
また、ＢＰノード１は、送信先決定テーブル１２の内容とアクセスキャッシュ２４の内容とを同一化するため、送信先問合せ要求８１および送信先応答通知８２の組について、実際に送信された送信先問合せ要求８１だけに限定せずに、複数組をまとめてサービスノード２に通知してもよい。これにより、アクセスキャッシュ２４が徐々に送信先決定テーブル１２に近づいていくペースを、早めることができ、ヒット率を早い段階で向上することができる。
【００６８】
図９は、サービス実行システムの別の一例（共有ストレージ９８を活用する形態）を示す構成図である。図９と図１との違いは、送信先応答通知８２の返信先を必ず「問合せ要求元」とするか（図１）、「送信先」とするか（図９）である点と、共有ストレージ９８を備えているか（図９）否か（図１）という点にある。なお、サービスノード２ｃへの送信先応答通知８２は、その送信先応答通知８２の「送信先」が「なし」であるため、自身へと返信されている。
【００６９】
図９のサービス実行システムは、複数のサービスノード２にそれぞれ接続される共有ストレージ９８を有する。そして、図９では、サービスノード２間のサービス実行要求８３の通信がサービスノード２間で直接行われる図１と異なり、共有ストレージ９８を介して間接的に行われる。
つまり、送信側のサービスノード２のサービス呼出部２３が共有ストレージ９８にサービス実行要求８３を書き込み、受信側のサービスノード２が共有ストレージ９８からサービス実行要求８３を読み込む。
【００７０】
なお、受信側のサービスノード２は、「送信先」として送信された送信先応答通知８２を受信することにより、共有ストレージ９８へのサービス実行要求８３の書き込みを知ることができる。そして、書き込みを知ったサービスノード２は、共有ストレージ９８に対して、サービス実行要求８３を読み取る。
つまり、共有ストレージ９８は、サービス実行要求８３を読み取るサービスノード２を指定する必要がない。よって複数のサービスノード２が同じサービス実行要求８３を読み取る重複処理が発生しない。これにより、共有ストレージ９８は、サービスノード２間の排他制御をする必要がないため、高速なサービス実行要求８３の読み書き処理が可能となる。
【００７１】
これにより、特に、サービス実行要求８３のサイズが非常に大きい場合、ネットワーク９の通信帯域を圧迫せず、円滑な通信処理を実現することができる。
【００７２】
図１０は、図３のＢＰに沿って、図９のサービス実行システムが実行するサービス連携処理を示すフローチャートである。
【００７３】
図１０と図５との違いは、送信先問合せ処理（Ｓ１０３ｃ、Ｓ１１３ｃ）において、送信先問合せ要求８１の応答先として「送信先」を指定することにより、送信先応答通知８２の応答先が変更されている（Ｓ１３１ｃ、Ｓ１３２ｃ）。
そして、図１０と図５との違いは、実行要求の送信処理を送信相手に直接送信する（Ｓ１０４，Ｓ１１４）図５に比べ、共有ストレージ９８を介して間接的に送信する（Ｓ１０４ｃ，Ｓ１１４ｃ）図１０は、点にある。
そのため、共有ストレージ９８は、サービスノード２から受信したサービス実行要求８３を一時的に格納するとともに、別のサービスノード２からの要求に応じて格納しているサービス実行要求８３を転送する（Ｓ１４１，Ｓ１４２）。
【００７４】
図１１は、サービス実行システムの別の一例（ＢＰノード１のクラスタ構成）を示す構成図である。
図１１と図１との違いは、ＢＰノード１の台数を１台にするか（図１）、複数台にするか（図１１）という点と、サービス実行システムにロードバランサ３を含めるか（図１１）、否か（図１）という点にある。
【００７５】
ロードバランサ３は、複数のＢＰノード１に対して、送信先問合せ要求８１および送信先応答通知８２の処理を振り分ける。振り分け先のＢＰノード１は、互いに同じ内容の送信先決定テーブル１２をあらかじめ共有しているので、どのＢＰノード１に対して送信先問合せ要求８１を送信しても、その応答としての送信先応答通知８２の内容は同じである。
【００７６】
よって、ロードバランサ３は、複数のＢＰノード１の中から混雑していないＢＰノード１を選択して処理を振り分けることにより、負荷分散や信頼性確保を実現することができる。例えば、図１１の３台のＢＰノード１のうち、混雑している（既に多くの処理が割り当てられている）ＢＰノード１ａに対して新たに処理を振り分けないことにより、負荷分散が可能となる。
【００７７】
なお、ＢＰノード１は、ＢＰの状態遷移を規定する送信先決定テーブル１２は管理するものの、現在処理中のＢＰの状態そのものは管理しないため、システムの負荷状況に応じてＢＰノード１の台数を増減させることも可能である。
つまり、ＢＰノード１を多重化するときに、ＢＰノード１間でサービスの実行経過を示すプロセス状態情報（サービス実行要求８３におけるデータ部の内容）を管理する必要が無く、容易に多重化構成を実現できる。
【００７８】
図１２は、サービス実行システムが実行するＢＰの別の一例を示すフローチャートである。このフローチャートは、受信したデータに対して、紙面への印刷と記憶媒体への格納とを並列に実行する旨のＢＰを示す。
【００７９】
図１２と図３との主な違いは、図３では各サービス呼び出しアクティビティが直列に実行されるのに対し、図１２では２つのサービス呼び出しアクティビティ（Ｓ２４，Ｓ２６）が並列で実行される。そのために、Ｓ２３において、処理を択一的ではなく並列的に分岐するＡＮＤ分岐（Ｆｏｒｋ分岐とも呼ばれる）を実行する。
まず、サービスＤ処理としてデータ受信処理を行い（Ｓ２１）、その処理結果が失敗なら（Ｓ２２，失敗）、異常終了する。
次に、Ｓ２４とＳ２６とを並列に処理させるＡＮＤ分岐を実行する（Ｓ２３）。
Ｓ２４では、サービスＥ処理として送信されたデータの印刷を行い（Ｓ２４）、その結果が成功であれば（Ｓ２５，成功）正常終了し、失敗であれば（Ｓ２５，異常）異常終了する。
Ｓ２６では、サービスＦ処理として送信されたデータの格納を行い（Ｓ２６）、その結果が成功であれば（Ｓ２７，成功）正常終了し、失敗であれば（Ｓ２７，異常）異常終了する。なお、サービスＢの印刷処理はロールバックが不可能であるため、サービスＢとサービスＣとの処理の同期合わせは行わない。
【００８０】
【表８】
2010002963.tif 000010
【００８１】
表８は、図１２のＢＰに対応した送信先決定テーブル１２の内容を示している。遷移前状態「サービス処理Ｄ」において、サービス実行結果が「成功」の場合に、２つの送信先応答通知が記述されている。この２つの記述は、サービスＤ処理を実行するサービスノード２から、サービスＥ処理を実行するサービスノード２と、サービスＦ処理を実行するサービスノード２と、の両方にサービス実行要求８３を並列で送信することを示す。
【００８２】
以上説明した本実施形態によれば、以下の顕著な効果を得ることができる。
【００８３】
比較例として、ＢＰノード１とサービスノード２との間でサービス実行要求８３およびその応答をやりとりする例を挙げる。この比較例では、サービスノード２間で送受信されるサービス実行要求８３を、ＢＰノード１が中継する必要があるため、ＢＰノード１の通信処理に伴う負荷が大きくなってしまう。
【００８４】
一方、本実施形態のサービス実行システムでは、ＢＰノード１は、サービス実行要求８３の送受信には直接関わらず、その代わりにサービス実行要求８３の送信先を決定する処理（具体的には、送信先問合せ要求８１に対して送信先応答通知８２を応答する処理）を担当する。これにより、ＢＰノード１の負荷が大幅に軽減されることである。
なお、送信先問合せ要求８１および送信先応答通知８２は、表１，表２に示される所定のメッセージ・フォーマットであり、サービス実行要求８３のデータ部に関する詳細な情報を含まないため、パケットサイズが小さくて済む。よって、ＢＰノード１における送信先問合せ要求８１への処理負荷は、比較例におけるサービス実行要求８３への処理負荷に比べ、大幅に軽減される。また、サービスノード２の処理負荷は、本実施形態と比較例とで、ほとんど変わらない。
【００８５】
さらに、本実施形態では、ＢＰノード１がサービス実行要求８３を扱わないため、ＢＰノード１間でサービスの実行経過を示すプロセス状態情報（サービス実行要求８３におけるデータ部の内容）を管理する必要が無い。よって、本実施形態では、ＢＰノード１の障害が発生しても、今まで実行されたプロセス状態情報は失われないので、障害に強いサービス実行システムを提供することができる。一方、比較例では、プロセス状態情報はＢＰノード１側が管理するので、そのＢＰノード１の障害により、プロセス状態情報が失われてしまう可能性がある。
【図面の簡単な説明】
【００８６】
【図１】本発明の一実施形態に関するサービス実行システムの一例を示す構成図である。
【図２】本発明の一実施形態に関する図１に示したサービス実行システムを構成する各装置の詳細を示す構成図である。
【図３】本発明の一実施形態に関する図１のサービス実行システムが実行するＢＰの一例を示すフローチャートである。
【図４】本発明の一実施形態に関する図３のＢＰから作成されるＢＰを示す状態遷移図である。
【図５】本発明の一実施形態に関する図３のＢＰに沿って、図１のサービス実行システムが実行するサービス連携処理を示すフローチャートである。
【図６】本発明の一実施形態に関する図５の処理において、各装置に着目した処理を示すフローチャートである。
【図７】本発明の一実施形態に関するサービス実行システムの別の一例（アクセスキャッシュを活用する形態）を示す構成図である。
【図８】本発明の一実施形態に関する図３のＢＰに沿って、図７のサービス実行システムが実行するサービス連携処理を示すフローチャートである。
【図９】本発明の一実施形態に関するサービス実行システムの別の一例（共有ストレージを活用する形態）を示す構成図である。
【図１０】本発明の一実施形態に関する図３のＢＰに沿って、図９のサービス実行システムが実行するサービス連携処理を示すフローチャートである。
【図１１】本発明の一実施形態に関するサービス実行システムの別の一例（ＢＰノードのクラスタ構成）を示す構成図である。
【図１２】本発明の一実施形態に関するサービス実行システムが実行するＢＰの別の一例を示すフローチャートである。
【符号の説明】
【００８７】
１      ＢＰノード
２      サービスノード
３      ロードバランサ
９      ネットワーク
１１    送信先決定部
１２    送信先決定テーブル
１３    アクセスログ
１４    応答通知部
２１    サービス処理部
２２    送信先問合せ部
２３    サービス呼出部
２４    アクセスキャッシュ
８１    送信先問合せ要求
８２    送信先応答通知
８３    サービス実行要求
９１    ＣＰＵ
９２    メモリ
９３    ＯＳ
９４    Ｉ／Ｏデバイス
９５    通信処理部
９６    コンソール
９７    ハードディスク
９８    共有ストレージ
【図１】
2010002963.tif 000011
【図２】
2010002963.tif 000012
【図３】
2010002963.tif 000013
【図４】
2010002963.tif 000014
【図５】
2010002963.tif 000015
【図６】
2010002963.tif 000016
【図７】
2010002963.tif 000017
【図８】
2010002963.tif 000018
【図９】
2010002963.tif 000019
【図１０】
2010002963.tif 000020
【図１１】
2010002963.tif 000021
【図１２】
2010002963.tif 000022