JP2009169793A

JP2009169793A - サービス管理方法とシステムおよびプログラム

Info

Publication number: JP2009169793A
Application number: JP2008008727A
Authority: JP
Inventors: Susumu Matsuoka; 進松岡
Original assignee: Hitachi Information Systems Ltd
Current assignee: Hitachi Information Systems Ltd
Priority date: 2008-01-18
Filing date: 2008-01-18
Publication date: 2009-07-30
Anticipated expiration: 2028-01-18
Also published as: JP5086820B2

Abstract

【課題】サービスの利用者は、同じ処理内容のサービスが複数ある場合にもそれぞれのサービスを意識することなく、最適なサービスを利用することができ、利用者の操作負荷を軽減する。
【解決手段】ＥＳＢシステム等のサービス管理技術であって、サービス情報格納部１１１は、それぞれ同じ結果を取得できる複数のサービスの各識別情報を１つの共通識別情報に対応付けた対応付け情報（サービス群情報テーブル１１３）を生成し、リクエスト受付部１０６は、サービス利用者（コンピュータ１０２，１０３のサービスリクエスタ処理機能１０２ａ，１０３ａ）からのサービス要求を受け付け、経路制御部１０７は、要求されたサービスの識別情報と同じ共通識別情報が対応付けられた各サービスをサービス群情報テーブル１１３を参照して特定し、サービス連結部１０８，１０９、運用制御部１１０により、経路制御部１０７が特定した各サービス（コンピュータ１０４，１０５のサービス処理機能１０４ａ，１０５ａ）の１つを選択して起動する。
【選択図】図１

Description

本発明は、ＳＯＡ（ＳｅｒｖｉｃｅＯｒｉｅｎｔｅｄＡｒｃｈｉｔｅｃｔｕｒｅ）に基づくＷｅｂサービスやＪＣＡ（Ｊａｖａ（登録商標）２ＥｎｔｅｒｐｒｉｓｅＥｄｉｔｉｏｎＣｏｎｎｅｃｔｏｒＡｒｃｈｉｔｅｃｔｕｒｅ）など、標準仕様に準拠して開発されたコンピュータ処理サービス（外部から標準化された手順によって呼び出すことができる一まとまりのソフトウェアの集合）を相互連携させる、ＥＳＢ（ＥｎｔｅｒｐｒｉｓｅＳｅｒｖｉｃｅＢｕｓ）システムに係り、特に、サービスを利用する側の負担を軽減するのに好適な技術に関するものである。

ビジネスのグローバル化、規制緩和、組織合併など、ビジネスをとりまく環境の変化は以前にまして激しくなり、これに伴うコンピュータを用いた情報システムの変更機会も非常に多くなっているが、部門単位でのシステム構築や個別対応によって処理が複雑に絡み合ってしまい、システムを硬直化させ、システムの変化を困難にしている。

システムの効率的な再利用を目的とした技術としてＳＯＡが注目されている。このＳＯＡは、ネットワーク接続された各コンピュータにより提供されるサービスの集まりとして、大規模なシステムを構築する設計技術である。

このＳＯＡに基づいたＷｅｂサービスやＪＣＡなどのオープンな標準仕様に準拠して開発されたサービス（アプリケーションやコンポーネント）を連携させるための中核となるＥＳＢシステムが開発されている。

ＥＳＢシステムでは、例えば、非特許文献１に記載のように、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）、ＳＯＡＰ（ＳｉｍｐｌｅＯｂｊｅｃｔＡｃｃｅｓｓＰｒｏｔｏｃｏｌ）、ＪＭＳ（Ｊａｖａ（登録商標）ＭｅｓｓａｇｅＳｅｒｖｉｃｅ）などの標準的プロトコルに対応し、サービス同士を同期または非同期に連携させる。

また、例えば特許文献１にて開示された技術として、さまざまなプロトコル間とサービスの中から最適な利用者ニーズのサービスを選択する技術がある。

しかし、このような従来技術では、ネットワーク上には同じ目的の（結果を得る）ためのサービスが複数存在するので、利用者がサービスを利用する際に指定する情報と、サービスが公開する情報とが一致しない場合にはサービスの決定が行われず、また、多くのサービスが同じ条件に一致した場合にはサービスを絞りこめず、利用者は、サービスを決定する情報の見直しをしなければならない。

また、サービスは決定されたが、決定されたサービス側の異常応答や停止のために、正しい結果が取得できないといった場合には、利用者は、再度、別のサービス呼び出しを実行しなければならず、利用者側での操作負荷が増加してします。

