JP2020531956A - トランザクション処理サーバ、トランザクション処理サーバへのクライアント接続を管理する方法、およびコンピュータ・プログラム - Google Patents

Abstract

【課題】トランザクション処理サーバと、クライアント−サーバ接続を介してサーバに対して要求を送出する、関連するクライアントとを提供する。【解決手段】サーバは、要求を処理し、要求しているクライアントに対して応答を発行するように動作可能な、トランザクション処理領域を有する。サーバは、最近のクライアント要求を処理するのにかかった処理時間履歴の記録を維持する。サーバは、入ってくるクライアント要求を監視し、それらの要求から、各要求に含まれる、要求がその中で処理されることをクライアントが予想する最大時間である、目標応答時間を抽出するように動作可能な、接続マネージャを有する。サーバは、目標応答時間内で処理される可能性が高いか否かの決定に基づいて、入ってくる各クライアント要求を許可または拒否する。要求が拒否された場合、サーバは、拒否メッセージを作成元のクライアントに送信する。【選択図】図７

Description

本開示は、高負荷を管理するため、サーバに対するクライアント接続を管理する、方法および装置に関する。

顧客情報管理システム（ＣＩＣＳ（Ｒ））トランザクション・サーバ（ＴＳ） ｆｏｒ ＩＢＭ（Ｒ） ｚ／ＯＳ（Ｒ）など、サーバのトランザクション処理領域は、複数のネットワーク接続を通じてそのクライアントから作業を受信することができる。これらの接続は、短寿命または長寿命のどちらかであることができる。例えば、ウェブ・ブラウザからの接続は、一般に長寿命であり、潜在的に、非常に多数の複数の同時接続要求に対応していることがある。したがって、長寿命の接続からの要求は、本開示の主題である、効率的な動作を担保するための管理を必要とすることになる。要求および応答メッセージは、接続を通じてシリアル化され、一般的に、ヘッダ部分およびペイロード部分を有するパケット形式となる。メッセージは、クライアントがサーバに渡す（またはその逆の）要求データを含むこととなり、それがメッセージのペイロードまたはボディを形成することとなる。メッセージはまた、メタデータを含むこととなり、それがメッセージの１つまたは複数のヘッダを形成することとなり、その場合、メタデータの役割は、要求データをどのように扱うかに関する命令をメッセージの受信者に提供することである。接続は、サーバ・コンポーネントが始動したときに確立されてもよく、サーバ・コンポーネントがアクティブの状態で追加または除去されてもよい。サーバ・コンポーネントは、それが稼動するマシンの中央処理装置（ＣＰＵ）が利用することができる利用量、およびそれがアクセスできるメモリの量などの要因によって制限される、有限の容量を有することとなる。システム管理者は、リソース不足による失速のリスクを冒すことなく、対応できる作業量が最大限になるようにサーバ・コンポーネントを構成し、高負荷になることによってサーバ・コンポーネント全体が故障するのを回避する対策を講じる。この文脈では、失速とは、リソース競合がアプリケーション・タスクの処理に影響を与えたときにサーバで起こる状態である。サーバ・コンポーネントが同時に稼動させることができるタスクの最大数に対して、制限が設定される。一般的に、これは、サーバ・コンポーネントに対する個々の接続を通じて対応される数よりも多いが、１つの接続が非常にビジーで他の接続が軽負荷である場合があるので、全ての接続を合わせた数よりも少ない。

場合によっては、一連の接続を通じて到達する作業が多すぎると、サーバ・コンポーネントが高負荷になることがあり、即ちその全容量に達することがある。サーバ・コンポーネントが既に全容量に達しているときに受信される過度な作業要求は、即座に処理することができないので、サーバ・コンポーネント内でキューに入れられて、処理できるときまで待機する。しかしながら、キュー自体およびその管理は、既に過負荷になっているサーバ・コンポーネントの更なるシステム・リソースを消費する。現在、サーバ・コンポーネントがそのときの作業負荷に耐えられないことを検出したとき、これらのネットワークの問題を自動的に解決するメカニズムは存在しない。

１つのネットワーク・ノードが、その相手方のネットワーク・ノードがそのときの作業負荷を処理できないとき、相手方に要求を送り過ぎないようにする、制御が知られている。例えば、固定数の要求スロットのみを有するように、要求送出側（本書では、クライアントと呼ばれる）を構成することが知られている。例えば、「送出セッション数」を構成するパラメータを使用して、クライアントが接続を通じて経路指定することができる同時要求の最大数を設定することができる。その数は、接続が最初に確立されたときに設定され、接続の持続期間の間存続する。別の既知の例は、サービス提供者（本書では、サーバと呼ばれる）が、受信しているがまだ処理していない要求に対するキューを維持しており、キューがいっぱいになると、サーバが受信するそれ以上の更なる要求は拒否するというものである。これらの方策は、単一の接続のみを有する対になったシステムの場合、全体容量を前もって計算することができ、それに合わせて接続の容量を設定できるので、良好に働く。しかしながら、大規模システムでは、複数のエントリー・ポイントを有する場合が多いので、それらの要求を有効に管理する形で接続を構成するのは単純な作業ではない。

例えば、ＩＢＭ ＣＩＣＳ（Ｒ） ＴＳ ｆｏｒ ｚ／ＯＳのプロダクション・サーバ・コンポーネントは、要求メッセージがそれを通じて到達することがある複数の接続を有する可能性がある。任意の単一の接続を通じた要求のトラフィック量は、時間に伴って大幅に変動する可能性がある。更に、異なる接続間での要求のトラフィック量も、時間に伴って大幅に変動する可能性がある。サーバがそのクライアント全ての最大容量に合致するように構成することは、大量の冗長性に結び付き、また需要がピークに近くない限り、使用されないリソースが無駄になるので、実用的ではない。その代わりに、各接続は、サーバの全体容量におけるその正当な配分よりも多い容量に対応するように構成されるので、サーバがあまりビジーではない間、ビジーなクライアントはより多量の要求をサーバへと経路指定することができる。結果的に、要求をサーバがサービスすることができるまで要求がキューに入れられる期間、または要求がサーバによって拒否される期間が延長されることがある。

この問題に対処するため、クライアントは、クライアントがその全容量まで特定の接続を使用しているかを知るための、追加のソフトウェアを使用することが知られている。ＩＢＭ ｚ／ＯＳワーク・ロード・マネージャ（ＷＬＭ）およびＩＢＭ Ｔｉｖｏｌｉ（Ｒ） Ｎｅｔｖｉｅｗ（Ｒ）は、かかる作業負荷バランシング・ソフトウェアの例である。作業負荷のバランシングは、ＴＣＰ／ＩＰベースの作業負荷要求（接続）を同様のサーバ・アプリケーション間で分配して、最適なリソース利用を達成し、スループットを最大限にし、応答時間を最小限に抑え、サーバ・アプリケーションまたはシステムが過負荷になるのを回避する技術である。負荷バランシングを含む複数のサーバ・アプリケーションを（単一のサーバ・アプリケーションの代わりに）使用することによって、冗長性を通して信頼性を増大させることができる。負荷バランシングのサービスは、通常、専用のソフトウェア・プログラムまたはハードウェア・デバイスによって提供される。作業負荷マネージャは、分配の推奨案を負荷バランシング・サービス（即ち、負荷バランサー・アプライアンス）に提供する。

このタイプの作業負荷管理環境では、同じデータ・ソースにアクセスするサーバ・アプリケーションは、一般的に同じ作業負荷に含まれる。これによって、これらのアプリケーション全てが利用可能であること、また作業負荷の代わりに追加の接続を扱えることを検証するのに、エージェントを監視することが可能になる。また、作業負荷マネージャが、作業負荷におけるアプリケーションの統合ビューを有することができるようになり、それにより、地理的に離れた場所（即ち、システムの異なるクラスタ）の間で作業負荷を簡単に切り替えることができるようになる。特に、作業負荷マネージャは、作業負荷を構成しているサーバ・アプリケーションに対する全ての接続を、代わりの場所に同時に切り替えるべきであることを、負荷バランサー・アプリケーションに信号で伝えることができる。これによって、アプリケーションによるデータ・ソースへのアクセスは、いずれの時点でも１つの場所のみから行われることが確定される。作業負荷バランシング・ソフトウェアは、接続を使用しているシステムと一緒に稼動する。しかしながら、かかる追加のソフトウェアは、それが監視する接続とは別個に構成されなければならないという不利な点がある。

高いサーバ負荷を扱う別の既知の方策は、サーバが、健康データと呼ばれるサーバの負荷状態に関連するクライアント・データを送出することである。サーバの負荷状態データを使用して、クライアントは、サーバが既にビジーである場合、要求をサーバに送出するかまたはその送出を遅らせるか否かを決定することができる。

トランザクション処理サーバ、トランザクション処理サーバへのクライアント接続を管理する方法、およびコンピュータ・プログラムを提供すること。

本開示では、本発明者らは、１つの接続または複数の同時接続のどちらであるかにかかわらず、所与の期間で多数の要求を受信するサーバから生じるサーバのトランザクション処理領域における持続的な高負荷を自動的に管理する、コーピング・メカニズムであって、並列で提供されることもあってもなくてもよい任意の作業負荷バランシング基準とは独立して動作する、コーピング・メカニズムを提案する。

本開示の一態様によれば、クライアント接続を管理することができる、トランザクション処理サーバが提供され、サーバは、サーバに対する個々のクライアント−サーバ接続を確立し、維持し、終了するように動作可能であり、各接続がクライアント要求をサーバに送信することができる、クライアント−サーバ・コネクタと、クライアント要求を処理し、応答を発行するように動作可能なサーバのトランザクション処理領域と、クライアント要求がどのくらい迅速に処理されているかの性能記録を維持するように動作可能なサーバ性能マネージャと、入ってくるクライアント要求を監視し、目標応答時間内でクライアント要求を処理するようにトランザクション処理サーバに対して示す目標応答時間を、クライアント要求から抽出し、また目標応答時間に基づくとともに性能記録を参照して、入ってくる各クライアント要求を許可または拒否するように動作可能な、接続マネージャとを備える。

