(57)【特許請求の範囲】
【請求項１】
サービス要求を処理するための少なくとも１つのサービス単位５５を備え、各サービス単位５５が、着信サービス要求を受け取って待ち行列化する待ち行列５７と、サービス要求を実行する複数のサーバ６０〜６８とを有するトランザクション・システム内のサーバ６０〜６８の数を動的に制御する方法であって、
各サービス単位５５内の現在のサービス要求の数と、当該各サービス単位５５に割り振られている現在のサーバ６０〜６８の数とを監視する第１のステップ２４０と、
各サービス単位５５内の現在のサービス要求の数を定義可能なしきい値で割ることにより、当該各サービス単位５５ごとにサーバ６０〜６８の最適数を決定する第２のステップ２６０と、
各サービス単位５５内の現在のサービス要求の数がしきい値以下である場合には、最小数のサーバ６０〜６８を永続サーバ６０〜６８として当該各サービス単位５５に割り振る第３のステップ２５０と、
各サービス単位５５内の現在のサービス要求の数がしきい値を上回る場合には、最適数のサーバ６０〜６８を一時サーバとして、定義可能な期間または待ち行列５７内の少なくとも１つのサービス要求がそれぞれの一時サーバによって処理可能である間のみ、当該各サービス単位５５に割り振る第４のステップ２６０とを含む、方法。
【請求項２】
サーバ６０〜６８の数が、各サービス単位５５内のサーバの定義可能な最大数を超えないことを特徴とする、請求項１に記載の方法。
【発明の詳細な説明】
【０００１】
【産業上の利用分野】
本発明は、メッセージ主導トランザクション環境における作業負荷の動的平衡化に関する。
【０００２】
【従来の技術】
メッセージ主導トランザクション環境では、ユーザ・インタフェースまたはその他のアプリケーション・プロセスとの通信が、待ち行列に入れられたメッセージに基づいて行われる。メッセージとは、あるクライアント・プロセスからサーバ・プロセスにまたはその逆に送信されるサービス要求または応答（たとえば、資金移動要求、照会要求）であると見なすことができる。
【０００３】
図１は、典型的なクライアント／サーバ概念を示している。サーバ１０は、ネットワーク１５内に設置され、少なくとも１台のクライアント２０にサービスを提供する。このようなサービスとしては、たとえば、顧客に関する情報の照会が考えられる。ネットワーク１５は、複数のサーバ１０と複数のクライアント２０とを含むことができ、それにより、各種サービスがクライアントによって要求され、サーバによって提供される。クライアントはサーバからのサービスを要求でき、そのサーバはクライアントとしてさらにサービスを要求できるので、「クライアント」と「サーバ」という用語は置き換えることができる。また、サーバまたはクライアントは、どのようなタイプのプロセス、コンピュータ・プログラムなどでもよいことに留意されたい。サーバ１０は、クライアント２０からサービス要求を受け取るために要求待ち行列２５を含んでいる。サーバ１０は、この要求待ち行列２５からの要求を処理し、それぞれのクライアント２０に適切な応答を送信し、この応答はまずクライアント２０の応答待ち行列３０に入る。最終的にクライアント２０はこの応答待ち行列３０から応答を受け取る。並列処理または直列処理により、クライアントとサーバとの間の複数の対話を同時に処理できることは明らかである。また、それぞれのサーバまたはクライアントが複数の待ち行列を含むことができることも明らかである。
【０００４】
基本的に、クライアント／サーバのシナリオでは、要求の処理のために以下の２通りの構成のいずれかが必要になる。第１の構成では、サーバ１０が事前始動され、いずれかのクライアントからのサービス要求メッセージが要求待ち行列２５に届くのを待つ。要求が要求待ち行列２５に届くと、サーバ１０は、その要求を処理し、応答を送り返し、次の要求を待つ。
【０００５】
着信要求の並列処理を達成するため、１台のサーバ１０の複数の処理ユニットを事前始動させ、サーバ１０の同一要求待ち行列２５のサービス要求を処理するためにそのユニットを待機させることもできる。このようにすると、特に、複数のサーバが入出力処理（たとえば、データベースへのアクセス）を実行したり、初期サービス要求に対する応答として他のサーバへの２次メッセージの流れを開始したりするときに、サーバ１０上でのパフォーマンスおよび負荷が改善される。
【０００６】
クライアント／サーバのシナリオの第２の構成では、サービス要求メッセージが要求待ち行列２５に入ったときに、サーバ１０だけが（たとえば、開始プロセスによって自動的に）始動される。最終的にその要求が処理されると、サーバ１０が終了し、次の要求を処理するために別の処理ユニットが始動される。
【０００７】
パフォーマンスと資源の使用状況を考慮して、適切な機構を選択する必要がある。しかし、どちらの構成でも、システムが動的挙動をするため、条件の厳しい管理方式または複雑な手作業による対話が必要になる。また、１営業日中でもシステムの作業負荷（たとえば、１時間当たりのメッセージ数）が変化する（たとえば、ある顧客がテープで多数のサービス要求を提供する場合もあれば、処理する要求がまったくない場合もある）ので、いくつかの問題が発生する可能性がある。
【０００８】
考えられる問題の１つは、作業負荷が低いために事前始動したサーバ１０の処理ユニットが遊んでしまう点である。記憶装置、ディスク空間、またはディスパッチ・リストなどのシステム資源が占有されるので、他のシステム・ユーザのパフォーマンスに影響する場合がある。
【０００９】
考えられるもう１つの問題は、事前始動したサーバ１０の処理ユニットの数が少なすぎて、満足できる応答時間内に待ち行列２５の多数の要求メッセージを処理できない点である。サーバ１０が入出力処理が完了するまで待ってから次の要求が処理されるので、このシナリオでは中央演算処理装置（ＣＰＵ）が十分活用されない可能性がある。サーバ１０が使用した処理ユニットが１台だけの場合には、すべての着信要求が完全に順次処理される。
【００１０】
考えられるもう１つの問題は、要求メッセージの到着後に追加サーバを始動すると、プロセスの始動と停止のためにシステム・オーバヘッドが高くなる点である。
【００１１】
【発明が解決しようとする課題】
したがって、本発明の目的は、システム資源のパフォーマンスおよび使用効率が高く、システム・オーバヘッドが低い、トランザクション・システムを提供することにある。
【００１２】
【課題を解決するための手段】
本発明の目的は、サービス要求を処理するための少なくとも１つのサービス単位５５を備えたトランザクション・システム内のサーバ６０〜６８の数を動的に制御する方法において、各サービス単位５５が、着信サービス要求を受け取って待ち行列化する待ち行列５７と、サービス要求を実行する複数のサーバ６０〜６８とを有し、前記方法が、現在のサービス要求の数と、サービス単位５５のそれぞれに割り振られている現在のサーバ６０〜６８の数とを監視する第１のステップ２４０と、現在のサービス要求の数と、現在のサーバ６０〜６８の数とに応じて、各サービス単位５５ごとにサーバ６０〜６８の最適数を決定する第２のステップ２６０と、各サービス単位５５ごとに最適数のサーバ６０〜６８を割り振る第３のステップ２６０とを含み、各サービス単位５５に割り振られたサーバ６０〜６８が、永続サーバと一時サーバとを含み、一時サーバのそれぞれが、定義可能な期間または待ち行列５７内の少なくとも１つのサービス要求がそれぞれの一時サーバによって処理可能である間のみ、サービス単位５５に割り振られることを特徴とする方法によって解決される。
【００１３】
一例として、添付図面に関して本発明について説明する。
【００１４】
【実施例】
図２は、本発明によるメッセージ主導トランザクション・システムの実施例を示している。このシステムは少なくとも１つのサービス・ポイント５０を含み、さらにこのサービス・ポイントは少なくとも１つのサービス単位５５を含んでいる。明確にするため、本発明の原理を説明するために図２には１つのサービス単位５５を備えたサービス・ポイントを１つだけ示す。サービス単位５５は、サービス・ポイント５０に接続されたクライアント２０のいずれかからサービス要求を受け取るサービス単位待ち行列５７を含んでいる。このサービス単位待ち行列５７は複数のサーバ６０〜６８とリンクされ、それにより、サーバ６０〜６８はサービス単位待ち行列５７に待ち行列化されているサービス要求を実行する。サーバ６０〜６８のそれぞれは、要求されたサービスを実行するためにさらに複数のサービス・ルーチン７０〜７４とリンクされており、それにより、サービス・ルーチン７０〜７４のそれぞれが要求されたサービスのモジュラ・ステップを実行する。サーバ６０〜６８のそれぞれは、他のサーバまたは資源管理プログラムにもサービス要求を出すことができることに留意されたい。
【００１５】
図２では、サーバ６０〜６８の処理の例をサーバ６０についてのみ示すが、この例は他のどのサーバについても同様である。サーバ６０はサービス単位待ち行列５７からサービス要求の１つを受け取る。サービス要求は、サービスの処理に必要な情報（たとえば、要求されたサービスのタイプ、サービスに必要なデータ）を提供する。次に、サーバは対応するサービス・ルーチン（この例では、サービス・ルーチン７０および７２）をリンクし、サービス・ルーチン７０および７２を使用することにより要求されたサービスを実行する。
【００１６】
サービス・ポイント５０は、待ち行列化モニタ８５に接続された開始待ち行列８０をさらに含んでいる。サービス単位待ち行列５７に最初のサービス要求が入ると、待ち行列化システムによってトリガ・メッセージ８７が生成され、それが開始待ち行列８０に送られる。待ち行列化モニタ８５は、サービス単位待ち行列５７の名前と始動するサーバの名前とが入っているトリガ・メッセージ８７を受け取る。次に、待ち行列化モニタ８５は、サービス・ポイント５０の各サービス単位５５についてサーバ６０〜６８を監視し制御する。待ち行列化モニタ８５が使用する監視および制御の方法については、後述する。
【００１７】
図３は、複数のサービス・ポイント５０、１００、および１０２を有するメッセージ主導トランザクション・システムの実施例を示しているが、これらのサービス・ポイントはさらに複数のサービス単位５５、１０４、および１２０を含んでいる。明確にするため、図２と同じ特徴を示す参照番号はそのまま使用する。たとえば、サービス・ポイント５０は、複数のサービス単位５５、１０４、および１２０を示している。サービス単位１０４は、サーバ１１０および１１２にリンクされたサービス単位待ち行列１０５を含んでいる。また、サービス単位１２０は、サーバ１３０〜１３６にリンクされたサービス単位待ち行列１２５を含んでいる。サーバ６０〜６４、１１０〜１１２、および１３０〜１３６のそれぞれは複数のサービス・ルーチン１５０〜１７４にリンク可能であり（図３にはそれらのリンクの一部のみ示す）、それぞれのサービス要求内の情報に応じたサービスを提供する。また、それぞれのサーバは、初期サービス要求を処理するために２次要求になりうるサービス要求を出すこともできる。
【００１８】
サービス単位５５、１０４、および１２０のそれぞれは、サービス単位待ち行列５７、１０５、または１２５がそれぞれの最初のサービス要求を受け取ったときに、それぞれのトリガ・メッセージを開始待ち行列８０に送信する。待ち行列化モニタ８５は、そのトリガ・メッセージを受け取り、各サービス単位５５、１０４、および１２０ごとに複数のセットアップ・プロファイル９０〜９４からの対応するセットアップ・プロファイルをリンクする。各セットアップ・プロファイル９０〜９４は複数のサービス単位についてリンク可能で、特定のサービス単位１つについてのみカスタマイズされるのではないことは明らかである。次に、待ち行列化モニタ８５は、各サービス単位５５、１０４、および１２０ごとにサーバの数を監視し制御する。
【００１９】
前述のサービス・ポイント５０と同様に、サービス・ポイント１００および１０２を構築することができ、それにより、各サービス・ポイントにおけるサービス単位の数と実行回数が変化する可能性がある。
【００２０】
図２および図３の待ち行列化モニタ８５は、サーバ１０の各種プロセスに対して動的作業負荷平衡化と定義済みの構造（図７で説明する）を提供する。動的作業負荷平衡化については以下に説明するが、その際、明確にするために図２の参照番号を使用することが好ましい。
【００２１】
待ち行列化モニタ８５は、指定のセットアップ・プロファイル９０〜９４から、監視対象の各サービス単位５５に関する制御情報を受け取る。この制御情報は、以下の顧客定義のサービス単位パラメータを含む。
１．監視対象のサービス単位待ち行列５７（複数も可）の名前。これにより、１つの待ち行列化モニタ８５によって１つのサービス・ポイント５０内の複数のサービス単位待ち行列を監視することができる。
２．着信サービス要求の処理のためのそれぞれのサービス単位５５の関連サーバ（複数も可）６０〜６８の名前。
３．各サービス単位５５のサーバの最小数。この最小数は、処理すべきメッセージがない場合でも永続的に動作する必要があるサービス単位５５内のサーバ・プロセスの数に相当する。この最小数の値は、各サービス単位待ち行列５７ごとに指定することができる。
４．各サービス単位５５のサーバの最大数。この最大数は、待ち行列に多くの業務要求が入っている高作業負荷状況で動作する必要があるサービス単位５５内のサーバ・プロセスの数に相当する。この最大数の値は、各サービス単位待ち行列５７ごとに指定することができる。
５．それぞれのサービス単位待ち行列内の業務要求を迅速に処理するためにリンクする必要があるサーバの数を定義するしきい値。リンクする必要があるサーバの数は、待ち行列内の業務要求の数（待ち行列内項目数）をしきい値で割った数によって決まる。サーバの最大数と、リンクする必要があるサーバの数とを組み合わせると、最終的に、各サービス単位５５によってリンクされるサーバ６０〜６８の数が決まる。
６．待ち行列化モニタ８５がサービス単位（複数も可）５５の現在の状態の監視を繰り返す時間間隔を定義するモニタ時間間隔。
７．サービス単位５５をただちに始動するか、トリガ・メッセージ８７の到着後に始動するかを決定する自動始動指示。
【００２２】
作業負荷状況の変化に対応するため、上記のパラメータはいずれもユーザが動的に変更することができる。
【００２３】
待ち行列化モニタ８５は永続的に動作し、実行時環境が開始されたときに自動的に始動する。待ち行列化モニタ８５は、サービス・ポイント５０内で待ち行列化モニタ８５が監視する各サービス単位５５、１０４、および１２０ごとに最適数のサーバを使用する。図４は、監視する各サービス単位ごとに最適数のサーバを使用するために待ち行列化モニタ８５または他の待ち行列化モニタが提供する動的作業負荷平衡化方法を示している。
【００２４】
ステップ２００で、待ち行列化モニタ８５は、トリガ・メッセージ（複数も可）８７が開始待ち行列８０に到着するのを待ち、次にステップ２１０で、リンクされたセットアップ・プロファイルの定義通り、各サービス単位５５、１０４、および１２０ごとに指定の最小数のサーバを始動する。ただし、２２０の自動始動指示に応じて、待ち行列化モニタの始動後ただちに待ち行列化モニタ８５によってステップ２１０の最小数のサーバを始動することもできる。
【００２５】
待ち行列化モニタ８５は、ステップ２１０に続く次のステップ２３０で、リンクするサーバのパラメータとして、処理する必要があるサービス単位待ち行列の名前と、状態指示とを提供する。この状態指示は、それぞれのサーバが永続的に使用されるのか、一時的に使用されるだけなのかを決定するものである。永続サーバはシステムが終了するまでそれぞれのサービス単位にリンクされるが、一時実行マネージャは、サービス単位待ち行列からの１つのサービス要求を処理する場合のみ、それぞれのサービス単位にリンクされる。このサービス要求の処理が完了したときに処理すべきサービス要求が他になければ、この一時サーバへのリンクが終了するか、サーバ自体が終了する。
【００２６】
最小数のサーバとしてリンクされているサーバは永続サーバとして示されるので、サービス単位当たりの永続サーバの数は、通常の条件下でサービス単位パラメータによって示されるサーバの指定の最小数によって決まる。しかし、サービス単位当たりの一時サーバの数は、指定のサービス単位パラメータと、それぞれのサービス単位待ち行列５７内のサービス要求の数とによって決まる。
【００２７】
指定のモニタ時間間隔が経過すると、待ち行列化モニタ８５は、次のステップ２４０でサービス単位５５（１０４および１２０）のそれぞれから以下の情報を問い合わせる。
１．それぞれのサービス単位待ち行列内の現在のサービス要求の数。これは待ち行列内項目数ともいう。
２．このサービス単位待ち行列にリンクされている現在のサーバの数。
【００２８】
それぞれのサービス単位５５内の現在のサービス要求（ＳＲ）の数が指定のしきい値以下であるときは、待ち行列化モニタ８５は追加のサーバを始動する必要がない。保全性を維持するため、待ち行列化モニタ８５は、ステップ２５０で最小数のサーバが動作していることを検査する。動作しているサーバが指定の最小数のサーバより少ない場合は、待ち行列化モニタ８５は、このサーバの最小数に達するために必要な数のサーバのみ再始動する。
【００２９】
サービス単位待ち行列５７内のサービス要求の数が指定のしきい値を上回る場合は、待ち行列化モニタ８５は、以下の式に基づいてステップ２６０で追加のサーバをリンクまたは始動する。
【００３０】
【数１】
リンク／始動するサーバの数＝待ち行列内項目数／しきい値
【００３１】
リンク／始動するサーバの数の計算値にすでに動作しているサーバの数を加えた合計がサーバ数の指定の最大値を上回る場合は、待ち行列化モニタ８５は、このサーバの最大数に達するために必要な数のサーバのみリンクまたは始動する。
【００３２】
ステップ２５０または２６０のいずれかに続いて、もう一度ステップ２３０に戻り、そこでステップ２５０で再始動されたサーバが永続サーバとして示され、ステップ２６０で始動された追加のサーバが一時サーバとして示される。
【００３３】
実行時環境が終了すると、待ち行列化モニタは、監視したすべてのサービス単位待ち行列を使用禁止にし、サーバに対してこの事象に関する通知を行う。
【００３４】
図５および図６は、動的作業負荷平衡化の例を示している。図５の例では、待ち行列化モニタ８５は、指定のセットアップ・プロファイル９０〜９４から以下の顧客定義のサービス単位パラメータを受け取る。
１．監視するサービス単位待ち行列５７
３．サーバの最小数は３である。
４．サーバの最大数は１０である。
５．しきい値は２である。
【００３５】
次に、待ち行列化モニタ８５は、サービス単位待ち行列５７の現在の待ち行列内項目数を要求し、この例では「待ち行列内項目数は６である」というメッセージを受け取る。さらに待ち行列化モニタ８５は、サービス単位５５で使用されている現在のサーバの数を要求し、「３台の永続サーバと２台の一時サーバが使用され、現在のサーバの数は５である」というメッセージを受け取る。
【００３６】
ここで待ち行列化モニタ８５は、リンクするサーバの数を決定する。待ち行列内項目数（＝６）をしきい値（＝２）で割ると、リンクする必要がある一時サーバの数が３になる。ただし、待ち行列化モニタ８５は、３台の一時サーバをリンクする前に、使用するサーバの総数がサーバの最大数（＝１０）を超えていないかどうか検査する。すでに使用している５台のサーバに、使用する必要がある３台のサーバを加えると、合計８台のサーバになるはずだが、１０台のサーバという所与の最大数を超えない。これは、サービス単位待ち行列５７からのサービス要求を迅速に処理するために待ち行列化モニタが最終的に３台のサーバを一時サーバとしてリンクすることを意味する。
【００３７】
図６の例では、待ち行列化モニタ８５は、指定のセットアップ・プロファイル９０〜９４から図５の例と同じサービス単位パラメータを受け取るが、以下の点のみ異なっている。
３．サーバの最小数は４である。
５．しきい値は３である。
【００３８】
次に、待ち行列化モニタ８５は、サービス単位待ち行列５７の現在の待ち行列内項目数とサービス単位５５で使用されている現在のサーバの数とをもう一度要求し、「待ち行列内項目数は９であり、４台の永続サーバと４台の一時サーバが使用され、現在のサーバの数は８である」というメッセージを受け取る。
【００３９】
待ち行列内項目数（＝９）をしきい値（＝３）で割ると、リンクする必要がある一時サーバの数が３になる。ただし、すでに使用されている８台のサーバに追加して使用する必要があるサーバ３台を加えると合計１１台のサーバになり、１０台のサーバという所与の最大数を１台上回るので、使用するサーバの総数がサーバの最大数（＝１０）を超えるはずである。これは、待ち行列化モニタがサービス単位待ち行列５７に対して２台の追加サーバしか一時サーバとしてリンクできないことを意味する。
【００４０】
図７は、サーバによるサービス要求の処理を示すものである。ステップ３００で、サーバ６０〜６８は、ステップ２３０で待ち行列化モニタ８５によって提供されたパラメータを受け取る。このパラメータは、処理する必要があるサービス単位待ち行列の名前と、それぞれのサーバが永続的に使用されるのか、一時的にのみ使用されるのかを示す状態指示とを含んでいる。
【００４１】
次のステップ３１０で、サーバ６０〜６８は、それぞれのサービス単位待ち行列５７によってサービス単位が割り振られるように所定の待ち時間待機する。サーバの待ち時間の値は、状態指示によって決まる。一時サーバの待ち時間は定義可能な期間であるが、永続サーバの待ち時間は不定として設定される。すなわち、一時サーバは、ゼロにもなりうる定義可能な期間だけ待機するが、永続サーバは、サービス単位待ち行列からサービス要求が最終的に割り振られるまで待機することになる。
【００４２】
指定の待ち時間内にサービス単位待ち行列５７にサービス要求が入っている場合、そのサービス要求はステップ３２０でそれぞれのサーバによって読み取られ、処理される。サービス要求が最終的に処理されると、サーバは、処理したサービス要求の送信側（クライアント）に応答信号を出し、ステップ３１０に戻る。
【００４３】
指定の待ち時間内にサービス単位待ち行列５７にサービス要求が一切入っていない場合（たとえば、待ち行列が空であるか、使用禁止になっているとき）は、一時サーバが終了し、そのサービス単位へのリンクはステップ３３０で解除される。
【００４４】
前述の待ち行列化モニタとサーバ構造により、メッセージ・システム内で最良の資源使用効率と応答時間を達成することが可能になる。この平衡化方法は完全に動的なものなので、システムの動作中にすべての構成データを変更することができる。
【００４５】
リンクするサーバの数を決定するために提供される方法は前述の実施例に限定されないことに留意されたい。サービス単位内の現在のサーバの数を現在の作業負荷に動的に適応させるという要件を満たすものであれば、他の方法も適用可能である。
【００４６】
オブジェクト指向アプリケーションでは、本明細書で使用する「サーバ」という用語が「サーバ・インスタンス」（”Ｏｂｊｅｃｔ−ｏｒｉｅｎｔｅｄ  Ｓｏｆｔｗａｒｅ  Ｃｏｎｓｔｒｕｃｔｉｏｎ”、Ｂｅｒｔｒａｎｄ  Ｍｅｙｅｒ著、１９８８年、Ｐｒｅｎｔｉｃｅ  Ｈａｌｌ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｌｔｄ（英国）発行、ＩＳＢＮ  ０−１３−６２９０４９−３、７１ページ、５．２．１章を参照）という用語で置換え可能であることに留意されたい。
【００４９】
【発明の効果】
本願発明によれば、サービス要求を処理するための少なくとも１つのサービス単位（５５）を含むトランザクション・システム内のサーバ（６０〜６８）の数を動的に制御することができることとなった。
【図面の簡単な説明】
【図１】典型的なクライアント／サーバの概念を示す図である。
【図２】本発明によるメッセージ主導トランザクション・システムの実施例を示す図である。
【図３】複数のサービス・ポイントを有するメッセージ主導トランザクション・システムの実施例を示す図である。
【図４】待ち行列化モニタによって提供される動的作業負荷平衡化方法を示す図である。
【図５】動的作業負荷平衡化の例を示す図である。
【図６】動的作業負荷平衡化の例を示す図である。
【図７】サーバによるサービス要求の処理を示す図である。
【符号の説明】
５０  サービス・ポイント
５５  サービス単位
５７  サービス単位待ち行列
６０  サーバ
６２  サーバ
６４  サーバ
６６  サーバ
６８  サーバ
７０  サービス・ルーチン
７２  サービス・ルーチン
７４  サービス・ルーチン
８０  開始待ち行列
８５  待ち行列化モニタ
８７  トリガ・メッセージ
９０  セットアップ・プロファイル
９２  セットアップ・プロファイル
９４  セットアップ・プロファイル
【図１】
0003610120.tif 000002
【図２】
0003610120.tif 000003
【図３】
0003610120.tif 000004
【図４】
0003610120.tif 000005
【図５】
0003610120.tif 000006
【図６】
0003610120.tif 000007
【図７】
0003610120.tif 000008