特表２００６−５２６１８５号公報ＤａｖｉｄＡ. Ｃｈａｐｐｅｌｌ著，「エンタープライズサービスバス」，株式会社オライリー・ジャパン，２００５年０２月０８日発行．

解決しようとする問題点は、従来の技術では、ネットワーク上に同じ目的の（同じ結果を得る）ためのサービスが複数存在する場合、サービスを利用する際に利用者が指定する情報とサービスが公開する情報とが一致しない場合にはサービスの決定が行われず、また、多くのサービスが同じ条件に一致した場合にはサービスを絞りこめず、利用者は、サービスを決定する情報の見直しをしなければならない点、および、サービスは決定されたが、決定されたサービス側の異常応答や停止のために、正しい結果が取得できない場合に、利用者は、再度、別のサービス呼び出しを実行しなければならない点である。

本発明の目的は、これら従来技術の課題を解決し、ＥＳＢシステムにおける利用者側の操作負担を軽減することである。

上記目的を達成するため、本発明では、ＥＳＢシステムを構成するＷｅｂサービスなど、ネットワークに接続する複数の同じ目的のサービスを１つのサービス群としてまとめ、同じサービス群に属する複数のサービスから１つのサービスをシステム側で自動的に選択することで、利用者からのサービスの選択手順を簡単にする。また、選択したサービスが、異常処理が発生した場合には、システムが自動的に、同じサービス群に属する別のサービスを呼び出し、正常な結果が取得できるようにする。例えば、ＥＳＢシステムにおいて、オープンな標準仕様に準拠して開発された新たなサービスをネットワークに追加するときに、同じ結果を取得できるサービスが既に公開されている場合には、本発明のサービス選択システムにより、公開済みのサービスと同じサービス群に登録する。尚、同じ結果を取得できるサービスとは、在庫管理システムや検索システムだけではないが、同じ結果を取得することができるシステムが複数点在しているサービスのことである。サービスの利用者は、利用したいサービスに要求すれば、サービス選択システムが、サービス群の中から自動的に、要求されたサービスに対応する最適なサービスを選択してサービスへの要求を行う。このように、サービスへの接続はＥＳＢシステムが行うので、サービス利用者は、要求するサービスにアクセスするためのプロトコルや所在を意識する必要はない。また、新たなサービスの既存サービス群への登録および既存サービスのサービス群からの削除も、本発明のサービス選択システムが自動的に、利用者に影響を与えずに行うことができる。また、選択したサービスでの処理結果が異常の場合やサービスシステム自体が停止してしまったなどの問題発生時にも、本発明のサービス選択システムが、サービス群の未実行サービスの中なら最適なサービスを再度選択し直してサービスへの要求を行うことで、利用者の異常発生時における操作作業を軽減することができる。

本発明によれば、サービスの利用者は、同じ処理内容のサービスが複数ある場合にもそれぞれのサービスを意識することなく、最適なサービスを利用することができる。また、新たに同じ結果を取得するサービスが追加される場合や１つのサービスが削除される場合にも、利用者へのサービスの変更を通知することなくサービスの変更を行うことができる。また、サービス側で異常となっても別のサービスが利用できるのであれば自動的に別のサービスが再実行されるので、利用者の異常時における操作負荷を軽減することができる。

以下、図を用いて本発明を実施するための最良の形態例を説明する。図１は、本発明に係るサービス管理システムを設けたＥＳＢシステムの構成例を示すブロック図である。

図１に示す本例のＥＳＢシステムは、それぞれネットワークで接続されたコンピュータ（図中「サーバ」と記載）１０１とコンピュータ１０２〜１０５により構成されている。

各コンピュータ１０１〜１０５は、ＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）や主メモリ、表示装置、入力装置、外部記憶装置を具備した構成からなり、光ディスク駆動装置等を介してＣＤ−ＲＯＭ等の記憶媒体に記録されたプログラムやデータを外部記憶装置内にインストールした後、この外部記憶装置から主メモリに読み込みＣＰＵで処理することにより、プログラムされたコンピュータ処理を実行する各機能を有する。

例えば、プログラムされたコンピュータ処理を実行する機能として、コンピュータ１０１には本発明に係る処理を実行するサービス選択システム１０１ａが設けられ、コンピュータ１０２，１０３にはサービスリクエスタ処理機能（図中「サービスリクエスタ」と記載）１０２ａ，１０３ａが設けられ、コンピュータ１０４，１０５にはサービス処理機能（図中「サービス」と記載）１０４ａ，１０５ａが設けられ、コンピュータ１０１にはサービス選択システム１０１ａが設けられている。