提案される方策によって、サーバが、クライアント指定の緊急性要件に基づいて、各要求を異なるように処理することが可能になる。サーバはまた、ビジーすぎて対応できないリソース管理要求を消費することによって失速を回避する。この方策は、状況を管理するのに第三者のリソースを使用することも伴わず、それよりもむしろ、クライアント指定の目標応答時間に作用するサーバのみに基づく。この方策はまた、要求がサーバによって前もって拒否されることになるため、目標応答時間内に応答していない要求に関して、クライアントがサーバに「取消し要求」を送出する必要がない可能性が高いので、サーバにおけるトランザクション作業の回復の複雑さを減少させることができる。従来、かかる「取消し要求」は、特にサーバが要求の処理を開始しており、パージ・プロセスによって作業のバックアウトを行う必要がある場合、サーバの手間がかかる。

接続マネージャは、任意に、拒否された要求の作成元であるクライアントに対して、要求拒否メッセージを送信するように更に動作可能である。このように、要求が処理されないことがクライアントに直接通知されるので、例えば、クライアントは、利用量が少ないと思われ、要求をより迅速に実行できる可能性が高い代替サーバに、要求を自由に再送出することができる。要求拒否メッセージは、性能記録を参照して得られている、要求を処理するための予測応答時間を含んでもよい。この追加情報は次に、クライアントが拒否を受信したときに、どのように反応するのが最善であるかを決定するのに使用することができる。例えば、クライアントは、同じ要求を同じサーバに再送出する選択肢を有するが、このとき、例えば、拒否に含まれる予測処理時間を参照して設定した、それに等しい、または２０％超過、５０％超過、もしくは二倍など、何らかのより大きい値に等しい、目標応答時間を指定する。

接続マネージャは、有利には、要求を処理するのにかかるはずの時間よりもはるかに短い時間内で、要求拒否メッセージを送信するように動作可能である。例えば、接続マネージャは、いくつかの実施形態では、目標応答時間の何分の１か（例えば、１／５、１／１０、１／２０、１／５０、および１／１００）以内で、要求拒否メッセージを送信するように動作可能である。別の例は、性能記録から推論した予想応答時間の何分の１か以内で要求拒否メッセージを送信するものであろう。一般に、設計の目的は、いかなる拒否も、要求を処理するのにかかる時間よりもはるかに短い時間スケールで行われることを担保して、要求が拒否されたという応答をクライアントが即時に、またはほぼ即時に得ることである。これによってクライアントは、例えば要求を異なるサーバに送出することによって、反応することができる。

多くの実施形態に当てはまるように、接続上の通信がパケット・ベースであると仮定すると、要求拒否メッセージは、便利には、例えば「サーバ・ビジー」応答として、サーバからクライアントへのデータ・パケットのメタデータに挿入される。メタデータは、拒否を伝達する目的で生成された特定のパケットに挿入することができ、または他の情報を伝達するパケットもしくはパケット群に、例えば別の処理済み要求の結果を返すパケットに追加することができる。目標応答時間も、便利には、クライアント要求のメタデータに含まれる。

要求拒否／許可テストは、全ての要求に対して全般的に、または要求がトランザクション・タイプを有する場合、トランザクション・タイプに特異的に実施することができ、性能記録は、クライアント要求に対する処理時間履歴を含む。いくつかの実施形態では、複数のトランザクション・タイプそれぞれに対して処理時間履歴があることになる。例えば、５つの異なるトランザクション・タイプがある場合、５つの異なる最近の応答時間値を性能記録で維持することができる。

処理時間履歴は、関連する最近のクライアント要求から集めた平均時間であってもよい。平均は、より最近処理されたクライアント要求がより大きい重み付けを有して、リーセンシーによって重み付けされてもよい。あるいは、平均は、重み付けしていない、即ち各要素が等しい重み付けを有する、単純な平均であることができる。更に、平均は、中間値、最頻値、または中央値であり得ることが理解される。

特定の実施形態では、入ってくるクライアント要求は、評価されるクライアント要求に関連する目標応答時間および応答時間履歴の比較に基づいて、許可または拒否される。性能記録は、例えば、最後の２００秒以内の時間、または１２：２８ ＣＥＴ（中央ヨーロッパ標準時）以後の時間の少なくとも１つによって定義される、ウィンドウ内で処理されたクライアント要求に基づいてもよい。あるいは、ウィンドウは、多数のクライアント要求によって定義することができ、例えば、最後の１００個の処理済み要求、または処理された特定のタイプの最後の５つの要求に基づくことができる。

サーバはキューを更に含んでもよく、サーバが要求を許可する容量を現在有していないとき、サーバに対するクライアント要求はキューに入れられる。いくつかの実施形態では、接続マネージャはキューに対するゲート・キーパーとして作用するので、要求は、スクリーニングされ許可された後にのみキューに入れられる。つまり、接続マネージャは、入ってくるクライアント要求が許可されることを条件としてキューに追加され、拒否された要求はキューへのアクセスを拒絶されるように、キューへのアクセスをゲートで制御するように動作可能である。このように、拒否された要求がキュー・リソースを消費することが回避される。他の実施形態では、接続マネージャがキューに対してそのスクリーニングを実施するので、全ての要求がキューに入るが、接続マネージャがチェックした後にのみキューを出るようにクリアされ、トランザクション処理が許可される。つまり、入ってくるクライアント要求の接続マネージャによる監視は、キューを見ることによって行われ、拒否されたクライアント要求はキューから消去される。この方策はやはり、接続マネージャの過負荷の可能性を回避しながら、または接続マネージャにそれ自体の別個のキューを提供しなければならない一方、迅速な拒否をクライアントに送出することを可能にする。

本開示の別の態様によれば、トランザクション処理サーバへのクライアント接続を管理する方法が提供され、方法は、サーバによって実施され、クライアントからのクライアント要求をクライアント−サーバ接続で受信することと、クライアント要求から、クライアントがどのくらい迅速に要求が処理されることを望むかを示す目標応答時間を抽出することと、目標応答時間に基づいて、またサーバによって維持されている、クライアント要求がどのくらい迅速に処理されているかの性能記録を参照して、クライアント要求を許可または拒否することとを含む。

方法は、要求が拒否された場合、拒否メッセージをクライアントに送信することを更に含んでもよい。いくつかの実施形態では、クライアント要求はタイプ分類を含み、要求を許可または拒否するのに使用されるインジケータは、そのタイプに特異的である。

本開示の別の態様によれば、コンピュータ・プログラム製品が提供され、コンピュータ・プログラム製品は、プログラム命令が具現化されたコンピュータ可読記憶媒体を備え、コンピュータ可読記憶媒体は一過性信号自体ではなく、プログラム命令は、プロセッサに方法を実施させるようにプロセッサによって実行可能であり、方法は、クライアントからのクライアント要求をクライアント−サーバ接続で受信することと、クライアント要求から、目標応答時間内でクライアント要求を処理するようにトランザクション処理サーバに対して示す、目標応答時間を抽出することと、要求される目標応答時間とトランザクション処理サーバにおける要求されるタイプのトランザクションに関する完了時間の性能記録との比較に基づいて、クライアント要求を許可または拒否することと、クライアント要求を拒否するように示す比較に基づいて、トランザクション処理サーバが、クライアント要求を完了する予測時間量を拒否メッセージに含むこととを含む。

以下、本発明について、図面に示される例示の実施形態を参照して、単なる例として更に記載する。

例示的実施形態の例示の態様が実現されてもよい、分散データ処理環境を示す例示のブロック図である。 例示的実施形態の例示の態様が実現されてもよい、データ処理システムを示す例示のブロック図である。 単一のサーバおよび複数のクライアントがネットワーク接続を介して接続される、本発明の実施形態に関するシステム環境を示す概略図である。 図３のネットワーク接続を介して送出されるメッセージのメッセージ構造を示す図である。 図３のサーバをより詳細に示す図である。 図３のクライアントをより詳細に示す図である。 図５のサーバによって実施される接続管理を示すフローチャートである。 図６のクライアントによって実施される接続管理を示すフローチャートである。 本開示の一実施形態によるクラウド・コンピューティング環境を示す図である。 本開示の一実施形態による抽象モデルレイヤを示す図である。

以下の詳細な説明では、限定ではなく説明の目的で、本開示の更なる理解を提供するために具体的な詳細について説明する。本開示は、これらの特定の詳細から逸脱する他の実施形態において実践されてもよいことが、当業者には明白となるであろう。

本開示の実施形態によるクライアントは、任意の適切なコンピューティング・デバイス、例えば、携帯電話（スマートフォン）、ファブレット、タブレット、ラップトップ・コンピュータ、ゲーム機、パーソナル・コンピュータ、スマート・テレビ、またはメディア・プレーヤーであってもよい。コンピューティング・デバイスは、１つまたは複数の電気通信規格によって定義されるようなユーザ機器であってもよい。コンピューティング・デバイスは、携帯型、例えば手持ち式コンピューティング・デバイス、または固定型であってもよい。

図１は、例示的実施形態の例示の態様が実現されてもよい、分散データ処理システム１００の例示のブロック図である。分散データ処理システム１００は、例示的実施形態の態様が実現されてもよい、コンピュータのネットワークを含んでもよい。分散データ処理システム１００は、分散データ処理システム１００内で互いに接続された、様々なデバイスおよびコンピュータの間に通信リンクを提供するのに使用される媒体である、少なくとも１つのネットワーク１０２を含む。ネットワーク１０２は、ワイヤ、ワイヤレス通信リンク、または光ファイバー・ケーブルなどの接続を含んでもよい。ネットワーク１０２は、インターネットなどの外部ネットワーク、またはイーサネット（Ｒ）ネットワークもしくは仮想私設ネットワーク（ＶＰＮ）などの内部ネットワークであってもよい。

図示される例では、サーバ１０４およびサーバ１０６は、記憶装置ユニット１０８とともにネットワーク１０２に接続される。それに加えて、クライアント１１０、１１２、および１１４もネットワーク１０２に接続される。これらのクライアント１１０、１１２、および１１４は、例えば、パーソナル・コンピュータ、ネットワーク・コンピュータなどであってもよい。図示される例では、サーバ１０４は、ブート・ファイル、オペレーティング・システム画像、およびアプリケーションなどのデータを、クライアント１１０、１１２、および１１４に提供する。クライアント１１０、１１２、および１１４は、図示される例では、サーバ１０４に対するクライアントである。分散データ処理システム１００は、追加のサーバ、クライアント、および図示されない他のデバイスを含んでもよい。

