JP2004362449A - サービス提供装置及びサービスコーディネータ装置及びサービス提供方法及びサービスコーディネート方法及びプログラム及びプログラムを記録したコンピュータ読み取り可能な記録媒体 - Google Patents
サービス提供装置及びサービスコーディネータ装置及びサービス提供方法及びサービスコーディネート方法及びプログラム及びプログラムを記録したコンピュータ読み取り可能な記録媒体 Download PDFInfo
- Publication number
- JP2004362449A JP2004362449A JP2003162663A JP2003162663A JP2004362449A JP 2004362449 A JP2004362449 A JP 2004362449A JP 2003162663 A JP2003162663 A JP 2003162663A JP 2003162663 A JP2003162663 A JP 2003162663A JP 2004362449 A JP2004362449 A JP 2004362449A
- Authority
- JP
- Japan
- Prior art keywords
- service
- group
- unit
- services
- request information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Abstract
【課題】ユーザ要件の中でも特にレスポンス要件を保証して複数のサービスを組み合わせて実行できる装置を提供することを目的とする。
【解決手段】複数のサービスのサービス提供条件を示すＳＬＡ情報１０を記憶する記憶装置５１と、上記複数のサービスの内、いくつかをグループとして組合わせた連携サービスの各サービスを提供することを求めるリクエスト情報を受信する受信部５２と、上記連携サービスの各サービスの現在の提供状況を管理し、上記記憶装置５１により記憶されたＳＬＡ情報１０が示す条件に基づいて、受信されたリクエスト情報が求める連携サービスの各サービスを提供することが可能かどうかを判断する連携サービス管理部６と、判断された結果に基づいて、上記受信部５２により受信されたリクエスト情報が求める連携サービスの各サービスの提供を実行する実行部５４とを備えたことを特徴とする。
【選択図】 図１
【解決手段】複数のサービスのサービス提供条件を示すＳＬＡ情報１０を記憶する記憶装置５１と、上記複数のサービスの内、いくつかをグループとして組合わせた連携サービスの各サービスを提供することを求めるリクエスト情報を受信する受信部５２と、上記連携サービスの各サービスの現在の提供状況を管理し、上記記憶装置５１により記憶されたＳＬＡ情報１０が示す条件に基づいて、受信されたリクエスト情報が求める連携サービスの各サービスを提供することが可能かどうかを判断する連携サービス管理部６と、判断された結果に基づいて、上記受信部５２により受信されたリクエスト情報が求める連携サービスの各サービスの提供を実行する実行部５４とを備えたことを特徴とする。
【選択図】 図１
Description
【０００１】
【発明の属する技術分野】
この発明は、サービス提供装置或いはサービスコーディネータ装置、またはサービス提供方法或いはサービスコーディネート方法に関するものである。特に、サービス連携制御方式に関するものである。
【０００２】
【従来の技術】
ユーザの要求するアプリケーション・サービスの提供を効率良く行うことが可能な技術を提供することを目的とした以下の手段が文献に記載されている。ユーザにアプリケーション・サービスを提供するアプリケーション・サービス・提供方法において、単数或いは複数のアプリケーション提供者が提供する複数のアプリケーションの中からユーザの要求する要件であるユーザ要件を満たすアプリケーション或いはアプリケーション提供者とその提供するアプリケーションを選択するステップと、前記選択されたアプリケーションの間のデータ形式変換または通信プロトコル変換或いはワークフロー管理を行ってアプリケーション・サービスを提供するステップとを有するものである。（特許文献１参照）
【０００３】
【特許文献１】
特開２００１−３０６５３５号公報
【０００４】
【発明が解決しようとする課題】
特許文献１における構成を取るアプリケーション・サービス・提供システムでは、ユーザが中間プロバイダにアクセスし、中間プロバイダからアプリケーション分類一覧を受信し、対象アプリケーションを選択する。次に中間プロバイダから要件入力シートを受信し、ユーザ要件（機能要件、課金要件、レスポンス要件）を入力する。中間プロバイダは機能要件と課金要件を満足するアプリケーション候補一覧を表示し、ユーザはこの候補一覧からアプリケーションを選択する。中間プロバイダはユーザ要件情報をユーザ要件データベースに保存し、サービスを開始する。サービス実行中にレスポンス要件を満足できない状況が発生したときは、新たなアプリケーション候補一覧を作成し、ユーザが候補一覧から選択し、実行するアプリケーションを切り替えるか現状を維持してサービスを続行する。
【０００５】
上記のような構成を取るアプリケーション・サービス・提供システムでは、以下のような問題があった。
アプリケーションを選択する際に個々のアプリケーションがユーザ要件を満足するかどうかは確認できるが、連携したアプリケーション・サービス全体でユーザ要件を満足するかどうかの確認ができない。
また、多数のユーザからの要求が重なったときなど、連携サービスの実行途中にレスポンス要件を満足できなくなり、動的にアプリケーションの切替処理が行われるが、レスポンス要件を満たすアプリケーションが存在しない場合は、ユーザに通知を行うため、処理が中断するとともに、レスポンス要件を保証して連携アプリケーション全体を実行することができないという問題があった。
また、動的にレスポンス要件を測定する処理がプロバイダにとっての負荷となるという問題があった。
【０００６】
この発明は、ユーザ要件の中でも特にレスポンス要件を保証して複数のサービスを組み合わせて実行できる装置を提供することを目的とする。
【０００７】
【課題を解決するための手段】
この発明に係るサービス提供装置は、複数のサービスのサービス提供条件を示す複数のサービス提供条件情報を記憶する記憶部と、
上記複数のサービスの内、いくつかをグループとして組合わせたサービスグループの各サービスを提供することを求めるリクエスト情報を受信する受信部と、
上記サービスグループの各サービスの現在の提供状況を管理し、上記記憶部により記憶された複数のサービス提供条件情報が示すサービス提供条件に基づいて、上記受信部により受信されたリクエスト情報が求めるサービスグループの各サービスを提供することが可能かどうかを判断する管理部と、
上記管理部により判断された結果に基づいて、上記受信部により受信されたリクエスト情報が求めるサービスグループの各サービスの提供を実行する実行部とを備えたことを特徴とする。
【０００８】
【発明の実施の形態】
実施の形態１．
実施の形態１では、複数のサービスを連携して動作させるときに、あらかじめサービスプロバイダ（サービスプロバイダ装置）とサービスコーディネータ（サービスコーディネータ装置）の間で結ばれたサービスレベルアグリーメント情報に基づいて、サービスリクエスタ（サービスリクエスタ装置）からの要求を受け付け、サービスを割り当て、管理することにより、ユーザ要件の中でも特にレスポンス要件を保証して複数のサービスを組み合わせて実行できる連携サービス制御方式を説明する。
【０００９】
図１は、実施の形態１に係るサービス連携制御方式の一実施例を示す構成図である。
図１において、サービス連携制御方式におけるサービス連携制御システムは、サービスを提供するサービスプロバイダ２１，３１、サービスを要求するクライアントであるサービスリクエスタ１２、サービスプロバイダ２１或いはサービスプロバイダ３１が提供する提供サービスを複数組み合わせてサービスリクエスタ１２に提供するサービスコーディネータ５（サービスコーディネータ装置、サービス提供装置の一例である）を備えている。サービスリクエスタ１２に提供される複数組み合わされた提供サービスは、１つのサービスプロバイダ（例えば、サービスプロバイダ２１）が提供する複数の提供サービスであってもよいし、複数のサービスプロバイダ（例えば、サービスプロバイダ２１，３１）が提供する複数の提供サービスであってもよい。
【００１０】
サービスプロバイダ２１は、サービスプロバイダ２１が提供する提供サービス２２とサービスプロバイダ２１が提供サービスの処理状況を示す負荷情報２３とを記憶する記憶装置２５、サービスプロバイダ２１がサービスレベルアグリーメント情報を処理するＳＬＡ（サービスレベルアグリーメント）処理部２４を有している。同様に、サービスプロバイダ３１は、サービスプロバイダ３１が提供する提供サービス３２とサービスプロバイダ２１が提供サービスの処理状況を示す負荷情報３３とを記憶する記憶装置３５、サービスプロバイダ２１がサービスレベルアグリーメント情報を処理するＳＬＡ処理部３４を有している。
【００１１】
サービスコーディネータ５は、複数のサービスを連携して動作させるための連携サービス管理部６（管理部の一例である）、記憶装置５１（記憶部の一例である）、受信部５２、送信部５３、実行部５４を有している。連携サービス管理部６は、サービスコーディネータ５でサービスレベルを調整するＳＬＡ処理部７、連携サービスを処理するための連携サービス実行管理部８を有している。記憶装置５１には、複数のサービスの組合せ情報を管理する連携サービス定義９、ＳＬＡ情報１０、実際のサービスを管理する連携サービス実行管理テーブル１１が記憶されている。
【００１２】
サービスリクエスタ１２は、記憶装置１２１を有し、記憶装置１２１には、サービスを要求するクライアントプログラムが記憶されている。
【００１３】
次に動作について説明する。
記憶装置５１は、サービスを提供するサービスプロバイダとの間で予め設定された複数のサービスのサービス提供条件を示すＳＬＡ情報１０（複数のサービス提供条件情報の一例である）を記憶する。
【００１４】
受信部５２は、上記複数のサービスの内、いずれかをグループとして組合わせたサービスグループの各サービスを提供することを求めるリクエスト情報をサービスリクエスタ１２から受信し、上記サービスグループの各サービスを上記サービスプロバイダ２１，３１から受信する。
【００１５】
連携サービス管理部６は、上記サービスグループの各サービスの現在の提供状況を管理し、上記記憶装置５１により記憶された複数のサービス提供条件情報が示すサービス提供条件に基づいて、上記受信部５２により受信されたリクエスト情報が求めるサービスグループの各サービスを提供することが可能かどうかを判断する。
【００１６】
実行部５４は、上記連携サービス管理部６により判断された結果に基づいて、上記受信部５２により上記サービスリクエスタ１２から受信されたリクエスト情報が求める上記受信部５２により上記サービスプロバイダ２１，３１から受信されたサービスグループの各サービスを実行し、上記サービスリクエスタ１２に提供する。
【００１７】
送信部５３は、上記連携サービス管理部６により判断された結果、上記受信部５２により受信されたリクエスト情報が求めるサービスグループの各サービス全部を提供することが可能でない場合、上記受信部５２により受信されたリクエスト情報の受け付けを拒否する受付拒否情報を上記サービスリクエスタ１２に送信する。
【００１８】
本実施の形態１では、サービスプロバイダとは別に、サービスコーディネータ５が、サービスプロバイダ２１或いはサービスプロバイダ３１が提供する提供サービスを複数組み合わせてサービスリクエスタ１２に提供する構成としているが、サービスプロバイダがサービスコーディネータ５の機能を備えた構成にしていても構わない。すなわち、記憶装置５１が、複数のサービスのサービス提供条件を示すＳＬＡ情報１０（複数のサービス提供条件情報の一例である）を記憶している。
そして、受信部５２は、上記複数のサービスの内、いくつかをグループとして組合わせたサービスグループの各サービスを提供することを求めるリクエスト情報を受信する。
そして、連携サービス管理部６は、上記サービスグループの各サービスの現在の提供状況を管理し、上記記憶装置５１により記憶された複数のサービス提供条件情報が示すサービス提供条件に基づいて、上記受信部５２により受信されたリクエスト情報が求めるサービスグループの各サービスを提供することが可能かどうかを判断する。
そして、実行部５４は、上記連携サービス管理部６により判断された結果に基づいて、上記受信部５２により受信されたリクエスト情報が求めるサービスグループの各サービスの提供を実行する。
【００１９】
図２は、実施の形態１におけるサービス連携制御方式の動作を示すフローチャート図である。
前記のように構成されたサービス連携制御方式において、サービス連携制御方式の動作を図２にしたがって説明する。
まず、サービスリクエスタ１２は、サービスコーディネータ５にアクセスする（Ｓ２０１）。
【００２０】
サービスコーディネータ５における連携サービス管理部６は、記憶装置５１に記憶された連携サービス定義９に基づいて提供する連携サービス一覧を表示する（Ｓ２０８）。
【００２１】
サービスリクエスタ１２は表示された連携サービスから実行したい連携サービス（サービスグループの一例である）を選択する。（Ｓ２０２）。言い換えれば、サービスコーディネータ５における受信部５２は、サービスリクエスタ１２により実行したい連携サービスが選択されることにより、選択動作に係る受信情報をリクエスト情報として受信する。
【００２２】
サービスコーディネータ５における連携サービス管理部６は選択された連携サービスが実行可能かどうか記憶装置５１に記憶された連携サービス実行管理テーブル１１をチェックする（Ｓ２０９）。
【００２３】
サービスコーディネータ５における連携サービス管理部６は、選択された連携サービスを実行できるかどうかを判定し（Ｓ２１０）、受け付けられない場合は受付拒否（受付拒否情報）を送信部５３より送信し（Ｓ２１１）、受付可能な場合は、選択された連携サービスを連携サービス実行管理テーブル１１に登録し（Ｓ２１２）、受付可能（受付可能情報）を送信部５３より送信する（Ｓ２１３）。
【００２４】
サービスリクエスタ１２は受付可否を受信し（Ｓ２０３）、受付可能かどうかを判定し（Ｓ２０４）、受け付けられない場合は連携サービスの選択を終了する（Ｓ２０７）。受付可能な場合は、連携サービス実行に必要なデータを入力し（Ｓ２０５）、サービスコーディネータ５における実行部５４は受信部５２を介して受信したデータにより連携サービスを実行する（Ｓ２１４）。
【００２５】
サービスコーディネータ５における連携サービス管理部６は連携サービスが完了すると実行完了通知と実行結果を送信し（Ｓ２１５）、連携サービス実行管理テーブル１１から削除して（Ｓ２１６）、終了する（Ｓ２１７）。
サービスリクエスタ１２は連携サービス実行完了通知と実行結果を受信して（Ｓ２０６）、終了する（Ｓ２０７）。
【００２６】
以上のように、サービス連携制御方式におけるサービス連携制御システムは、サービスを提供するサービスプロバイダ２１，３１、サービスの実行を要求するサービスリクエスタ１２、サービスのリクエストに対して複数のサービスを連携して実行するサービスコーディネータ５から構成され、サービスプロバイダ２１，３１とサービスコーディネータ５の間でサービスリクエストに対する実行時間を保証するサービスレベルアグリーメントを結び、サービスレベルアグリーメント情報に基づいて、複数のサービスリクエスタ１２に対して、応答時間を保証するために、連携サービス実行管理テーブル１１を備える。
【００２７】
図３は、本実施の形態１のサービスレベルアグリーメント（ＳＬＡ）情報の例を示す図である。
サービスコーディネータ５はサービスプロバイダ２１，３１との間で、あるサービスの処理件数とその処理時間に関する実行保障であるサービスレベルアグリーメントを結び、その情報をサービスレベル定義情報（サービス提供条件情報の一例である）として管理する。
【００２８】
図４は、本実施の形態１の連携サービス定義情報の例を示す図である。
サービスコーディネータ５における連携サービス実行管理部８は、ＳＬＡ情報におけるサービスから連携サービス（サービスグループの一例である）を実行するために必要な処理時間とその連携サービスを実行するために必要な処理時間を算出し、連携サービス定義情報として管理する。サービスコーディネータ５はサービスリクエスタ１２に対して、実行可能な連携サービスの一覧を連携サービス定義９（連携サービス定義情報）に基づいて表示する。
【００２９】
図５は、本実施の形態１の連携サービス実行管理テーブルの例を示す図である。
連携サービス実行管理テーブル１１は設定した単位時間で、連携サービスを構成するすべてのサービスが全体でいつ、どれだけ利用されるかを管理している。なお、図５では単位時間を５秒としている。図５において、管理状態５０１では連携サービス１と連携サービス２のリクエストがそれぞれ２５０件ずつ要求された場合の管理状態を示している。
図５の管理状態５０２は管理状態５０１の状態から５秒後に連携サービス１のリクエスト要求２５０件を受け付けた状態である。この状態で連携サービス１のリクエストを受けると連携サービス１を構成するサービスの一つであるサービスＢ１がＳＬＡで定義された処理可能件数を２０秒後の時点で満たせなくなるため、連携サービス１の受付を不可能とする。
【００３０】
図６は、連携サービス実行管理テーブルチェック手順を示すフローチャート図である。
図６に基づいて、連携サービス実行管理テーブルチェック手順について説明する。連携サービス実行管理テーブルチェックでは、連携サービス管理部６が、連携サービスを構成する各サービスとその実行順序を記憶装置５１に記憶された連携サービス定義９（連携サービス定義情報）から取得する（Ｓ６０１）。
次に、連携サービス管理部６が、各サービスの処理可能件数と処理時間をＳＬＡ情報１０（ＳＬＡ定義情報）から取得する（Ｓ６０２）。
次に、連携サービス管理部６が、各サービスの処理時間を連携サービス実行管理テーブル１１の管理単位時間に分割する（Ｓ６０３）。
次に、連携サービス管理部６が、単位時間あたり最初に実行されるサービスに対し、連携サービス実行管理テーブル１１に記録されている処理件数とそのサービスの処理可能件数を比較する（Ｓ６０４）。
連携サービス管理部６は、テーブル上で管理している処理件数が処理可能件数を超えない場合は（Ｓ６０５）、連携サービス実行管理テーブル１１の処理件数をカウントアップする（Ｓ６０６）。
連携サービス管理部６は、単位時間当たりのすべてのサービスについて比較が完了した場合（Ｓ６０７）、チェックを終了し、サービスリクエスタ１２に受付可能と判定する（Ｓ６０８）。
連携サービス管理部６は、Ｓ６０５で処理可能件数を超える場合は、今までにカウントアップしたすべてのサービスの処理件数をカウントダウンし（Ｓ６０９）、処理を終了し、サービスリクエスタに受付不可と判定する（Ｓ６１０）。
【００３１】
以上のように、サービスプロバイダ２１，３１とサービスコーディネータ５の間で締結されたＳＬＡに基づいて連携サービスの実行を管理することにより、連携サービス全体の処理時間を保証することができるという効果がある。
【００３２】
実施の形態２．
上記実施の形態１では、ＳＬＡ定義情報で定義されている処理可能件数が固定されているため、サービスコーディネータ５で実行されているサービスリクエスタ１２からのリクエスト数が多く処理可能件数に余裕がないが、サービスプロバイダ２１，３１が提供する処理可能件数に余裕がある場合や、逆にリクエスト数が少なく、実行しているサービスが少ないが、他のサービスコーディネータ５が実行している処理件数が多い場合に、処理可能件数を再配分することができない。
実施の形態２では、上記実施の形態１の動作に加え、さらに、図１でサービスコーディネータ５のＳＬＡ処理部７がサービスプロバイダ２１のＳＬＡ処理部２４（サービスプロバイダ３１であればＳＬＡ処理部３４）にＳＬＡで管理されている処理可能件数の変更を問い合わせ、サービスプロバイダ２１はＳＬＡ処理部２４が管理している実行情報により変更の可否を回答し、サービスコーディネータ５はＳＬＡ情報１０を変更する。実施の形態２の構成は、図１と同様である。
【００３３】
送信部５３は、上記記憶装置５１により記憶された複数のサービス提供条件情報の内、少なくとも１つのサービス提供条件情報が示すサービス提供条件の変更を求める問い合わせ情報を上記サービスプロバイダ２１、或いはサービスプロバイダ３１、或いは双方に送信する。
上記受信部５２は、上記送信部５３により送信された問い合わせ情報に対する回答情報を受信する。
上記連携サービス管理部６は、上記受信部５２により受信された回答情報に基づいて、上記受信部５２により受信されたリクエスト情報が求めるサービスグループの各サービス全部を提供することが可能かどうかを判断する。
上記実行部５４は、上記連携サービス管理部６により上記回答情報に基づいて判断された結果に基づいて、上記受信部５２により上記サービスリクエスタ１２から受信されたリクエスト情報が求める上記受信部５２により上記サービスプロバイダ２１（或いはサービスプロバイダ３１、或いは双方）から受信されたサービスグループの各サービス全部を実行し、上記サービスリクエスタ１２に提供する。
【００３４】
図７は本実施の形態２の動作について説明したものである。
サービスコーディネータ５におけるＳＬＡ処理部７は、Ｓ２１０で受付不可能な場合、サービスプロバイダ２１に対してＳＬＡ変更可否の問い合わせを行う（Ｓ２１８）。
サービスプロバイダ２１では、ＳＬＡ処理部２４が負荷情報２３を参照し、変更の可否を回答情報として回答する（Ｓ２２２）。
サービスコーディネータ５におけるＳＬＡ処理部７は受け取った回答を判断し（Ｓ２１９）、変更が不可能な場合は受付拒否をサービスリクエスタ１２に送信部５３を介して送信する（Ｓ２１１）。
サービスコーディネータ５におけるＳＬＡ処理部７は、Ｓ２１９において変更が可能な場合はサービスプロバイダ２１にＳＬＡ変更要求を出し（Ｓ２２０）、記憶装置５１に記憶されたＳＬＡ情報１０（ＳＬＡ定義情報）を変更し（Ｓ２２１）、サービスリクエスタ１２からのリクエストに基づく連携サービスについて連携サービス実行管理テーブル１１への登録を行う（Ｓ２１２）。
サービスプロバイダ２１におけるＳＬＡ処理部２４はＳＬＡ変更要求を受けるとＳＬＡを変更し（Ｓ２２３）、ＳＬＡ定義情報を変更する（Ｓ２２４）。
【００３５】
以上のように、実施の形態２では、サービスリクエスタからサービスリクエストが要求されたとき、連携サービス実行管理状況により、サービスレベルアグリーメントを変更することが可能なときに、サービスプロバイダに対してサービスレベルアグリーメントの変更が可能か問い合わせる手段を備える。
【００３６】
本実施の形態によれば、サービスレベルを動的に変更することが可能になるため、実行可能な連携サービスの処理件数を変化させることができるという効果がある。
【００３７】
実施の形態３．
上記実施の形態２で、サービスリクエスタ１２からの連携サービス実行要求に対して連携サービス実行管理テーブル１１で管理している実行可能な処理件数がＳＬＡ定義情報で定義されている処理可能件数に達していた場合、連携サービスの実行はできない。しかし、サービスプロバイダ２１，３１ではサービスを実行する余裕がある場合がある。
実施の形態３では、実施の形態２に加え、さらに、図１でサービスコーディネータ５のＳＬＡ処理部７がサービスプロバイダ２１のＳＬＡ処理部２４にＳＬＡで管理されている処理可能件数の変更を問い合わせ、サービスプロバイダ２１のＳＬＡ処理部２４が管理している実行情報により増加の可否を回答し、サービスコーディネータ５がＳＬＡ情報１０を増加する。実施の形態３の構成は、図１と同様である。
【００３８】
図８は実施の形態３の動作について説明するフローチャート図である。
サービスコーディネータ５におけるＳＬＡ処理部７は、Ｓ２１０で受付不可能な場合、サービスプロバイダ２１に対してＳＬＡ変更（増加）可否の問い合わせを行う（Ｓ２１８）。
サービスプロバイダ２１のＳＬＡ処理部２４は負荷情報２３を参照し、変更（増加）の可否を回答する（Ｓ２２２）。
サービスコーディネータ５におけるＳＬＡ処理部７は受け取った回答を判断し（Ｓ２１９）、変更（増加）が不可能な場合は受付拒否を送信部５３を介してサービスリクエスタ１２に送信する（Ｓ２１１）。
サービスコーディネータ５におけるＳＬＡ処理部７は、変更（増加）が可能な場合はサービスプロバイダ２１にＳＬＡ変更（増加）要求を出し（Ｓ２２０）、ＳＬＡ情報１０（ＳＬＡ定義情報）を変更し（Ｓ２２１）、連携サービス実行管理テーブル１１への登録を行う（Ｓ２１２）。
サービスプロバイダ２１はＳＬＡ変更（増加）要求を受けるとＳＬＡを増加し（Ｓ２２３）、ＳＬＡ定義情報を変更する（Ｓ２２４）。
【００３９】
以上のように、本実施の形態３では、サービスレベルアグリーメントで決められた条件をサービスプロバイダとサービスコーディネータの間で増加できるときにサービスレベルを増加し、実行可能なリクエストを一時的に増加できる。
【００４０】
本実施の形態３によれば、サービスレベルを動的に増加することが可能になるため、実行可能な連携サービスの処理件数を増加できるという効果がある。
【００４１】
実施の形態４．
上記実施の形態２で、サービスリクエスタ１２からの連携サービス実行要求に対して連携サービス実行管理テーブル１１で管理している実行可能な処理件数がＳＬＡ定義情報で定義されている処理可能件数より大幅に少ない場合、現状のＳＬＡを維持しておく必要がない。しかし、サービスプロバイダ２１，３１ではサービスを実行したい場合がある。
実施の形態４では、実施の形態２に加え、さらに、図１でサービスコーディネータ５のＳＬＡ処理部７がサービスプロバイダ２１のＳＬＡ処理部２４にＳＬＡで管理されている処理可能件数の変更を問い合わせ、サービスプロバイダ２１のＳＬＡ処理部２４が管理している実行情報により減少の可否を回答し、サービスコーディネータ５がＳＬＡ情報１０を減少する。
【００４２】
図９は本実施形態の動作について説明するフローチャート図である。
サービスコーディネータ５におけるＳＬＡ処理部７は、Ｓ２１０で受付可能な場合、サービスプロバイダに対してＳＬＡ変更（減少）可否の問い合わせを行う（Ｓ２１８）。
サービスプロバイダ２１のＳＬＡ処理部２４は負荷情報２３を参照し、変更（減少）の可否を回答する（Ｓ２２２）。
サービスコーディネータ５におけるＳＬＡ処理部７は受け取った回答を判断し（Ｓ２１９）、変更（減少）が不可能な場合は連携サービス実行管理テーブル１１への登録を行う（Ｓ２１２）。
サービスコーディネータ５におけるＳＬＡ処理部７は、変更（減少）が可能な場合はサービスプロバイダ２１にＳＬＡ変更（減少）要求を出し（Ｓ２２０）、ＳＬＡ定義情報を変更し（Ｓ２２１）、連携サービス実行管理テーブル１１への登録を行う（Ｓ２１２）。
サービスプロバイダ２１はＳＬＡ変更（減少）要求を受けるとＳＬＡを変更し（Ｓ２２３）、ＳＬＡ定義情報を変更する（Ｓ２２４）。
【００４３】
以上のように、本実施の形態４では、サービスレベルアグリーメントで決められた条件をサービスプロバイダとサービスコーディネータの間で減少できるときにサービスレベルを減少し、実行可能なリクエストを一時的に減少できる。
【００４４】
本実施の形態４によれば、サービスレベルを動的に減少することが可能になるため、一度増加した処理件数を減らすことができるとともに、増加していない場合でも他のサービスコーディネータで実行可能な連携サービスの処理件数を増加できるという効果がある。
【００４５】
実施の形態５．
上記実施形態１では、サービスリクエスタ１２からのリクエスト件数がＳＬＡ定義情報で定義される処理可能件数を超えるときは、連携サービスの実行を行えなかった。
【００４６】
実施の形態５では、連携サービス実行管理テーブル１１を調べることにより、要求された連携サービスが実行可能になるかを判断し、その情報を通知することができる。言い換えれば、上記連携サービス管理部６は、管理する上記サービスグループの各サービスの現在の提供状況に基づいて、上記受信部５２によりサービスリクエスタ１２から受信されたリクエスト情報が求めるサービスグループの各サービス全部を提供することが可能な時刻を判断し、上記送信部５３は、上記連携サービス管理部６により判断された時刻を上記サービスリクエスタ１２に送信する。
【００４７】
図１０は本実施の形態５の動作について説明するフローチャート図である。
連携サービス管理部６における連携サービス実行管理部８は、Ｓ２１０で受付不可能な場合、連携サービス実行管理テーブル１１を検索して、サービスの実行が可能となる時間を取得する（Ｓ２２５）。
サービスコーディネータ５における連携サービス実行管理部８は、受付拒否と連携サービスを実行可能になる時刻とを送信部５３を介してサービスリクエスタ１２に送信する（Ｓ２１１）。
サービスリクエスタ１２はこの情報に基づいて実行可能な時間に再度連携サービスの実行を要求する。
【００４８】
以上のように、本実施の形態５では、現在受付不能なサービスへのリクエストが要求されたときに、連携サービス実行管理状況からリクエストを受け付けることが可能な時間を通知する。
【００４９】
本実施の形態５によれば、現在実行できない連携サービスが実行可能になる時間を知ることができ、無駄に待つことがないという効果がある。
【００５０】
実施の形態６．
上記実施の形態５では、希望する連携サービスがいつ実行可能になるかを知ることができる。実施の形態６では、さらに、サービスコーディネータ５に実行予約管理テーブルを設け、その情報を管理することにより、実行可能になった段階で連携サービスを実行することができる。
【００５１】
図１１は、実施の形態６に係るサービス連携制御方式の一実施例を示す構成図である。
図１１において、記憶装置５１は、さらに、実行予約管理テーブル１４を記憶している。連携サービス管理部６は、さらに、予約時刻管理部１５を有している。その他の構成は、図１と同様である。
【００５２】
上記連携サービス管理部６は、上記サービスグループの各サービスの現在の提供状況に基づいて、上記受信部５２によりサービスリクエスタ１２から受信されたリクエスト情報が求めるサービスグループの各サービス全部を提供することが可能な時刻に上記リクエスト情報が求めるサービスグループの各サービス全部の実行を予約し、上記実行部５４は、上記連携サービス管理部６により予約された時刻に、上記受信部５２により上記サービスリクエスタ１２から受信されたリクエスト情報が求めるサービスグループの各サービス全部を実行し、上記サービスリクエスタ１２に提供する。
【００５３】
図１２は実施の形態６の動作について説明するフローチャート図である。
サービスコーディネータ５の連携サービス管理部６における予約時刻管理部１５は、Ｓ２１０で受付不可能な場合、連携サービス実行管理テーブル１１を検索して、サービスの実行が可能となる時間を取得し（Ｓ２２５）、実行予約管理テーブル１４にその時刻で登録する（Ｓ２２６）。
予約時刻管理部１５は、連携サービス実行管理テーブル１１にその時刻で登録し（Ｓ２１２）、予約時刻にタイマーを設定する（Ｓ２２７）。
サービスコーディネータの連携サービス管理部６における予約時刻管理部１５は、サービスリクエスタ１２に受付可能と連携サービスの実行を予約した時刻を送信部５３を介して送信する（Ｓ２２８）。
サービスコーディネータにおける実行部５４はタイマーに設定した時刻に連携サービスの実行処理を開始する（Ｓ２１４）。
【００５４】
図１３は、実施の形態６の実行予約管理テーブルの例を示す図である。
実行予約管理テーブル１４は予約時刻、連携サービス名、クライアント名を管理する。
【００５５】
以上のように、実施の形態６では、現在受付不能なサービスへのリクエストが要求されたときに、連携サービス実行管理状況からリクエストを受け付けることが可能な時間を通知するとともに、実行予約管理テーブルを備え、このテーブルによりその時刻からの実行開始を予約する。
【００５６】
本実施の形態６によれば、現在実行できない連携サービスがいつ実行可能になるか知ることができるとともにその開始を予約することができ、再実行しなくても実行できるという効果がある。
【００５７】
実施の形態７．
上記各実施の形態では、ＳＬＡ定義情報の見直しは実行しようとする連携サービスを構成するサービスに限られていた。実施の形態７では、ＳＬＡ定義情報の見直しをすべてのサービスに拡大することで、管理しているサービス全体で需要を予測することにより、サービスレベルを変更することができる。
【００５８】
図５の管理状態５０２の状態で連携サービス２のリクエスト要求を受け付けたとき、連携サービス２はサービスＢ２を実行するので受付可能である。しかし、００：００：２０でサービスＢ１の件数がＳＬＡ情報で定義された処理可能件数５００件になっており、受付不可であることがわかる。したがって、サービスコーディネータ５はサービスプロバイダ２１，３１との間でＳＬＡの増加調整を行い、増加可能であれば、あらかじめ連携サービス１を受付可能としておく。このとき、記憶装置５１では一時的に変更された処理可能件数をＳＬＡ情報１０の一時処理可能件数として保持する。
【００５９】
図１４は、実施の形態７の動作について説明したものである。
連携サービス管理部６は、各サービスの処理時間を連携サービス実行管理テーブル１１の管理単位時間に分割した後（Ｓ６０３）、連携サービス実行管理テーブル１１で管理しているすべてのサービスに対して、単位時間当たりで現在管理している件数と処理可能件数を比較し（Ｓ６１１）、図７のＳ２１８からＳ２２４のステップを実行することで、変更の余地がある場合（Ｓ６１２）、ＳＬＡ定義情報を変更し（Ｓ６１３）、すべてのサービスについて処理が完了した後（Ｓ６１４）、Ｓ６０４の処理を実行する。
【００６０】
以上のように、実施の形態７では、サービスリクエスタ１２からのサービスリクエスト要求にかかわらず、現在管理している連携サービス実行管理状況からサービスレベルの変動を予測し、あらかじめサービスレベルアグリーメントを変更可能な構成としている。
【００６１】
本実施の形態７によれば、サービス要求の予測を行うことができ、事前にＳＬＡ情報を変更しておくことにより、リクエスト時に実行できないケースが減るという効果がある。
【００６２】
実施の形態８．
実施の形態８では、上記実施の形態７に加え、すべてのサービスの処理件数を調べ、不足しそうなサービス（たとえば、処理可能件数の９０％の件数を実行している）がある場合は処理可能件数を増加するようにＳＬＡを変更する。
図１５は、実施の形態８の動作について説明するフローチャート図である。
連携サービス管理部６は、各サービスの処理時間を連携サービス実行管理テーブルの管理単位時間に分割した後（Ｓ６０３）、連携サービス実行管理テーブル１１で管理しているすべてのサービスに対して、単位時間当たりで現在管理している件数と処理可能件数を比較し（Ｓ６１１）、図７のＳ２１８からＳ２２４のステップを実行することで、変更（増加）の余地がある場合（Ｓ６１２）、ＳＬＡ定義情報を変更（増加）し（Ｓ６１３）、すべてのサービスについて処理が完了した後（Ｓ６１４）、Ｓ６０４の処理を実行する。
【００６３】
以上のように、本実施の形態８では、現在管理している連携サービス実行管理状況からサービスレベルの変動を予測し、あらかじめサービスレベルを増加できる。
【００６４】
本実施の形態８によれば、事前に処理可能件数を増加することができ、連携サービス実行に失敗する可能性が少なくなるという効果がある。
【００６５】
実施の形態９．
実施の形態９では、実施の形態７に加え、すべてのサービスの処理件数を調べ、余りそうなサービス（たとえば、処理可能件数の２０％以下の件数しか実行していない）がある場合は処理可能件数を減少するようにＳＬＡを変更する。
図１６は、実施の形態９の動作について説明するフローチャート図である。
連携サービス管理部６は、各サービスの処理時間を連携サービス実行管理テーブル１１の管理単位時間に分割した後（Ｓ６０３）、連携サービス実行管理テーブル１１で管理しているすべてのサービスに対して、単位時間当たりで現在管理している件数と処理可能件数を比較し（Ｓ６１１）、図７のＳ２１８からＳ２２４のステップを実行することで、変更（減少）の余地がある場合（Ｓ６１２）、ＳＬＡ定義情報を変更（減少）し（Ｓ６１３）、すべてのサービスについて処理が完了した後（Ｓ６１４）、Ｓ６０４の処理を実行する。
【００６６】
以上のように、実施の形態９では、現在管理している連携サービス実行管理状況からサービスレベルの変動を予測し、あらかじめサービスレベルを減少できる。
【００６７】
本実施の形態９によれば、事前に処理可能件数を減少することができ、他のサービスプロバイダで連携サービス実行に失敗する可能性が少なくなるという効果がある。
【００６８】
実施の形態１０．
上記実施形態８では、処理可能な連携サービスの件数を事前に変更することができたが、すでに予約されている連携サービスのサービスリクエスタはそれを知る手段がなく、変更することができなかった。
実施の形態１０では、現在管理している連携サービス実行管理状況からサービスレベルの変動を予測し、あらかじめサービスレベルを増加し、リクエスト受付可能時間が早くなったときに、連携サービス管理部が変更された時間を通知する。
【００６９】
図１７は、実施の形態１０の動作について説明するフローチャート図である。
連携サービス管理部６は、各サービスの処理時間を連携サービス実行管理テーブル１１の管理単位時間に分割した後（Ｓ６０３）、連携サービス実行管理テーブル１１で管理しているすべてのサービスに対して、単位時間当たりで現在管理している件数と処理可能件数を比較し（Ｓ６１１）、図７のＳ２１８からＳ２２４のステップを実行することで、変更（増加）の余地がある場合（Ｓ６１２）、ＳＬＡ定義情報を変更（増加）し（Ｓ６１３）、すべてのサービスについて処理が完了した後（Ｓ６１４）、現在実行予約管理テーブル１４に予約されている連携サービスで開始時刻を変更可能なサービスがある場合（Ｓ６１５）、予約時刻が変更可能なことをサービスリクエスタ１２に通知し（Ｓ６１６）、Ｓ６０４の処理を実行する。
【００７０】
本実施の形態１０によれば、受付可能になる時刻をサービスリクエスタに通知することができ、サービスリクエスタの待ち時間を短縮できるという効果がある。
【００７１】
実施の形態１１．
上記実施の形態６，１０では、連携サービスを実行することが可能になる時刻が早くなっても、予約された時刻を変更することができなかった。
実施の形態１１では、現在管理している連携サービス実行管理状況からサービスレベルの変動を予測し、あらかじめサービスレベルが増加でき、リクエスト受付が可能な時間が早くなったときに、連携サービス実行管理部が実行を開始する予約時刻を変更する。
【００７２】
図１８は、実施の形態１１の動作について説明するフローチャート図である。連携サービス管理部６は、各サービスの処理時間を連携サービス実行管理テーブルの管理単位時間に分割した後（Ｓ６０３）、連携サービス実行管理テーブル１１で管理しているすべてのサービスに対して、単位時間当たりで現在管理している件数と処理可能件数を比較し（Ｓ６１１）、図７のＳ２１８からＳ２２４のステップを実行することで、変更（増加）の余地がある場合（Ｓ６１２）、ＳＬＡ定義情報を変更（増加）し（Ｓ６１３）、すべてのサービスについて処理が完了した後（Ｓ６１４）、現在実行予約管理テーブル１４に予約されている連携サービスで開始時刻を変更可能なサービスがある場合（Ｓ６１５）、予約時刻を変更し（Ｓ６１６）、Ｓ６０４の処理を実行する。
【００７３】
本実施の形態１１によれば、予約されている連携サービスが実行可能になる時刻が速くなったとき予約時刻を変更することができ、連携サービス実行結果を早く得られるという効果がある。
【００７４】
以上の各実施の形態の説明において、サービスプロバイダ２１，３１とサービスコーディネータ５とサービスリクエスタ１２とは、図示されていないが、システムユニット、ＣＲＴ（Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ）表示装置、キーボード（Ｋ／Ｂ）、マウス、コンパクトディスク装置（ＣＤＤ）、プリンタ装置、スキャナ装置を備えている。ＣＲＴ表示装置、Ｋ／Ｂ、マウス、ＣＤＤ、プリンタ装置、スキャナ装置は、システムユニットにケーブルで接続されている。
また、サービスプロバイダ２１，３１とサービスコーディネータ５とサービスリクエスタ１２とは、図示されていないが、プログラムを実行するＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）を備えている。ＣＰＵは、バスを介してＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）（記憶装置の一例である）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）（記憶装置の一例である）、通信ボード、ＣＲＴ表示装置、Ｋ／Ｂ、マウス、ＦＤＤ（Ｆｌｅｘｉｂｌｅ Ｄｉｓｋ Ｄｒｉｖｅ）、磁気ディスク装置（記憶装置の一例である）、ＣＤＤ、プリンタ装置、スキャナ装置と接続されている。通信ボードは、インターネットに接続されている。
ここで、通信ボードは、インターネットに限らず、さらに、ＬＡＮ（ローカルエリアネットワーク）、或いはＩＳＤＮ等のＷＡＮ（ワイドエリアネットワーク）に接続されていても構わない。
磁気ディスク装置には、オペレーティングシステム（ＯＳ）、ウィンドウシステム、プログラム群、ファイル群が記憶されている。プログラム群は、ＣＰＵ、ＯＳ、ウィンドウシステムにより実行される。
【００７５】
また、以上の説明において、各実施の形態の説明において「〜部」として説明したものは、一部或いはすべてコンピュータで動作可能なプログラムにより構成することができる。これらのプログラムは、例えば、Ｃ言語により作成することができる。或いは、ＨＴＭＬやＳＧＭＬやＸＭＬを用いても構わない。或いは、ＪＡＶＡ（登録商標）を用いて画面表示を行っても構わない。
プログラムにより構成する場合、上記プログラム群には、各実施の形態の説明において「〜部」として説明したものにより実行されるプログラムが記憶されている。ファイル群には、上記実施の形態の説明において「〜情報」、「〜テーブル」として説明したものが記憶されている。
また、各実施の形態の説明において「〜部」として説明したものは、ＲＯＭに記憶されたファームウェアで実現されていても構わない。或いは、ソフトウェア或いは、ハードウェア或いは、ソフトウェアとハードウェアとファームウェアとの組み合わせで実施されても構わない。
また、上記各実施の形態を実施させるプログラムは、また、磁気ディスク装置、ＦＤ（Ｆｌｅｘｉｂｌｅ Ｄｉｓｋ）、光ディスク、ＣＤ（コンパクトディスク）、ＭＤ（ミニディスク）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）等のその他の記録媒体による記録装置を用いて記憶されても構わない。
また、出力部は、ＣＲＴ表示装置、その他の表示装置、プリンタ装置等の出力装置を用いても構わない。
【００７６】
【発明の効果】
本発明によれば、ユーザ要件の中でも特にレスポンス要件を保証して複数のサービスを組み合わせて実行できる装置を提供することができる。
【図面の簡単な説明】
【図１】実施の形態１に係るサービス連携制御方式の一実施例を示す構成図である。
【図２】実施の形態１におけるサービス連携制御方式の動作を示すフローチャート図である。
【図３】本実施の形態１のサービスレベルアグリーメント（ＳＬＡ）情報の例を示す図である。
【図４】本実施の形態１の連携サービス定義情報の例を示す図である。
【図５】本実施の形態１の連携サービス実行管理テーブルの例を示す図である。
【図６】連携サービス実行管理テーブルチェック手順を示すフローチャート図である。
【図７】本実施の形態２の動作について説明した図である。
【図８】実施の形態３の動作について説明するフローチャート図である。
【図９】本実施の形態４の動作について説明するフローチャート図である。
【図１０】本実施の形態５の動作について説明するフローチャート図である。
【図１１】実施の形態６に係るサービス連携制御方式の一実施例を示す構成図である。
【図１２】実施の形態６の動作について説明するフローチャート図である。
【図１３】実施の形態６の実行予約管理テーブルの例を示す図である。
【図１４】実施の形態７の動作について説明した図である。
【図１５】実施の形態８の動作について説明するフローチャート図である。
【図１６】実施の形態９の動作について説明するフローチャート図である。
【図１７】実施の形態１０の動作について説明するフローチャート図である。
【図１８】実施の形態１１の動作について説明するフローチャート図である。
【符号の説明】
１ 連携サービス、２ 連携サービス、５ サービスコーディネータ、６ 連携サービス管理部、７ ＳＬＡ処理部、８ 連携サービス実行管理部、９ 連携サービス定義、１０ ＳＬＡ情報、１１ 連携サービス実行管理テーブル、１２サービスリクエスタ、１４ 実行予約管理テーブル、１５ 予約時刻管理部、２１ サービスプロバイダ、２２ 提供サービス、２３ 負荷情報、２４ ＳＬＡ処理部、２５ 記憶装置、３１ サービスプロバイダ、３２ 提供サービス、３３ 負荷情報、３４ ＳＬＡ処理部、３５ 記憶装置、５１ 記憶装置、５２受信部、５３ 送信部、５４ 実行部、１２１ 記憶装置、５０１ 管理状態、５０２ 管理状態。
【発明の属する技術分野】
この発明は、サービス提供装置或いはサービスコーディネータ装置、またはサービス提供方法或いはサービスコーディネート方法に関するものである。特に、サービス連携制御方式に関するものである。
【０００２】
【従来の技術】
ユーザの要求するアプリケーション・サービスの提供を効率良く行うことが可能な技術を提供することを目的とした以下の手段が文献に記載されている。ユーザにアプリケーション・サービスを提供するアプリケーション・サービス・提供方法において、単数或いは複数のアプリケーション提供者が提供する複数のアプリケーションの中からユーザの要求する要件であるユーザ要件を満たすアプリケーション或いはアプリケーション提供者とその提供するアプリケーションを選択するステップと、前記選択されたアプリケーションの間のデータ形式変換または通信プロトコル変換或いはワークフロー管理を行ってアプリケーション・サービスを提供するステップとを有するものである。（特許文献１参照）
【０００３】
【特許文献１】
特開２００１−３０６５３５号公報
【０００４】
【発明が解決しようとする課題】
特許文献１における構成を取るアプリケーション・サービス・提供システムでは、ユーザが中間プロバイダにアクセスし、中間プロバイダからアプリケーション分類一覧を受信し、対象アプリケーションを選択する。次に中間プロバイダから要件入力シートを受信し、ユーザ要件（機能要件、課金要件、レスポンス要件）を入力する。中間プロバイダは機能要件と課金要件を満足するアプリケーション候補一覧を表示し、ユーザはこの候補一覧からアプリケーションを選択する。中間プロバイダはユーザ要件情報をユーザ要件データベースに保存し、サービスを開始する。サービス実行中にレスポンス要件を満足できない状況が発生したときは、新たなアプリケーション候補一覧を作成し、ユーザが候補一覧から選択し、実行するアプリケーションを切り替えるか現状を維持してサービスを続行する。
【０００５】
上記のような構成を取るアプリケーション・サービス・提供システムでは、以下のような問題があった。
アプリケーションを選択する際に個々のアプリケーションがユーザ要件を満足するかどうかは確認できるが、連携したアプリケーション・サービス全体でユーザ要件を満足するかどうかの確認ができない。
また、多数のユーザからの要求が重なったときなど、連携サービスの実行途中にレスポンス要件を満足できなくなり、動的にアプリケーションの切替処理が行われるが、レスポンス要件を満たすアプリケーションが存在しない場合は、ユーザに通知を行うため、処理が中断するとともに、レスポンス要件を保証して連携アプリケーション全体を実行することができないという問題があった。
また、動的にレスポンス要件を測定する処理がプロバイダにとっての負荷となるという問題があった。
【０００６】
この発明は、ユーザ要件の中でも特にレスポンス要件を保証して複数のサービスを組み合わせて実行できる装置を提供することを目的とする。
【０００７】
【課題を解決するための手段】
この発明に係るサービス提供装置は、複数のサービスのサービス提供条件を示す複数のサービス提供条件情報を記憶する記憶部と、
上記複数のサービスの内、いくつかをグループとして組合わせたサービスグループの各サービスを提供することを求めるリクエスト情報を受信する受信部と、
上記サービスグループの各サービスの現在の提供状況を管理し、上記記憶部により記憶された複数のサービス提供条件情報が示すサービス提供条件に基づいて、上記受信部により受信されたリクエスト情報が求めるサービスグループの各サービスを提供することが可能かどうかを判断する管理部と、
上記管理部により判断された結果に基づいて、上記受信部により受信されたリクエスト情報が求めるサービスグループの各サービスの提供を実行する実行部とを備えたことを特徴とする。
【０００８】
【発明の実施の形態】
実施の形態１．
実施の形態１では、複数のサービスを連携して動作させるときに、あらかじめサービスプロバイダ（サービスプロバイダ装置）とサービスコーディネータ（サービスコーディネータ装置）の間で結ばれたサービスレベルアグリーメント情報に基づいて、サービスリクエスタ（サービスリクエスタ装置）からの要求を受け付け、サービスを割り当て、管理することにより、ユーザ要件の中でも特にレスポンス要件を保証して複数のサービスを組み合わせて実行できる連携サービス制御方式を説明する。
【０００９】
図１は、実施の形態１に係るサービス連携制御方式の一実施例を示す構成図である。
図１において、サービス連携制御方式におけるサービス連携制御システムは、サービスを提供するサービスプロバイダ２１，３１、サービスを要求するクライアントであるサービスリクエスタ１２、サービスプロバイダ２１或いはサービスプロバイダ３１が提供する提供サービスを複数組み合わせてサービスリクエスタ１２に提供するサービスコーディネータ５（サービスコーディネータ装置、サービス提供装置の一例である）を備えている。サービスリクエスタ１２に提供される複数組み合わされた提供サービスは、１つのサービスプロバイダ（例えば、サービスプロバイダ２１）が提供する複数の提供サービスであってもよいし、複数のサービスプロバイダ（例えば、サービスプロバイダ２１，３１）が提供する複数の提供サービスであってもよい。
【００１０】
サービスプロバイダ２１は、サービスプロバイダ２１が提供する提供サービス２２とサービスプロバイダ２１が提供サービスの処理状況を示す負荷情報２３とを記憶する記憶装置２５、サービスプロバイダ２１がサービスレベルアグリーメント情報を処理するＳＬＡ（サービスレベルアグリーメント）処理部２４を有している。同様に、サービスプロバイダ３１は、サービスプロバイダ３１が提供する提供サービス３２とサービスプロバイダ２１が提供サービスの処理状況を示す負荷情報３３とを記憶する記憶装置３５、サービスプロバイダ２１がサービスレベルアグリーメント情報を処理するＳＬＡ処理部３４を有している。
【００１１】
サービスコーディネータ５は、複数のサービスを連携して動作させるための連携サービス管理部６（管理部の一例である）、記憶装置５１（記憶部の一例である）、受信部５２、送信部５３、実行部５４を有している。連携サービス管理部６は、サービスコーディネータ５でサービスレベルを調整するＳＬＡ処理部７、連携サービスを処理するための連携サービス実行管理部８を有している。記憶装置５１には、複数のサービスの組合せ情報を管理する連携サービス定義９、ＳＬＡ情報１０、実際のサービスを管理する連携サービス実行管理テーブル１１が記憶されている。
【００１２】
サービスリクエスタ１２は、記憶装置１２１を有し、記憶装置１２１には、サービスを要求するクライアントプログラムが記憶されている。
【００１３】
次に動作について説明する。
記憶装置５１は、サービスを提供するサービスプロバイダとの間で予め設定された複数のサービスのサービス提供条件を示すＳＬＡ情報１０（複数のサービス提供条件情報の一例である）を記憶する。
【００１４】
受信部５２は、上記複数のサービスの内、いずれかをグループとして組合わせたサービスグループの各サービスを提供することを求めるリクエスト情報をサービスリクエスタ１２から受信し、上記サービスグループの各サービスを上記サービスプロバイダ２１，３１から受信する。
【００１５】
連携サービス管理部６は、上記サービスグループの各サービスの現在の提供状況を管理し、上記記憶装置５１により記憶された複数のサービス提供条件情報が示すサービス提供条件に基づいて、上記受信部５２により受信されたリクエスト情報が求めるサービスグループの各サービスを提供することが可能かどうかを判断する。
【００１６】
実行部５４は、上記連携サービス管理部６により判断された結果に基づいて、上記受信部５２により上記サービスリクエスタ１２から受信されたリクエスト情報が求める上記受信部５２により上記サービスプロバイダ２１，３１から受信されたサービスグループの各サービスを実行し、上記サービスリクエスタ１２に提供する。
【００１７】
送信部５３は、上記連携サービス管理部６により判断された結果、上記受信部５２により受信されたリクエスト情報が求めるサービスグループの各サービス全部を提供することが可能でない場合、上記受信部５２により受信されたリクエスト情報の受け付けを拒否する受付拒否情報を上記サービスリクエスタ１２に送信する。
【００１８】
本実施の形態１では、サービスプロバイダとは別に、サービスコーディネータ５が、サービスプロバイダ２１或いはサービスプロバイダ３１が提供する提供サービスを複数組み合わせてサービスリクエスタ１２に提供する構成としているが、サービスプロバイダがサービスコーディネータ５の機能を備えた構成にしていても構わない。すなわち、記憶装置５１が、複数のサービスのサービス提供条件を示すＳＬＡ情報１０（複数のサービス提供条件情報の一例である）を記憶している。
そして、受信部５２は、上記複数のサービスの内、いくつかをグループとして組合わせたサービスグループの各サービスを提供することを求めるリクエスト情報を受信する。
そして、連携サービス管理部６は、上記サービスグループの各サービスの現在の提供状況を管理し、上記記憶装置５１により記憶された複数のサービス提供条件情報が示すサービス提供条件に基づいて、上記受信部５２により受信されたリクエスト情報が求めるサービスグループの各サービスを提供することが可能かどうかを判断する。
そして、実行部５４は、上記連携サービス管理部６により判断された結果に基づいて、上記受信部５２により受信されたリクエスト情報が求めるサービスグループの各サービスの提供を実行する。
【００１９】
図２は、実施の形態１におけるサービス連携制御方式の動作を示すフローチャート図である。
前記のように構成されたサービス連携制御方式において、サービス連携制御方式の動作を図２にしたがって説明する。
まず、サービスリクエスタ１２は、サービスコーディネータ５にアクセスする（Ｓ２０１）。
【００２０】
サービスコーディネータ５における連携サービス管理部６は、記憶装置５１に記憶された連携サービス定義９に基づいて提供する連携サービス一覧を表示する（Ｓ２０８）。
【００２１】
サービスリクエスタ１２は表示された連携サービスから実行したい連携サービス（サービスグループの一例である）を選択する。（Ｓ２０２）。言い換えれば、サービスコーディネータ５における受信部５２は、サービスリクエスタ１２により実行したい連携サービスが選択されることにより、選択動作に係る受信情報をリクエスト情報として受信する。
【００２２】
サービスコーディネータ５における連携サービス管理部６は選択された連携サービスが実行可能かどうか記憶装置５１に記憶された連携サービス実行管理テーブル１１をチェックする（Ｓ２０９）。
【００２３】
サービスコーディネータ５における連携サービス管理部６は、選択された連携サービスを実行できるかどうかを判定し（Ｓ２１０）、受け付けられない場合は受付拒否（受付拒否情報）を送信部５３より送信し（Ｓ２１１）、受付可能な場合は、選択された連携サービスを連携サービス実行管理テーブル１１に登録し（Ｓ２１２）、受付可能（受付可能情報）を送信部５３より送信する（Ｓ２１３）。
【００２４】
サービスリクエスタ１２は受付可否を受信し（Ｓ２０３）、受付可能かどうかを判定し（Ｓ２０４）、受け付けられない場合は連携サービスの選択を終了する（Ｓ２０７）。受付可能な場合は、連携サービス実行に必要なデータを入力し（Ｓ２０５）、サービスコーディネータ５における実行部５４は受信部５２を介して受信したデータにより連携サービスを実行する（Ｓ２１４）。
【００２５】
サービスコーディネータ５における連携サービス管理部６は連携サービスが完了すると実行完了通知と実行結果を送信し（Ｓ２１５）、連携サービス実行管理テーブル１１から削除して（Ｓ２１６）、終了する（Ｓ２１７）。
サービスリクエスタ１２は連携サービス実行完了通知と実行結果を受信して（Ｓ２０６）、終了する（Ｓ２０７）。
【００２６】
以上のように、サービス連携制御方式におけるサービス連携制御システムは、サービスを提供するサービスプロバイダ２１，３１、サービスの実行を要求するサービスリクエスタ１２、サービスのリクエストに対して複数のサービスを連携して実行するサービスコーディネータ５から構成され、サービスプロバイダ２１，３１とサービスコーディネータ５の間でサービスリクエストに対する実行時間を保証するサービスレベルアグリーメントを結び、サービスレベルアグリーメント情報に基づいて、複数のサービスリクエスタ１２に対して、応答時間を保証するために、連携サービス実行管理テーブル１１を備える。
【００２７】
図３は、本実施の形態１のサービスレベルアグリーメント（ＳＬＡ）情報の例を示す図である。
サービスコーディネータ５はサービスプロバイダ２１，３１との間で、あるサービスの処理件数とその処理時間に関する実行保障であるサービスレベルアグリーメントを結び、その情報をサービスレベル定義情報（サービス提供条件情報の一例である）として管理する。
【００２８】
図４は、本実施の形態１の連携サービス定義情報の例を示す図である。
サービスコーディネータ５における連携サービス実行管理部８は、ＳＬＡ情報におけるサービスから連携サービス（サービスグループの一例である）を実行するために必要な処理時間とその連携サービスを実行するために必要な処理時間を算出し、連携サービス定義情報として管理する。サービスコーディネータ５はサービスリクエスタ１２に対して、実行可能な連携サービスの一覧を連携サービス定義９（連携サービス定義情報）に基づいて表示する。
【００２９】
図５は、本実施の形態１の連携サービス実行管理テーブルの例を示す図である。
連携サービス実行管理テーブル１１は設定した単位時間で、連携サービスを構成するすべてのサービスが全体でいつ、どれだけ利用されるかを管理している。なお、図５では単位時間を５秒としている。図５において、管理状態５０１では連携サービス１と連携サービス２のリクエストがそれぞれ２５０件ずつ要求された場合の管理状態を示している。
図５の管理状態５０２は管理状態５０１の状態から５秒後に連携サービス１のリクエスト要求２５０件を受け付けた状態である。この状態で連携サービス１のリクエストを受けると連携サービス１を構成するサービスの一つであるサービスＢ１がＳＬＡで定義された処理可能件数を２０秒後の時点で満たせなくなるため、連携サービス１の受付を不可能とする。
【００３０】
図６は、連携サービス実行管理テーブルチェック手順を示すフローチャート図である。
図６に基づいて、連携サービス実行管理テーブルチェック手順について説明する。連携サービス実行管理テーブルチェックでは、連携サービス管理部６が、連携サービスを構成する各サービスとその実行順序を記憶装置５１に記憶された連携サービス定義９（連携サービス定義情報）から取得する（Ｓ６０１）。
次に、連携サービス管理部６が、各サービスの処理可能件数と処理時間をＳＬＡ情報１０（ＳＬＡ定義情報）から取得する（Ｓ６０２）。
次に、連携サービス管理部６が、各サービスの処理時間を連携サービス実行管理テーブル１１の管理単位時間に分割する（Ｓ６０３）。
次に、連携サービス管理部６が、単位時間あたり最初に実行されるサービスに対し、連携サービス実行管理テーブル１１に記録されている処理件数とそのサービスの処理可能件数を比較する（Ｓ６０４）。
連携サービス管理部６は、テーブル上で管理している処理件数が処理可能件数を超えない場合は（Ｓ６０５）、連携サービス実行管理テーブル１１の処理件数をカウントアップする（Ｓ６０６）。
連携サービス管理部６は、単位時間当たりのすべてのサービスについて比較が完了した場合（Ｓ６０７）、チェックを終了し、サービスリクエスタ１２に受付可能と判定する（Ｓ６０８）。
連携サービス管理部６は、Ｓ６０５で処理可能件数を超える場合は、今までにカウントアップしたすべてのサービスの処理件数をカウントダウンし（Ｓ６０９）、処理を終了し、サービスリクエスタに受付不可と判定する（Ｓ６１０）。
【００３１】
以上のように、サービスプロバイダ２１，３１とサービスコーディネータ５の間で締結されたＳＬＡに基づいて連携サービスの実行を管理することにより、連携サービス全体の処理時間を保証することができるという効果がある。
【００３２】
実施の形態２．
上記実施の形態１では、ＳＬＡ定義情報で定義されている処理可能件数が固定されているため、サービスコーディネータ５で実行されているサービスリクエスタ１２からのリクエスト数が多く処理可能件数に余裕がないが、サービスプロバイダ２１，３１が提供する処理可能件数に余裕がある場合や、逆にリクエスト数が少なく、実行しているサービスが少ないが、他のサービスコーディネータ５が実行している処理件数が多い場合に、処理可能件数を再配分することができない。
実施の形態２では、上記実施の形態１の動作に加え、さらに、図１でサービスコーディネータ５のＳＬＡ処理部７がサービスプロバイダ２１のＳＬＡ処理部２４（サービスプロバイダ３１であればＳＬＡ処理部３４）にＳＬＡで管理されている処理可能件数の変更を問い合わせ、サービスプロバイダ２１はＳＬＡ処理部２４が管理している実行情報により変更の可否を回答し、サービスコーディネータ５はＳＬＡ情報１０を変更する。実施の形態２の構成は、図１と同様である。
【００３３】
送信部５３は、上記記憶装置５１により記憶された複数のサービス提供条件情報の内、少なくとも１つのサービス提供条件情報が示すサービス提供条件の変更を求める問い合わせ情報を上記サービスプロバイダ２１、或いはサービスプロバイダ３１、或いは双方に送信する。
上記受信部５２は、上記送信部５３により送信された問い合わせ情報に対する回答情報を受信する。
上記連携サービス管理部６は、上記受信部５２により受信された回答情報に基づいて、上記受信部５２により受信されたリクエスト情報が求めるサービスグループの各サービス全部を提供することが可能かどうかを判断する。
上記実行部５４は、上記連携サービス管理部６により上記回答情報に基づいて判断された結果に基づいて、上記受信部５２により上記サービスリクエスタ１２から受信されたリクエスト情報が求める上記受信部５２により上記サービスプロバイダ２１（或いはサービスプロバイダ３１、或いは双方）から受信されたサービスグループの各サービス全部を実行し、上記サービスリクエスタ１２に提供する。
【００３４】
図７は本実施の形態２の動作について説明したものである。
サービスコーディネータ５におけるＳＬＡ処理部７は、Ｓ２１０で受付不可能な場合、サービスプロバイダ２１に対してＳＬＡ変更可否の問い合わせを行う（Ｓ２１８）。
サービスプロバイダ２１では、ＳＬＡ処理部２４が負荷情報２３を参照し、変更の可否を回答情報として回答する（Ｓ２２２）。
サービスコーディネータ５におけるＳＬＡ処理部７は受け取った回答を判断し（Ｓ２１９）、変更が不可能な場合は受付拒否をサービスリクエスタ１２に送信部５３を介して送信する（Ｓ２１１）。
サービスコーディネータ５におけるＳＬＡ処理部７は、Ｓ２１９において変更が可能な場合はサービスプロバイダ２１にＳＬＡ変更要求を出し（Ｓ２２０）、記憶装置５１に記憶されたＳＬＡ情報１０（ＳＬＡ定義情報）を変更し（Ｓ２２１）、サービスリクエスタ１２からのリクエストに基づく連携サービスについて連携サービス実行管理テーブル１１への登録を行う（Ｓ２１２）。
サービスプロバイダ２１におけるＳＬＡ処理部２４はＳＬＡ変更要求を受けるとＳＬＡを変更し（Ｓ２２３）、ＳＬＡ定義情報を変更する（Ｓ２２４）。
【００３５】
以上のように、実施の形態２では、サービスリクエスタからサービスリクエストが要求されたとき、連携サービス実行管理状況により、サービスレベルアグリーメントを変更することが可能なときに、サービスプロバイダに対してサービスレベルアグリーメントの変更が可能か問い合わせる手段を備える。
【００３６】
本実施の形態によれば、サービスレベルを動的に変更することが可能になるため、実行可能な連携サービスの処理件数を変化させることができるという効果がある。
【００３７】
実施の形態３．
上記実施の形態２で、サービスリクエスタ１２からの連携サービス実行要求に対して連携サービス実行管理テーブル１１で管理している実行可能な処理件数がＳＬＡ定義情報で定義されている処理可能件数に達していた場合、連携サービスの実行はできない。しかし、サービスプロバイダ２１，３１ではサービスを実行する余裕がある場合がある。
実施の形態３では、実施の形態２に加え、さらに、図１でサービスコーディネータ５のＳＬＡ処理部７がサービスプロバイダ２１のＳＬＡ処理部２４にＳＬＡで管理されている処理可能件数の変更を問い合わせ、サービスプロバイダ２１のＳＬＡ処理部２４が管理している実行情報により増加の可否を回答し、サービスコーディネータ５がＳＬＡ情報１０を増加する。実施の形態３の構成は、図１と同様である。
【００３８】
図８は実施の形態３の動作について説明するフローチャート図である。
サービスコーディネータ５におけるＳＬＡ処理部７は、Ｓ２１０で受付不可能な場合、サービスプロバイダ２１に対してＳＬＡ変更（増加）可否の問い合わせを行う（Ｓ２１８）。
サービスプロバイダ２１のＳＬＡ処理部２４は負荷情報２３を参照し、変更（増加）の可否を回答する（Ｓ２２２）。
サービスコーディネータ５におけるＳＬＡ処理部７は受け取った回答を判断し（Ｓ２１９）、変更（増加）が不可能な場合は受付拒否を送信部５３を介してサービスリクエスタ１２に送信する（Ｓ２１１）。
サービスコーディネータ５におけるＳＬＡ処理部７は、変更（増加）が可能な場合はサービスプロバイダ２１にＳＬＡ変更（増加）要求を出し（Ｓ２２０）、ＳＬＡ情報１０（ＳＬＡ定義情報）を変更し（Ｓ２２１）、連携サービス実行管理テーブル１１への登録を行う（Ｓ２１２）。
サービスプロバイダ２１はＳＬＡ変更（増加）要求を受けるとＳＬＡを増加し（Ｓ２２３）、ＳＬＡ定義情報を変更する（Ｓ２２４）。
【００３９】
以上のように、本実施の形態３では、サービスレベルアグリーメントで決められた条件をサービスプロバイダとサービスコーディネータの間で増加できるときにサービスレベルを増加し、実行可能なリクエストを一時的に増加できる。
【００４０】
本実施の形態３によれば、サービスレベルを動的に増加することが可能になるため、実行可能な連携サービスの処理件数を増加できるという効果がある。
【００４１】
実施の形態４．
上記実施の形態２で、サービスリクエスタ１２からの連携サービス実行要求に対して連携サービス実行管理テーブル１１で管理している実行可能な処理件数がＳＬＡ定義情報で定義されている処理可能件数より大幅に少ない場合、現状のＳＬＡを維持しておく必要がない。しかし、サービスプロバイダ２１，３１ではサービスを実行したい場合がある。
実施の形態４では、実施の形態２に加え、さらに、図１でサービスコーディネータ５のＳＬＡ処理部７がサービスプロバイダ２１のＳＬＡ処理部２４にＳＬＡで管理されている処理可能件数の変更を問い合わせ、サービスプロバイダ２１のＳＬＡ処理部２４が管理している実行情報により減少の可否を回答し、サービスコーディネータ５がＳＬＡ情報１０を減少する。
【００４２】
図９は本実施形態の動作について説明するフローチャート図である。
サービスコーディネータ５におけるＳＬＡ処理部７は、Ｓ２１０で受付可能な場合、サービスプロバイダに対してＳＬＡ変更（減少）可否の問い合わせを行う（Ｓ２１８）。
サービスプロバイダ２１のＳＬＡ処理部２４は負荷情報２３を参照し、変更（減少）の可否を回答する（Ｓ２２２）。
サービスコーディネータ５におけるＳＬＡ処理部７は受け取った回答を判断し（Ｓ２１９）、変更（減少）が不可能な場合は連携サービス実行管理テーブル１１への登録を行う（Ｓ２１２）。
サービスコーディネータ５におけるＳＬＡ処理部７は、変更（減少）が可能な場合はサービスプロバイダ２１にＳＬＡ変更（減少）要求を出し（Ｓ２２０）、ＳＬＡ定義情報を変更し（Ｓ２２１）、連携サービス実行管理テーブル１１への登録を行う（Ｓ２１２）。
サービスプロバイダ２１はＳＬＡ変更（減少）要求を受けるとＳＬＡを変更し（Ｓ２２３）、ＳＬＡ定義情報を変更する（Ｓ２２４）。
【００４３】
以上のように、本実施の形態４では、サービスレベルアグリーメントで決められた条件をサービスプロバイダとサービスコーディネータの間で減少できるときにサービスレベルを減少し、実行可能なリクエストを一時的に減少できる。
【００４４】
本実施の形態４によれば、サービスレベルを動的に減少することが可能になるため、一度増加した処理件数を減らすことができるとともに、増加していない場合でも他のサービスコーディネータで実行可能な連携サービスの処理件数を増加できるという効果がある。
【００４５】
実施の形態５．
上記実施形態１では、サービスリクエスタ１２からのリクエスト件数がＳＬＡ定義情報で定義される処理可能件数を超えるときは、連携サービスの実行を行えなかった。
【００４６】
実施の形態５では、連携サービス実行管理テーブル１１を調べることにより、要求された連携サービスが実行可能になるかを判断し、その情報を通知することができる。言い換えれば、上記連携サービス管理部６は、管理する上記サービスグループの各サービスの現在の提供状況に基づいて、上記受信部５２によりサービスリクエスタ１２から受信されたリクエスト情報が求めるサービスグループの各サービス全部を提供することが可能な時刻を判断し、上記送信部５３は、上記連携サービス管理部６により判断された時刻を上記サービスリクエスタ１２に送信する。
【００４７】
図１０は本実施の形態５の動作について説明するフローチャート図である。
連携サービス管理部６における連携サービス実行管理部８は、Ｓ２１０で受付不可能な場合、連携サービス実行管理テーブル１１を検索して、サービスの実行が可能となる時間を取得する（Ｓ２２５）。
サービスコーディネータ５における連携サービス実行管理部８は、受付拒否と連携サービスを実行可能になる時刻とを送信部５３を介してサービスリクエスタ１２に送信する（Ｓ２１１）。
サービスリクエスタ１２はこの情報に基づいて実行可能な時間に再度連携サービスの実行を要求する。
【００４８】
以上のように、本実施の形態５では、現在受付不能なサービスへのリクエストが要求されたときに、連携サービス実行管理状況からリクエストを受け付けることが可能な時間を通知する。
【００４９】
本実施の形態５によれば、現在実行できない連携サービスが実行可能になる時間を知ることができ、無駄に待つことがないという効果がある。
【００５０】
実施の形態６．
上記実施の形態５では、希望する連携サービスがいつ実行可能になるかを知ることができる。実施の形態６では、さらに、サービスコーディネータ５に実行予約管理テーブルを設け、その情報を管理することにより、実行可能になった段階で連携サービスを実行することができる。
【００５１】
図１１は、実施の形態６に係るサービス連携制御方式の一実施例を示す構成図である。
図１１において、記憶装置５１は、さらに、実行予約管理テーブル１４を記憶している。連携サービス管理部６は、さらに、予約時刻管理部１５を有している。その他の構成は、図１と同様である。
【００５２】
上記連携サービス管理部６は、上記サービスグループの各サービスの現在の提供状況に基づいて、上記受信部５２によりサービスリクエスタ１２から受信されたリクエスト情報が求めるサービスグループの各サービス全部を提供することが可能な時刻に上記リクエスト情報が求めるサービスグループの各サービス全部の実行を予約し、上記実行部５４は、上記連携サービス管理部６により予約された時刻に、上記受信部５２により上記サービスリクエスタ１２から受信されたリクエスト情報が求めるサービスグループの各サービス全部を実行し、上記サービスリクエスタ１２に提供する。
【００５３】
図１２は実施の形態６の動作について説明するフローチャート図である。
サービスコーディネータ５の連携サービス管理部６における予約時刻管理部１５は、Ｓ２１０で受付不可能な場合、連携サービス実行管理テーブル１１を検索して、サービスの実行が可能となる時間を取得し（Ｓ２２５）、実行予約管理テーブル１４にその時刻で登録する（Ｓ２２６）。
予約時刻管理部１５は、連携サービス実行管理テーブル１１にその時刻で登録し（Ｓ２１２）、予約時刻にタイマーを設定する（Ｓ２２７）。
サービスコーディネータの連携サービス管理部６における予約時刻管理部１５は、サービスリクエスタ１２に受付可能と連携サービスの実行を予約した時刻を送信部５３を介して送信する（Ｓ２２８）。
サービスコーディネータにおける実行部５４はタイマーに設定した時刻に連携サービスの実行処理を開始する（Ｓ２１４）。
【００５４】
図１３は、実施の形態６の実行予約管理テーブルの例を示す図である。
実行予約管理テーブル１４は予約時刻、連携サービス名、クライアント名を管理する。
【００５５】
以上のように、実施の形態６では、現在受付不能なサービスへのリクエストが要求されたときに、連携サービス実行管理状況からリクエストを受け付けることが可能な時間を通知するとともに、実行予約管理テーブルを備え、このテーブルによりその時刻からの実行開始を予約する。
【００５６】
本実施の形態６によれば、現在実行できない連携サービスがいつ実行可能になるか知ることができるとともにその開始を予約することができ、再実行しなくても実行できるという効果がある。
【００５７】
実施の形態７．
上記各実施の形態では、ＳＬＡ定義情報の見直しは実行しようとする連携サービスを構成するサービスに限られていた。実施の形態７では、ＳＬＡ定義情報の見直しをすべてのサービスに拡大することで、管理しているサービス全体で需要を予測することにより、サービスレベルを変更することができる。
【００５８】
図５の管理状態５０２の状態で連携サービス２のリクエスト要求を受け付けたとき、連携サービス２はサービスＢ２を実行するので受付可能である。しかし、００：００：２０でサービスＢ１の件数がＳＬＡ情報で定義された処理可能件数５００件になっており、受付不可であることがわかる。したがって、サービスコーディネータ５はサービスプロバイダ２１，３１との間でＳＬＡの増加調整を行い、増加可能であれば、あらかじめ連携サービス１を受付可能としておく。このとき、記憶装置５１では一時的に変更された処理可能件数をＳＬＡ情報１０の一時処理可能件数として保持する。
【００５９】
図１４は、実施の形態７の動作について説明したものである。
連携サービス管理部６は、各サービスの処理時間を連携サービス実行管理テーブル１１の管理単位時間に分割した後（Ｓ６０３）、連携サービス実行管理テーブル１１で管理しているすべてのサービスに対して、単位時間当たりで現在管理している件数と処理可能件数を比較し（Ｓ６１１）、図７のＳ２１８からＳ２２４のステップを実行することで、変更の余地がある場合（Ｓ６１２）、ＳＬＡ定義情報を変更し（Ｓ６１３）、すべてのサービスについて処理が完了した後（Ｓ６１４）、Ｓ６０４の処理を実行する。
【００６０】
以上のように、実施の形態７では、サービスリクエスタ１２からのサービスリクエスト要求にかかわらず、現在管理している連携サービス実行管理状況からサービスレベルの変動を予測し、あらかじめサービスレベルアグリーメントを変更可能な構成としている。
【００６１】
本実施の形態７によれば、サービス要求の予測を行うことができ、事前にＳＬＡ情報を変更しておくことにより、リクエスト時に実行できないケースが減るという効果がある。
【００６２】
実施の形態８．
実施の形態８では、上記実施の形態７に加え、すべてのサービスの処理件数を調べ、不足しそうなサービス（たとえば、処理可能件数の９０％の件数を実行している）がある場合は処理可能件数を増加するようにＳＬＡを変更する。
図１５は、実施の形態８の動作について説明するフローチャート図である。
連携サービス管理部６は、各サービスの処理時間を連携サービス実行管理テーブルの管理単位時間に分割した後（Ｓ６０３）、連携サービス実行管理テーブル１１で管理しているすべてのサービスに対して、単位時間当たりで現在管理している件数と処理可能件数を比較し（Ｓ６１１）、図７のＳ２１８からＳ２２４のステップを実行することで、変更（増加）の余地がある場合（Ｓ６１２）、ＳＬＡ定義情報を変更（増加）し（Ｓ６１３）、すべてのサービスについて処理が完了した後（Ｓ６１４）、Ｓ６０４の処理を実行する。
【００６３】
以上のように、本実施の形態８では、現在管理している連携サービス実行管理状況からサービスレベルの変動を予測し、あらかじめサービスレベルを増加できる。
【００６４】
本実施の形態８によれば、事前に処理可能件数を増加することができ、連携サービス実行に失敗する可能性が少なくなるという効果がある。
【００６５】
実施の形態９．
実施の形態９では、実施の形態７に加え、すべてのサービスの処理件数を調べ、余りそうなサービス（たとえば、処理可能件数の２０％以下の件数しか実行していない）がある場合は処理可能件数を減少するようにＳＬＡを変更する。
図１６は、実施の形態９の動作について説明するフローチャート図である。
連携サービス管理部６は、各サービスの処理時間を連携サービス実行管理テーブル１１の管理単位時間に分割した後（Ｓ６０３）、連携サービス実行管理テーブル１１で管理しているすべてのサービスに対して、単位時間当たりで現在管理している件数と処理可能件数を比較し（Ｓ６１１）、図７のＳ２１８からＳ２２４のステップを実行することで、変更（減少）の余地がある場合（Ｓ６１２）、ＳＬＡ定義情報を変更（減少）し（Ｓ６１３）、すべてのサービスについて処理が完了した後（Ｓ６１４）、Ｓ６０４の処理を実行する。
【００６６】
以上のように、実施の形態９では、現在管理している連携サービス実行管理状況からサービスレベルの変動を予測し、あらかじめサービスレベルを減少できる。
【００６７】
本実施の形態９によれば、事前に処理可能件数を減少することができ、他のサービスプロバイダで連携サービス実行に失敗する可能性が少なくなるという効果がある。
【００６８】
実施の形態１０．
上記実施形態８では、処理可能な連携サービスの件数を事前に変更することができたが、すでに予約されている連携サービスのサービスリクエスタはそれを知る手段がなく、変更することができなかった。
実施の形態１０では、現在管理している連携サービス実行管理状況からサービスレベルの変動を予測し、あらかじめサービスレベルを増加し、リクエスト受付可能時間が早くなったときに、連携サービス管理部が変更された時間を通知する。
【００６９】
図１７は、実施の形態１０の動作について説明するフローチャート図である。
連携サービス管理部６は、各サービスの処理時間を連携サービス実行管理テーブル１１の管理単位時間に分割した後（Ｓ６０３）、連携サービス実行管理テーブル１１で管理しているすべてのサービスに対して、単位時間当たりで現在管理している件数と処理可能件数を比較し（Ｓ６１１）、図７のＳ２１８からＳ２２４のステップを実行することで、変更（増加）の余地がある場合（Ｓ６１２）、ＳＬＡ定義情報を変更（増加）し（Ｓ６１３）、すべてのサービスについて処理が完了した後（Ｓ６１４）、現在実行予約管理テーブル１４に予約されている連携サービスで開始時刻を変更可能なサービスがある場合（Ｓ６１５）、予約時刻が変更可能なことをサービスリクエスタ１２に通知し（Ｓ６１６）、Ｓ６０４の処理を実行する。
【００７０】
本実施の形態１０によれば、受付可能になる時刻をサービスリクエスタに通知することができ、サービスリクエスタの待ち時間を短縮できるという効果がある。
【００７１】
実施の形態１１．
上記実施の形態６，１０では、連携サービスを実行することが可能になる時刻が早くなっても、予約された時刻を変更することができなかった。
実施の形態１１では、現在管理している連携サービス実行管理状況からサービスレベルの変動を予測し、あらかじめサービスレベルが増加でき、リクエスト受付が可能な時間が早くなったときに、連携サービス実行管理部が実行を開始する予約時刻を変更する。
【００７２】
図１８は、実施の形態１１の動作について説明するフローチャート図である。連携サービス管理部６は、各サービスの処理時間を連携サービス実行管理テーブルの管理単位時間に分割した後（Ｓ６０３）、連携サービス実行管理テーブル１１で管理しているすべてのサービスに対して、単位時間当たりで現在管理している件数と処理可能件数を比較し（Ｓ６１１）、図７のＳ２１８からＳ２２４のステップを実行することで、変更（増加）の余地がある場合（Ｓ６１２）、ＳＬＡ定義情報を変更（増加）し（Ｓ６１３）、すべてのサービスについて処理が完了した後（Ｓ６１４）、現在実行予約管理テーブル１４に予約されている連携サービスで開始時刻を変更可能なサービスがある場合（Ｓ６１５）、予約時刻を変更し（Ｓ６１６）、Ｓ６０４の処理を実行する。
【００７３】
本実施の形態１１によれば、予約されている連携サービスが実行可能になる時刻が速くなったとき予約時刻を変更することができ、連携サービス実行結果を早く得られるという効果がある。
【００７４】
以上の各実施の形態の説明において、サービスプロバイダ２１，３１とサービスコーディネータ５とサービスリクエスタ１２とは、図示されていないが、システムユニット、ＣＲＴ（Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ）表示装置、キーボード（Ｋ／Ｂ）、マウス、コンパクトディスク装置（ＣＤＤ）、プリンタ装置、スキャナ装置を備えている。ＣＲＴ表示装置、Ｋ／Ｂ、マウス、ＣＤＤ、プリンタ装置、スキャナ装置は、システムユニットにケーブルで接続されている。
また、サービスプロバイダ２１，３１とサービスコーディネータ５とサービスリクエスタ１２とは、図示されていないが、プログラムを実行するＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）を備えている。ＣＰＵは、バスを介してＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）（記憶装置の一例である）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）（記憶装置の一例である）、通信ボード、ＣＲＴ表示装置、Ｋ／Ｂ、マウス、ＦＤＤ（Ｆｌｅｘｉｂｌｅ Ｄｉｓｋ Ｄｒｉｖｅ）、磁気ディスク装置（記憶装置の一例である）、ＣＤＤ、プリンタ装置、スキャナ装置と接続されている。通信ボードは、インターネットに接続されている。
ここで、通信ボードは、インターネットに限らず、さらに、ＬＡＮ（ローカルエリアネットワーク）、或いはＩＳＤＮ等のＷＡＮ（ワイドエリアネットワーク）に接続されていても構わない。
磁気ディスク装置には、オペレーティングシステム（ＯＳ）、ウィンドウシステム、プログラム群、ファイル群が記憶されている。プログラム群は、ＣＰＵ、ＯＳ、ウィンドウシステムにより実行される。
【００７５】
また、以上の説明において、各実施の形態の説明において「〜部」として説明したものは、一部或いはすべてコンピュータで動作可能なプログラムにより構成することができる。これらのプログラムは、例えば、Ｃ言語により作成することができる。或いは、ＨＴＭＬやＳＧＭＬやＸＭＬを用いても構わない。或いは、ＪＡＶＡ（登録商標）を用いて画面表示を行っても構わない。
プログラムにより構成する場合、上記プログラム群には、各実施の形態の説明において「〜部」として説明したものにより実行されるプログラムが記憶されている。ファイル群には、上記実施の形態の説明において「〜情報」、「〜テーブル」として説明したものが記憶されている。
また、各実施の形態の説明において「〜部」として説明したものは、ＲＯＭに記憶されたファームウェアで実現されていても構わない。或いは、ソフトウェア或いは、ハードウェア或いは、ソフトウェアとハードウェアとファームウェアとの組み合わせで実施されても構わない。
また、上記各実施の形態を実施させるプログラムは、また、磁気ディスク装置、ＦＤ（Ｆｌｅｘｉｂｌｅ Ｄｉｓｋ）、光ディスク、ＣＤ（コンパクトディスク）、ＭＤ（ミニディスク）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）等のその他の記録媒体による記録装置を用いて記憶されても構わない。
また、出力部は、ＣＲＴ表示装置、その他の表示装置、プリンタ装置等の出力装置を用いても構わない。
【００７６】
【発明の効果】
本発明によれば、ユーザ要件の中でも特にレスポンス要件を保証して複数のサービスを組み合わせて実行できる装置を提供することができる。
【図面の簡単な説明】
【図１】実施の形態１に係るサービス連携制御方式の一実施例を示す構成図である。
【図２】実施の形態１におけるサービス連携制御方式の動作を示すフローチャート図である。
【図３】本実施の形態１のサービスレベルアグリーメント（ＳＬＡ）情報の例を示す図である。
【図４】本実施の形態１の連携サービス定義情報の例を示す図である。
【図５】本実施の形態１の連携サービス実行管理テーブルの例を示す図である。
【図６】連携サービス実行管理テーブルチェック手順を示すフローチャート図である。
【図７】本実施の形態２の動作について説明した図である。
【図８】実施の形態３の動作について説明するフローチャート図である。
【図９】本実施の形態４の動作について説明するフローチャート図である。
【図１０】本実施の形態５の動作について説明するフローチャート図である。
【図１１】実施の形態６に係るサービス連携制御方式の一実施例を示す構成図である。
【図１２】実施の形態６の動作について説明するフローチャート図である。
【図１３】実施の形態６の実行予約管理テーブルの例を示す図である。
【図１４】実施の形態７の動作について説明した図である。
【図１５】実施の形態８の動作について説明するフローチャート図である。
【図１６】実施の形態９の動作について説明するフローチャート図である。
【図１７】実施の形態１０の動作について説明するフローチャート図である。
【図１８】実施の形態１１の動作について説明するフローチャート図である。
【符号の説明】
１ 連携サービス、２ 連携サービス、５ サービスコーディネータ、６ 連携サービス管理部、７ ＳＬＡ処理部、８ 連携サービス実行管理部、９ 連携サービス定義、１０ ＳＬＡ情報、１１ 連携サービス実行管理テーブル、１２サービスリクエスタ、１４ 実行予約管理テーブル、１５ 予約時刻管理部、２１ サービスプロバイダ、２２ 提供サービス、２３ 負荷情報、２４ ＳＬＡ処理部、２５ 記憶装置、３１ サービスプロバイダ、３２ 提供サービス、３３ 負荷情報、３４ ＳＬＡ処理部、３５ 記憶装置、５１ 記憶装置、５２受信部、５３ 送信部、５４ 実行部、１２１ 記憶装置、５０１ 管理状態、５０２ 管理状態。
Claims (10)
- 複数のサービスのサービス提供条件を示す複数のサービス提供条件情報を記憶する記憶部と、
上記複数のサービスの内、いくつかをグループとして組合わせたサービスグループの各サービスを提供することを求めるリクエスト情報を受信する受信部と、
上記サービスグループの各サービスの現在の提供状況を管理し、上記記憶部により記憶された複数のサービス提供条件情報が示すサービス提供条件に基づいて、上記受信部により受信されたリクエスト情報が求めるサービスグループの各サービスを提供することが可能かどうかを判断する管理部と、
上記管理部により判断された結果に基づいて、上記受信部により受信されたリクエスト情報が求めるサービスグループの各サービスの提供を実行する実行部とを備えたことを特徴とするサービス提供装置。 - サービスを提供するサービスプロバイダとの間で予め設定された複数のサービスのサービス提供条件を示す複数のサービス提供条件情報を記憶する記憶部と、
上記複数のサービスの内、いずれかをグループとして組合わせたサービスグループの各サービスを提供することを求めるリクエスト情報をサービスリクエスタから受信し、上記サービスグループの各サービスを上記サービスプロバイダから受信する受信部と、
上記サービスグループの各サービスの現在の提供状況を管理し、上記記憶部により記憶された複数のサービス提供条件情報が示すサービス提供条件に基づいて、上記受信部により受信されたリクエスト情報が求めるサービスグループの各サービスを提供することが可能かどうかを判断する管理部と、
上記管理部により判断された結果に基づいて、上記受信部により上記サービスリクエスタから受信されたリクエスト情報が求める上記受信部により上記サービスプロバイダから受信されたサービスグループの各サービスを実行し、上記サービスリクエスタに提供する実行部と
を備えたことを特徴とするサービスコーディネータ装置。 - サービスコーディネータ装置は、さらに、上記管理部により判断された結果、上記受信部により受信されたリクエスト情報が求めるサービスグループの各サービス全部を提供することが可能でない場合、上記受信部により受信されたリクエスト情報の受け付けを拒否する受付拒否情報を上記サービスリクエスタに送信する送信部を備えたことを特徴とする請求項２記載のサービスコーディネータ装置。
- サービスコーディネータ装置は、さらに、上記記憶部により記憶された複数のサービス提供条件情報の内、少なくとも１つのサービス提供条件情報が示すサービス提供条件の変更を求める問い合わせ情報を上記サービスプロバイダに送信する送信部を備え、
上記受信部は、上記送信部により送信された問い合わせ情報に対する回答情報を受信し、
上記管理部は、上記受信部により受信された回答情報に基づいて、上記受信部により受信されたリクエスト情報が求めるサービスグループの各サービス全部を提供することが可能かどうかを判断し、
上記実行部は、上記管理部により上記回答情報に基づいて判断された結果に基づいて、上記受信部により上記サービスリクエスタから受信されたリクエスト情報が求める上記受信部により上記サービスプロバイダから受信されたサービスグループの各サービス全部を実行し、上記サービスリクエスタに提供することを特徴とする請求項２記載のサービスコーディネータ装置。 - 上記管理部は、管理する上記サービスグループの各サービスの現在の提供状況に基づいて、上記受信部により受信されたリクエスト情報が求めるサービスグループの各サービス全部を提供することが可能な時刻を判断し、
上記送信部は、上記管理部により判断された時刻を上記サービスリクエスタに送信することを特徴とする請求項３記載のサービスコーディネータ装置。 - 上記管理部は、上記サービスグループの各サービスの現在の提供状況に基づいて、上記受信部により受信されたリクエスト情報が求めるサービスグループの各サービス全部を提供することが可能な時刻に上記リクエスト情報が求めるサービスグループの各サービス全部の実行を予約し、
上記実行部は、上記管理部により予約された時刻に、上記受信部により上記サービスリクエスタから受信されたリクエスト情報が求めるサービスグループの各サービス全部を実行し、上記サービスリクエスタに提供することを特徴とする請求項３記載のサービスコーディネータ装置。 - 複数のサービスのサービス提供条件を示す複数のサービス提供条件情報を記憶装置に記憶させる記憶工程と、
上記複数のサービスの内、いくつかをグループとして組合わせたサービスグループの各サービスを提供することを求めるリクエスト情報を受信する受信工程と、
上記サービスグループの各サービスの現在の提供状況を管理し、上記記憶工程により記憶された複数のサービス提供条件情報が示すサービス提供条件に基づいて、上記受信工程により受信されたリクエスト情報が求めるサービスグループの各サービスを提供することが可能かどうかを判断する管理工程と、
上記管理工程により判断された結果に基づいて、上記受信工程により受信されたリクエスト情報が求めるサービスグループの各サービスの提供を実行する実行工程と
を備えたことを特徴とするサービス提供方法。 - サービスを提供するサービスプロバイダとの間で予め設定された複数のサービスのサービス提供条件を示す複数のサービス提供条件情報を記憶装置に記憶させる記憶工程と、
上記複数のサービスの内、いずれかをグループとして組合わせたサービスグループの各サービスを提供することを求めるリクエスト情報をサービスリクエスタから受信し、上記サービスグループの各サービスを上記サービスプロバイダから受信する受信工程と、
上記サービスグループの各サービスの現在の提供状況を管理し、上記記憶工程により記憶された複数のサービス提供条件情報が示すサービス提供条件に基づいて、上記受信工程により受信されたリクエスト情報が求めるサービスグループの各サービスを提供することが可能かどうかを判断する管理工程と、
上記管理工程により判断された結果に基づいて、上記受信工程により上記サービスリクエスタから受信されたリクエスト情報が求める上記受信工程により上記サービスプロバイダから受信されたサービスグループの各サービスを実行し、上記サービスリクエスタに提供する実行工程と
を備えたことを特徴とするサービスコーディネート方法。 - 複数のサービスのサービス提供条件を示す複数のサービス提供条件情報を記憶装置に記憶させる記憶処理と、
上記複数のサービスの内、いくつかをグループとして組合わせたサービスグループの各サービスを提供することを求めるリクエスト情報を受信する受信処理と、
上記サービスグループの各サービスの現在の提供状況を管理し、上記記憶処理により記憶された複数のサービス提供条件情報が示すサービス提供条件に基づいて、上記受信処理により受信されたリクエスト情報が求めるサービスグループの各サービスを提供することが可能かどうかを判断する管理処理と、
上記管理処理により判断された結果に基づいて、上記受信処理により受信されたリクエスト情報が求めるサービスグループの各サービスの提供を実行する実行処理と
をコンピュータに実行させるためのプログラム又は上記プログラムを記録したコンピュータ読み取り可能な記録媒体。 - サービスを提供するサービスプロバイダとの間で予め設定された複数のサービスのサービス提供条件を示す複数のサービス提供条件情報を記憶装置に記憶させる記憶処理と、
上記複数のサービスの内、いずれかをグループとして組合わせたサービスグループの各サービスを提供することを求めるリクエスト情報をサービスリクエスタから受信し、上記サービスグループの各サービスを上記サービスプロバイダから受信する受信処理と、
上記サービスグループの各サービスの現在の提供状況を管理し、上記記憶処理により記憶された複数のサービス提供条件情報が示すサービス提供条件に基づいて、上記受信処理により受信されたリクエスト情報が求めるサービスグループの各サービスを提供することが可能かどうかを判断する管理処理と、
上記管理処理により判断された結果に基づいて、上記受信処理により上記サービスリクエスタから受信されたリクエスト情報が求める上記受信処理により上記サービスプロバイダから受信されたサービスグループの各サービスを実行し、上記サービスリクエスタに提供する実行処理と
をコンピュータに実行させるためのプログラム又は上記プログラムを記録したコンピュータ読み取り可能な記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003162663A JP2004362449A (ja) | 2003-06-06 | 2003-06-06 | サービス提供装置及びサービスコーディネータ装置及びサービス提供方法及びサービスコーディネート方法及びプログラム及びプログラムを記録したコンピュータ読み取り可能な記録媒体 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003162663A JP2004362449A (ja) | 2003-06-06 | 2003-06-06 | サービス提供装置及びサービスコーディネータ装置及びサービス提供方法及びサービスコーディネート方法及びプログラム及びプログラムを記録したコンピュータ読み取り可能な記録媒体 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004362449A true JP2004362449A (ja) | 2004-12-24 |
Family
ID=34054743
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003162663A Abandoned JP2004362449A (ja) | 2003-06-06 | 2003-06-06 | サービス提供装置及びサービスコーディネータ装置及びサービス提供方法及びサービスコーディネート方法及びプログラム及びプログラムを記録したコンピュータ読み取り可能な記録媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2004362449A (ja) |
Cited By (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006268794A (ja) * | 2005-03-25 | 2006-10-05 | Fuji Xerox Co Ltd | 画像処理装置及び方法並びに情報処理システム及び装置 |
| JP2007036479A (ja) * | 2005-07-25 | 2007-02-08 | Fujitsu Ltd | ネットワークシステム、提供装置および利用装置 |
| WO2009084669A1 (ja) * | 2007-12-28 | 2009-07-09 | Nec Corporation | 棄却判定機能を有する合成ワークフローモニタリング方法、装置、および記憶媒体 |
| WO2010131778A1 (ja) * | 2009-05-15 | 2010-11-18 | 日本電気株式会社 | ワークフロー監視制御システム、監視制御方法および監視制御プログラム |
| WO2010146761A1 (ja) * | 2009-06-19 | 2010-12-23 | 日本電気株式会社 | ネットワークサービス制御システム、ネットワークサービス制御方法および記憶媒体 |
| JP2011150654A (ja) * | 2010-01-25 | 2011-08-04 | Mitsubishi Electric Corp | Ｗｅｂサービス稼動監視システムおよびＷｅｂサービス稼動監視方法 |
| WO2012114889A1 (ja) * | 2011-02-23 | 2012-08-30 | 日本電気株式会社 | アプリケーション構築配置システム、アプリケーション構築配置方法、およびプログラム |
| JP2014170312A (ja) * | 2013-03-01 | 2014-09-18 | Ricoh Co Ltd | 情報処理装置、情報処理システム |
| US8966492B2 (en) | 2008-01-31 | 2015-02-24 | Nec Corporation | Service provision quality control device |
| JP2016027476A (ja) * | 2011-06-27 | 2016-02-18 | アマゾン・テクノロジーズ・インコーポレーテッド | 規模変更可能なデータ記憶サービスを実装するためのシステムおよび方法 |
-
2003
- 2003-06-06 JP JP2003162663A patent/JP2004362449A/ja not_active Abandoned
Cited By (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006268794A (ja) * | 2005-03-25 | 2006-10-05 | Fuji Xerox Co Ltd | 画像処理装置及び方法並びに情報処理システム及び装置 |
| JP2007036479A (ja) * | 2005-07-25 | 2007-02-08 | Fujitsu Ltd | ネットワークシステム、提供装置および利用装置 |
| JP4585399B2 (ja) * | 2005-07-25 | 2010-11-24 | 富士通株式会社 | ネットワークシステム、提供装置および利用装置 |
| JP5187318B2 (ja) * | 2007-12-28 | 2013-04-24 | 日本電気株式会社 | 棄却判定機能を有する合成ワークフローモニタリング方法、装置、およびプログラム |
| WO2009084669A1 (ja) * | 2007-12-28 | 2009-07-09 | Nec Corporation | 棄却判定機能を有する合成ワークフローモニタリング方法、装置、および記憶媒体 |
| US8756093B2 (en) | 2007-12-28 | 2014-06-17 | Nec Corporation | Method of monitoring a combined workflow with rejection determination function, device and recording medium therefor |
| US8966492B2 (en) | 2008-01-31 | 2015-02-24 | Nec Corporation | Service provision quality control device |
| WO2010131778A1 (ja) * | 2009-05-15 | 2010-11-18 | 日本電気株式会社 | ワークフロー監視制御システム、監視制御方法および監視制御プログラム |
| US8918792B2 (en) | 2009-05-15 | 2014-12-23 | Nec Corporation | Workflow monitoring and control system, monitoring and control method, and monitoring and control program |
| WO2010146761A1 (ja) * | 2009-06-19 | 2010-12-23 | 日本電気株式会社 | ネットワークサービス制御システム、ネットワークサービス制御方法および記憶媒体 |
| JP2011150654A (ja) * | 2010-01-25 | 2011-08-04 | Mitsubishi Electric Corp | Ｗｅｂサービス稼動監視システムおよびＷｅｂサービス稼動監視方法 |
| WO2012114889A1 (ja) * | 2011-02-23 | 2012-08-30 | 日本電気株式会社 | アプリケーション構築配置システム、アプリケーション構築配置方法、およびプログラム |
| JP2016027476A (ja) * | 2011-06-27 | 2016-02-18 | アマゾン・テクノロジーズ・インコーポレーテッド | 規模変更可能なデータ記憶サービスを実装するためのシステムおよび方法 |
| JP2014170312A (ja) * | 2013-03-01 | 2014-09-18 | Ricoh Co Ltd | 情報処理装置、情報処理システム |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN113169897B (zh) | 用于分析功能发现的方法和设备 | |
| CN1610347B (zh) | 在基于群集的系统内管理性能及资源利用率的方法和设备 | |
| EP3843341B1 (en) | Selection, by a network function repository function device, of network function services meeting multiple conditions | |
| US20030061078A1 (en) | Method for providing information to manage queue and method for reserving service | |
| US20030037093A1 (en) | Load balancing system and method in a multiprocessor system | |
| US20080184254A1 (en) | Systems, methods and apparatus for load balancing across computer nodes of heathcare imaging devices | |
| US9223896B2 (en) | Screen generation method, and screen generation apparatus | |
| JP2004362449A (ja) | サービス提供装置及びサービスコーディネータ装置及びサービス提供方法及びサービスコーディネート方法及びプログラム及びプログラムを記録したコンピュータ読み取り可能な記録媒体 | |
| CN112514429A (zh) | 分析辅助的ue注册以支持网络切片内和网络切片间的负载平衡的设备和方法 | |
| JP2009244945A (ja) | 負荷分散プログラム、負荷分散方法、負荷分散装置およびそれを含むシステム | |
| US7904561B2 (en) | Brokering mobile web services | |
| EP2633405A1 (en) | Application specific resource management | |
| CN106713028A (zh) | 业务降级方法、装置和分布式任务调度系统 | |
| JP4405548B2 (ja) | クライアント・サーバシステムでコンテンツを配信する方法、および装置、プログラム | |
| JP2508589B2 (ja) | サ―バ運用方式 | |
| US20080163233A1 (en) | Method and apparatus for service load consolidation, and computer product | |
| CN109428926B (zh) | 一种调度任务节点的方法和装置 | |
| JPH0991215A (ja) | 広告表示機能付き文書閲覧システム及び同システムに適用される広告文書表示方法 | |
| CN101567875A (zh) | 一种在实现缓存策略控制的方法、系统及装置 | |
| US20060041647A1 (en) | System and method for profiling messages | |
| EP4013087A1 (en) | System and method for 5g mobile network management | |
| US20210298031A1 (en) | Control apparatus for presenting communication requirement, control method, and computer-readable storage medium | |
| US20220365826A1 (en) | Allocation of heterogeneous computational resource | |
| US20060031413A1 (en) | Computer systems and methods for providing failure protection | |
| US20030126244A1 (en) | Apparatus for scheduled service of network requests and a method therefor |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20041026 |
|
| A621 | Written request for application examination |
Effective date: 20060207 Free format text: JAPANESE INTERMEDIATE CODE: A621 |
|
| A977 | Report on retrieval |
Effective date: 20070927 Free format text: JAPANESE INTERMEDIATE CODE: A971007 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20071002 |
|
| A762 | Written abandonment of application |
Effective date: 20071024 Free format text: JAPANESE INTERMEDIATE CODE: A762 |