また、コンピュータ１０１におけるサービス選択システム１０１ａは、リクエスト受付部１０６、経路制御部１０７、サービス連結部１０８，１０９、運用制御部１１０、サービス情報格納部１１１からなり、サービス情報格納部１１１はサービス情報テーブル１１２とサービス群情報テーブル１１３を生成して記憶装置において登録管理している。

図１のＥＳＢシステムにおいて、コンピュータ１０２，１０３がサービスを利用する利用者側のコンピュータであり、コンピュータ１０４，１０５がサービスを提供する側のコンピュータである。

本例では、コンピュータ１０２，１０３が、サービスリクエスタ処理機能１０２ａ，１０３ａにより、コンピュータ１０４，１０５のサービス処理機能１０４ａ，１０５ａに対して、所望のサービスの実行を要求する際、サーバ１０１がサービス選択システム１０１ａにより、当該サービスに対するアクセス制御を行う。

サービス選択システム１０１ａは、サービスを利用するコンピュータ１０２，１０３のサービスリクエスタ処理機能１０２ａ，１０３ａがサービスを利用するために送ってきた電文に応じて、利用するサービスを選択し、選択したサービスを実行するコンピュータ１０４，１０５に対して当該電文を送信する。

電文を受けたコンピュータ１０４，１０５は、サービス処理機能１０４ａ，１０５により、受信した電文に対する処理を行い、その処理結果をサービス選択システム１０１ａに返送し、サービス選択システム１０１ａは、受け取った処理結果をコンピュータ１０２，１０３のサービスリクエスタ処理機能１０２ａ，１０３ａに返す。

特に、コンピュータ１０４，１０５のサービス処理機能１０４ａ，１０５は、標準仕様に準拠して開発されたコンピュータ処理サービスを行うものであり、コンピュータ１０２，１０３のサービスリクエスタ処理機能１０２ａ，１０３ａは、コンピュータ１０１のサービス選択システム１０１ａを介して、コンピュータ１０４，１０５のサービス処理機能１０４ａ，１０５から提供されるサービスを相互連携させて利用する。

この際、本例のサービス選択システム１０１ａは、サービス情報格納部１１１により、外部から入力された指示情報に基づき、それぞれ同じ結果を取得できる複数のサービスの各識別情報を１つの共通識別情報に対応付けたサービス群情報テーブル１１３を予め生成してハードウェア等の記憶装置に登録しておく。

そして、サービス選択システム１０１ａは、リクエスト受付部１０６により、コンピュータ１０４，１０５のサービス処理機能１０４ａ，１０５ａからサービス利用者が指定したサービスの受け付けを行い、経路制御部１０７により、指定のサービスの識別情報と同じ共通識別情報が対応付けられた各サービスをサービス群情報テーブル１１３を参照して特定し、サービス連結部１０８，１０９により、特定した各サービスの１つを選択し、当該サービスを提供するコンピュータ１０４，１０５のサービス処理機能１０４ａ，１０５ａに対してサービス要求電文を送信する。

もし、サービス連結部１０８，１０９により起動したサービス（サービス処理機能１０４ａ，１０５ａ）に異常があれば、経路制御部１０７により、サービス群情報テーブル１１３を参照し、同じ共通識別情報が対応付けられた別のサービスを選択し、当該サービスを提供するコンピュータ１０４，１０５のサービス処理機能１０４ａ，１０５ａに対して当該サービス要求電文を送信する。

また、サービス選択システム１０１ａは、運用制御部１１０により、外部から入力された指示情報に基づき、サービス情報格納部１１１を介して、新たなサービスをサービス情報テーブル１１２およびサービス群情報テーブル１１３に追加すると共に、既存のサービスをサービス情報テーブル１１２およびサービス群情報テーブル１１３から削除する。

以下、図２〜図１１を用いて、このようなコンピュータ１０１（サービス選択システム１０１ａ）、コンピュータ１０２，１０３（サービスリクエスタ処理機能１０２ａ，１０３ａ）、コンピュータコンピュータ１０４，１０５（サービス処理機能１０４ａ，１０５ａ）による、本発明に係る処理内容を説明する。