サーバ１０４、１０６はそれぞれ、１つもしくは複数のプロセッサおよび１つもしくは複数のメモリを備えるコンピューティング・デバイス、ならびに潜在的に、バス、記憶デバイス、通信インターフェースなどを含む、当該技術で一般に知られている他の任意のコンピューティング・デバイス要素を含むか、またはそれらに対するアクセスを有する。サーバは、クライアント−サーバ通信チャネルを形成するのに用いられてもよいものを含む、他のコンピューティング・デバイスからの通信を受信する入力ポートと、クライアント−サーバ通信チャネルを形成するのに用いられてもよいものを含む、他のコンピューティング・デバイスに通信を送信する出力ポートとを有する。

分散データ処理システム１００は、一例では、ネットワーク１０２が、互いに通信するプロトコルの伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）一式を使用するネットワークおよびゲートウェイの世界規模の総体を表す、インターネットであってもよい。インターネットの中心には、データおよびメッセージを経路指定する数千の商用、政府、教育、および他のコンピュータ・システムから成る、主要ノードまたはホスト・コンピュータ間の高速データ通信ラインのバックボーンがある。分散データ処理システム１００はまた、例えば、イントラネット、ローカル・エリア・ネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）など、多数の異なるタイプのネットワークを含むように実現されてもよい。上述したように、図１は、開示される主題の異なる実施形態に対するアーキテクチャ上の制限ではなく実施例として意図され、したがって、図１に示される特定の要素は、本発明の例示的実施形態が実現されてもよい環境に関する制限と見なすべきではない。

図示されるように、サーバ１０４、１０６、クライアント１１０、１１２、１１４、および記憶装置１０８または任意のネットワーク作業負荷マネージャ（図示なし）などの他のネットワーク・リソースを含む、様々な情報処理システムを、コンピュータ・ネットワーク１０２を使用して互いにネットワーク化することができる。様々な情報処理システムを相互接続するのに使用することができる、コンピュータ・ネットワーク１０２のタイプとしては、ローカル・エリア・ネットワーク（ＬＡＮ）、ワイヤレス・ローカル・エリア・ネットワーク（ＷＬＡＮ）、インターネット、公衆交換電話網（ＰＳＴＮ）、他のワイヤレス・ネットワーク、および情報処理システムを相互接続するのに使用することができる他の任意のネットワーク・トポロジーが挙げられる。情報処理システムの多くは、ハード・ドライブまたは不揮発性メモリあるいはその両方など、不揮発性データ・ストアを含む。不揮発性データ・ストアは、様々な情報処理システムの外部にあるコンポーネントであることができ、または情報処理システムの１つの内部にあることができる。

図２は、例示的実施形態が実現されてもよい、データ処理システムのブロック図である。データ処理システム２００は、例示的実施形態の場合に、プロセスを実現するコンピュータ使用可能プログラム・コードまたは命令が位置してもよい、図１のサーバ１０４またはクライアント１１０など、コンピュータの一例である。この実例では、データ処理システム２００は、プロセッサ・ユニット２０４、メモリ２０６、永続記憶装置２０８、通信ユニット２１０、入出力（Ｉ／Ｏ）ユニット２１２、およびディスプレイ２１４の間の通信を提供する、通信ファブリック２０２を含む。

プロセッサ・ユニット２０４は、メモリ２０６にロードされてもよい、ソフトウェアに対する命令を実行するのに役立つ。プロセッサ・ユニット２０４は、特定の実現例に応じて、１つもしくは複数のプロセッサのセットであってもよく、またはマルチプロセッサ・コアであってもよい。更に、プロセッサ・ユニット２０４は、補助プロセッサが単一のチップ上にあって、主要プロセッサが存在する、１つまたは複数のヘテロジニアス・プロセッサ・システムを使用して実現されてもよい。別の実例として、プロセッサ・ユニット２０４は、同じタイプの複数のプロセッサを含む対称型マルチプロセッサ（ＳＭＰ）システムであってもよい。

メモリ２０６および永続記憶装置２０８は記憶デバイスの例である。記憶デバイスは、一時的または永続的あるいはその両方のいずれかで情報を記憶することができる、任意のハードウェア部品である。メモリ２０６は、これらの例では、例えば、ランダム・アクセス・メモリ、または他の任意の適切な揮発性もしくは不揮発性記憶デバイスであってもよい。永続記憶装置２０８は、特定の実現例に応じて様々な形態をとってもよい。例えば、永続記憶装置２０８は、１つもしくは複数のコンポーネントまたはデバイスを含んでもよい。例えば、永続記憶装置２０８は、ハード・ドライブ、フラッシュ・メモリ、書換え可能光学ディスク、書換え可能磁気テープ、ベルヌーイ・カートリッジ、またはそれらの何らかの組み合わせであってもよい。永続記憶装置２０８によって使用される媒体はまた、取外し可能であってもよい。例えば、リムーバブル・ハード・ドライブが永続記憶装置２０８に使用されてもよい。

通信ユニット２１０は、これらの例では、他のデータ処理システムまたはデバイスとの通信に対応する。これらの例では、通信ユニット２１０はネットワーク・インターフェース・カードである。通信ユニット２１０は、物理的およびワイヤレスどちらかまたは両方の通信リンクを使用することによって通信を提供してもよい。

入出力ユニット２１２は、データ処理システム２００に接続されてもよい他のデバイスとの間での、データの入力および出力を可能にする。例えば、入出力ユニット２１２は、キーボードおよびマウスを通してユーザ入力するための接続を提供してもよい。更に、入出力ユニット２１２は出力をプリンタに送出してもよい。ディスプレイ２１４は、情報をユーザに対して表示するメカニズムを提供する。

オペレーティング・システムおよびアプリケーションまたはプログラムに対する命令は、永続記憶装置２０８上にある。これらの命令は、プロセッサ・ユニット２０４による実行のためメモリ２０６にロードされてもよい。異なる実施形態のプロセスは、メモリ２０６などのメモリに入れられてもよいコンピュータ実装命令を使用して、プロセッサ・ユニット２０４によって実施されてもよい。これらの命令は、プロセッサ・ユニット２０４のプロセッサによって読み出され実行されてもよい、プログラム・コード、コンピュータ使用可能プログラム・コード、またはコンピュータ可読プログラム・コードと呼ばれる。異なる実施形態のプログラム・コードは、メモリ２０６もしくは永続記憶装置２０８など、異なる物理的または有形コンピュータ可読媒体上で具現化されてもよい。

プログラム・コード２１６は、選択的に取外し可能であって、プロセッサ・ユニット２０４によって実行するためにデータ処理システム２００にロードされるかまたは転送されてもよい、コンピュータ可読媒体２１８上に機能的形態で存在する。プログラム・コード２１６およびコンピュータ可読媒体２１８は、これらの例ではコンピュータ・プログラム製品２２０を形成する。一例では、コンピュータ可読媒体２１８は、例えば、ドライブか、または永続記憶装置２０８の一部であるハード・ドライブなど、記憶デバイス上に転送される永続記憶装置２０８の一部である他のデバイスに、挿入されるかもしくは入れられる光学または磁気ディスクなど、有形形態であってもよい。有形形態で、コンピュータ可読媒体２１８はまた、ハード・ドライブ、サムドライブ、またはデータ処理システム２００に接続されるフラッシュ・メモリなど、永続記憶装置の形態をとってもよい。コンピュータ可読媒体２１８の有形形態は、コンピュータ記録可能記憶媒体とも呼ばれる。いくつかの例では、コンピュータ記録可能媒体２１８は取外し可能でなくてもよい。

あるいは、プログラム・コード２１６は、通信ユニット２１０への通信リンクを通して、または入出力ユニット２１２への接続を通して、あるいはその両方で、コンピュータ可読媒体２１８からデータ処理システム２００に転送されてもよい。通信リンクまたは接続あるいはその両方は、実例では、物理的またはワイヤレスであってもよい。コンピュータ可読媒体はまた、通信リンク、またはプログラム・コードを含むワイヤレス送信など、非有形媒体の形態をとってもよい。データ処理システム２００に関して示される異なるコンポーネントは、異なる実施形態が実現されてもよいやり方に対してアーキテクチャ上の制限をもたらすものではない。異なる例示的実施形態は、データ処理システム２００に関して例示したものに加えてまたはその代わりにコンポーネントを含む、データ処理システムにおいて実現されてもよい。図２に示される他のコンポーネントは、図示される実例とは異なる可能性がある。一例として、データ処理システム２００の記憶デバイスは、データを記憶してもよい任意のハードウェア装置である。メモリ２０６、永続記憶装置２０８、およびコンピュータ可読媒体２１８は、有形形態の記憶デバイスの例である。

別の例では、バス・システムは、通信ファブリック２０２を実現するのに使用されてもよく、システム・バスもしくは入出力バスなど、１つまたは複数のバスで構成されてもよい。当然ながら、バス・システムは、バス・システムに取り付けられた異なるコンポーネントまたはデバイスの間でデータの転送を提供する、任意の適切なタイプのアーキテクチャを使用して実現されてもよい。それに加えて、通信ユニットは、モデムもしくはネットワーク・アダプタなど、データを送受信するのに使用される１つまたは複数のデバイスを含んでもよい。更に、メモリは、例えば、メモリ２０６、または、通信ファブリック２０２に存在してもよいインターフェースおよびメモリコントローラ・ハブで見出されるような、キャッシュであってもよい。

本発明の動作を実施するコンピュータ・プログラム・コードは、Ｊａｖａ（ＴＭ）、Ｃ＋＋、Ｃ＃、Ｏｂｊｅｃｔｉｖｅ−Ｃなどのオブジェクト指向プログラミング言語、および従来の手続き型プログラミング言語を含む、１つまたは複数のプログラミング言語の任意の組み合わせで書かれてもよい。プログラム・コードは、完全にユーザのコンピュータ上で、部分的にユーザのコンピュータ上で、独立型ソフトウェア・パッケージとして、部分的にユーザのコンピュータ上および部分的にリモート・コンピュータ上で、または完全にリモート・コンピュータもしくはサーバ上で実行してもよい。後者のシナリオでは、リモート・コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）もしくは広域ネットワーク（ＷＡＮ）を含む任意のタイプのネットワークを通して、ユーザのコンピュータに接続されてもよく、または（例えば、インターネット・サービス・プロバイダを使用してインターネットを通して）外部のコンピュータに対して接続が作られてもよい。

