(57)【特許請求の範囲】
【請求項１】
ホストから受信したサービス要求を処理する方法であって、
（ａ）サービスゲートウェイからサーバへのサービス要求を、前記サービスゲートウェイと前記サーバとの間のサービスセッションでリレーするステップと、
（ｂ）前記サービスゲートウェイが、前記サービスセッションのサービス要求時を決定するステップと、
（ｃ）前記サービスゲートウェイが、前記サーバからサービス応答を受信するステップと、
（ｄ）前記サービスゲートウェイが、サービス応答時を決定するステップと、
（ｅ）前記サービスゲートウェイが、前記サービス要求時と前記サービス応答時とから、前記サービス要求のサービス処理時間を計算するステップと、
（ｆ）前記サービス処理時間を期待サービス処理時間と比較するステップと、
（ｇ）前記比較に応じて、前記サーバのサーバビジー状態インジケータを更新するステップとを有し、
前記リレーするステップ（ａ）は、
（ａ１）前記サービスゲートウェイが前記ホストからサービス要求を受信するステップと、
（ａ２）前記サービスゲートウェイが前記サーバのサーバビジー状態インジケータをチェックするステップと、
（ａ３）前記サーバがビジー状態であると前記サーバビジー状態インジケータが示すとの判断に応じて、前記サービスゲートウェイが前記サービス要求をサービス要求バッファに入れるステップと、
（ａ４）前記サーバがビジー状態でないことを前記サーバビジー状態インジケータが示すとの判断に応じて、前記サービス要求を、前記サービスゲートウェイとサーバとの間のサービスセッションで前記サービスゲートウェイから前記サーバにリレーするステップを有し、
前記リレーするステップ（ａ４）は、
（ａ４ｉ）前記サービスゲートウェイが、前記サービス要求バッファが空かチェックするステップと、
（ａ４ｉｉ）前記サービス要求バッファが空であるとの判断に応じて、前記サービス要求を、前記サービスゲートウェイとサーバとの間のサービスセッションで、前記サービスゲートウェイからサーバにリレーするステップと、
（ａ４ｉｉｉ）前記サービス要求バッファが空でないとの判断に応じて、前記サービスゲートウェイが、前記サービス要求をサービス要求バッファに入れるステップとを有する、
方法。
【請求項２】
前記更新するステップ（ｇ）は、
（ｇ１）前記サービス処理時間が前記期待サービス処理時間より長いとの判断に応じて、前記サービスゲートウェイが前記サーバビジー状態インジケータを更新して、前記サーバがビジー状態であることを示すステップと、
（ｇ２）前記サービス処理時間が前記期待サービス処理時間より長くないとの判断に応じて、前記サービスゲートウェイが前記サーバビジー状態インジケータを更新して、前記サーバがビジー状態でないことを示すステップとを有する、
請求項１に記載の方法。
【請求項３】
前記計算するステップ（ｅ）は、
（ｅ１）前記サービスゲートウェイが、前記サービス要求時と前記サービス応答時との間の時間的長さとして、前記サービス要求のサービス処理時間を計算するステップを有する、
請求項１に記載の方法。
【請求項４】
前記サービス応答はエラー表示を含み、前記エラー表示がエラーを示す場合、前記サービスゲートウェイは前記サービス処理時間を計算しない、
請求項１に記載の方法。
【請求項５】
前記比較するステップ（ｆ）は、
（ｆ１）前記サービスゲートウェイが、前記サービス要求のサービス属性又は前記サーバに応じて、前記期待サービス処理時間を設定するステップを有する、
請求項１に記載の方法。
【請求項６】
前記期待サービス処理時間は、前記サービス属性に関連し、データストアに格納され、前記設定するステップ（ｆ１）は、
（ｆ１ｉ）前記サービスゲートウェイが、前記サービス要求又は前記サーバを、前記データストア中のサービス属性と比較するステップと、
（ｆ１ｉｉ）前記サービス要求又はサーバが前記データストア中のサービス属性と一致したとき、前記一致したサービス属性に関連する期待サービス処理時間を読み出すステップとを有する、
請求項５に記載の方法。
【請求項７】
前記比較するステップ（ｆ）は、さらに、
（ｆ２）セキュアゲートウェイと前記サーバとの間の前のサービスセッションのサービス処理時間に基づき、修正期待サービス処理時間を計算するステップを有する、
請求項５に記載の方法。
【請求項８】
前記入れるステップ（ａ３）は、
（ａ３ｉ）前記サービスゲートウェイが、前記サービスゲートウェイにあるタイマーが満了したか判断するステップと、
（ａ３ｉｉ）前記タイマーが満了したとの判断に応じて、前記サービス要求を、前記サービスゲートウェイとサーバとの間のサービスセッションで、前記サービスゲートウェイからサーバにリレーするステップとを有する、
請求項１に記載の方法。
【請求項９】
前記サービス要求は優先度と関連づけられ、前記サービス要求バッファは前記優先度と関連づけられたサービス要求を格納するように構成され、
前記入れるステップ（ａ３）は、
（ａ３ｉ）前記サービスゲートウェイが、サービス要求を前記サービス要求バッファに入れるステップと、
（ａ３ｉｉ）前記サービス要求バッファ中のサービス要求を、関連づけられた優先度に応じて、前記サービスゲートウェイから前記サーバにリレーするステップとを有する、
請求項１に記載の方法。
【請求項１０】
ホストから受信したサービス要求を処理するコンピュータプログラムであって、
コンピュータ読み取り可能プログラムコードを有するコンピュータ読み取り可能記憶媒体を有し、前記コンピュータ読み取り可能プログラムコードは、
サービスゲートウェイからサーバへのサービス要求を、前記サービスゲートウェイと前記サーバとの間のサービスセッションでリレーし、
前記サービスセッションのサービス要求時を決定し、
前記サーバからサービス応答を受信し、
サービス応答時を決定し、
前記サービス要求時とサービス応答時とから前記サービス要求のサービス処理時間を計算し、
前記サービス処理時間を期待サービス処理時間と比較し、
前記比較に応じて、前記サーバのサーバビジー状態インジケータを更新するように構成され、
サービス要求を、前記サービスゲートウェイと前記サーバとの間のサービスセッションで、サービスゲートウェイからサーバへリレーするように構成されたコンピュータ読み取り可能プログラムコードは、さらに、
前記ホストからサービス要求を受信し、
前記サーバのサーバビジー状態インジケータをチェックし、
前記サーバがビジー状態であると前記サーバビジー状態インジケータが示すとの判断に応じて、前記サービス要求をサービス要求バッファに入れ、
前記サーバがビジー状態でないことを前記サーバビジー状態インジケータが示すとの判断に応じて、前記サービス要求を、前記サービスゲートウェイとサーバとの間のサービスセッションで前記サービスゲートウェイから前記サーバにリレーするように構成され、
前記サーバがビジー状態でないと前記サーバビジー状態インジケータが示すとの判断に応じて、サービス要求を、前記サービスゲートウェイと前記サーバとの間のサービスセッションで、サービスゲートウェイからサーバへリレーするように構成されたコンピュータ読み取り可能プログラムコードは、さらに、
前記サービス要求バッファが空かチェックし、
前記サービス要求バッファが空であるとの判断に応じて、前記サービス要求を、前記サービスゲートウェイとサーバとの間のサービスセッションで、前記サービスゲートウェイからサーバにリレーし、
前記サービス要求バッファが空でないとの判断に応じて、前記サービス要求をサービス要求バッファに入れるように構成される、
コンピュータプログラム。
【請求項１１】
前記比較に応じて、前記サーバのサーバビジー状態インジケータを更新するように構成されたコンピュータ読み取り可能プログラムコードは、さらに、
前記サービス処理時間が前記期待サービス処理時間より長いとの判断に応じて、前記サーバビジー状態インジケータを更新して、前記サーバがビジー状態であることを示し、
前記サービス処理時間が前記期待サービス処理時間より長くないとの判断に応じて、前記サーバビジー状態インジケータを更新して、前記サーバがビジー状態でないことを示すように構成された、
請求項１０に記載のコンピュータプログラム。
【請求項１２】
前記サービス要求時とサービス応答時とから前記サービス要求のサービス処理時間を計算するように構成されたコンピュータ読み取り可能プログラムコードは、さらに、
前記サービス要求時とサービス応答時との間の時間的長さとして前記サービス要求のサービス処理時間を計算するように構成された、
請求項１０に記載のコンピュータプログラム。
【請求項１３】
前記サービス処理時間を前記期待サービス処理時間と比較するように構成されたコンピュータ読み取り可能プログラムコードは、さらに、
前記サービス要求のサービス属性又は前記サーバに応じて、前記期待サービス処理時間を設定するように構成された、
請求項１０に記載のコンピュータプログラム。
【請求項１４】
前記期待サービス処理時間は前記サービス属性と関連づけられ、データストアに格納され、
前記サービス要求のサービス属性又は前記サーバに応じて、前記期待サービス処理時間を設定するように構成されたコンピュータ読み取り可能プログラムコードは、
前記サービス要求又はサーバを前記データストア中のサービス属性と比較し、
前記サービス要求又はサーバが前記データストア中のサービス属性と一致したとき、前記一致したサービス属性に関連する期待サービス処理時間を読み出すようにさらに構成された、
請求項１３に記載のコンピュータプログラム。
【請求項１５】
前記サービス処理時間を前記期待サービス処理時間と比較するように構成されたコンピュータ読み取り可能プログラムコードは、
セキュアゲートウェイと前記サーバとの間の前のサービスセッションのサービス処理時間に基づき、修正期待サービス処理時間を計算するようにさらに構成された、
請求項１３に記載のコンピュータプログラム。
【請求項１６】
前記サーバがビジー状態であると前記サーバビジー状態インジケータが示すとの判断に応じて、前記サービス要求をサービス要求バッファに入れるように構成されたコンピュータ読み取り可能プログラムコードは、さらに、
サービスゲートウェイにあるタイマーが満了したか判断し、
前記タイマーが満了したとの判断に応じて、前記サービス要求を、前記サービスゲートウェイとサーバとの間のサービスセッションで、前記サービスゲートウェイからサーバにリレーするように構成された、
請求項１４に記載のコンピュータプログラム。
【請求項１７】
前記サービス要求は優先度と関連づけられ、前記サービス要求バッファは前記優先度と関連づけられたサービス要求を格納するように構成され、
前記サーバがビジー状態であると前記サーバビジー状態インジケータが示すとの判断に応じて、前記サービス要求をサービス要求バッファに入れるように構成されたコンピュータ読み取り可能プログラムコードは、さらに、
前記サービス要求を前記サービス要求バッファに入れ、
前記サービス要求バッファ中のサービス要求を、関連づけられた優先度に応じて、前記サービスゲートウェイから前記サーバにリレーするように構成された、
請求項１４に記載のコンピュータプログラム。
【請求項１８】
サービス要求を処理するサーバと、
プロセッサと、コンピュータ読み取り可能プログラムコードを有するコンピュータ読み取り可能記憶媒体とを有するサービスゲートウェイとを有し、
前記コンピュータ読み取り可能プログラムコードは、前記プロセッサにより実行されると、前記サービスゲートウェイに、
サーバへのサービス要求を、前記サービスゲートウェイと前記サーバとの間のサービスセッションでリレーし、
前記サービスセッションのサービス要求時を決定し、
前記サーバからサービス応答を受信し、
サービス応答時を決定し、
前記サービス要求時とサービス応答時とから前記サービス要求のサービス処理時間を計算し、
前記サービス処理時間を期待サービス処理時間と比較し、
前記比較に応じて、前記サーバのサーバビジー状態インジケータを更新するように構成され、
サービス要求を、前記サービスゲートウェイと前記サーバとの間のサービスセッションでサービスゲートウェイからサーバへリレーすることは、
ホストからサービス要求を受信し、
前記サーバのサーバビジー状態インジケータをチェックし、
前記サーバがビジー状態であると前記サーバビジー状態インジケータが示すとの判断に応じて、前記サービス要求をサービス要求バッファに入れ、
前記サーバがビジー状態でないことを前記サーバビジー状態インジケータが示すとの判断に応じて、前記サービス要求を、前記サービスゲートウェイとサーバとの間のサービスセッションで前記サービスゲートウェイから前記サーバにリレーすることを含み、
前記サーバがビジー状態でないと前記サーバビジー状態インジケータが示すとの判断に応じて、サービス要求を、前記サービスゲートウェイと前記サーバとの間のサービスセッションで、サービスゲートウェイからサーバへリレーすることは、さらに、
前記サービス要求バッファが空かチェックし、
前記サービス要求バッファが空であるとの判断に応じて、前記サービス要求を、前記サービスゲートウェイとサーバとの間のサービスセッションで、前記サービスゲートウェイからサーバにリレーし、
前記サービス要求バッファが空でないとの判断に応じて、前記サービス要求をサービス要求バッファに入れるように構成される、
システム。
【請求項１９】
前記比較に応じて、前記サーバのサーバビジー状態インジケータを更新することは、
前記サービス処理時間が前記期待サービス処理時間より長いとの判断に応じて、前記サーバビジー状態インジケータを更新して、前記サーバがビジー状態であることを示し、
前記サービス処理時間が前記期待サービス処理時間より長くないとの判断に応じて、前記サーバビジー状態インジケータを更新して、前記サーバがビジー状態でないことを示すことを含む、
請求項１８に記載のシステム。
【請求項２０】
前記サービス処理時間を期待サービス処理時間と比較することは、
前記サービス要求のサービス属性又は前記サーバに応じて、前記期待サービス処理時間を設定することを含む、
請求項１８に記載のシステム。
【請求項２１】
前記期待サービス処理時間は、前記サービス属性に関連し、データストアに格納され、
前記サービス要求のサービス属性又は前記サーバに応じて、前記期待サービス処理時間を設定することは、
前記サービス要求又はサーバを前記データストア中のサービス属性と比較し、
前記サービス要求又はサーバが前記データストア中のサービス属性と一致したとき、前記一致したサービス属性に関連する期待サービス処理時間を読み出すことを含む、
請求項２０に記載のシステム。
【請求項２２】
前記サービス処理時間を期待サービス処理時間と比較することは、
セキュアゲートウェイと前記サーバとの間の前のサービスセッションのサービス処理時間に基づき、修正期待サービス処理時間を計算することを含む、
請求項２０に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概してデータ通信に関し、より具体的には、サービスプロセスパラメータに基づきサーバにアプリケーショントラフィックを配信する方法とシステムに関する。
【背景技術】
【０００２】
ウェブサービスとクラウドコンピューティングは前例のない速さで展開されている。データセンターには毎日、新しいサーバが運ばれ、設置されている。あらゆる方向から、ウェブサービスとコーポレートコンピューティングへの需要がある。消費者向けサービスには、スマートホンアプリ、ロケーションベースサービスなどの携帯アプリ、ナビゲーションサービス、キンドルなどの電子ブックサービス、ユーチューブやＨｕｌｕなどのビデオアプリケーション、パンドラやｉＴｕｎｅｓなどの音楽アプリケーション、Ｎｅｔｆｌｉｘなどのインターネットテレビジョンサービス、その他の急速に成長している多数の消費者向けウェブサービスなどがある。企業面では、Google(TM)  docs、Microsoft(TM)  Office  Live、Sharepoint(TM)  softwareなどのサービスに基づくクラウドコンピューティング、Salesforce.com(TM)のオンラインソフトウェアサービス、テレプレゼンス、及びウェブ会議サービス、及びその他の多数の企業クラウドコンピューティングサービスがある。
【０００３】
結果として、増大するコンピューティング需要を満たすため、ますます多くのサービスが展開されている。従来、これらのサーバは、固定モジュールやシャーシ中の典型的なネットワークアプリケーションであるApplication  Delivery  Controller  or  Server  Load  Balancer  (ADC/SLB)などのサービスゲートウェイにより管理されているか、または商品化されたサーバＡＤＣ／ＳＬＢで動作するソフトウェアモジュールが入来するサービス要求に基づきサーバへのアプリケーショントラフィックを管理している。サーバ間でトラフィックを分配する一般的な方法は、アプリケーション（ＨＴＴＰ、ＦＴＰ、ＨＴＴＰＳなど）、ＵＲＬなどのサービスアドレス、ネットワークインタフェースに基づく優先度、又はホストＩＰアドレスに基づきサービス要求を分配することである。ＡＤＣ／ＳＬＢは、サーバを完全に利用できてサービス要求を処理できると過程して、そのサービス要求をサーバに分配する。一般的に、フル負荷（fully  loaded）のサーバは、サービス要求をうまく処理できない。実際、サーバがビジー状態のとき、すべてではなくてもほとんどのサービス要求が遅延し、又はサービスを受けられない。ビジー状態のサーバには、それ以上サービス要求を分配しない方がよいことも多い。現在のＡＤＣ／ＳＬＢにより、ネットワークアドミニストレータは、最大サービスセッション容量を設定して、ＡＤＣ／ＳＬＢがサーバにその最大容量より多いサービス要求を送らないようにできる。しかし、サーバに統計的に設定された制限では、サーバの容量を完全に利用できず、すべてのサービス要求がサーバの同じ処理を必要とするものでもない。ＡＤＣ／ＳＬＢが、サーバからのサービス応答時間に基づいて、そのサーバがビジー状態であるか判断し、そのサーバにそれ以上のサービス要求を送ることを少なくすると都合がよい。
【０００４】
それゆえ、ＡＤＣ／ＳＬＢのシステムと方法が、動的サービス応答時間に基づいてサーバの過負荷を保護する必要がある。
【発明の概要】
【課題を解決するための手段】
【０００５】
本発明の一実施形態による方法は、ホストから受信したサービス要求を処理する方法であって、（ａ）サービスゲートウェイからサーバへのサービス要求を、前記サービスゲートウェイと前記サーバとの間のサービスセッションでリレーするステップと、（ｂ）前記サービスゲートウェイが前記サービスセッションのサービス要求時を決定するステップと、（ｃ）前記サービスゲートウェイが、前記サーバからサービス応答を受信するステップと、（ｄ）前記サービスゲートウェイが、サービス応答時を決定するステップと、（ｅ）前記サービスゲートウェイが、前記サービス要求時と前記サービス応答時とから、前記サービス要求のサービス処理時間を計算するステップと、（ｆ）前記サービス処理時間を期待サービス処理時間と比較するステップと、（ｇ）前記比較に応じて、前記サーバのサーバビジー状態インジケータを更新するステップとを有する。
【０００６】
本発明の一態様において、前記更新するステップ（ｇ）は、（ｇ１）前記サービス処理時間が前記期待サービス処理時間より長いとの判断に応じて、前記サービスゲートウェイが前記サーバビジー状態インジケータを更新して、前記サーバがビジー状態であることを示すステップと、（ｇ２）前記サービス処理時間が前記期待サービス処理時間より長くないとの判断に応じて、前記サービスゲートウェイが前記サーバビジー状態インジケータを更新して、前記サーバがビジー状態でないことを示すステップとを有する。
【０００７】
本発明の一態様において、前記計算するステップ（ｅ）は、（ｅ１）前記サービスゲートウェイが、前記サービス要求時と前記サービス応答時との間の時間的長さとして、前記サービス要求のサービス処理時間を計算するステップを有する。
【０００８】
本発明の一態様において、前記サービス応答はエラー表示を含み、前記エラー表示がエラーを示す場合、前記サービスゲートウェイは前記サービス処理時間を計算しない。
【０００９】
本発明の一態様において、前記比較するステップ（ｆ）は、（ｆ１）前記サービスゲートウェイが、前記サービス要求のサービス属性又は前記サーバに応じて、前記期待サービス処理時間を設定するステップを有する。
【００１０】
本発明の一態様において、前記期待サービス処理時間は、前記サービス属性に関連し、データストアに格納され、前記設定するステップ（ｆ１）は、（ｆ１ｉ）前記サービスゲートウェイが、前記サービス要求又は前記サーバを、前記データストア中のサービス属性と比較するステップと、（ｆ１ｉｉ）前記サービス要求又はサーバが前記データストア中のサービス属性と一致したとき、前記一致したサービス属性に関連する期待サービス処理時間を読み出すステップとを有する。
【００１１】
本発明の一態様において、前記比較するステップ（ｆ）は、さらに、（ｆ２）前記セキュアゲートウェイと前記サーバとの間の前のサービス背ションのサービス処理時間に基づき、修正期待サービス処理時間を計算するステップを有する。
【００１２】
本発明の一態様において、前記リレーするステップ（ａ）は、（ａ１）前記サービスゲートウェイが前記ホストからサービス要求を受信するステップと、（ａ２）前記サービスゲートウェイが前記サーバのサーバビジー状態インジケータをチェックするステップと、（ａ３）前記サーバがビジー状態であると前記サーバビジー状態インジケータが示すとの判断に応じて、前記サービスゲートウェイが前記サービス要求をサービス要求バッファに入れるステップと、（ａ４）前記サーバがビジー状態でないことを前記サーバビジー状態インジケータが示すとの判断に応じて、前記サービス要求を、前記サービスゲートウェイとサーバとの間のサービスセッションで前記サービスゲートウェイから前記サーバにリレーするステップを有する。
【００１３】
本発明の一態様において、前記リレーするステップ（ａ４）は、（ａ４ｉ）前記サービスゲートウェイが、前記サービス要求バッファが空かチェックするステップと、（ａ４ｉｉ）前記サービス要求バッファが空であるとの判断に応じて、前記サービス要求を、前記サービスゲートウェイとサーバとの間のサービスセッションで、前記サービスゲートウェイからサーバにリレーするステップと、（ａ４ｉｉｉ）前記サービス要求バッファが空でないとの判断に応じて、前記サービスゲートウェイが、前記サービス要求をサービス要求バッファに入れるステップとを有する。
【００１４】
本発明の一態様において、前記入れるステップ（ａ３）は、（ａ３ｉ）前記サービスゲートウェイが、前記サービスゲートウェイにあるタイマーが満了したか判断するステップと、（ａ３ｉｉ）前記タイマーが満了したとの判断に応じて、前記サービス要求を、前記サービスゲートウェイとサーバとの間のサービスセッションで、前記サービスゲートウェイからサーバにリレーするステップとを有する。
【００１５】
本発明の一態様において、前記サービス要求は優先度と関連づけられ、前記サービス要求バッファは前記優先度と関連づけられたサービス要求を格納するように構成され、前記入れるステップ（ａ３）は、（ａ３ｉ）前記サービスゲートウェイが、サービス要求を前記サービス要求バッファに入れるステップと、（ａ３ｉｉ）前記サービス要求バッファ中のサービス要求を、関連づけられた優先度に応じて、前記サービスゲートウェイから前記サーバにリレーするステップとを有する。
【００１６】
上記の方法に対応するシステムとコンピュータプログラム製品もここに説明し特許請求の範囲に記載した。
【図面の簡単な説明】
【００１７】
【図１】サービスゲートウェイとサーバとの間のサービスセッションを示す図である。
【図２】サービスゲートウェイによるサービス要求の処理方法の一実施形態を示す図である。
【図３】サーバがビジー状態であるか判断する方法の一実施形態を示す図である。
【図４】サーバビジー状態インジケータに基づくサービス要求の処理方法の一実施形態を示す図である。
【図５】サービスゲートウェイがサーバビジー状態インジケータを更新した後にサービス要求の処理方法の一実施形態を示す図である。
【図６】サービス優先度に基づくサービス要求の処理方法の一実施形態を示す図である。
【図７】サービスゲートウェイによるサービス要求の処理方法の一実施形態を示すフローチャートである。
【図８】サーバビジー状態インジケータに基づくサービス要求の処理方法の一実施形態を示すフローチャートである。
【発明を実施するための形態】
【００１８】
本発明の実施形態は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態、またはハードウェアとソフトウェアを両方含む実施形態の形式を取ることができる。好ましい一実施形態では、本発明は、ソフトウェアで実施できる。ソフトウェアは、ファームウェア、レジデントソフトウェアなどを含むが、これらの限定されない。
【００１９】
さらに、本発明は、コンピュータや命令実行システムにより使用されるプログラムコードを提供するコンピュータ利用可能媒体またはコンピュータ読み取り可能媒体からアクセスできるコンピュータプログラム製品の形体を取りうる。本開示の目的では、コンピュータ使用可能またはコンピュータ読み取り可能媒体は、命令実行システム、装置、又はデバイスにより、またはそれらに関して使用される、プログラムを包含、格納、伝達、伝送、搬送できる任意の装置である。
【００２０】
この媒体は、電子的媒体、磁気的媒体、光媒体、光磁気媒体、赤外線媒体、半導体システム（または装置やデバイス）、伝達媒体などである。コンピュータ読み取り可能媒体の例としては、半導体または固体メモリ、磁気テープ、リムーバブルコンピュータディスケット、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、固定磁気ディスク、光ディスクなどがある。光ディスクの例としては、コンパクトディスク−リードオンリメモリ（ＣＤ−ＲＯＭ）、コンパクトディスク−リード／ライト（ＣＤ−Ｒ／Ｗ）、及びＤＶＤなどがある。
【００２１】
プログラムコードを格納及び／又は実行するのに好適なデータ処理システムは、システムバスを通してメモリ要素に直接的または間接的に結合された少なくとも１つのプロセッサを含む。メモリエレメントは、プログラムコードの実行時に使われるローカルメモリと、バルク記憶と、実行時にコードをバルク記憶から読み出さねばならない回数を低減するために、少なくともプログラムコードの一部を一時的に記憶するキャッシュメモリと、を含む。
【００２２】
（キーボード、ディスプレイ、ポインティングデバイスなどを含むがこれに限定されない）入出力すなわちＩ／Ｏデバイスを、直接的に、またはＩ／Ｏコントローラを介在させて、システムに結合できる。
【００２３】
ネットワークアダプタをシステムに結合して、データ処理システムを、プライベートネットワークやパブリックネットワークを通して、他のデータ処理システムやリモートプリンタや記憶装置に結合することもできる。モデム、ケーブルモデム及びイーサネット（登録商標）カードは、現在利用できるネットワークアダプタの一部である。
【００２４】
図のフローチャートとブロック図は、本発明の様々な実施形態によるシステム、方法及びコンピュータプログラム製品のアーキテクチャ、機能及びありうる実装の動作を示す。これに関連して、フローチャートやブロック図の各ブロックは、モジュール、セグメント、コードの一部分を表す。これは指定されたローカル機能を実装する一又は複数の実行可能命令を含む。留意すべき点として、代替的な実施形態では、ブロックに示した機能は図面に示した順序でない順序で行ってもよい。例えば、順次的に示された２つのブロックは、その機能に応じて、実際には、実質的に同時に実行してもよく、逆の順序で実行してもよい。また、留意点として、ブロック図及び／又はフローチャートの各ブロック、及びブロック図及び／又はフローチャートのブロックの組合せは、指定された機能や動作を実行する特定目的ハードウェアベースシステムにより、又は特定目的ハードウェアとコンピュータ命令との組合せにより実施できる。
【００２５】
ここで用いる用語は、具体的な実施形態を説明することを目的としており、本発明の限定を意図したものではない。ここで、冠詞「a」、「an」、及び「the」は、明らかに文脈に反しない限り、複数の場合も含む。さらに、言うまでもなく、「有する」との用語は、本明細書で用いるとき、記載した特徴、整数、ステップ、動作、要素及び／又はコンポーネントがあることを示し、その他の特徴、整数、ステップ、動作、要素、コンポーネント及び／またはこれらのグループがあることを排除するものではない。
【００２６】
図１は、サービスゲートウェイ１１０とサーバ２００との間のサービスセッション３２１を示す図である。サービスゲートウェイ１１０は、ホスト１００からサービス要求３０１を受信する。サービス要求３０１はデータネットワーク１５３により届く。一実施形態では、サービス要求３０１は、ウェブサービス要求であり、例えば、HTTP  (Hypertext  Transport  Protocol)要求、セキュアHTTP要求、FTP  (File  Transfer  Protocol)要求、ファイル転送要求、SIP  (Session  Initiation  Protocol)セッション要求、ウェブ技術に基づく要求、ビデオ又はオーディオストリーミング要求、ウェブ会議セッション要求、又はインターネット又は企業ネットワーク上の任意の要求である。
【００２７】
ホスト１００はネットワークアクセス機能を有するコンピューティング装置である。ホスト１００は、プロセッサ１０３及びコンピュータ読み取り可能媒体１０４に動作可能に結合している。コンピュータ読み取り可能媒体１０４は、ここに説明する、本発明の様々な実施形態を実施するコンピュータ読み取り可能プログラムコードを格納している。一実施形態では、ホスト１００はワークステーション、デスクトップパーソナルコンピュータ、又はラップトップパーソナルコンピュータである。一実施形態では、ホスト１００はパーソナルデータアシスタント（ＰＤＡ）、スマートホン、又はセルラー電話である。一実施形態では、ホスト１００は、セットトップボックス、インターネットメディアビュアー、インターネットメディアプレーヤ、スマートセンサ、スマートメディカルデバイス、ネットトップボックス、ネットワークテレビジョンセット、ネットワークＤＶＲ、ネットワークＢｌｕ−ｒａｙ（登録商標）プレーヤ、又はメディアセンターである。
【００２８】
一実施形態では、データネットワーク１５３はインターネットプロトコル（ＩＰ）ネットワークである。一実施形態では、データネットワーク１５３は、企業データネットワーク又は地域企業データネットワークである。一実施形態では、データネットワーク１５３はインターネットサービスプロバイダネットワークである。一実施形態では、データネットワーク１５３は住居データネットワークである。一実施形態では、データネットワーク１５３は、イーサネット（登録商標）などの有線ネットワークを含む。一実施形態では、データネットワーク１５３は、ＷｉＦｉネットワーク、セルラーネットワークなどの無線ネットワークを含む。
【００２９】
サービスゲートウェイ１１０は、プロセッサ１１３及びコンピュータ読み取り可能媒体１１４に動作可能に結合している。コンピュータ読み取り可能媒体１１４は、ここに説明する、プロセッサ１１３により実行された時、本発明の様々な実施形態を実施するコンピュータ読み取り可能プログラムコードを格納している。ある実施形態では、サービスゲートウェイ１１０は、複数のサーバへの負荷を分配する、サーバ負荷バランサ、アプリケーションデリバリコントローラ、サービスデリバリプラットフォーム、トラフィックマネージャ、セキュリティゲートウェイ、ファイアウォールシステムの一コンポーネント、仮想プライベートネットワーク（ＶＰＮ）の一コンポーネント、ビデオサーバの負荷バランサ、又はゲートウェイとして実装される。
【００３０】
サーバ２００は、プロセッサ２１３及びコンピュータ読み取り可能媒体２１４に動作可能に結合している。コンピュータ読み取り可能媒体２１４は、ここに説明する、プロセッサ２１３により実行された時、本発明の様々な実施形態を実施するコンピュータ読み取り可能プログラムコードを格納している。ある実施形態では、コンピュータ読み取り可能プログラムコードは、サーバ２００を、ウェブサーバ、ファイルサーバ、ビデオサーバ、データベースサーバ、アプリケーションサーバ、ボイスシステム、会議サーバ、メディアゲートウェイ、ＳＩＰサーバ、リモートアクセスサーバ、ＶＰＮサーバ、又はメディアセンターとして実施する。
【００３１】
サービスゲートウェイ１１０はデータネットワーク１５５を介してサーバ２００に接続している。一実施形態では、データネットワーク１５５はデータネットワーク１５３と同じものである。一実施形態では、データネットワーク１５５はデータネットワーク１５３と違うものである。一実施形態では、ホスト１００は、データネットワーク１５５には直接的にはアクセスしない。一実施形態では、ホスト１００は、データネットワーク１５５には直接的にアクセスできる。
【００３２】
図２と図７は、サービスゲートウェイ１００によるサービス要求の処理方法の一実施形態を示す図である。一実施形態では、サービスゲートウェイ１１０は、ホスト１００からサービス要求３０１を受信し、サービスゲートウェイ１１０とサーバ２００との間にサービスセッション３２１を確立することにより、サービス要求３０１をサーバ２００（７０１）にリレーする。サービスゲートウェイ１１０は、サービスセッション３２１のサービス要求時３６１を決定する（７０２）。一実施形態では、サービス要求時３６１は、時刻、システム時間、タイムカウンタなどのタイムスタンプである。一実施形態では、サービス要求時３６１は、サービスゲートウェイ１１０がサービス要求３０１をサーバ２００に送信した時である。一実施形態では、サービス要求時３６１は、サービスゲートウェイ１１０がサービス要求３０１を受信したアクノレッジメントをサーバ２００から受信した時である。
【００３３】
サーバ２００は、サービス要求３０１を処理した後、サービス応答３５２で応答する。一実施形態では、サービス応答３５２は、ウェブページ、文書、ファイル、ピクチャ、オーディオ信号又はビデオ信号のストリーミング、又は音声電話（voice  call）を含む。一実施形態では、サービス応答３５２はエラー表示３５４を含む。エラー表示３５４は、ＨＴＴＰエラーステータスコード、ＦＴＰエラーコード、ＳＩＰエラーメッセージ、その他の任意のエラーコードを含み得る。
【００３４】
サービスゲートウェイ１１０は、サービス応答３５２を受信し、そのサービス応答３５２をホスト１００にリレーする（７０３）。サービスゲートウェイ１１０は、サービス応答３５２の受信時、サービス応答時３６２を決定する（７０４）。一実施形態では、サービス応答時３６２は、時刻、システム時間、タイムカウンタなどのタイムスタンプであり、サービス要求時３６１とコンパチブルである。一実施形態では、サービス応答時３６２は、サービスゲートウェイ１１０がサービス応答３５２を受信した時である。一実施形態では、サービス応答時３６２は、サービスゲートウェイ１１０がサービス応答３５２の最初の情報を受信した時である。一実施形態では、サービス応答時３６２は、サービスゲートウェイ１１０がサービス応答３５２の最後の情報を受信した時である。一実施形態では、サービス応答時３６２は、サービスゲートウェイ１１０がサーバ２００からのサービスセッション３２１を切断した時である。一実施形態では、サービス応答時３６２はサービス応答３５２に含まれる。
【００３５】
サービスゲートウェイ１１０は、サービス要求時３６１とサービス応答時３６２とを決定した後、そのサービス要求時とサービス応答時とから、サービス要求３０１のサービス処理時間３６０を計算する（７０５）。サービス処理時間３６０は、一般的に、サービス要求時３６１とサービス応答時３６２との間の長さを測るものである。一実施形態では、サービスゲートウェイ１１０は、サービス応答時３６２からサービス要求時３６１を減算し、サービス処理時間３６０を求める。他の一実施形態では、サービスゲートウェイ１１０は、サービス要求時３６１とサービス応答時３６２との間の時間的長さを計算してサービス処理時間を決定する。例えば、サービス処理時間３６０は１０ミリ秒、５ミリ秒、２４７ミリ秒、３秒、１５秒、１分、７５マイクロ秒、又は２８９時間単位である。
【００３６】
一実施形態では、サービスゲートウェイ１１０は、サービス処理時間３６０を計算する前にサービス応答３５２を確認する。一例では、サービスゲートウェイ１１０は、サービス応答３５２がエラー表示３５４を含んでいるか、を確認する。一実施形態では、エラー表示３５４にエラーが表示されている場合、サービスゲートウェイ１１０は、サービス要求３０１に対するサービス処理時間３６０を計算しない。
【００３７】
一実施形態では、サービスゲートウェイ１１０は、完了サービスセッションカウンタ３２６を含む。このカウンタは、サービスゲートウェイ１１０とサーバ２００との間の完了したサービスセッションの数をカウントする。一実施形態では、サービスゲートウェイ１１０は、サービス応答３５２を受信すると、又はサーバ２００とのサービスセッション３２１を切断すると、完了サービスセッションカウンタ３２６を１だけインクリメントする。一実施形態では、サービスゲートウェイ１１０は、サービス処理時間３６０を決定した後、完了サービスセッションカウンタ３２６を１だけインクリメントする。
【００３８】
図３は、サーバ２００がビジー状態であるか判断する方法の一実施形態を示す図である。サービスゲートウェイ１１０は、サーバ２００のサーバビジー状態インジケータ３７８を含む。このインジケータは、サーバ２００がビジー状態であるか示す。一実施形態では、サーバビジー状態インジケータ３７８の値が０すなわち「Not  Busy」であると、サーバ２００がビジー状態でないことを示し、値が１すなわち「Busy」であると、サーバ２００がビジー状態であることを示す。サービスゲートウェイ１１０は、サービス処理時間３６０に応じて、サーバビジー状態インジケータ３７８を更新する。
【００３９】
一実施形態では、サービスゲートウェイ１１０は期待サービス処理時間３７４を含む。図３と図７を参照して、サービスゲートウェイ１１０は、サービス処理時間３６０を期待サービス処理時間３７４と比較する（７０６）。サービスゲートウェイ１１０は、サービス処理時間が期待サービス処理時間３７４より長いと判断すると、サーバビジー状態インジケータ３７８を「Busy」に更新する（７０８）。一実施形態では、サービス処理時間３６０は、期待サービス処理時間３７４より長いためには、期待サービス処理時間３７４より少なくとも５０％長い必要がある。一実施形態では、サービス処理時間３６０は、期待サービス処理時間３７４より少なくとも３００％長い必要がある。一実施形態では、サービス処理時間３６０は、期待サービス処理時間３７４より長い必要がある。
【００４０】
一実施形態では、サービスゲートウェイ１１０は、サービス処理時間３６０が期待サービス処理時間３７４より長くないと判断し、それに応じて、サーバビジー状態インジケータ３７８を「Not  Busy」に更新する（７０９）。
【００４１】
一実施形態では、期待サービス処理時間３７４はサービス要求３０１に基づく。一実施形態では、サービス要求３０１は、サービス要求ＵＲＬ（Universal  Resource  Locator）を含む。一実施形態では、期待サービス処理時間３７４は、サービス属性３７９に応じて設定される。サービス属性３７９は、期待サービス処理時間３７４に影響する属性である。例えば、プロトコルが異なれば、サービス要求の処理レートも異なり、期待サービス処理時間も異なるだろう。一実施形態では、サービス属性３７９はサービス要求ＵＲＬに基づく。一実施形態では、サービス属性３７９は、ドメイン名、ウェブサイト内のウェブフォルダー名、文書タイプ、サービス要求ＵＲＬに示されたプロトコルなどの、サービス要求ＵＲＬの一部に基づく。例えば、サービス要求ＵＲＬは、「http://www.abc.com/shops/shoe.html」である。サービス属性３７９は、ドメイン名「www.abc.com」、ウェブフォルダ「www.abc.com/shops」、文書タイプ.html（又は.php、.aspなどその他の文書タイプ）、プロトコルhttp（又はftp、https、sipなどその他のプロトコル）に基づく。一実施形態では、サービス属性３７９はサーバ２００で実施されるプログラムコードに関する。例えば、サーバ２００は、Apacheウェブサーバソフトウェア、マイクロソフトウェブサーバソフトウェア、オラクルウェブサーバソフトウェア、その他のウェブサーバソフトウェアを用いたウェブサーバである。サービス属性３７９は、ウェブサーバソフトウェアに関する。
【００４２】
一実施形態では、サービス属性３７９は、ドメイン名「www.a10networks.com」に基づき、期待サービス処理時間３７４は１０ミリ秒である。一実施形態では、サービス属性３７９はHTTPプロトコルに基づき、期待サービス処理時間３７４は７５ミリ秒である。一実施形態では、サービス属性３７９はFTPファイルダウンロードプロトコルに基づき、期待サービス処理時間３７４は２秒である。一実施形態では、サービス属性３７９はHTML文書タイプに基づき、期待サービス処理時間３７４は２０ミリ秒である。
【００４３】
一実施形態では、サービス属性３７９はサーバ２００で実施されるプログラムコードに関する。一実施形態では、サーバ２００はApacheウェブサーバソフトウェアを用い、期待処理時間は５０ミリ秒である。一実施形態では、サーバ２００はマイクロソフトウェブサーバソフトウェアを用い、期待処理時間は９０ミリ秒である。
【００４４】
一実施形態では、サービス属性３７９は、上記の複数の属性に関連する。期待処理時間は複数の属性の複数の期待処理時間の合計で決まる。
【００４５】
一実施形態では、サービスゲートウェイ１１０はデータストア３８０を含む。このデータストアは、期待サービス処理時間３７４と、関連するサービス属性３７９とを格納している。一実施形態では、サービスゲートウェイ１１０は、サービス要求３０１又はサーバ２００を、データストア３８０中のサービス属性３７９と比較する。一致すると、サービスゲートウェイ１１０は、一致したサービス属性３７９に関連する期待サービス処理時間３７４を読み出し、読み出した期待サービス処理時間３７４をサービス処理時間３６０と比較する。一実施形態では、期待サービス処理時間３７４は、どのサービス属性とも関連していない。サービスゲートウェイ１１０は、期待サービス処理時間３７４を読み出し、サービス処理時間３６０と比較する。
【００４６】
一実施形態では、期待サービス処理時間３７４は、ユーザにより設定される。
【００４７】
一実施形態では、期待サービス処理時間３７４は、前のサービスセッションのサービス処理時間に基づき自動的に決定される。サービスゲートウェイ１１０は、サービス処理時間３６０を決定するとき、
【００４８】
【数１】
0005963766.tif 000002
を用いて、修正期待サービス処理時間３７６を計算する。
【００４９】
この実施形態では、サービスゲートウェイ１１０は、完了サービスセッションカウンタ３２５を変更する前に、修正期待サービス処理時間３７６を計算する。一実施形態では、サービスゲートウェイ１１０は、サービス処理時間３６０が期待サービス処理時間３７４より長いとき、又はサービス応答３５２がエラー表示３５４を含むとき、期待サービス処理時間３７４を修正しない。この実施形態では、サービスゲートウェイ１１０は、完了サービスセッションカウンタ３２５を変更しない。
【００５０】
一実施形態では、期待サービス処理時間３７４は、サービス属性３７９に関連する。また、完了サービスセッションカウンタ３２６は、各サービス属性に対して異なる別々のカウンタを実施するため、サービス属性３７９に関連する。サービスゲートウェイ１１０は、修正期待サービス処理時間３７６を計算する前に、サービス要求３０１又はサーバ２００がサービス属性３７９と一致するかチェックする。
【００５１】
一実施形態では、サービスゲートウェイ１１０は、期待サービス処理時間３７４を修正期待サービス処理時間３７６で置き換える。修正期待サービス処理時間３７６は、サービスゲートウェイ１１０とサーバ２００との間の次のサービスセッションの期待サービス処理時間３７４になる。
【００５２】
サービスゲートウェイ１１０は、サーバビジー状態表示を更新した後、ホストから次のサービス要求を受信し（７１０）、上記プロセスをくり返す。
【００５３】
図４と図８は、サーバビジー状態インジケータ３７８に基づくサービス要求の処理方法の一実施形態を示す図である。  一実施形態では、サービスゲートウェイ１１０はサービス要求バッファ３３１を含む。一実施形態では、サービスゲートウェイ１１０は、ホスト１１０からサービス要求３０１を受信する（８０１）。一実施形態では、サービスゲートウェイ１１０は、サービス要求３０１をサービス要求バッファに入れる。他の一実施形態では、サービスゲートウェイ１１０は、サーバビジー状態インジケータ３７８をチェックする（８０２）。サーバ２００が「Busy」であることをサーバビジー状態インジケータ３７８が示した場合（８０３）サービスゲートウェイ１１０は、サービス要求３０１をサービス要求バッファ３３１に入れる（８０４）。一実施形態では、図２と図７を参照して上述したように、サーバ２００が「Not  Busy」であるとサーバビジー状態インジケータ３７８が表示する場合（８０３）、サービスゲートウェイ１１０は、サービス要求３０１をサーバ２００にリレーする（７０１）。他の一実施形態では、サーバ２００が「Not  Busy」であるとサーバビジー状態インジケータ３７８が表示する場合、サービスゲートウェイ１１０はサービス要求バッファ３３１が空であるかチェックする（８０５）。サービス要求バッファ３３１が空である場合、サービスゲートウェイ１１０は、サービス要求３０１をサーバ２００にリレーする（７０１）。サービス要求バッファ３３１が空でない場合、サービスゲートウェイ１１０は、サービス要求３０１をサービス要求バッファ３３１に入れる（８０６）。サービスゲートウェイ１１０は、サービス要求バッファ３３１が空になるまで、又はサーバビジー状態インジケータ３７８が「Busy」に変わるまで、サービス要求バッファ３３１中の各サービス要求をサーバ２００にリレーする（７０１）。
【００５４】
図５は、サービスゲートウェイ１１０がサーバビジー状態インジケータ３７８を更新した後のサービス要求の処理方法の一実施形態を示す図である。サービスゲートウェイ１１０は、サーバビジー状態インジケータ３７８の異なる値に応じて、サービス要求バッファ３３１中のサービス要求３０１を処理する。一実施形態では、サーバビジー状態インジケータ３７８の値は「Not  Busy」に更新される。サービスゲートウェイ１１０はサービス要求バッファ３３１を調べて、サービス要求３０１を発見する。サービスゲートウェイ１１０は、サービス要求３０１をサーバ２００にリレーする（７０１）。
【００５５】
一実施形態では、サーバビジー状態インジケータ３７８の値は「Busy」に更新される。一実施形態では、サービスゲートウェイ１１０はサービス要求バッファ３３１をすぐには処理しない。サービスゲートウェイ１１０はタイマー１１９を含む。タイマー１１９が満了すると、サービスゲートウェイ１１０は、サービス要求バッファ３３１中のサービス要求３０１を見つけ、サービス要求バッファ３３１中のサービス要求３０１をサーバ２００にリレーする（７０１）。タイマー１１９は、例えば、１分、３０秒、１秒、４００ミリ秒、５ミリ秒、３００マイクロ秒、その他のサービス要求３０１に対するサービスに大きな影響を与えない長さに設定できる。一実施形態では、時間的長さはサービス要求３０１の属性に基づく。
【００５６】
図６は、サービス優先度に基づくサービス要求の処理方法の一実施形態を示す図である。一実施形態では、サービス要求３０３はサービス優先度４０３に関連する。あるシナリオでは、サービス優先度４０３はサービス要求３０３のＵＲＬに基づく。あるシナリオでは、サービス優先度４０３は、ホスト１００に基づき、例えばホスト１００のＩＰアドレスやホスト１００のユーザ識別などに基づく。一シナリオでは、サービス優先度４０３は、サービスゲートウェイ１１０がサービス要求３０３を受信するネットワークインタフェースに関連する。サービスゲートウェイ１１０は、サービス要求３０３のサービス優先度４０３を決定する。
【００５７】
サービス要求バッファ３３１は、サービス優先度４０１とともにサービス要求を格納するように構成されている。一実施形態では、サーバビジー状態インジケータ３７８の値が「Busy」に更新された場合、サービスゲートウェイ１１０は、サービス優先度４０３をサービス優先度４０１と比較する。一致に応じて、サービスゲートウェイ１１０は、サービス要求３０３をサービス要求バッファ３３１に入れる。
【００５８】
一実施形態では、サービスゲートウェイ１１０は第２のサービス要求バッファ３３２を含む。サービス要求バッファ３３２は、サービス優先度４０２とともにサービス要求を格納するように構成されている。サービス優先度４０２はサービス優先度４０１より高いものである。
【００５９】
一実施形態では、サーバビジー状態インジケータ３７８の値が「Not  Busy」に更新された場合、サービスゲートウェイ１１０は、サービス要求バッファ３３１よりも前にサービス要求バッファ３３２中のサービス要求を処理する。一実施形態では、サービスゲートウェイ１１０は、サービス要求バッファ３３１中のサービス要求３０１をサーバ２００に送る前に、サービス要求バッファ３３２中のサービス要求３０２をサーバ２００に送る。
【００６０】
一実施形態では、サービスゲートウェイ１１０は、サービス要求バッファ３３１を処理する前に、サービス要求バッファ３３２のすべてのサービス要求を処理する。一実施形態では、サービスゲートウェイ１１０はサービス比率１１７を含み、比率１１７に応じて、サービス要求バッファ３３２とサービス要求バッファ３３１を処理する。サービス比率１１７は、サービス要求バッファ３３１中に優先度が低いサービス要求が無くならないように、優先度が低いサービス要求バッファ３３１よりも優先度が高いサービス要求バッファ３３２を優先して処理する。
【００６１】
本発明を実施形態を参照して説明したが、本技術分野の当業者には言うまでもなく、これらの実施形態にはバリエーションがあり、これらのバリエーションも本発明の精神と範囲に含まれる。したがって、本技術分野の当業者は、添付した特許請求の範囲の精神と範囲から逸脱せずに、多くの修正をすることができる。
【図１】
0005963766.tif 000003
【図２】
0005963766.tif 000004
【図３】
0005963766.tif 000005
【図４】
0005963766.tif 000006
【図５】
0005963766.tif 000007
【図６】
0005963766.tif 000008
【図７】
0005963766.tif 000009
【図８】
0005963766.tif 000010