図２は、図１におけるサービス管理システムの処理動作例を示すフローチャートであり、図３は、図１におけるサービス管理システムのリクエスト受付部による処理動作例を示すフローチャート、図４は、図１におけるサービス管理システムのサービス連結部による処理動作例を示すフローチャート、図５は、図１におけるサービス管理システムの経路制御部による処理動作例を示すフローチャート、図６は、図１におけるサービス管理システムの運用制御部による第１の処理動作例を示すフローチャート、図７は、図１におけるサービス管理システムの運用制御部による第２の処理動作例を示すフローチャート、図８は、図１におけるサービス管理システムの運用制御部による第３の処理動作例を示すフローチャート、図９は、図１におけるサービス管理システムのサービス情報格納部で管理するサービス群情報テーブルの登録例を示す説明図、図１０は、図１におけるサービス管理システムのサービス情報格納部で管理するサービス情報テーブルの登録内容例を示す説明図、図１１は、図１におけるサービス管理システムのサービス情報格納部で管理するサービス群情報テーブルの登録内容例を示す説明図である。

図２においては、サービス呼び出しによるサービス選択システム１０１ａ内の処理の流れを示しており、リクエスト受付１０６において、コンピュータ１０２のサービスリクエスタ処理機能１０２ａからのリクエスト要求（電文）を受け取り（ステップＳ２０１）、受け取ったリクエスト要求の中から宛先サービス名を取り出す（ステップＳ２０２）。

経路選択部１０７において、取り出した宛先サービス名をキーにサービス情報格納部１１１におけるサービス群情報テーブル１１３の情報（図９，図１１に示す構成内容）を検索して最適なサービス名を選択する（ステップＳ２０３）。

ここでの最適なサービスを選択する技術の例として、コストを条件として選択することが掲げることができる。すなわち、サービスリクエスタ１０２ａからの電文で、コストによる条件が指定されている場合、経路選択部１０７は、サービスを受けるまでのコストが低い条件で最適なサービスを選択する。

そして、経路選択部１０７は、選択したサービスに該当するサービス連結部、例えばサービス連結部１０８を呼び出し、サービス連結部１０８は、サービスの公開情報に合わせ電文形式を変換することで、選択したサービスが読める電文にしてからコンピュータ１０４のサービス処理機能１０４ａに対してサービスの呼び出しを行う（ステップＳ２０４）。

サービス処理機能１０４ａで処理が行われ、その処理結果を示す応答データがあれば、サービス連結部１０８は、経路制御部１０７およびリクエスト受付部１０６を介して、要求元のサービスリクエスタ処理機能１０２ａに、当該応答データを返す（ステップＳ２０５）。

尚、予め、リクエスト要求を受け付けてサービス呼び出しを行う宛先サービスの登録、すなわち、サービス情報格納部１１１におけるサービス情報テーブル１１２とサービス群情報テーブル１１３の登録は、運用制御部１１０により実行しておく。

図３においては、図１のリクエスト受付部１０６による、リクエスト要求を受け付けた際の処理の流れを示しており、リクエスト受付部１０６は、コンピュータ１０２のサービスリクエスタ処理機能１０２ａからリクエスト要求を受け取ると、実行可能な状態か否かを運用制御部１１０へ問い合わせる（ステップＳ３０１）。

実行可能であれば（ステップＳ３０２）、リクエスト要求（電文）の解析処理を行い、宛先サービス名を電文から取得し（ステップＳ３０３）、解析エラーがなければ（ステップＳ３０４）、経路制御部１０７にサービスへの電文を渡し（ステップＳ３０５）、サービスを呼び出した結果の応答を受けると（ステップＳ３０６）、その応答をサービスリクエスタ処理機能１０２ａに返す（ステップＳ３０７）。

ステップＳ３０２の判別処理結果においてリクエスト受付が実行できない場合や、ステップＳ３０４の判別処理結果においてリクエスト要求の解析処理にて異常を検出した場合には、エラーの電文を作成し（ステップＳ３０８）、サービスリクエスタ処理機能１０２ａに送信し、結果応答とする（ステップＳ３０７）。

図４においては、図１の経路制御部１０７から呼び出される図１のサービス連結部１０８におけるサービス情報の生成処理の流れを示しており、経路制御部１０７から呼び出されたサービス連結部１０８は、運用制御部１１０からサービスの公開情報を取得し（ステップＳ４０１）、取得したサービスの公開情報からサービス呼び出しに必要な情報を登録し（ステップＳ４０２）、コンピュータ１０４，１０５のサービス処理機能１０４ａ，１０５ａに対するサービス呼び出し処理を開始し（ステップＳ４０３）、サービスの開始および登録が完了したことを経路制御部１０７に対して応答する（ステップＳ４０４）。