当業者であれば、図１および図２のハードウェアは実現例に応じて異なることがあることを認識するであろう。フラッシュ・メモリ、等価の不揮発性メモリ、もしくは光学ディスクドライブなど、他の内部ハードウェアまたは周辺デバイスが、図１および図２に示されるハードウェアに加えて、またはその代わりに使用されてもよい。また、例示的実施形態のプロセスは、上述したＳＭＰシステム以外の、マルチプロセッサ・データ処理システムに適用されてもよい。

図から分かるように、本明細書に記載される技術は、クライアントマシンが１つまたは複数のマシンセットで実行されるインターネットアクセス可能なウェブベースのポータルと通信する、図１に示されるものなどの標準的なクライアント−サーバの枠組み内で連動して働いてもよい。エンドユーザは、ポータルにアクセスし相互作用することができる、インターネット接続可能なデバイス（例えば、デスクトップ・コンピュータ、ノートブック・コンピュータ、インターネットに接続可能な移動デバイスなど）を操作する。一般的に、各クライアントまたはサーバマシンは、ハードウェアおよびソフトウェアを備える図２に示されるようなデータ処理システムであり、これらのエンティティは、インターネット、イントラネット、エクストラネット、私設ネットワーク、または他の任意の通信媒体もしくはリンクなどのネットワークを通じて、互いに通信する。データ処理システムは、一般的に、１つまたは複数のプロセッサと、オペレーティング・システムと、１つまたは複数のアプリケーションと、１つまたは複数のユーティリティとを含む。データ処理システム上のアプリケーションは、非限定的に、中でも特にＨＴＴＰ、ＳＯＡＰ、ＸＭＬ、ＷＳＤＬ、ＵＤＤＩ、およびＷＳＦＬに対するサポートを含む、ウェブ・サービスへのネイティブ・サポートを提供する。ＳＯＡＰ、ＷＳＤＬ、ＵＤＤＩ、およびＷＳＦＬに関する情報は、これらの規格の開発および維持に関与するワールド・ワイド・ウェブ・コンソーシアム（Ｗ３Ｃ）から入手可能であり、ＨＴＴＰおよびＸＭＬに関する更なる情報は、インターネット技術特別調査委員会（ＩＥＴＦ）から入手可能である。これらの規格とのなじみやすさが推定される。

様々な実施形態では、ネットワーク１０２は、インターネット、物理的私設ネットワーク、仮想私設ネットワーク（ＶＰＮ）、またはこれらの任意の組み合わせなどの公衆ネットワークであってもよい。特定の実施形態では、ネットワーク１０２は、ブルートゥースまたは超広帯域（ＵＷＢ）などの技術に基づいた、パーソナルエリアネットワーク（ＰＡＮ）を含むワイヤレス・ネットワークであってもよい。様々な実施形態では、ワイヤレス・ネットワークは、Ｗｉ−Ｆｉと呼ばれる場合が多い、ＩＥＥＥ ８０２．１１仕様の変形に基づいた、ワイヤレス・ローカル・エリア・ネットワーク（ＷＬＡＮ）を含んでもよい。特定の実施形態では、ワイヤレス・ネットワークは、汎欧州デジタル移動電話方式（ＧＰＲＳ）およびＧＳＭ進化型高速データレート（ＥＤＧＥ）など、第２．５世代（２．５Ｇ）ワイヤレス技術を含む業界規格に基づいた、ワイヤレス広域ネットワーク（ＷＷＡＮ）を含んでもよい。様々な実施形態では、ワイヤレス・ネットワークは、ユニバーサル移動体通信システム（ＵＭＴＳ）および広帯域符号分割多重アクセス（Ｗ−ＣＤＭＡ）および新無線（ＮＲ）を含む、第３、第４、または第５世代（３Ｇ、４Ｇ、５Ｇ）ワイヤレス技術に基づいて、ＷＷＡＮを含んでもよい。

他の実施形態は、エボリューションデータ最適化（ＥＶＤＯ）、ＩＥＥＥ ８０２．１６（ＷｉＭＡＸ）、ワイヤレス・ブロードバンド（ＷｉＢｒｏ）、高速ダウンリンク・パケット・アクセス（ＨＳＤＰＡ）、高速アップリンク・パケット・アクセス（ＨＳＵＰＡ）、および４Ｇまたは５Ｇワイヤレス技術を含む、他の３Ｇ技術の実現例を含んでもよい。

本開示の実施形態の文脈におけるサーバは、場合によっては、「古典的」メインフレームであるか、またはメインフレームでホストされてもよい。メインフレーム・コンピュータ・システムは、多種多様なデータ処理機能に広く使用されている。例えば、多くの企業財務会計システムがメインフレーム・コンピューティング・システム向けに開発され、それらのシステム上で動作する。パーソナル・コンピュータおよびパーソナル・コンピュータ・ネットワークの使用は近年増殖してきたが、レガシー・システムと呼ばれるメインフレーム・コンピュータ・システムは、将来的な多くのタイプのデータ処理に対して一般的なままであることが予想される。メインフレーム・コンピュータ・システムは、一般的に、メインフレーム・ホスト・コンピュータに接続された複数のユーザ端末を含む。様々なソフトウェア・アプリケーションは、ホスト・コンピュータに常駐するか、またはそれにアクセス可能であってもよい。クライアント端末または「クライアント」と呼ばれる場合があるユーザ端末は、ホスト通信システムを介して、メインフレーム・ホスト・コンピュータと通信する。ＩＢＭ ３２７０端末システムは、ホスト・コンピュータと通信するためのより広く使用されているシステムの１つである。一般的に、３２７０端末はそれ自体のデータ処理能力を有さない。その代わりに、３２７０端末は、ホスト上で稼動するアプリケーションによって生成される表示画面であってもよく、ユーザからホストに情報を戻して処理してもよい。ＩＢＭ ３２７０端末システムのユーザ・インターフェースは、３２７０端末上に表示する、ホスト・アプリケーションによって生成される複数の画面を備える。過去数年にわたり、多くの３２７０端末が、３２７０端末エミュレーション・ソフトウェアを介してメインフレーム・コンピュータ・システムと通信するように構成された、パーソナル・コンピュータ（ＰＣ）に取って代わられてきた。

多くのアプリケーションでは、３２７０端末、または他のデータ処理デバイス（例えば、ＰＣ）は、今ではインターネットを介してホスト・コンピュータにアクセスする。例えば、ＴＮ３２７０Ｅプロトコルで動作するシステムでは、３２７０端末は、ＴＮ３２７０Ｅクライアント端末とＴＮ３２７０Ｅサーバとの間のＴＣＰ／ＩＰ接続の組み合わせを介して、またＴＮ３２７０Ｅサーバとホスト・メインフレーム・コンピュータ上のシステム・ネットワーク・アーキテクチャ（ＳＮＡ）アプリケーション・ソフトウェアとの間のＳＮＡセッションを介して、ホスト・コンピュータ上のアプリケーション・ソフトウェアにアクセスしてもよい。

また、クライアント−サーバ技術をメインフレーム・コンピューティング環境内で統合することが知られている。コンポーネントが協働して働いてより大きいシステムを形成する、このタイプの代表的なマルチコンポーネント・システムは、ＩＢＭ（Ｒ）のハイパーテキスト転送プロトコル（ＨＴＴＰ）、およびコンピューティング・マシンのＩＢＭ ｚ１９６ファミリーなどのＩＢＭメインフレーム・コンピュータを使用して実現されてもよい、ウェブ・サービス処理環境である。この環境は、一般的に、ＩＢＭ ＣＩＣＳ（顧客情報制御システム）またはＩＢＭ情報管理システム（ＩＭＳ）あるいはその両方など、１つまたは複数のトランザクション処理製品、ＩＢＭ ＷｅｂＳｐｈｅｒｅ（Ｒ）ＭＱなどのメッセージ処理製品、およびＩＢＭ ＤＢ２（Ｒ）などのリレーショナル・データベースと連動して働く、ＩＢＭ ＷｅｂＳｐｈｅｒｅ（Ｒ）アプリケーション・サーバ（ＷＡＳ）ミドルウェア・プラットフォーム・ソフトウェア製品を含む。マルチコンポーネント環境の目的は、ＨＴＴＰもしくは他のウェブ・サービスを使用して、インターネット・ブラウザを介してクライアント・エンドユーザにアクセス可能な、高性能トランザクション処理コンピューティング・システムまたは環境を提供することである。この環境では、ＨＴＴＰまたはウェブ・サービスの要求を作成するクライアント・エンドユーザは、アプリケーション・サーバと直接通信する。一般的に、分散クライアント・エンドユーザからのトランザクション要求を満たすため、アプリケーション・サーバは、環境中の１つまたは複数の他のコンポーネントのサービスを呼び出す。これらのコンポーネントの１つまたは複数は、一般的に、「メインフレーム」オペレーティング・システム・プラットフォームと呼ばれる場合が多い、ＩＢＭ ｚ／ＯＳオペレーティング・システムなどのオペレーティング・システム上で実行される。

図３は、単一のサーバおよび複数のクライアントがネットワーク接続を介して接続される、本発明の実施形態に関するシステム環境の概略図である。サーバ１０は、例えば、ＣＩＣＳトランザクション・サーバ（ＴＳ）であってもよく、図１に示されるサーバのいずれかに対応してもよく、多数のクライアント２０も配置されるシステム領域内にある。システムは、ＴＣＰ／ＩＰなどのネットワーク・プロトコルを使用して、異なるノードが通信するのを可能にする。各クライアント２０は、ネットワーク・プロトコルを使用して、少なくともサーバ１０に対するネットワーク接続１５を確立することができる。ネットワーク接続は終了されるまで持続するので、長寿命であってもよい。クライアントのうち選択されたものは、サーバに対する現在のネットワーク接続を有して示されており、複数の同時のネットワーク接続が例示されていることが注目される。確立されたネットワーク接続はそれぞれ、一般的にはパケット形式で、サーバからクライアントへ、またクライアントからサーバへそれぞれ、メッセージ３０を送受信することによって管理される。クライアントからサーバへのメッセージは、サーバに対するタスクまたは要求を含んでもよく、サーバからクライアントへのメッセージは、かかるタスクまたは要求に関する応答を含んでもよい。

