JP2006190005A - 優先度決定装置、サービス処理割当装置、制御方法、及びプログラム - 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. 利用者から要求されたサービスの処理をアプリケーションサーバに割当てるサービス処理割当装置を制御するプログラムであって、
    情報処理装置を、
    アプリケーションサーバにサービスを要求したサービス要求履歴を、当該サービスを要求した各々の利用者に対応付けて記録するサービス要求履歴記録部と、
    アプリケーションサーバに対するサービスの要求を受けたことに応答して、当該サービスを要求した利用者を識別する利用者識別部と、
    前記利用者識別部により識別された利用者について、当該利用者に対応する前記サービス要求履歴に基づいて、当該利用者から要求されたサービスを処理する優先度を決定する優先度決定部と、
    アプリケーションサーバに対するサービスの要求を格納する複数のリクエストキューと、
    当該利用者によるサービスの要求を、前記優先度決定部により決定された優先度に対応するリクエストキューに挿入するエンキュー処理部と、
    前記複数のリクエストキューの各々から、当該リクエストキューに対応する優先度に基づいて要求を取得してアプリケーションサーバに割当てる要求割当部と
    して機能させるプログラム。

Images