図５においては、図１の経路制御部１０７による、リクエスト要求をどのサービスに送信するかを選択する処理の流れを示しており、経路制御部１０７では、リクエスト受付処理においてリクエスト要求部１０６から、取得した宛先サービス名と電文が渡される（ステップＳ５０１）ので、受け取った宛先サービス名を検索キーとしてサービス情報格納部１１１のサービス群情報１１３を検索して（ステップＳ５０２）、宛先サービス名に一致するサービス名があるか否かを確認する（ステップＳ５０３）。

一致するサービスが無ければ、リクエスト要求するサービスが存在しないこと伝えるエラー応答電文を作成して（ステップＳ５０４）、リクエスト受付へ応答データを返し（ステップＳ５１８）、一致するサービス情報があれば、サービスの種類を判断する（ステップＳ５０５）。

サービス種類の判断結果が「サービス群」であれば、サービス情報格納部１１１のサービス群情報テーブル１１３を検索して一致するサービス群の情報を全て取得する（ステップＳ５０６）。

取得したサービス群情報にはサービスのサービス名が設定されており、サービスごとにサービス情報格納部１１１のサービス部の中か一致するサービス情報を取得してサービス群単位でのサービス情報の一覧を作成する（ステップＳ５０７）。

サービス情報の一覧から最適な１つのサービスを決定する（ステップＳ５０８）。このときリクエスト要求にてコストによるサービス選択の条件が設定されていれば、サービス情報テーブル１１２におけるサービス選択キーでコストに関するキーがあれば選択条件に加えて選択する。

サービスが決定すると、作成したサービス情報の一覧に決定サービスが分かるようフラグ（サービス実行フラグ）を立て（ステップＳ５０９）、決定したサービス名に対応するサービス連結部１０８，１０９に電文を渡す（ステップＳ５１０）。

ステップＳ５０５での判別処理において、サービス情報格納１１１部のサービス群情報テーブル１１３から決定したサービスの種類が単一サービスであれば、そのまま、当該サービス連結部１０８，１０９を呼び出して電文を渡す（ステップＳ５１０）。

サービス連結部１０８，１０９を呼び出すと、サービス側（コンピュータ１０４，１０５のサービス処理機能１０４ａ，１０５ａ）での処理が行われ、その応答結果を受け取る（ステップＳ５１１）。

リクエスト要求の宛先サービスがサービス群で応答結果が正常であれば（ステップＳ５１２）、受け取った応答電文をリクエスト受付部１０６に返して処理を終了する（ステップＳ５１８）。

しかし、リクエスト要求の宛先サービスがサービス群で応答結果が異常終了している場合には（ステップＳ５１２）、ステップ５０９の処理で作成したサービス情報一覧を取得し（ステップＳ５１３）、取得したサービス情報一覧の中から既に実行済みのフラグが立っているサービス以外から１つのサービスを決定し（ステップＳ５１４）、サービス情報の一覧に決定したサービスが分かるようフラグを立てる（ステップＳ５１５）。

そして、最適なサービスの再選択ができたか否かを判定し（ステップＳ５１６）、決定したサービス名があれば、ステップＳ５１０の処理に戻り、サービス名に対応するサービス連結部１０８，１０９を呼び出して電文を渡す。

サービス名を決定できなければ、エラーの応答電文を作成して（ステップＳ５１７）、リクエスト受付部１０６に応答データを返す（ステップＳ５１８）。

図６においては、図１の運用制御部１１０による処理の内、特に、リクエスト要求の受付制御に関する処理を示している。

サービス選択システムの設定時にはサービスリクエスタ処理機能１０２ａ，１０３ａからのリクエスト要求ができないようリクエスト受付部１０６での実行状態を管理する処理の流れを示しており、サービス選択システムが動作していない状態では、運用制御部１１０は、リクエスト受付に関する状態管理メモリ領域に停止指示情報を設定してリクエスト受付の動作を停止させる（ステップＳ６０１）。

リクエスト受付の起動要求があれば（ステップＳ６０２）、状態管理メモリ領域の設定を停止指示情報から起動指示情報に切り替えてリクエスト受付を可能とする（ステップＳ６０３）。

さらに、リクエスト受付の停止要求があれば（ステップＳ６０４）、再度、状態管理メモリ領域における設定を停止指示情報に切り替えてリクエスト受付の動作を停止させる（ステップＳ６０５）。