図４は、図３のネットワーク接続を介して送出されるメッセージのメッセージ構造を示している。各メッセージは、ヘッダ部分３２と、ペイロードまたはボディ部分３４とを備える。ヘッダは、メッセージ受信側の接続マネージャによって使用される制御情報を含み、ボディ３４は、クライアントがそこで行うことを要求しているサービスの詳細を含む。ヘッダ部分３２は、一連の複数のフィールド３２_１、３２_２、…、３２_ｎに分割されてもよく、それらはそれぞれ、受信するとペイロード部分３４を適切に処理するのに用いることができるメッセージに関連する異なるコマンドおよび制御情報を伝達する。ヘッダ・フィールドは単純にヘッダと呼ばれることがあるので、各メッセージは、１つまたは複数のヘッダとボディとのセットで構成されているものと説明できることが注目される。

図５は、図３のサーバ１０をより詳細に示している。動作原理について考察する例として、２つの現在のクライアント接続１５_１および１５_２が示されているが、１以上の任意の数が存在してもよく、事実上、数は通常２つ超過となる。クライアント−サーバ・コネクタ２７は、サーバ１０の入出力インターフェースとして作用し、特に、サーバ１０に対する個々のクライアント−サーバ接続１５_１および１５_２を確立し、維持し、終了するように動作可能である。パケット３０_１および３０_２は、接続１５_１および１５_２のそれぞれのクライアントから送出され、パケットは、要求またはタスクを含むサーバ１０に対するメッセージを含む。接続はそれぞれ、同時要求の上限が指定されてもよい。例えば、同時要求の上限は、接続１５_１に対しては１００、接続１５_２に対しては５０であることができ、サーバの同時要求の上限は１２０である。これは、組み合わされた同時接続セッションの限界１５０がサーバの限界１２０を上回るという意味で、一般的な構成である。

入ってくる要求は、要求またはタスクを処理するサーバ１０のトランザクション処理領域（ＴＰＲ）２２に入るキュー２５に入れられる。ＴＰＲ ２２が全容量未満で動作しているとき、要求は、キュー２５における明らかな待ち時間なしでＴＰＲ２２に直接入力されるか、またはキューを完全に迂回してもよい。他方で、ＴＰＲ ２２が全容量で動作しているとき、要求はキューに入れられる。処理済みの要求は、ＴＰＲからクライアント接続１５_１および１５_２へ流れる矢印線によって示されるように、組み合わされてパケットにされる返信情報をＴＰＲ ２２が発行することによって返信され、クライアント１５_１、１５_２などにおける要求の作成元であるクライアントに返送される。

サーバ１０は、接続マネージャ（ＣＭ）２４とサーバ性能モニタ（ＳＰＭ）２６とを更に備える。

ＳＰＭ ２６の役割は、クライアント要求がどのくらい迅速に処理されているかの性能記録を維持することである。これは、例えば、図５に示される、トランザクション識別子「トランザクションＩＤ」によって指定されるような、各トランザクション・タイプの平均応答時間を記憶することによって行われ、図中、ＳＰＭ ２６は、最近の平均応答時間値がそれぞれ４．５秒、５．０秒、４．５秒、５．５秒である、４つのトランザクションＩＤ ＴＲＡＮ１、…、４が示されるルックアップ・テーブルを含んで示されている。したがって、最近の応答時間は最近の処理時間の履歴記録である。平均は、より最近処理されたクライアント要求がより大きい重み付けを有して、リーセンシーによって重み付けされてもよい。あるいは、平均は、重み付けしていない、即ち各要素が等しい重み付けを有する、単純な平均であることができる。更に、平均は、中間値、最頻値、または中央値であり得ることが理解される。性能記録は、例えば、最後の２００秒以内の時間、または１２：２８ ＣＥＴ以後の時間の少なくとも１つによって定義される、ウィンドウ内で処理されたクライアント要求に基づいてもよい。あるいは、ウィンドウは、多数のクライアント要求によって定義することができ、例えば、最後の１００個の処理済み要求、または処理された特定のタイプの最後の５つの要求に基づくことができる。時間、要求数、および特定のタイプ内の要求数に対するウィンドウ値は、例えば、システム管理者によって構成することができる。

ＣＭ ２４の役割は入ってくるクライアント要求を監視することである。これは、クライアントが、要求がどのくらい迅速に処理されることを望むかを示す、要求に記憶された目標応答時間を抽出することによって行われる。ＣＭ ２４は次に、目標応答時間と、性能記録に記憶されているかまたは性能記録に記憶された情報から推論される予想応答時間との比較に基づいて、入ってくる各クライアント要求を許可または拒否する。要求が拒否されると、接続マネージャは、要求しているクライアントに対する要求拒否メッセージを生成するか、またはそれを生成させ、接続を通じてそのクライアントに対して送信させる。

多くの実施形態に当てはまるような、クライアント−サーバ接続におけるパケットベースの通信の場合、要求拒否メッセージは、便利には、クライアント−サーバ・コネクタ２７によって、例えば「サーバ・ビジー」応答として、サーバからクライアントへのデータ・パケットのメタデータに挿入される。メタデータは、拒否を伝達する目的で生成された特定のパケットに挿入することができ、または他の情報を伝達するパケットもしくはパケット群に、例えば別の処理済み要求の結果を返すパケットに追加することができる。

入ってくるクライアント要求が目標応答時間を含まない場合、即ち、クライアントが提案される方策にしたがって動作するように構成されていない場合、ＣＭ ２４は、デフォルトで要求を許可するように、またはデフォルトで要求を拒否するように構成されてもよい。デフォルトは何にもかかわらず適用されてもよく、またはデフォルトは、現在サーバがロードしている同時要求またはペンディングしている同時要求の数に基づいて、「許可」と「拒否」との間で適応的に変更されてもよい。

ＣＭ ２４はまた、クライアントに付された各接続から受信される要求の数、およびどのクライアントが要求の作成元であるかを監視するという独立した役割を有する。例えば、ある時点で、ＣＭ ２４は、第１の接続からの３８個のまだ返信していない要求、および第２の接続からの１７個のまだ返信していない要求があると知ることがある。ＣＭ ２４は、接続が確立され終了されるのを監視し、それによって現在アクティブである接続の記録を維持し、アクティブな接続それぞれに対して、サポートすることができる、またはサポートすることが許可された同時要求の最大数を維持する。ＣＭ ２４はまた、現在のセッション中における、または進行する時間窓に基づいた最近の過去における、各接続からの未処理要求の最大数の記録を保持してもよい。したがって、この最大数は、所与の接続に対するアクティビティの高水標を表すことになる。

ＳＰＭ ２６は、サーバ１０の、特にクライアント要求を扱うＴＰＲ ２２の予備容量を監視する。ＳＰＭ ２６は、サーバ１０の最大容量を知っており、現在どれだけの数の要求を扱っているかを監視し、それによってサーバのロード量を監視する。特に、ＳＰＭ ２６は、サーバ１０が全容量に近付いているとき、または全容量に達したときにそれを検出する。ＳＰＭ ２６は、どれだけの数の要求をサーバが扱っているかを直接監視することができ、またはキュー２５のフィル状態を監視することによって、全容量に達しているかを推論することができる。つまり、キュー２５が空またはほぼ空の場合、サーバが予備容量を有すると推論することができ、いくつかの要求がキューに入れられているか、または要求１つ当たりのキュー・ドウェル時間が閾値時間を上回っている場合、サーバが全容量またはそれに近い状態で動作していると推論することができる。ＳＰＭ ２６はまた、入ってくるパケット３０またはキュー２５で待機している要求における、各要求のメタデータを分析するように動作可能であり、それは、作成元のクライアント２０またはクライアント−サーバ接続１５の識別子として役立つ。

これは、所望の目標応答時間と予測応答時間との比較に基づいて要求を予備スクリーニングする、提案される方法とは完全に独立して動作している、過負荷を回避するクライアント要求管理アクティビティの一例である。したがって、目標応答時間と最近の平均応答時間との比較に基づいた提案される方法は、唯一の高負荷に対処できるメカニズムであり得るか、または別個に独立して並列で動作しているいくつかのコーピング・メカニズムの１つであり得る。

図６は、図３のクライアント２０のうち１つの一例をより詳細に示している。クライアント２０は、１つまたは複数のサーバに対するクライアント−サーバ接続を確立し、維持し、終了するように動作可能な、クライアント−サーバ・コネクタ３３を有し、各接続は、図示されるように、例えばパケット３０_１を使用して、クライアント要求を特定のサーバに送信することができる。クライアント２０はまた、どのくらい迅速に応答することが望ましいかをサーバに通知する、目標応答時間をクライアント要求に含めるように動作可能な、クライアント要求生成系２９を有する。これは、例えば、２．０秒、２．０秒、３．０秒、および６．０秒という時間値を有する４つのトランザクションＩＤ ＴＲＡＮ１、…、４のそれぞれに対する目標応答時間を記憶するルックアップ・テーブル３１を含む、図６に示されるようなトランザクションＩＤによって指定されるような、各トランザクション・タイプに対する目標応答時間を記憶することによって行われる。このように、目標応答時間は特定のクライアントそれぞれに特異的であり、即ちそのクライアントに対してローカルである。情報はルックアップ・テーブルに表されて示されており、これは１つの可能な現実世界の実現例であるが、他の実施形態では、同じ情報をアプリケーション論理に埋め込むことができることが注目される。一般に、応答時間目標情報は任意の適切な実現形態で組み込むことができる。

クライアント２０は、トランザクション処理サーバ１０に送出する各要求とともに、応答時間目標をメタデータとして供給することができる。次に、サーバ１０は、現在のシステム状態に基づいて、応答時間目標が満たされる可能性が低いとサーバが分析した場合、「サーバ・ビジー」を、より具体的にはエラーを返すことができる。トランザクション処理サーバ１０は、トランザクションＩＤによって分類されたトランザクション応答時間の最近の履歴を維持しているので、サーバが高負荷になった場合、応答時間が減少され、これが最近のトランザクションの性能記録に反映されることになる。応答時間目標は、トランザクション処理領域２２でトランザクションを行うため、要求を伴うメタデータとして付加される。

クライアント要求がトランザクション処理サーバ１０のＣＭ ２４コンポーネントに到達すると、応答時間目標およびトランザクションＩＤがメタデータから抽出され、要求のトランザクションＩＤに対する履歴データがアクセスされる。目標が達成可能であると見なされた場合、要求は許可される。他方で、達成可能ではないと見なされた場合、要求は、ＳＥＲＶＥＲＢＵＳＹ応答などの応答とともに即時に拒否される。任意に、トランザクションＩＤに対する予測応答時間は、ＳＥＲＶＥＲＢＵＳＹ応答とともにメタデータとして返すことができるので、クライアントは、拒否に対してどのように反応するのが最良かを決定する際に、この追加情報を考慮することができる。

図５および図６のルックアップ・テーブルに示される実例の値では、トランザクション処理領域２２は高負荷であり、その最近の応答時間平均は全て秒の倍数である。クライアントによって指定された応答時間目標に基づいて、サーバがこの時点で許可するであろうトランザクションＩＤはＴＲＡＮ４のみである。

「サーバ・ビジー」コードまたは他の拒否メッセージを受信した後、クライアントはいくつかの方式のうち任意の１つで反応してもよい。例えば、サーバからの拒否メッセージの一部としてクライアントに返送された場合のサーバからの予測応答時間を使用して、任意に以下の動作、
ａ．要求を別のサーバ・システムに再提出すること、ｂ．例えばサーバの予測応答時間に合致するかそれを上回る、より長い目標応答時間で同じサーバに要求を再提出すること、ｃ．要求を捨て、呼び出しているインターフェースにエラーを返すことのうちの、１つを実施することができる。

図７は、図５のサーバによって実施される接続管理のフローチャートである。

ステップＳ６１で、サーバがクライアントからの接続要求を許可するという点で、クライアントと協力してクライアント−サーバ接続が確立される。

ステップＳ６２で、サーバは、クライアント−サーバ接続上でクライアントから要求を受信する。

ステップＳ６３で、サーバは、クライアントがどのくらい迅速に要求が処理されることを望むかを示す目標応答時間を、クライアント要求から抽出する。

ステップＳ６４で、サーバは、要求をスクリーニングして、即ち分析して、クライアント要求においてクライアントが指定した目標応答時間に基づいて、許可すべきか拒否すべきかを決定する。これは、現在、即ち最近の過去にわたって、クライアント要求がどのくらい迅速に処理されているかを記録する、サーバによって記憶された性能記録を参照して行われる。上述したように、これはトランザクション・タイプに、即ちトランザクションＩＤに基づいて行われることが想到されるので、関連する要因は、その要求と同じタイプのクライアント要求がどのくらい迅速に現在処理されているかである。

拒否決定に続いて実行されるステップＳ６５ｒで、サーバは、拒否メッセージを構成してそれをクライアントに送信する。任意に、拒否メッセージは、その要求が許可されていた場合は処理にどのくらいの時間がかかる可能性があるかという、時間の指示を含んでもよい。例えば、目標応答時間が３．５秒だった場合、予測応答時間は拒否という結果になった場合よりも長くなり、例えば５．０秒であり、この後者の値が拒否メッセージに含まれる。続いて、更なるクライアント要求が、ステップＳ６５ｒからステップＳ６２に戻るフローの矢印によって示されるのと同じ方式で処理されてもよい。

許可決定に続いて実行されるステップＳ６５ａで、サーバは、サーバのトランザクション処理領域で処理するために要求をクリアする。続いて、更なるクライアント要求が、ステップＳ６５ａからステップＳ６２に戻るフローの矢印によって示されるのと同じ方式で処理されてもよい。

入ってくる要求がどのようにスクリーニングされ、次に許可または拒否されるかには、トランザクション・プロセッサが作用する前にクライアント要求がキューに入れられるサーバ・キューに関して、いくつかの構成上の決定を行うことが関与する。

１つの設計上の選択肢は、接続マネージャがキューに対するゲート・キーパーとして作用することであり、それによって要求は、スクリーニングされ許可された後にのみキューに入れられる。つまり、接続マネージャは、入ってくるクライアント要求が許可されることを条件としてキューに追加され、拒否された要求はキューへのアクセスを拒絶されるように、キューへのアクセスをゲートで制御するように動作可能である。このように、拒否された要求がキュー・リソースを消費することが回避される。

別の設計上の選択肢は、接続マネージャがキューに対してそのスクリーニングを実施することであり、それによって全ての要求がキューに入るが、接続マネージャがチェックした後にのみキューを出るようにクリアされ、トランザクション処理が許可される。つまり、入ってくるクライアント要求の接続マネージャによる監視は、キューを見ることによって行われ、拒否されたクライアント要求はキューから消去される。この方策はやはり、接続マネージャの過負荷の可能性を回避しながら、または接続マネージャにそれ自体の別個のキューを提供しなければならない一方、迅速な拒否をクライアントに送出することを可能にする。

図８は、図６のクライアントによって実施される接続管理のフローチャートである。

ステップＳ６６で、クライアントは、サーバと協力して、そのサーバに対するクライアント−サーバ接続を確立する。

ステップＳ６７で、クライアントは従来の要求を生成する。

ステップＳ６８で、クライアントは、どのくらい迅速に応答することが望ましいかをサーバに対して指定する、目標応答時間を要求に追加する。（ステップＳ６７およびＳ６８は統合して単一の動作にすることができる。）

ステップＳ６９で、要求は、クライアント−サーバ接続上でサーバに送信される。

ステップＳ７０で、クライアントは、クライアント−サーバ接続上でサーバの応答を受信する。

ステップＳ７１で、サーバの応答がＳＥＲＶＥＲＢＵＳＹメッセージであった場合、即ちクライアント要求を拒否するメッセージであった場合、フローは、ステップＳ７２でＳＥＲＶＥＲＢＵＳＹ応答を扱うように構成された処理論理へと方向付けられる。他の任意のタイプのサーバ応答では、フローは、ステップＳ７３で、通常の応答を、即ち要求に対する実体的な応答を扱うように構成された他方の処理論理へと方向付けられる。

提案される方法を実現するため、負荷バランシングを実施する作業負荷マネージャなど、他のネットワーク・リソースは関与しないことが注目される。それでもなお、提案される方法はかかる負荷バランシングと並列して実施できることが注目される。

本開示の実施形態は、クラウド・コンピューティングを使用して実現されてもよいことが、理解されるであろう。具体的には、サーバおよびネットワーク・リソースの１つまたは複数は、クラウドでホストされてもよい。

本開示はクラウド・コンピューティングに関する詳細な説明を含むが、本明細書に列挙する教示の実現は、クラウド・コンピューティング環境に限定されないことが、理解されるべきである。それよりもむしろ、本開示の実施形態は、現在知られているかまたは今後開発される、他の任意のタイプのコンピューティング環境と併用して実現することができる。

クラウド・コンピューティングは、最小限の管理作業またはサービス提供者との相互作用で迅速に供給しリリースすることができる、構成可能なコンピューティング・リソース（例えば、ネットワーク、ネットワーク帯域幅、サーバ、処理、メモリ、記憶装置、アプリケーション、仮想マシン、およびサービス）の共有プールに対する便利なオンデマンドのネットワーク・アクセスを可能にする、サービス送達のモデルである。このクラウド・モデルは、少なくとも５つの特性と、少なくとも３つのサービス・モデルと、少なくとも４つの展開モデルとを含んでもよい。

特性は次の通りである。
オンデマンド・セルフサービス：クラウドサービス利用者は、人間がサービス提供者と相互作用する必要なく自動的に、必要に応じて、サーバ時間およびネットワーク記憶などのコンピューティング能力を一方的に供給することができる。
ブロード・ネットワーク・アクセス：ネットワークを通じて能力が利用可能であり、ヘテロジニアス・シンまたはシック・クライアント・プラットフォーム（例えば、携帯電話、ラップトップ、およびＰＤＡなど）による使用を促進する、標準的メカニズムを通してアクセスされる。
リソース・プーリング：提供者のコンピューティング・リソースが、マルチテナント・モデルを使用する複数の利用者に役立つようにプールされ、異なる物理的および仮想リソースが需要にしたがって動的に割当ておよび再割当てされる。利用者は一般に、提供されるリソースの正確な位置に関する制御または知識を有さないが、より高い抽象度（例えば、国、州、またはデータセンター）で位置を指定することができてもよいという点で、位置の独立性という意味合いがある。
迅速な順応性：急速にスケール・アウトするため、能力を迅速に弾性的に、場合によっては自動的に供給し、また急速にスケール・インするため、迅速にリリースすることができる。利用者にとっては、供給に利用可能な能力は、無制限に見える場合が多く、いつでも任意の量で購入することができる。
測定されたサービス：クラウド・システムは、サービスのタイプ（例えば、記憶、処理、帯域幅、およびアクティブ・ユーザのアカウント）に適したあるレベルの抽象度で計測能力をレバレッジすることによって、リソース使用を自動的に制御し最適化する。リソース利用を監視し、制御し、報告して、利用されるサービスの提供者および利用者の両方に対して透明性を提供することができる。

サービス・モデルは次の通りである。
サービスとしてのソフトウェア（ＳａａＳ）：利用者に提供される能力は、クラウド・インフラストラクチャで稼動している提供者のアプリケーションを使用することである。アプリケーションは、ウェブ・ブラウザなどのシン・クライアント・インターフェース（例えば、ウェブベースの電子メール）を通して、様々なクライアント・デバイスからアクセス可能である。利用者は、限定されたユーザ指定のアプリケーション構成設定を場合によっては例外として、ネットワーク、サーバ、オペレーティング・システム、記憶装置、または更には個々のアプリケーション能力などを含む、基礎にあるクラウド・インフラストラクチャを管理または制御しない。
サービスとしてのプラットフォーム（ＰａａＳ）：利用者に提供される能力は、クラウド・インフラストラクチャ上に、提供者がサポートしているプログラミング言語およびツールを使用して作成された、利用者作成または獲得のアプリケーションを展開することである。利用者は、ネットワーク、サーバ、オペレーティング・システム、または記憶装置を含む、基礎にあるクラウド・インフラストラクチャを管理または制御しないが、展開されたアプリケーション、および場合によってはアプリケーション・ホスティング環境構成に対する制御は有する。
サービスとしてのインフラストラクチャ（ＩａａＳ）：利用者に提供される能力は、処理、記憶装置、ネットワーク、ならびに、オペレーティング・システムおよびアプリケーションを含むことができる任意のソフトウェアを利用者が展開し稼動させることができる、他の基本的なコンピューティング・リソースを供給することである。利用者は、基礎にあるクラウド・インフラストラクチャを管理または制御しないが、オペレーティング・システム、記憶装置、展開されたアプリケーションに対する制御を有し、また場合によっては、ネットワーキング・コンポーネント（例えば、ホスト・ファイアウォール）を選択する限定された制御を有する。