そして、リクエスト受付部１０６からの実行状態の問合せがあれば（ステップＳ６０６）、運用制御部１１０は、状態管理メモリ領域からリクエスト受付の状態（「停止」／「起動」）を取得し（ステップＳ６０７）、リクエスト受付部１０６に対して取得した状態情報を応答する（ステップＳ６０８）。

図７においては、図１の運用制御部１１０による処理の内、特に、サービス情報格納部１１１におけるサービス情報テーブル１１２に対する登録処理の流れを示しており、運用制御部１１０は、サービスを登録するために、サービス名やサービスとのインタフェース（プロトコル、宛先情報、アドレス、電文形式）といったサービスの公開情報を取得すると（ステップＳ７０１）、取得したサービス名がサービス情報格納部１１１で管理しているサービス情報テーブル１１２に既に登録されているか否かを検索する（ステップＳ７０２）。

登録しようとする名称が登録済みであれば、サービスの登録に失敗したことを示す応答を返し（ステップＳ７０３）、新たなサービス名の登録であれば、サービスと接続するサービス連結部１０８，１０９の生成を要求し（ステップＳ７０４）、サービス連結部１０８，１０９の生成結果を受けて（ステップＳ７０５）、サービス情報格納部１１１のサービス情報テーブル１１２にサービスの公開情報を格納し（ステップＳ７０６）、サービスの登録完了を応答する（ステップＳ７０７）。

図８においては、図１の運用制御部１１０による処理の内、特に、サービス情報格納部１１１におけるサービス群情報テーブル１１３に対する登録処理の流れを示している。

複数のサービス名を１つのまとまりとする総称名が、サービス群名で、サービスリクエスタ処理機能１０２ａ，１０３ａにとっては、提供されるサービスの名称であり、サービスリクエスタ処理機能１０２ａ，１０３ａはサービス名とサービス群名のどちらかを宛先サービス名としてリクエスト要求をする。

サービス群情報テーブル１１３では、このサービス群名と複数のサービス名を関連付けて登録する。

運用制御部１１０は、同じ結果を取得する複数のサービスをサービス群とするサービス群の登録要求を受け付けると（ステップＳ８０１）、サービス情報格納部１１１のサービス群情報テーブル１１３に既に登録されているかを検索し（ステップＳ８０２）、登録しようとする名称が登録済みならサービス群の登録に失敗したことを示す情報を返して登録失敗を応答する（ステップＳ８０３）。

例えば、図９において示すサービス群の登録例９０１では、登録するサービス群名が「サービス群名１」で、「サービス名１」から「サービス名３」までのサービス名を保持している。

ステップＳ８０２の検索結果で、登録しようとする名称が未だ登録されていなければ、サービス群の登録例９０１が新たなサービス群（サービス名）の登録として処理される（ステップＳ８０４）。すなわち、サービス群情報テーブル１１３に、サービス群名（「サービス群名１」）とその要素である「サービス名１」を組にして登録し、「サービス名２」，「サービス名３」も同様に登録する。

尚、サービスはいつでも登録できるので、サービス情報テーブル１１２に存在しないサービス名がサービス群情報テーブル１１３に指定したサービス名に指定されていてもよい。また、いつでもサービス群名とサービス名をサービス群情報テーブル１１３に追加することができ、利用者が意識することなく新たなサービスをサービス群に追加して利用できる。また、サービスの削除とサービス群情報テーブル１１３の削除についてもいつでも行うことができる。

サービス群情報テーブル１１３への登録が完了すれば、サービス群の登録完了を応答して処理を終了する（ステップＳ８０５）。

図１０においては、図１のサービスリクエスタ処理機能１０２ａ，１０３ａが利用するサービス情報の登録例、すなわち、図１におけるサービス情報格納部１１１が登録管理するサービス情報テーブル１１２の登録例を示しており、項目説明１００１に示す項目名における「サービス名」は、サービスリクエスタ処理機能１０２ａ，１０３ａがリクエストを要求するサービスのサービス名またはサービス群名を、「サービス連結部名」はサービスを呼び出すためのサービス連結部１０８，１０９の名称を、「サービス連結部状態」はサービス連結部１０８，１０９の状態を、「サービスのプロトコル」はサービスと接続するサービス連結部１０８，１０９の種類を、「サービスの種類」はサービスリクエスタ処理機能１０２ａ，１０３ａからの呼び出し種別を、「サービス連結部登録日」はサービス連結部１０８，１０９の登録日時を、「サービスの状態」はサービス連結部１０８，１０９がつながるサービスの状態を、「サービスの選択キー」はサービスを決定する選択条件の１つ（今回は配送コスト）を、「異常処理動作」は異常を検出した際の次に処理する動作ファイル先をそれぞれ示している。