展開モデルは次の通りである。
プライベート・クラウド：クラウド・インフラストラクチャはある組織に対してのみ操作される。組織または第三者によって管理されてもよく、施設内または施設外に存在してもよい。
コミュニティ・クラウド：クラウド・インフラストラクチャは、複数の組織によって共有され、共有の関心事（例えば、ミッション、セキュリティ要件、ポリシー、およびコンプライアンス上の考慮事項）を有する特定のコミュニティをサポートする。組織または第三者によって管理されてもよく、施設内または施設外に存在してもよい。
パブリック・クラウド：クラウド・インフラストラクチャは、一般大衆または大きい業界グループに対して利用可能にされ、クラウドサービスを販売する組織によって所有される。
ハイブリッド・クラウド：クラウド・インフラストラクチャは、固有のエンティティを残しているが、データおよびアプリケーションの可搬性（例えば、クラウド間の負荷バランシングのためのクラウド・バースティング）を可能にする、標準化されたまたは専用の技術によって互いに結合された、２つ以上のクラウド（プライベート、コミュニティ、もしくはパブリック）を組成したものである。

クラウド・コンピューティング環境は、ステートレス性、低結合性、モジュール性、およびセマンティック相互運用性に注目したサービス指向性である。クラウド・コンピューティングの中心には、相互接続されたノードのネットワークを含むインフラストラクチャがある。

次に図９を参照して、例示的なクラウド・コンピューティング環境５０について説明する。図示されるように、クラウド・コンピューティング環境５０は、１つまたは複数のクラウド・コンピューティング・ノードを含み、それらを用いて、例えば、個人情報端末（ＰＤＡ）もしくは携帯電話５４Ａ、デスクトップ・コンピュータ５４Ｂ、ラップトップ・コンピュータ５４Ｃ、または自動車コンピュータ・システム５４Ｎ、あるいはそれら全てなど、クラウドサービス利用者によって使用されるローカル・コンピューティング・デバイスが通信してもよい。ノードは互いに通信してもよい。それらは、上述したようなプライベート、コミュニティ、パブリック、もしくはハイブリッド・クラウド、またはそれらの組み合わせなど、１つまたは複数のネットワークで、物理的または仮想的にグループ化（図示なし）されてもよい。これによって、クラウド・コンピューティング環境５０が、インフラストラクチャ、プラットフォーム、またはソフトウェア、あるいはそれら全てを、クラウドサービス利用者がローカル・コンピューティング・デバイスでリソースを維持する必要がないサービスとして提示することが可能になる。図９に示されるコンピューティング・デバイス５４Ａ〜Ｎのタイプは例示にすぎず、コンピューティング・ノードおよびクラウド・コンピューティング環境５０は、任意のタイプのネットワーク、またはネットワークアドレス可能な接続（例えば、ウェブ・ブラウザを使用）、あるいはその両方を通じて、任意のタイプのコンピュータ化デバイスと通信できることが理解される。

次に図１０を参照すると、クラウド・コンピューティング環境５０（図９）によって提供される一連の機能抽象化レイヤが示されている。図１０に示されるコンポーネント、レイヤ、および機能は、例示のみを意図するものであり、本開示の実施形態はそれに限定されないことが、前もって理解されるべきである。図示されるように、次のレイヤおよび対応する機能が提供される。

ハードウェアおよびソフトウェア・レイヤ６０は、ハードウェアおよびソフトウェア・コンポーネントを含む。ハードウェア・コンポーネントの例としては、メインフレーム６１、ＲＩＳＣ（冗長命令セットコンピュータ）アーキテクチャ・ベースのサーバ６２、サーバ６３、ブレード・サーバ６４、記憶デバイス６５、ならびにネットワークおよびネットワーキング・コンポーネント６６が挙げられる。いくつかの実施形態では、ソフトウェア・コンポーネントとしては、ネットワーク・アプリケーション・サーバ・ソフトウェア６７、およびデータベース・ソフトウェア６８が挙げられる。

仮想化レイヤ７０は、仮想サーバ７１、仮想記憶装置７２、仮想私設ネットワークを含む仮想ネットワーク７３、仮想アプリケーションおよびオペレーティング・システム７４、ならびに仮想クライアント７５といった、仮想エンティティの例を提供するのに用いてもよい、抽象化レイヤを提供する。

図１および図２に示されるサーバまたはサーバ要素のいずれかが、レイヤ６０および７０それぞれの物理的または仮想化コンポーネントに対応してもよいことが認識されるであろう。

一例では、管理レイヤ８０は後述する機能を提供してもよい。リソース供給８１は、コンピューティング・リソース、およびクラウド・コンピューティング環境内でタスクを実施するのに利用される他のリソースの、動的調達を提供する。計量および価格決定８２は、リソースがクラウド・コンピューティング環境内で利用されたときのコスト追跡、およびこれらのリソースの消費に対する請求書の作成または提出を提供する。一例では、これらのリソースはアプリケーション・ソフトウェア・ライセンスを含んでもよい。セキュリティは、クラウドサービス利用者およびタスクに対する識別情報検証、ならびにデータおよび他のリソースの保護を提供する。ユーザ・ポータル８３は、利用者およびシステム管理者のクラウド・コンピューティング環境へのアクセスを提供する。サービスレベル管理８４は、必要なサービスレベルが満たされるように、クラウド・コンピューティング・リソースの割当ておよび管理を提供する。サービスレベル合意（ＳＬＡ）計画および履行８５は、ＳＬＡにしたがって今後の必要性が予測されるクラウド・コンピューティング・リソースの予備配置および調達を提供する。

作業負荷レイヤ９０は、クラウド・コンピューティング環境が利用されてもよい機能性の例を提供する。このレイヤから提供されてもよい作業負荷および機能の例としては、マッピングおよびナビゲーション９１、ソフトウェア開発およびライフサイクル管理９２、仮想教室教育供給９３、データ分析処理９４、トランザクション処理９５、およびサーバ１０が挙げられる。

好ましい実施形態の論理的プロセス・ステップの全てまたは一部は、あるいは、方法の論理的プロセス・ステップを実施するように配置された論理要素を備える、論理装置または複数の論理装置において具現化されてもよいこと、ならびにかかる論理要素は、ハードウェア・コンポーネント、ファームウェア・コンポーネント、またはそれらの組み合わせを備えてもよいことが、当業者には明白となるであろう。

好ましい実施形態の論理コンポーネントの全てまたは一部は、あるいは、方法のステップを実施する論理要素を備える論理装置において具現化されてもよいこと、ならびにかかる論理要素は、例えばプログラマブル論理アレイまたは特定用途向け集積回路の論理ゲートなどのコンポーネントを備えてもよいことが、当業者には等しく明白となるであろう。かかる論理配置は更に、例えば、固定のもしくは送信可能なキャリア媒体を使用して記憶され送信されてもよい仮想ハードウェア記述子言語を使用して、かかるアレイまたは回路において、要素が論理構造を一時的または恒久的に確立できるようにして具現化されてもよい。

更なる代替実施形態では、本開示は、コンピュータ・インフラストラクチャ内へと展開されそこで実行されると、コンピューティング・デバイスに方法の全てのステップを実施させるように動作可能な、コンピュータ・プログラムを展開するステップを含む、サービスを展開するコンピュータ実装方法の形態で実現されてもよい。

好ましい実施形態の方法およびコンポーネントは、あるいは、並列ソフトウェアを実行する２つ以上のプロセッサを備えるパラレル・コンピューティング・システムにおいて、完全にまたは部分的に具現化されてもよいことが認識されるであろう。

本開示の更なる実施形態は、システムおよび方法に関して定義されるコンピュータ・プログラム製品である。コンピュータ・プログラム製品は、プロセッサに本開示の態様を実施させるコンピュータ可読プログラム命令を有する、コンピュータ可読記憶媒体を含んでもよい。

コンピュータ可読記憶媒体は、命令実行デバイスによって使用される命令を保持し記憶することができる、有形デバイスであることができる。

本開示は、システム、方法、またはコンピュータ・プログラム製品、あるいはそれら全てであってもよい。コンピュータ・プログラム製品は、プロセッサに本開示の態様を実施させるコンピュータ可読プログラム命令を有する、コンピュータ可読記憶媒体を含んでもよい。

コンピュータ可読記憶媒体は、命令実行デバイスによって使用される命令を保持し記憶することができる、有形デバイスであることができる。コンピュータ可読記憶媒体は、例えば、電子記憶デバイス、磁気記憶デバイス、光学記憶デバイス、電磁記憶デバイス、半導体記憶デバイス、またはそれらの任意の適切な組み合わせであってもよいが、それらに限定されない。コンピュータ可読記憶媒体のより具体的な例の非排他的リストとしては、携帯型コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）、消去可能プログラマブル読出し専用メモリ（ＥＰＲＯＭもしくはフラッシュ・メモリ）、静的ランダム・アクセス・メモリ（ＳＲＡＭ）、携帯型コンパクト・ディスク読出し専用メモリ（ＣＤ−ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ）、メモリ・スティック、フロッピー（Ｒ）ディスク、パンチカード、もしくは命令が記録された溝の隆起構造を有するものなどの、機械的に符号化されたデバイス、およびそれらの任意の適切な組み合わせが挙げられる。コンピュータ可読記憶媒体は、本明細書で使用するとき、電波もしくは他の自由に伝播する電磁波、導波路もしくは他の伝達媒体を通って伝播する電磁波（例えば、光ファイバー・ケーブルを通る光パルス）、またはワイヤを通って伝送される電気信号など、一過性信号自体としては解釈されない。

本明細書に記載するコンピュータ可読プログラム命令は、コンピュータ可読記憶媒体からそれぞれのコンピューティング／処理デバイスに、またはネットワーク、例えばインターネット、ローカル・エリア・ネットワーク、広域ネットワーク、またはワイヤレス・ネットワーク、あるいはそれら全てを介して、外部コンピュータまたは外部記憶デバイスにダウンロードすることができる。ネットワークは、銅の伝送ケーブル、光伝送ファイバー、ワイヤレス送信、ルーター、ファイアウォール、スイッチ、ゲートウェイ・コンピュータ、またはエッジサーバ、あるいはそれら全てを含んでもよい。各コンピューティング／処理デバイスのネットワーク・アダプタ・カードまたはネットワーク・インターフェースは、コンピュータ可読プログラム命令をネットワークから受信し、コンピュータ可読プログラム命令を転送して、それぞれのコンピューティング／処理デバイス内のコンピュータ可読記憶媒体に記憶する。