なお、データ例１００２において、サービス情報テーブル１１２における具体的なデータ例を示している。

図１１においては、図１のサービスリクエスタ処理機能１０２ａ，１０３ａが利用するサービス群の登録例、すなわち、図１におけるサービス情報格納部１１１が登録管理するサービス群情報テーブル１１３の登録例を示しており、項目説明１１０１に示す項目名における「サービス群名」は、サービスリクエスタ処理機能１０２ａ，１０３ａがリクエスト要求するサービスの総称名を、「サービス名」は、図９に示すサービス群の登録例９０１における各サービス名をそれぞれ示している。なお、データ例１１０２において、サービス群情報テーブル１１３における具体的なデータ例を示している。

以上、図１〜図１１を用いて説明したように、本例では、ＳＯＡに基づくＷｅｂサービスやＪＣＡなど、標準仕様に準拠して開発されたコンピュータ処理サービスをネットワークを介して相互連携させるＥＳＢシステム等のコンピュータシステムによるサービス管理技術として、コンピュータシステムとしてのコンピュータ（サーバ）１０１に、プログラムされたコンピュータ処理機能（サービス選択システム１０１ａ）として、リクエスト受付部１０６、経路制御部１０７、サービス連結部１０８，１０９、運用制御部１１０、サービス情報格納部１１１等を設け、サービス情報格納部１１１により、それぞれ同じ結果を取得できる複数のサービスの各識別情報を、１つの共通識別情報に対応付けた対応付け情報（サービス群情報テーブル１１３）を生成して記憶装置に登録する手順を実行し、リクエスト受付部１０６により、サービス利用者（コンピュータ１０２，１０３のサービスリクエスタ処理機能１０２ａ，１０３ａ）からのサービス要求を受け付け、経路制御部１０７により、サービス利用者（コンピュータ１０２，１０３のサービスリクエスタ処理機能１０２ａ，１０３ａ）から指定されたサービスの識別情報と同じ共通識別情報が対応付けられた各サービスを対応付け情報（サービス群情報テーブル１１３）を参照して特定し、サービス連結部１０８，１０９、運用制御部１１０により、経路制御部１０７が特定した各サービス（コンピュータ１０４，１０５のサービス処理機能１０４ａ，１０５ａ）の１つを選択して起動する。

また、サービス選択システム１０１ａは、運用制御１１０により、起動したサービスに異常があれば、対応付け情報（サービス群情報テーブル１１３）を参照し、同じ共通識別情報が対応付けられた別のサービスを選択して起動する手順を実行する。

また、サービス選択システム１０１ａは、運用制御１１０により、外部から入力された指示情報に基づき、新たなサービスを上記対応付け情報に追加する手順、および、既存のサービスを上記対応付け情報から削除する手順を実行する。

このことにより、従来技術の問題点（「従来技術では、ネットワーク上に同じ目的の（同じ結果を得る）ためのサービスが複数存在する場合、サービスを利用する際に利用者が指定する情報とサービスが公開する情報とが一致しない場合にはサービスの決定が行われず、また、多くのサービスが同じ条件に一致した場合にはサービスを絞りこめず、利用者は、サービスを決定する情報の見直しをしなければならない点、および、サービスは決定されたが、決定されたサービス側の異常応答や停止のために、正しい結果が取得できない場合に、利用者は、再度、別のサービス呼び出しを実行しなければならない点」）を解決し、ＥＳＢシステムにおける利用者側の操作負担を軽減することができる。すなわち、サービスの利用者は、同じ処理内容のサービスが複数ある場合にもそれぞれのサービスを意識することなく、最適なサービスを利用することができる。また、新たに同じ結果を取得するサービスが追加される場合や１つのサービスが削除される場合にも、利用者へのサービスの変更を通知することなくサービスの変更を行うことができる。また、サービス側で異常となっても別のサービスが利用できるのであれば自動的に別のサービスが再実行されるので、利用者の異常時における操作負荷を軽減することができる。