本開示の動作を実施するコンピュータ可読プログラム命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、マイクロコード、ファームウェア命令、状態設定データ、あるいはＳｍａｌｌｔａｌｋ（Ｒ）、Ｃ＋＋などのオブジェクト指向型言語、および「Ｃ」プログラミング言語または類似のプログラミング言語などの従来の手続き型プログラミング言語を含む、１つもしくは複数のプログラミング言語の任意の組み合わせで書かれる、ソース・コードまたはオブジェクト・コードであってもよい。コンピュータ可読プログラム命令は、完全にユーザのコンピュータ上で、部分的にユーザのコンピュータ上で、独立型ソフトウェア・パッケージとして、部分的にユーザのコンピュータ上および部分的にリモート・コンピュータ上で、または完全にリモート・コンピュータもしくはサーバ上で実行してもよい。後者のシナリオでは、リモート・コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）もしくは広域ネットワーク（ＷＡＮ）を含む任意のタイプのネットワークを通して、ユーザのコンピュータに接続されてもよく、または（例えば、インターネット・サービス・プロバイダを使用してインターネットを通して）外部のコンピュータに対して接続が作られてもよい。いくつかの実施形態では、例えば、プログラマブル論理回路構成、フィールドプログラマブル・ゲート・アレイ（ＦＰＧＡ）、またはプログラマブル論理アレイ（ＰＬＡ）などを含む、電子回路構成は、本開示の態様を実施するために、コンピュータ可読プログラム命令の状態情報を利用して電子回路構成を個人化することによって、コンピュータ可読プログラム命令を実行してもよい。

本開示の態様は、本開示の実施形態による方法、装置（システム）、およびコンピュータ・プログラム製品のフローチャート図またはブロック図あるいはその両方を参照して、本明細書に記載されている。フローチャート図もしくはブロック図またはその両方の各ブロック、あるいはフローチャート図もしくはブロック図またはその両方におけるブロックの組み合わせは、コンピュータ可読プログラム命令によって実現できることが理解されるであろう。

これらのコンピュータ可読プログラム命令は、コンピュータまたは他のプログラマブル・データ処理装置のプロセッサを介して実行する命令が、フローチャートまたはブロック図あるいはその両方の１つもしくは複数のブロックで指定される機能／動作を実現する手段を作成するように、汎用コンピュータ、専用コンピュータ、または他のプログラマブル・データ処理装置のプロセッサがマシンを作成するために提供されてもよい。これらのコンピュータ可読プログラム命令はまた、命令が記憶されたコンピュータ可読記憶媒体が、フローチャートまたはブロック図あるいはその両方の１つもしくは複数のブロックで指定される機能／動作の態様を実現する、命令を含む製品を含むように、コンピュータ、プログラマブル・データ処理装置、または他のデバイスあるいはそれら全てが、特定の方式で機能するように命令することができる、コンピュータ可読記憶媒体に記憶されてもよい。

コンピュータ可読プログラム命令はまた、コンピュータ、他のプログラマブル・データ処理装置、または他のデバイス上で実行する命令が、フローチャートまたはブロック図あるいはその両方の１つまたは複数のブロックで指定される機能／動作を実現するように、コンピュータ、他のプログラマブル・データ処理装置、または他のデバイスにロードされて、一連の動作ステップをコンピュータ、他のプログラマブル・データ処理装置、または他のデバイス上で実施させて、コンピュータ実装プロセスを生成してもよい。

図面中のフローチャートおよびブロック図は、本開示の様々な実施形態によるシステム、方法、およびコンピュータ・プログラム製品の可能な実現例のアーキテクチャ、機能性、および動作を示している。この点で、フローチャートまたはブロック図の各ブロックは、指定された論理的機能を実現する１つもしくは複数の実行可能命令を含む、モジュール、セグメント、または命令の部分を表してもよい。いくつかの代替実現例では、ブロックに示される機能は図面に示される以外の順序で行われてもよい。例えば、関与する機能性に応じて、連続して示される２つのブロックが、実際には実質的に同時に実行されてもよく、またはブロックは、場合によっては逆の順序で実行されてもよい。また、ブロック図またはフローチャート図あるいはその両方の各ブロック、ならびにブロック図またはフローチャート図あるいはその両方のブロックの組み合わせは、指定された機能もしくは動作を実施するか、または専用ハードウェアおよびコンピュータ命令の組み合わせを実施する、専用ハードウェアベースのシステムによって実現できることが注目されるであろう。

本発明は、クライアント、サーバ、ネットワークを通じて接続されたクライアントおよびサーバを備えるコンピュータ・システム、方法、またはコンピュータ・プログラム製品、あるいはそれらの全てであってもよい。コンピュータ・プログラム製品は、プロセッサに本発明の態様を実施させるコンピュータ可読プログラム命令を有する、コンピュータ可読記憶媒体を含んでもよい。

本開示の範囲から逸脱することなく、上述の例示的実施形態に対して多くの改善および修正を行い得ることが、当業者には明白となるであろう。

Claims (20)

1. クライアント接続を管理することができるトランザクション処理サーバであって、
   前記サーバに対する個々のクライアント−サーバ接続を確立し、維持し、終了するように動作可能であり、各接続がクライアント要求を前記サーバに送信することができる、クライアント−サーバ・コネクタと、
   クライアント要求を処理し、応答を発行するように動作可能な、前記サーバのトランザクション処理領域と、
   クライアント要求がどのくらい迅速に処理されているかの性能記録を維持するように動作可能な、サーバ性能マネージャと、
   入ってくるクライアント要求を監視し、各クライアント要求から、目標応答時間内で前記クライアント要求を処理するように前記トランザクション処理サーバに対して示す目標応答時間を抽出し、また前記目標応答時間に基づくとともに前記性能記録を参照して、入ってくる各クライアント要求を許可または拒否するように動作可能な、接続マネージャとを備える、トランザクション処理サーバ。
2. 前記接続マネージャが、拒否された要求の作成元であるクライアントに対して、要求拒否メッセージを送信するように更に動作可能である、請求項１に記載のサーバ。
3. 前記要求拒否メッセージが、サーバからクライアントへのデータ・パケットのメタデータに挿入される、請求項２に記載のサーバ。
4. 前記要求拒否メッセージが、前記性能記録を参照して得られる、前記要求を処理するための予測応答時間を含む、請求項２に記載のサーバ。
5. 前記目標応答時間が前記クライアント要求のメタデータに含まれる、請求項１に記載のサーバ。
6. 前記要求がトランザクション・タイプを有し、前記性能記録が、各トランザクション・タイプに基づいたクライアント要求の処理時間履歴を含む、請求項１に記載のサーバ。
7. 各処理時間が、関連するクライアント要求から集めた平均時間である、請求項１に記載のサーバ。
8. 前記平均が、より最近処理されたクライアント要求がより大きい重み付けを有して、リーセンシーによって重み付けされる、請求項１に記載のサーバ。
9. 入ってくるクライアント要求が、評価される前記クライアント要求に関連する前記目標応答時間および応答時間履歴の比較に基づいて、許可または拒否される、請求項１に記載のサーバ。
10. 前記性能記録が、時間によって定義されるウィンドウ内で処理されたクライアント要求に基づく、請求項１に記載のサーバ。
11. 前記性能記録が、多数の過去のトランザクション内におけるトランザクション・タイプの多数のクライアント要求に基づく、請求項１に記載のサーバ。
12. 前記性能記録が多数の過去のクライアント要求に基づく、請求項１に記載のサーバ。
13. 前記サーバがクライアント要求を許可する容量を現在有していないとき、前記サーバに対するクライアント要求がキューに入れられる、キューを更に備える、請求項１に記載のサーバ。
14. 前記接続マネージャが、入ってくるクライアント要求が許可されることを条件として前記キューに追加され、拒否された要求が前記キューへのアクセスを拒絶されるように、前記キューへのアクセスをゲートで制御するように動作可能である、請求項１３に記載のサーバ。
15. 入ってくるクライアント要求の前記接続マネージャによる前記監視が、前記キューを見ることによって行われ、拒否されたクライアント要求が前記キューから消去される、請求項１３に記載のサーバ。
16. トランザクション処理サーバへのクライアント接続を管理する、前記サーバによって実施される方法であって、
    クライアントからのクライアント要求をクライアント−サーバ接続で受信することと、
    前記クライアント要求から、前記クライアントがどのくらい迅速に前記要求が処理されることを望むかを示す目標応答時間を抽出することと、
    前記目標応答時間に基づいて、また前記サーバによって維持されている、クライアント要求がどのくらい迅速に処理されているかの性能記録を参照して、前記クライアント要求を許可または拒否することとを含む、方法。
17. 前記要求が拒否された場合、拒否メッセージを前記クライアントに送信することを更に含む、請求項１６に記載の方法。
18. 前記クライアント要求がタイプ分類を含み、前記要求を許可または拒否するのに使用されるインジケータが前記タイプに特異的である、請求項１６に記載の方法。
19. プログラム命令が具現化されたコンピュータ可読記憶媒体を備え、前記コンピュータ可読記憶媒体が一過性信号自体ではなく、前記プログラム命令が、プロセッサに方法を実施させるように前記プロセッサによって実行可能であり、前記方法が、
    クライアント要求をトランザクション処理サーバによって、クライアント−サーバ接続で受信することと、
    前記クライアント要求から、目標応答時間内で前記クライアント要求を処理するように前記トランザクション処理サーバに対して示す、前記目標応答時間を抽出することと、
    前記要求される目標応答時間と前記トランザクション処理サーバにおける要求されるタイプのトランザクションに関する完了時間の性能記録との比較に基づいて、前記クライアント要求を許可または拒否することと、
    前記クライアント要求を拒否するように示す前記比較に基づいて、前記トランザクション処理サーバが、前記クライアント要求を完了する予測時間量を拒否メッセージに含むこととを含む、コンピュータ・プログラム製品。
20. 前記クライアント要求が前記トランザクション処理サーバによって拒否されたことに基づいて、前記クライアントに拒否メッセージを送信することを更に含み、前記クライアント要求がタイプ分類を含み、前記要求を許可または拒否するのに使用されるインジケータが前記タイプに特異的であり、前記拒否メッセージが前記目標応答時間よりも短い時間で送信される、請求項１９に記載のコンピュータ・プログラム製品。