尚、本発明は、図１〜図１１を用いて説明した例に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能である。例えば、本例では、１つのコンピュータ（サーバ）１０１内にサービス選択システム１０１ａとサービス情報格納部１１１を設けた構成としているが、サービス情報格納部１１１を別のコンピュータに設けた構成としても良い。

また、本例のコンピュータ（サーバ）１０１の構成例としても、キーボードや光ディスクの駆動装置の無い構成としても良い。また、本例では、光ディスクを記録媒体として用いているが、ＦＤ（ＦｌｅｘｉｂｌｅＤｉｓｋ）等を記録媒体として用いることでも良い。また、プログラムのインストールに関しても、通信装置を介してネットワーク経由でプログラムをダウンロードしてインストールすることでも良い。

本発明に係るサービス管理システムを設けたＥＳＢシステムの構成例を示すブロック図である。図１におけるサービス管理システムの処理動作例を示すフローチャートである。図１におけるサービス管理システムのリクエスト受付部による処理動作例を示すフローチャートである。図１におけるサービス管理システムのサービス連結部による処理動作例を示すフローチャートである。図１におけるサービス管理システムの経路制御部による処理動作例を示すフローチャートである。図１におけるサービス管理システムの運用制御部による第１の処理動作例を示すフローチャートである。図１におけるサービス管理システムの運用制御部による第２の処理動作例を示すフローチャートである。図１におけるサービス管理システムの運用制御部による第３の処理動作例を示すフローチャートである。図１におけるサービス管理システムのサービス情報格納部で管理するサービス群情報テーブルの登録例を示す説明図である。図１におけるサービス管理システムのサービス情報格納部で管理するサービス情報テーブルの登録内容例を示す説明図である。図１におけるサービス管理システムのサービス情報格納部で管理するサービス群情報テーブルの登録内容例を示す説明図である。

符号の説明

１０１：コンピュータ（サーバ）、１０１ａ：サービス選択システム、１０２〜１０５：コンピュータ、１０２ａ，１０３ａ：サービスリクエスタ処理機能、１０４ａ，１０５ａ：サービス処理機能、１０６：リクエスト受付部、１０７：経路制御部、１０８，１０９：サービス連結部、１１０：運用制御部、１１１：サービス情報格納部、１１２：サービス情報テーブル、１１３：サービス群情報テーブル、９０１：サービス群の登録例、１００１：項目説明（サービス情報テーブル）、１００２：データ例（サービス情報テーブル）、１１０１：項目説明（サービス群情報テーブル）、１１０２：データ例（サービス群情報テーブル）。

Claims

標準仕様に準拠して開発された複数のコンピュータ処理サービスをネットワークを介して相互連携させるコンピュータシステムのサービス管理方法であって、
上記コンピュータシステムは、プログラムされたコンピュータ処理手段として、第１の手段、第２の手段を具備し、
上記第１の手段は、
それぞれ同じ結果を取得できる複数のサービスの各識別情報を、１つの共通識別情報に対応付けた対応付け情報を生成して記憶装置に登録する手順を実行し、
上記第２の手段は、
サービス利用者から指定されたサービスの識別情報と同じ共通識別情報が対応付けられた各サービスを上記対応付け情報を参照して特定し、特定した各サービスの１つを選択して起動する手順を実行する
ことを特徴とするサービス管理方法。
請求項１に記載のサービス管理方法であって、
上記コンピュータシステムは、プログラムされたコンピュータ処理手段として、第３の手段を具備し、
上記第３の手段は、
上記第２の手段が起動したサービスに異常があれば、上記対応付け情報を参照し、同じ共通識別情報が対応付けられた別のサービスを選択して起動する手順を実行する
ことを特徴とするサービス管理方法。
請求項１もしくは請求項２のいずれかに記載のサービス管理方法であって、
上記コンピュータシステムは、プログラムされたコンピュータ処理手段として、第４の手段を具備し、
上記第４の手段は、
外部から入力された指示情報に基づき、新たなサービスを上記対応付け情報に追加する手順、および、既存のサービスを上記対応付け情報から削除する手順を実行する
ことを特徴とするサービス管理方法。
コンピュータに、請求項１から請求項３のいずれかに記載のサービス管理方法における各手段による手順を実行させるためのプログラム。
標準仕様に準拠して開発された複数のコンピュータ処理サービスをネットワークを介して相互連携させるコンピュータシステムであって、
プログラムされたコンピュータ処理手段として、
請求項１から請求項３のいずれかに記載のサービス管理方法における各手段を具備した
ことを特徴とするサービス管理システム。