(57)【要約】      （修正有）【課題】利用者からの要求に対する実行処理を抑制制御する。【解決手段】ネットワーク５を介してクライアント１０から送り込まれた要求情報を受信する入出力応答処理部と、予め設定されたアプリケーションに基づき前記要求情報に応じた実行処理を行うアプリケーションサーバ部１００とを有し、アプリケーションサーバ部１００が、前記要求情報のプロパティ情報に基づき前記要求情報の送信元を特定すると共に当該特定された送信元に基づいて前記実行処理を抑制するか否かの判定を行う実行抑制判定手段を備え、入出力応答処理部が、前記実行処理が抑制される場合に、前記実行処理の抑制状態をクライアント１０に通知する抑制状態通知手段を備えた。【選択図】図１
2009187542.tif 000002
【特許請求の範囲】
【請求項１】
クライアントから送り込まれた要求情報を受信する入出力応答処理部と、予め設定されたアプリケーションに基づき前記要求情報に応じた実行処理を行うアプリケーションサーバ部とを有する要求処理システムであって、
前記アプリケーションサーバ部が、前記要求情報のプロパティ情報に基づき前記要求情報の送信元を特定すると共に当該特定された送信元に基づいて前記実行処理を抑制するか否かの判定を行うと共に予め設定された送信元の要求情報に対する実行処理を抑制する実行抑制判定手段を備え、
前記入出力応答処理部が、前記実行処理が抑制される場合に、前記実行処理の抑制状態を前記クライアントに通知する抑制状態通知手段を有することを特徴とした要求処理システム。
【請求項２】
前記請求項１に記載の要求処理システムにおいて、
前記アプリケーションサーバ部は、企業情報システム構築向けのJava（登録商標）規格であるJAVA EEに準拠して設定されたことを特徴とする要求処理システム。
【請求項３】
前記請求項１に記載の要求処理システムにおいて、
前記実行抑制判定手段が、前記要求情報のプロパティ情報に基づいて前記要求情報の要求種別を特定すると共に当該特定された要求種別に基づき前記実行処理を抑制するか否かの判定を行う要求種別実行抑制判定機能を備えたことを特徴とする要求処理システム。
【請求項４】
前記請求項２に記載の要求処理システムにおいて、
前記アプリケーションサーバ部が、前記実行処理を抑制するか否かを判定する条件を示す抑制判定条件を、予め設定された実行ポリシーに基づき設定する抑制判定条件設定手段を備えたことを特徴とする要求処理システム。
【請求項５】
前記請求項４に記載の要求処理システムにおいて、
前記アプリケーションサーバ部は、前記アプリケーションが前記実行処理時に読み込まれるメモリ領域を備え、
前記抑制判定条件は、前記実行処理時に前記メモリ領域に前記アプリケーションと併記された状態で読み込まれることを特徴とした要求処理システム。
【請求項６】
前記請求項４、５に記載の要求処理システムにおいて、
前記アプリケーションサーバ部は、前記設定された抑制判定条件の内容をファイル情報として記憶する抑制条件情報記憶手段を備えたことを特徴とする要求処理システム。
【請求項７】
前記請求項４に記載の要求処理システムにおいて、
前記アプリケーションサーバ部は、前記抑制判定条件内に前記要求情報のプロパティ情報に合致する情報が含まれるか否かを判定する情報検索手段と、
前記抑制判定条件内に前記プロパティ情報に合致する情報が含まれる場合に、前記要求情報の送信元に対して前記要求情報に対する実行処理が抑制されることを示す要求実行エラーを通知する実行エラー通知手段とを備えたことを特徴とする要求処理システム。
【請求項８】
前記請求項７に記載の要求処理システムにおいて、
前記アプリケーションサーバ部は、前記実行処理を行うのに際し予め設定されたネットワークを介して接続された異なるアプリケーション部に遠隔実行要求を送信する遠隔実行要求手段と、前記遠隔実行要求に含まれるプロパティ情報に基づいて前記遠隔実行要求に応じた遠隔実行処理を抑制するか否かを判定する遠隔実行判定手段と、前記遠隔実行処理が抑制される場合に、前記遠隔実行処理の要求元に対して予め設定されたエラー通知を行う遠隔実行エラー通知手段とを備えたことを特徴とする要求処理システム。
【請求項９】
前記請求項８に記載の要求処理システムにおいて、
前記遠隔実行処理を抑制するか否かの条件を示す遠隔実行抑制判定条件を、予め設定された実行ポリシーに基づき設定する遠隔実行判定条件設定手段を前記遠隔実行判定手段に併設したことを特徴とする要求処理システム。
【請求項１０】
クライアントとの相互通信を行う入出力応答処理部と、前記クライアントから送り込まれた処理要求情報に応じて実行処理を行うアプリケーションサーバ部とを備え、前記実行処理を制御する要求処理方法において、
前記クライアントから送り込まれた処理要求を受信し当該処理要求を解析する要求解析行程と、前記処理要求の送信元を特定する送信元特定行程と、前記処理要求に応じた実行処理を行うか否かの判定を行う実行処理判定行程と、前記特定された送信元が実行処理の抑制対象である場合に、前記送信元に対して前記実行処理の抑制状態を通知する実行抑制通知行程とを備えたことを特徴とする要求処理方法。
【請求項１１】
クライアントとの相互通信を行う入出力応答処理部と、前記クライアントから送り込まれた処理要求情報に応じて実行処理を行うアプリケーションサーバ部とを備え、前記実行処理を制御するための要求処理プログラムにおいて、
前記クライアントから送り込まれた処理要求を受信し当該処理要求を解析する要求解析機能と、前記処理要求の送信元を特定する送信元特定機能と、前記処理要求に応じた実行処理を行うか否かの判定を行う実行処理判定機能と、前記特定された送信元が実行処理の抑制対象である場合に、前記送信元に対して前記実行処理の抑制状態を通知する実行抑制通知機能とを、コンピュータに実行させることを特徴とした要求処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クライアント・サーバシステムにあってクライアントからの要求に対するサーバ側の処理制御システムに関し、特に、特定のクライアントからの要求に応じてサーバ側で行われる実行処理を抑制する手法に関する。
【背景技術】
【０００２】
ウェブ(Web)システムが広く様々な分野で利用され、双方向のサービスやWebサーバ側で高度な処理を行う動的なサービスの提供が求められている。
又、Webサーバにアクセスが集中した場合に、Webサーバに多大な負荷がかかり、処理速度の低下やWebサーバのダウンなどの問題が生じる可能性がある。
このため、一般にクライアント−サーバシステムで実現されてきた特定のクライアントやアクセス元からのリクエストに対する実行処理を抑制する必要が生じている。
【０００３】
一方、Webサーバで提供されるサービスが高度になるに従い、Webサーバが行う処理も肥大化している。このため、Webサーバの負荷を軽減し、クライアントからの要求に応えるための業務に特化した処理を行うWebアプリケーションサーバが活用されてきている。
更に、Webシステムにおいては、JAVA EEアプリケーションサーバが広く活用されている。JAVA EEアプリケーションサーバは汎用的なソフトウェア仕様の集合であり、このJAVA EEアプリケーションを実装したアプリケーションサーバが、様々なベンダから提供されている。
【０００４】
これに対して、例えば、HTTP(HyperText Transfer Protocol)クライアントから送り込まれるHTTPリクエストに対する実行処理を抑制する手法として、ロードバランサやプロキシサーバが、HTTPリクエストを受け付け、当該HTTPリクエストに対する実行処理を一定の条件に基づいてHTTPサーバやアプリケーションサーバに振り分けることにより、リクエストに対する実行抑制を行う手法が考えられる。
【０００５】
この関連技術として、代表サーバが、クライアントから送り込まれたHTTPリクエストの内容を解析すると共に、このHTTPリクエストに付加された情報に基づいてHTTPリクエストに対する実行処理の振り分け先であるコンテンツサーバを特定し、HTTPリクエストを特定されたコンテンツサーバに対してリダイレクションを行い、HTTPリクエストの振り分けを行う手法が開示されている(特許文献１)。
ここでは、HTTPリクエストの実行処理の振り分けを行うのに際して、HTTPリクエストが、リダイレクションによってクライアントに返されることにより、特定のHTTPリクエストの実行処理が抑制される。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００１−１０９６９４公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、上記特許文献１に開示された関連技術では、HTTPリクエストに応じた実行処理を行うサーバやアプリケーションで利用されるデータを、サーバやアプリケーションに対してエクスポートすると共に、実行処理の抑制判定の条件情報としてロードバランサやプロキシサーバ内に設定する必要が生じる。
【０００８】
又、この場合、ロードバランサやプロキシサーバの機器独自の言語で振り分け条件のロジックを作成する必要が生じるといった運用にあたっての煩雑で煩わしい作業が必要となるという不都合がある。
【０００９】
更に、一般的なWebシステムでは、認証サーバなどを利用した認証方式によって、システム利用者のシステムへのアクセス権限などを一元的に管理している。この場合、システム内に設定された個々のアプリケーション毎の利用制限など利用者やアプリケーションに応じた柔軟な利用制限を設定することが困難となる不都合がある。
【００１０】
［発明の目的］
本発明は、上記従来例の有する不都合を改善し、利用者からの要求に対する実行処理にかかる負荷を有効に軽減する要求処理システム、要求処理方法、および要求処理プログラムを提供することを、その目的とする。
【課題を解決するための手段】
【００１１】
上記目的を達成するために、本発明に係る要求処理システムは、クライアントから送り込まれた要求情報を受信する入出力応答処理部と、予め設定されたアプリケーションに基づき前記要求情報に応じた実行処理を行うアプリケーションサーバ部とを有する要求処理システムであって、前記アプリケーションサーバ部が、前記要求情報のプロパティ情報に基づき前記要求情報の送信元を特定すると共に当該特定された送信元に基づき前記実行処理を抑制するか否かの判定を行うと共に予め設定された送信元の要求情報に対する実行処理を抑制する実行抑制判定手段を備え、前記入出力応答処理部が、前記実行処理が抑制される場合に、前記実行処理の抑制状態を前記クライアントに通知する抑制状態通知手段を備えた構成をとっている。
【００１２】
又、本発明にかかる要求処理方法は、クライアントとの相互通信を行う入出力応答処理部と、前記クライアントから送り込まれた処理要求情報に応じて実行処理を行うアプリケーションサーバ部とを備え、前記実行処理を制御する要求処理方法において、前記クライアントから送り込まれた処理要求を受信し当該処理要求を解析する要求解析行程と、前記処理要求の送信元を特定する送信元特定行程と、前記処理要求に応じた実行処理を行うか否かの判定を行う実行処理判定行程と、前記特定された送信元が実行処理の抑制対象である場合に、前記送信元に対して前記実行処理の抑制状態を通知する実行抑制通知行程と、を備えたことを特徴としている。
【００１３】
更に、本発明にかかる要求処理プログラムは、クライアントとの相互通信を行う入出力応答処理部と、前記クライアントから送り込まれた処理要求情報に応じて実行処理を行うアプリケーションサーバ部とを備え、前記実行処理を制御するための要求処理プログラムにおいて、前記クライアントから送り込まれた処理要求を受信し当該処理要求を解析する要求解析機能と、前記処理要求の送信元を特定する送信元特定機能と、前記処理要求に応じた実行処理を行うか否かの判定を行う実行処理判定機能と、前記特定された送信元が実行処理の抑制対象である場合に、前記送信元に対して前記実行処理の抑制状態を通知する実行抑制通知機能と、をコンピュータに実行させることを特徴としている。
【発明の効果】
【００１４】
本発明は、以上のように構成され機能するので、これによると、クライアントから送り込まれた処理要求情報に応じた実行処理を行うアプリケーションサーバが、処理要求情報に含まれるプロパティ情報に基づき実行処理を抑制するか否かの判定を行う手段を備えた構成としたことにより、クライアントからの要求に応じた実行処理にかかる処理負荷を軽減し、且つ特定のクライアントに対する要求実行処理を有効に抑制制御することができる要求処理システム、要求処理方法、および要求処理プログラムを提供することができる。
【図面の簡単な説明】
【００１５】
【図１】本発明による要求処理システムの一実施形態を示す概略ブロック図である。
【図２】図１に開示した要求処理システムにおけるHTTPリクエストハンドリング制御部１２０で抑制対象判定が行われる場合の動作処理ステップを示したシーケンスチャートである。
【図３】図１に開示した要求処理システムにおけるJNDI lookup制御部１５０で抑制対象判定が行われる場合の動作処理ステップを示したシーケンスチャートである。
【図４】図１に開示した要求処理システムにおけるHTTPリクエストハンドリング制御部１２０で抑制対象判定が行われる場合の動作処理ステップを示したシーケンスチャートである。
【図５】図１に開示した要求処理システムにおけるRMI over IIOPハンドリング制御部１８０で抑制対象判定が行われる場合の動作処理ステップを示したシーケンスチャートである。
【図６】図１に開示した要求処理システムにおける抑制対象判定の動作処理ステップを示したフローチャートである。
【図７】図１に開示した要求処理システムにおける実行抑制判定条件テーブルの一例を示す説明図である。
【図８】図１に開示した要求処理システムにおけるテーブル情報管理部の一実施形態を示す概略ブロック図である。
【図９】図１に開示した要求処理システムにおけるテーブル情報管理部の一実施形態を示す概略ブロック図である。
【図１０】図１に開示した要求処理システムにおけるテーブル情報管理部の一実施形態を示す概略ブロック図である。
【図１１】図１に開示した要求処理システムにおける実行抑制判定情報テーブルの初期化動作の処理ステップを示すフローチャートである。
【図１２】図１に開示した要求処理システムにおける実行抑制判定情報テーブルの更新処理の動作ステップを示すフローチャートである。
【図１３】図１に開示した要求処理システムにおける実行抑制判定の動作処理ステップを示すフローチャートである。
【図１４】図１に開示した要求処理システムにおける実行抑制判定の動作処理ステップを示すフローチャートである。
【発明を実施するための形態】
【００１６】
［実施形態］
次に、本発明の実施形態について、その基本的構成内容を説明する。
【００１７】
本実施形態の要求処理システムは、図１に示すように、WebシステムクライアントであるHTTPクライアント１０と、ネットワーク５を介して送り込まれた要求に対して要求レスポンスを行うJAVA EE(Enterprise Edition)アプリケーションサーバ(以下「JAVA EEサーバ」という)１００を備えたサーバ装置１と、このJAVA EEサーバ１００に接続されRMIクライアントとしてRMI-IIOP(Remote Method Invocation over Internet Inter ORB Protocol)によりメソッドの呼出を行うRMIクライアント３０を備えた構成となっている。
【００１８】
尚、上記サーバ装置１は、プログラム制御により動作する中央演算装置(CPU)と、このCPUを制御するプログラムとプログラムが制御するデータを保持するメモリと、電源断の場合でも永続的にプログラムとデータを保持する記憶装置とを少なくとも備え、上記JAVA EEサーバ１００は、上記メモリおよび記憶装置内に実行可能に展開されたアプリケーションプログラム(業務アプリケーション)に基づき上記CPUが実行処理を行うことにより設定される。
【００１９】
又、サーバ装置１内で動作するJAVA EEサーバ１００は、JAVA Enterprise Editionに準拠し動作するJAVA EEアプリケーションサーバであって、当該JAVA EEサーバ１００上で接続処理を管理するオブジェクトであるセッションオブジェクト１１０と、HTTPクライアントからのHTTPリクエストをハンドリング処理するHTTPリクエストハンドリング制御部１２０と、このHTTPリクエストハンドリング制御部１２０にポリシー条件を入力する利用者振り分けポリシー設定部１３０とを備えている。
【００２０】
又、JAVA EEサーバ１００は、アプリケーション実行制御情報１４０と、JNDI(JAVA Naming and Directory Interface) lookupハンドリング制御部１５０、RMI over IIOP呼び出し制御１７０と、RMI over IIOPハンドリング制御１８０を提供し(呼び出し)、HTTPクライアント１０およびRMIクライアント３０からの要求情報に応じて、予め設定されたWebアプリケーションプログラムモジュール２１０，２３０と、EJBアプリケーションプログラムモジュール２２０，２４０の実行処理を行う構成となっている。
【００２１】
以下、これを詳説する。
【００２２】
JAVA EEサーバ１００内は、Enterprise JAVABeans(EJB)に準拠してWebコンテナ、EJBコンテナ、およびJNDIサーバを設定し、メソッドの呼び出しやEnterprise Beanのインスタンス生成などを行い、JAVA EEサーバ１００内に設定されたEJBアプリケーションの実行を制御する。
【００２３】
Webコンテナは、JAVA EEサーバ１００により設定され、Webアプリケーションモジュール２１０，２３０を監視する。
又、Webコンテナは、Webアプリケーションモジュール２１０，２３０に対して共通に働くサーブレットフィルタ相当の機能（以下「コンテナフィルタ機能」を備えている。
【００２４】
更に、Webコンテナは、上記コンテナフィルタ機能を実行することにより、当該Webコンテナに対して送り込まれたHTTPリクエストをハンドリングし、当該HTTPリクエストにプロパティ情報（KEY=VALUE形式のキーと値が対となる情報）が含まれている場合に、予め設定されたテーブル情報としての実行抑制判定情報テーブル(図７：抑制判定条件)に基づきプロパティ情報の一致の可否を判定する機能と、実行抑制状態を通知するWebアプリケーションモジュールにHTTPリクエストを転送するリクエスト転送機能を備えている。
これにより、Webコンテナは、例えばHTTPクライアント１０から要求されたWebアプリケーションモジュールの実行を抑制すると共に、この実行処理抑制状態をHTTPクライアント１０に通知することができる。
【００２５】
又、Webコンテナは、JAVA EE仕様に基づき、インターフェースを実装したクラスを実行するクラス実行機能を有し、サーバ装置１の利用者からの要求に応じて実行処理の抑制判定条件のカスタマイズを行うことを可能とする。
【００２６】
HTTPクライアント１０は、Webアプリケーションの呼出し要求を行うクライアントプログラムであって、ネットワーク５を介してJAVA EEサーバ１００に対してHTTPリクエストを送信するHTTP要求送信機能を備えている。HTTPクライアント１０は、一般的には、Webブラウザなどにより実現される。尚、本実施形態では、HTTPクライアント１０は、ネットワーク５に１つ接続されているが、複数接続され実行されてもよい。
【００２７】
RMIクライアント３０は、EJB呼び出し要求を行うクライアントプログラムであって、ネットワーク５を介してJAVA EEサーバ１００に対してRMIリクエストを送信するRMI要求送信機能を有する。
尚、RMIクライアント３０としては、JAVA EEアプリケーションサーバプログラム以外のStand Alone JAVA Applicationや.NetアプリケーションなどからのEJBメソッド呼び出し要求を行うプログラム全般を想定している。
【００２８】
セッションオブジェクト１１０は、JAVA EEサーバ１００がHTTPクライアント１０から送り込まれる初回のHTTPリクエストを受信したときに生成され、クライアント(HTTPクライアント)とサーバ(サーバ装置１０)間の接続を表すオブジェクトである。
【００２９】
HTTPリクエストハンドリング制御部１２０は、JAVA EEサーバ１００起動時にアプリケーションサーバプログラムの起動時処理として実行され、起動完了後は、HTTPリクエストがJAVA EEサーバ１００に送り込まれる毎にHTTPリクエストを引数に指定されたメソッドを呼び出す機能を備えている。
又、HTTPリクエストハンドリング制御部１２０は、HTTPリクエストにおけるデータのヘッダであるHTTPヘッダ情報や、JAVA EEサーバ１００により実行される業務アプリケーションが定常的に参照、更新するデータを利用することができる。
このため、HTTPリクエストハンドリング制御部１２０は、業務データに応じたリクエストに対する実行処理の実行抑制処理を行うことができる。
【００３０】
利用者振り分けポリシー設定部１３０は、HTTPリクエストハンドリング制御部１２０から呼び出され、HTTPリクエストハンドリング制御部１２０が取得したHTTPリクエストオブジェクトを受け取る機能を有する。
【００３１】
アプリケーション実行制御情報１４０は、サーバ装置１のメモリ上に展開されたインスタンスデータであって、JNDI lookupハンドリング制御部１５０、およびRMI over IIOPハンドリング制御部１８０が扱うデータおよび操作メソッドの集合情報である。
【００３２】
JNDI lookupハンドリング制御部(以下「JNDI lookup制御部」という)１５０は、JAVA Naming and Directory Interface(JNDI)の実装であり、EJB(Enterprise JAVABeans)が呼び出されたときにEJBクライアントが取得するInitialContextのFactoryクラスを提供する機能を備えている。
又、JNDI lookup制御部１５０は、JNDIクライアントからのlookupメソッドに指定されたJNDI名、名前オブジェクト、および、InitialContext生成時に指定されたプロパティ情報に基づき、抑制対象か否かの判定を行う抑制対象判定機能を有する。
ここで、抑制対象と判定された場合には、所定の例外をEJBクライアントに対し送信する。
更に、JNDI lookup制御部１５０は、抑制対象外と判定されたクライアントからのlookupメソッドについては、その処理をJAVA EEサーバ１００が管理するJNDIサーバに委譲する機能を備えている。
【００３３】
ここで、予め設定されたEJBクライアント(Webアプリケーション２１０，２３０)はJNDI lookup制御部１５０を介してContextオブジェクトを取得する機能を有する。
又、JNDI lookup制御部１５０は、JNDIクライアントからのlookupメソッドに指定されたJNDI名、名前オブジェクト、およびInitialContext生成時に指定された任意のプロパティ情報に基づいて、抑制対象か否かの判定を行う抑制対象判定機能を備えている。
【００３４】
ここで、JNDI lookup制御部１５０は、JNDIクライアントが抑制対象と判定された場合、エラー通知(例外情報)をEJBクライアントとしてのWebアプリケーション２１０，２３０に対して送信する例外情報送信機能を備えている。
これにより、EJBクライアントからのJNDI lookup制御部１５０での実行抑制を行うことができる。
【００３５】
又、JNDI lookup制御部１５０は、lookupメソッドでインターフェースを実装したクラスを実行するクラス実行機能を有すると共に、利用者によりクラスの設定が変更されることにより、実行抑制判定条件のカスタマイズを行うことができる。又、InitialContext生成時に指定されるマップオブジェクトに含まれるシリアライザブルな業務データに応じた判定ロジックを実装することも可能である。
【００３６】
利用者振り分けポリシー設定部１６０は、JNDI lookupハンドリング制御部１５０によって呼び出され、JNDI lookupハンドリング制御１５０が取得した利用者プロパティ情報を含んだマップオブジェクトを受け取る機能を有する。
【００３７】
RMI over IIOP呼び出し制御部１７０は、JAVA EEサーバ１００により提供され、RMIクライアント３０を含みクライアントからのRMIリクエストを受け取ると共に、RMI仕様に基づきリモートオブジェクトのメソッド呼び出しを行う機能を備えている。
又、RMI over IIOP呼び出し制御部１７０は、リモートメソッドの呼び出しを行うに際してServerRequestInterceptorの実装クラスであるRMI over IIOPハンドリング制御１８０のメソッド呼び出しを行う機能を備えている。
【００３８】
RMI over IIOPハンドリング制御部１８０は、ServerRequestInterceptorインターフェースの実装クラスであって、EJBメソッドの呼び出しが行われる毎にリクエストオブジェクトを引数に取るメソッドが呼出される。
又、RMI over IIOPハンドリング制御部１８０は、呼出されたメソッド内でリクエストオブジェクトの解析を行い、プロパティ情報に基づいてリクエストオブジェクトの要求元が抑制対象か否かの判定を行う機能を備えている。
ここで、上記要求元が抑制対象と判定された場合には、例外情報(CORBA例外)をRMIクライアントに対して返す(送信する)例外情報送信機能を有する。
【００３９】
RMI over IIOPハンドリング制御部１８０は、RMI over IIOPを介して行われるEJBのメソッド呼出し要求の実行を抑制する、CORBA仕様に規定されたPortable InterceptorのJAVAにおけるインターフェースであって、org.omg.PortableInterceptor.ServerRequestInterceptor（以下「ServerRequestインターセプタ部」という）を利用して、EJBコンテナに送り込まれたEJBのメソッド呼び出し要求をハンドリングする。又、RMIリクエストに予め設定されたプロパティ情報が含まれている場合に、予め設定されたテーブル情報である実行抑制判定情報テーブル(抑制判定条件：図７)に基づきプロパティ情報が実行抑制条件に合致した場合には、以後のEJBメソッドの実行を抑制する機能を有する。
【００４０】
又、上記ServerRequestインターセプタ部は、RMIリクエストのハンドリング部で、インターフェースを実装したクラスを実行するクラス実行機能を有し、利用者によりクラスの設定が変更されることにより、実行抑制判定条件のカスタマイズを行うことができる。又、RMIリクエストに含まれるシリアライザブルな業務データに応じた判定ロジックの実装も可能である。
【００４１】
利用者振り分けポリシー設定部１９０は、RMI over IIOPハンドリング制御１８０から呼び出され、RMI over IIOPハンドリング制御１８０が取得した利用者プロパティを含むリクエストオブジェクトを受け取る機能を有する。
【００４２】
Webアプリケーションプログラムモジュール(以下「Webアプリケーションモジュール」という)２１０、および２３０は、JAVA EEサーバ１００上で実行可能な状態で設定され、JAVA EEアプリケーションサーバプログラムが管理するWebコンテナ内においてContext-pathによって一意にプログラムモジュールが特定される。
尚、Webアプリケーションプログラムモジュール２１０、および２３０は、HTTPクライアント１０からのHTTPリクエストに含まれるURIを元に、JAVA EEサーバ１００が該当するContext-pathを有するWebアプリケーションプログラムへの振り分けを行うことによって実行される。
【００４３】
EJBアプリケーションプログラムモジュール(以下「EJBアプリケーションモジュール」という)２２０、および、２４０は、JAVA EEサーバ１００上で実行可能な状態で設定され、JAVA EEアプリケーションサーバプログラムが管理するJNDIツリー内においてJNDI名によって一意にプログラムモジュールが特定される。
【００４４】
尚、EJBクライアントとして機能するRMIクライアント３０、Webアプリケーションプログラムモジュール２１０および２２０は、EJBアプリケーションモジュールを呼び出される際に、JNDIツリー構造にアクセスし、呼び出し対象のEJBアプリケーションプログラムモジュールのリモートオブジェクトを取得する機能と、このリモートオブジェクトを介してEJBアプリケーションモジュール２２０、２４０に備えられたメソッド呼び出し機能が実行される。
【００４５】
また、JAVA EEサーバ１００は、抑制対象判定を行う際に参照される実行抑制判定テーブル１０２の情報の管理を行い、初期化、および更新を実行する構成であるテーブル情報管理部を備えている。
【００４６】
以下、このテーブル情報管理部(実施形態Ａとする)について説明する。
テーブル情報管理部は、図８に示すように、アプリケーション実行プロセス内の任意のポイントで利用可能なAPI(Application Program Interface)として設定された実行抑制判定情報参照部１０１と、実行抑制判定に使用するキーワード情報等を含む実行抑制判定情報テーブル１０２を記憶する判定情報テーブル記憶手段と、実行抑制判定情報テーブル１０２が保持する情報をファイル情報(実行抑制判定情報永続化情報)として記憶する永続化情報記憶手段１０３と、実行抑制判定情報テーブル１０２の情報の初期化および更新処理を実行する実行抑制判定情報管理部１０４と、後述する管理要求送信部１０７からの管理要求を受信すると共に受信した管理要求に基づき実行抑制判定情報管理部１０４の呼び出しを行う管理要求受信部１０５と、アプリケーション実行プロセス起動時に実行抑制判定情報管理部１０４および管理要求受信部１０５の起動設定を行う初期化部１０６と、実行抑制判定情報入力部１０８を介して送り込まれた登録情報、および管理要求を管理要求受信部に対して送信する管理要求送信部１０７と、外部から送り込まれた実行抑制判定情報テーブル１０２に登録される情報(登録情報)や、実行抑制判定情報テーブル１０２内の情報の参照および更新を要求するメッセージを示す管理要求を、管理要求送信部１０７に対して入力する実行抑制判定情報入力部１０８を備えた構成となっている。
【００４７】
尚、実行抑制判定情報テーブル１０２は、Java EEサーバ１００上で動作するアプリケーションと同一のｊａｖａメモリ内に読み込まれ、かつ、ＨａｓｈＭａｐとして実装されているものとする。これにより、実行抑制判定情報参照部１０１の処理動作を迅速化することが可能となる。
【００４８】
また、実行抑制判定情報参照部１０１は、上述のように、アプリケーション内の任意のポイントで利用可能なＡＰＩとして提供され、実行抑制判定情報テーブル102の参照を行い、予め引数として設定されたキーワードと一致するキーワードが存在するか否かの判定を行う。
【００４９】
永続化情報記憶手段１０３は、実行抑制判定情報テーブル１０２が保持する情報をファイル情報(実行抑制判定情報永続化情報)として記憶する。これにより、ＪＡＶＡ  ＥＥ  アプリケーションサーバ１００のｊａｖａプロセスが、正常または異常終了した後、再起動された場合でも、javaプロセス終了以前の実行抑制判定情報テーブル内の情報を保持することができる。
【００５０】
実行抑制判定情報入力部１０８は、外部からＪＡＶＡ  ＥＥ  アプリケーションサーバ１００に対して送り込まれた登録情報、および管理要求、および、ＪＡＶＡ  ＥＥ  アプリケーションサーバ１００内に設定されたＷｅｂコンテナから送り込まれた登録情報、および管理要求を受信し、管理要求送信部１０７に対する入力を行う。
【００５１】
また、実行抑制判定情報テーブルを更新、管理するための実行抑制判定情報管理部１０４、および、管理要求送受信部１０５が実装されていることにより、ＪＡＶＡ  ＥＥ  アプリケーションサーバ１００の利用者は実行抑制制御の本質部である、実行抑制判定を行う箇所と実行抑制判定に使用する文字列の設計に注力することができる。
【００５２】
次に、上記テーブル情報管理部の動作について、図１１〜１３に示すフローチャートに基づき説明する。
【００５３】
始めに、実行抑制判定情報テーブル１０２の初期化を行う動作について、図１１のフローチャートに基づき説明する。
【００５４】
まず、Java EEサーバ１００におけるアプリケーション実行プロセス起動時に、初期化部１０６が実行される（ステップＳ２２１）、ここで、初期化部106は、実行抑制判定情報管理部１０４の初期動作設定を行う（ステップＳ２２２）。
【００５５】
ここで、予め実行抑制判定情報管理部１０４が実行抑制判定情報テーブル１０２の保持情報をファイル情報として永続化情報記憶手段１０３に対して格納してある場合、永続化情報記憶手段１０３には、実行抑制判定情報永続化情報利用フラグがセットされる。
【００５６】
次いで、実行抑制判定情報管理部１０４は、永続化情報記憶手段１０３における実行抑制判定情報永続化情報の存在確認を行う（ステップＳ２２３）と共に、実行抑制判定情報永続化情報が存在し、かつ、初期化時の実行抑制判定情報永続化情報利用フラグがセットされている場合（ステップＳ２２４）に、実行抑制判定情報永続化情報に含まれる情報を使用して、実行抑制判定情報テーブル１０２の初期化処理を行う（ステップＳ２２５）。
【００５７】
一方、実行抑制判定情報永続化情報１０３が存在していない、または、初期化時の実行抑制判定情報永続化情報利用フラグがセットされていない場合、実行抑制判定情報管理部104は、実行抑制判定情報テーブル１０２を空の状態(保持データ無し)で初期化する（ステップＳ２２６）。
【００５８】
これにより、実行抑制判定情報テーブル１０２は実行抑制判定情報参照部１０１から参照可能な状態に設定される。
【００５９】
また、アプリケーション実行プロセスにより初期化部１０６が呼び出された時点（ステップＳ２２１）で、初期化部１０６は、管理要求受信部１０５を動作起動状態に設定する（ステップＳ２２７）。管理要求受信部１０５は、アプリケーション実行プロセス内に存在し、管理要求の受信待ち状態となる（ステップＳ２２８）。
【００６０】
次に、実行抑制判定情報テーブル１０２の更新処理を行う動作について、図５のフローチャートに基づき説明する。
実行抑制判定情報テーブル１０２の情報の更新を行う場合、まず、実行抑制判定情報テーブル１０２への入力情報として管理要求の送信先、および、管理要求の送信先との接続権限情報が管理要求送信部１０７に対して入力される（ステップＳ３０１）。
尚、上記管理要求送信部１０７に対する入力情報の入力は、ＪＡＶＡ  ＥＥ  アプリケーションサーバのオペレータにより行われる設定であってもよい。
次いで、管理要求送信部１０７は、管理要求の送信先との接続を、接続権限情報を使用して行う（ステップＳ３０２）。
【００６１】
また、管理要求送信部１０７は、管理要求受信部１０５を呼び出し（ステップＳ３０３）、管理要求受信部１０５は、実行抑制判定情報管理部１０４を呼び出し、実行抑制判定情報テーブル１０２の更新要求を行う（ステップＳ３０４）。
ここで、実行抑制判定情報永続化フラグがセットされている場合(ステップＳ３０５：ＹＥＳ)、実行抑制判定情報管理部１０４は、更新情報を実行抑制判定情報永続化情報１０３に反映する（ステップＳ３０６）。
また、実行抑制判定情報管理部１０４は、更新情報を実行抑制判定情報テーブル１０２に反映する（ステップＳ３０７）。次いで、実行抑制判定情報管理部１０４は、実行抑制判定情報の更新処理結果を、管理要求受信部１０５を介して管理要求送信部１０７に返す（ステップＳ３０８）。
【００６２】
次に、実行抑制判定情報参照部１０１により行われる実行抑制判定の動作フローについて、図１３のフローチャートに基づき説明する。
【００６３】
まず、実行抑制判定情報参照部１０１は、ＨＴＴＰリクエストハンドリング制御部１２０、ＪＮＤＩ  ｌｏｏｋｕｐ  ハンドリング制御部１５０、またはＲＭＩ  ｏｖｅｒ  ＩＩＯＰハンドリング制御部１８０から実行制御判定に使用するキーワードを指定され呼び出される（ステップＳ４０１）。
次いで、実行抑制判定情報参照部１０１は、実行抑制判定情報テーブル102を参照し、実行抑制判定情報参照部１０１の引数に指定されたキーワードと一致するキーワードが存在するか否かを確認する（ステップＳ４０２）。一致するキーワードが実行抑制判定情報テーブル102に含まれる場合(ステップＳ４０３：ＹＥＳ)、実行抑制判定情報参照部１０１は、実行抑制状態であると判定し呼び出し元に、その判定結果(true)を返す（ステップＳ４０４）。
【００６４】
一方、一致するキーワードが実行抑制判定情報テーブル１０２に含まれない場合、実行抑制判定情報参照部１０１は、実行抑制状態ではないと判定し呼び出し元に、その判定結果を返す（ステップＳ４０５）。
【００６５】
［テーブル情報管理部の他の実施形態］
次に、テーブル情報管理部の他の実施形態(実施形態Ｂとする)について説明する。
【００６６】
本実施形態のテーブル情報管理部(実施形態Ｂ)は、上記実施形態とほぼ同様の構成を有するが、図９に示すように、上記実行抑制判定情報参照部１０１、実行抑制判定情報テーブル１０２と、実行抑制判定情報管理部１０４と、管理要求受信部１０５、および初期化部１０６を内部構成として有するJava EEアプリケーションサーバのjavaプロセス２００を備えた点が異なる。他の構成については上記実施形態と同様であり、前述したテーブル情報管理部の実施形態Ａと同一の部分については、同一の符号を付するものとする。
【００６７】
実行抑制判定情報参照部１０１は、Java EEアプリケーションサーバ１００内に設定されたアプリケーションにおける実行プロセスの任意のポイントで利用可能なAPIとして提供される。
【００６８】
実行抑制判定情報テーブル１０２は、実行抑制判定に使用するキーワード情報を含むものである。ここでは表記の便宜上テーブルとしているが、データベース上のテーブル情報とは異なるものであり、本実施形態ではHashMapとして実装され、Java EEアプリケーションサーバ１００のjavaプロセスのメモリ内に展開されているものとする。
【００６９】
実行抑制判定情報永続化情報１０３は、実行抑制判定情報テーブル１０２が保持する情報を永続化したデータ情報であって、通常のファイルデータとして設定される。
実行抑制判定情報管理部１０４は、上記実施形態Ａと同様に、実行抑制判定情報テーブル１０４のコントローラである。
【００７０】
管理要求受信部１０５は、管理要求送信部１０７からの管理要求を受信し、受信した管理要求を元に、実行抑制判定情報管理部１０４を呼び出す。本実施形態では、Ｊａｖａ  ＥＥのＪＭＸ仕様に準拠した管理オブジェクトとして実装される。Socketを使用した独自の通信方式として実装されていてもよい。
【００７１】
初期化部１０６は、Java EEアプリケーションサーバ１００のjavaプロセス起動時に、Java EEアプリケーションサーバ１００により呼び出される起動時の初期化処理を実行する。
管理要求送信部１０７は、実行抑制判定情報テーブル１０２の情報の参照、更新といった、管理要求を送信するものである。本実施例では、JMXクライアントプログラムとして実装されている。Socketを使用した独自の通信方式の実装も考えられる。
【００７２】
実行抑制判定情報入力部１０８は、実行抑制判定情報テーブル１０２へ登録する情報を入力するものである。本実施形態Ｂでは、コマンドとして実装されている。
次に、図１１から図１３のフローチャートを参照して本実施形態Ｂの動作について詳細に説明する。
【００７３】
始めに、Java EEアプリケーションサーバのjavaプロセス起動時に実行される、実行抑制判定情報テーブル１０２の初期化処理に関する処理フローについて、図４のフローチャートに基づき説明する。
【００７４】
まず、Java EEアプリケーションサーバ１００により初期化部１０６が呼び出され（ステップＳ２２１）、初期化部１０６は、実行抑制判定情報管理部１０４の起動設定を行う（ステップＳ２２２）。
実行抑制判定情報管理部１０４は、実行抑制判定情報永続化情報の存在確認を行い（ステップＳ２２３）、永続化情報記憶手段１０３に実行抑制判定情報永続化情報が存在し、かつ、初期化時の実行抑制判定情報永続化情報利用フラグがセットされている場合（ステップＳ２２４）に、実行抑制判定情報永続化情報１０３に含まれる情報を使用して実行抑制判定情報テーブル１０２の初期化処理を行う（ステップＳ２２５）。
一方、実行抑制判定情報永続化情報１０３が存在していない、または、初期化時の実行抑制判定情報永続化情報利用フラグがセットされていない場合、実行抑制判定情報管理部１０４は、実行抑制判定情報テーブル１０２を空の状態で初期化する（ステップＳ２２６）。
これにより、実行抑制判定情報テーブル１０２は実行抑制判定情報参照部１０１から参照可能な状態となる。
【００７５】
また、Java EEサーバ１００により初期化部１０６が呼び出されたときに（ステップＳ２２１）、初期化部１０６は、管理要求受信部１０５を生成する（ステップＳ２２７）。管理要求受信部１０５は、Java EEアプリケーションサーバのjavaプロセス内に存在し、管理要求の受信待ち状態となる（ステップＳ２２８）。
【００７６】
次に、実行抑制判定情報テーブル１０２の更新処理を行う動作について、図１２のフローチャートに基づき説明する。
【００７７】
実行抑制判定情報テーブル１０２を更新する場合、オペレータが実行抑制判定情報テーブルへの入力情報を管理要求の送信先、および、管理要求の送信先との接続権限情報を、入力する（ステップＳ３０１）。管理要求送信部１０７は、管理要求の送信先との接続を、接続権限情報を使用して行う（ステップＳ３０２）。管理要求送信部１０７は、管理要求受信部１０５を呼び出し（ステップＳ３０３）、管理要求受信部１０５は、実行抑制判定情報管理部１０４を呼び出し、実行抑制判定情報テーブル１０２の更新要求を行う（ステップＳ３０４）。
実行抑制判定情報永続化フラグがセットされている場合、実行抑制判定情報管理部１０４は、更新情報を実行抑制判定情報永続化情報に反映する（ステップＳ３０６）。
実行抑制判定情報管理部１０４は、更新情報を実行抑制判定情報テーブル１０２に反映する（ステップＳ３０７）。実行抑制判定情報管理部１０４は、実行抑制判定情報の更新処理結果を、管理要求受信部１０５を通じて、管理要求送信部１０７に返す（ステップＳ３０８）。
【００７８】
次に、実行抑制判定情報参照部１０１により行われる実行抑制判定の動作フローについて、図１３のフローチャートに基づき説明する。
【００７９】
実行抑制判定情報参照部１０１は、引数に文字列であるキーワードを指定して呼び出される（ステップＳ４０１）。実行抑制判定情報参照部１０１は、実行抑制判定情報テーブル１０２を参照し、実行抑制判定情報参照部１０１の引数に指定された文字列と一致する文字列が存在するか否かを確認する（ステップＳ４０２）。
一致する文字列が実行抑制判定情報テーブル１０１に含まれる場合、実行抑制判定情報参照部１０１は、実行抑制状態であると判定し呼び出し元にtrueを返す（ステップＳ４０３）。
【００８０】
一方、一致する文字列が実行抑制判定情報テーブル１０２に含まれない場合、実行抑制判定情報参照部１０１は、実行抑制状態ではないと判定し呼び出し元にfalseを返す（ステップＳ４０４）。
【００８１】
次に、上記テーブル情報管理部の他の実施形態(実施形態Ｃとする)について説明する。
テーブル情報管理部の本実施形態Ｃは、図１０に示すように、実施形態ＢにおけるJava EEアプリケーションサーバのjavaプロセス２００(以下「javaプロセス２００」という)を備えると共に、このjavaプロセス２００内に、管理要求受信部１０５に接続され管理要求をjavaプロセス２００の外部へと送信する管理要求送信部３０９が設けられている。
また、Java EEサーバのjavaプロセス２００とほぼ同様の内部構成を有するJava EEサーバのjavaプロセス３００をjavaプロセス２００に併設すると共に、このjavaプロセス３００に接続して設けられた永続化情報記憶手段３１３を有する点が、上述した実施形態Ｂと異なる。
【００８２】
Java EEサーバのjavaプロセス３００(以下「ｊａｖａプロセス３００」という)は、上記実行抑制判定情報参照部１０１、実行抑制判定情報テーブル１０２、実行抑制判定情報管理部１０４、管理要求受信部１０５、および初期化部１０６にそれぞれ対応して設けられた上記実行抑制判定情報参照部３１１、実行抑制判定情報テーブル３１２、実行抑制判定情報管理部３１４、管理要求受信部３１５、および初期化部３１６を内部構成として備えている。
また、管理要求受信部３１５は、上述した管理要求送信部３０９に接続されて設けられ、javaプロセス２００から送り込まれる管理要求などの情報を受信する構成となっている。
【００８３】
尚、この実施形態Ｃにおける他の構成については上記実施形態と同様であり、前述したテーブル情報管理部の実施形態ＡおよびＢと同一の部分については、同一の符号を付するものとする。
【００８４】
ここで、本実施形態Ｃは、複数の異なるjavaプロセス間で主従関係にある構成となっており、例えば、javaプロセス間は相互に遠隔地に設置されたサーバ上に設定され、通信回線で接続された構成としてもよい。
また、Java EEアプリケーションサーバのjavaプロセス２００とJava EEアプリケーションサーバのjavaプロセス３００とは、主と従の関係に設定されており、Java EEアプリケーションサーバのjavaプロセス３００はJava EEアプリケーションサーバのjavaプロセス２００の管理下にあるものとする。
【００８５】
尚、上記複数の異なるjavaプロセスは、異なるJava EEアプリケーションサーバ(Java EEサーバ)上で実行されていてもよい。
【００８６】
また、Java EEサーバのjavaプロセス２００はJava EEサーバのjavaプロセス３００の、属性情報を保持しており、Java EEサーバのjavaプロセス３００に対する操作は、Java EEサーバのjavaプロセス２００を介して実行することができる。
【００８７】
次に、実施形態Ｃにおける実行抑制判定情報テーブル１０２、および実行抑制判定情報テーブル３１２の更新処理について説明する。
【００８８】
まず、実行抑制判定情報テーブル１０２を更新する場合、オペレータが実行抑制判定情報テーブルへの入力情報を管理要求の送信先、および、管理要求の送信先との接続権限情報を入力する。
管理要求送信部１０７は、管理要求の送信先との接続を、接続権限情報を使用して行う。次いで、管理要求送信部１０７は、管理要求受信部１０５を呼び出し、管理要求受信部１０５は、実行抑制判定情報管理部１０４を呼び出し、実行抑制判定情報テーブル１０２の更新要求を行う。
この時、管理要求受信部１０５が受信した管理要求の送信先情報に、Java EEアプリケーションサーバのjavaプロセス２００の管理対象プロセスである、Java EEアプリケーションサーバのjavaプロセス３００が含まれている場合、管理要求受信部１０５は、管理要求送信部１０９を呼び出す。
管理要求送信部１０９は、管理要求受信部３１５を呼び出し、管理要求受信部３１５は、実行抑制判定情報管理部３１４を呼び出し、実行抑制判定情報テーブル３１２の更新要求を行う。
Java EEサーバのjavaプロセス２００に対して、実行抑制判定情報永続化フラグがセットされている場合、実行抑制判定情報管理部１０４は、更新情報を実行抑制判定情報永続化情報１０３に反映する。また、Java EEアプリケーションサーバのjavaプロセス３００に対して、実行抑制判定情報永続化フラグがセットされている場合、実行抑制判定情報管理部３１４は、更新情報を実行抑制判定情報永続化情報３１３に反映する。
次いで、実行抑制判定情報管理部１０４は、更新情報を実行抑制判定情報テーブル302に反映し、実行抑制判定情報管理部３１４は、更新情報を実行抑制判定情報テーブル３１２に反映する。
ここで、実行抑制判定情報管理部３１４は、実行抑制判定情報テーブル３１２の更新処理結果を、管理要求受信部３１５を介して、管理要求送信部１０９に返す。実行抑制判定情報管理部１０４は、実行抑制判定情報テーブル１０２、および実行抑制判定情報テーブル３１２の更新処理結果を、管理要求受信部１０５を介して、管理要求送信部１０７に返す。
【００８９】
次に、実行抑制判定情報参照部１０１、および３１１により行われる実行抑制判定の動作フローについて、図１４のフローチャートに基づき説明する。
尚、実行抑制判定情報参照部１０１、および３１１はそれぞれ同様の動作処理を行うが、ここでは、実行抑制判定情報参照部３１１の動作について、説明する。
【００９０】
実行抑制判定情報参照部３１１は、ＫＥＹ＝ＶＡＬＵＥのプロパティが指定されて呼び出される（ステップＳ５０１）。ここで、実行抑制判定情報参照部３１１は、実行抑制判定情報テーブル３１２を参照し、実行抑制判定情報参照部３１１に指定されたＫＥＹと一致するエントリが存在するか否かを確認する（ステップＳ５０２）。
ここで、一致するエントリが実行抑制判定情報テーブル３１２に含まれる場合(ステップＳ５０３：ＹＥＳ)、実行抑制判定情報参照部３１１は、エントリにＶＡＬＵＥに一致する値が含まれているか否かの確認を行う(ステップＳ５０４)。
【００９１】
ここで、エントリにＶＡＬＵＥに一致する値が含まれている場合(ステップＳ５０５：ＹＥＳ)、実行抑制判定情報参照部３１１は、実行抑制状態であると判定し、呼び出し元に対してtrueを返す（ステップＳ５０６）。
【００９２】
一方、ステップＳ５０３で一致するエントリが実行抑制判定情報テーブル３１２に含まれていない場合、またはステップＳ５０５で、エントリにＶＡＬＵＥに一致する値が含まれていない場合、実行抑制判定情報参照部３１１は、呼び出し元を実行抑制状態ではないと判定、つまり、実行抑制対象外であると判定し、呼び出し元にfalseを返す（ステップＳ５０７）。
尚、上述のように、実行抑制が行なわれる場合、Java EEサーバのjavaプロセスが管理要求送信部１０７に対してエラー通知を行う構成(エラー通知機能)としてもよい。
【００９３】
以上に示すようにテーブル情報管理部を構成することによって、JAVA EEアプリケーションサーバ１００の利用者は、実行抑制判定を行う箇所と実行抑制判定に使用する文字列の設計に注力することが可能となる。
【００９４】
［実施形態の動作説明］
次に、本実施形態の全体の動作について、説明する。
先ず、HTTPクライアント１０から送り込まれた処理要求を受信し当該処理要求を解析し(要求解析行程)、この処理要求の送信元を特定し(送信元特定行程)、処理要求に応じた実行処理を行うか否かの判定を行う(実行処理判定行程)。
次いで、特定された送信元が実行処理の抑制対象である場合に、前記送信元に対して前記実行処理の抑制状態をHTTPクライアント１０に通知する(実行抑制通知行程)。
【００９５】
ここで、上記要求解析行程、送信元特定行程、実行処理判定行程および実行抑制通知行程については、その実行内容をプログラム化し、コンピュータに実行させるように構成してもよい。
【００９６】
次に、上記実施形態のHTTPリクエストハンドリング制御部１２０において抑制対象判定が行われる場合の動作について図２のシーケンスチャートに基づいて説明する。
【００９７】
まず、HTTPクライアント１０が、JAVA EEアプリケーションサーバ１００に対して、Webアプリケーションモジュールの実行リクエストであるHTTPリクエストを送信する（ステップS１１）。
このHTTPリクエストをJAVA EEアプリケーションサーバ１００内で動作するWebコンテナが、受信する（ステップS２１）と共にHTTPハンドリング制御部１２０を呼び出す（ステップS２２）。
【００９８】
次いで、このHTTPハンドリング制御部１２０は、上記HTTPリクエストを解析（ステップS３１）すると共に、当該HTTPリクエストに予め設定されたプロパティ情報が含まれている場合に、HTTPリクエストの送信元がHTTPリクエストの実行抑制対象であるか否かを判定する処理を行う（ステップS３２）。
ここで、実行抑制対象ではないと判定された場合、HTTPハンドリング制御部１２０は、HTTPリクエストに対する実行処理制御をWebコンテナに戻す(ステップS３２：NO)。
【００９９】
次にWebコンテナは、HTTPリクエストに応じたWebアプリケーションモジュールを実行し（ステップS２３）、その処理結果をHTTPレスポンスとして、HTTPクライアントに返す（ステップS２４）。
【０１００】
一方、プロパティ情報に基づきHTTPリクエストの送信元が抑制対象であると判定された場合(ステップS３２：YES)、HTTPハンドリング制御部１２０は、予め設定された処理閉塞状態を通知するWebアプリケーションモジュール２１０にHTTPリクエストを転送する(Forward)と共に、WebコンテナにHTTPリクエストに対する実行処理制御を戻す（ステップS３３）。
【０１０１】
次いで、Webコンテナは、上記HTTPリクエストの転送先であるWebアプリケーションモジュール２１０を実行すると共に、その実行処理結果(処理抑制状態通知)をHTTPレスポンスとして、HTTPクライアント１０に送信する（ステップS２５）。
【０１０２】
上記実施形態のJNDI lookupハンドリング制御部１５０で抑制対象判定が行われる場合の動作について図３のシーケンスチャートに基づいて説明する。
【０１０３】
まず、EJB／JNDIクライアントとしてのWebアプリケーションモジュール２１０、２３０、又はRMIクライアント３０(ここでは総称として「lookupクライアント」という)が、JNDI lookupハンドリング制御１５０が提供するContextFactoryクラスをインスタンス化(生成)する(ステップS４１)と共に、FactoryクラスオブジェクトからJNDI lookupハンドリング制御１５０のInitialContextを取得する（ステップS４２）。
【０１０４】
lookupクライアントは、取得したInitialContextオブジェクトを介して呼び出し対象のEJBのHomeインターフェースにおけるJNDI名、または名前オブジェクトを指定してlookupメソッドを実行すると共にlookup要求を送信する（ステップS４３）。
【０１０５】
JNDI lookupハンドリング制御１５０は、lookupメソッドの実行により指定されたJNDI名、名前オブジェクト、および、InitialContext生成時にセットしたマップオブジェクトに格納されたプロパティ(負荷情報)に基づいて、送信されたlookup要求が抑制対象であるか否かの判定を行う（ステップS５１：抑制対象判定）。
【０１０６】
ここで、JNDI lookupハンドリング制御１５０は、上記lookup要求の送信元(lookupクライアント)が抑制対象と判定された場合(ステップS５１：YES)、lookupクライアントに対して予め設定された例外通知を返す（ステップS５２）。
【０１０７】
又、上記lookup要求の送信元(lookupクライアント)が抑制対象外であると判定された場合(ステップS５１：NO)、JNDI lookupハンドリング制御１５０はlookup要求の実行処理をJAVA EEサーバ１００内に予め設定されたJNDIサーバに委譲する（ステップS５３）。
【０１０８】
JNDIサーバは、lookupメソッド内に指定されたJNDI名または名前オブジェクトにマッピングされているEJB Homeインターフェースオブジェクトを、lookupクライアントに返す(ステップS６１)。
次いで、lookupクライアントは、取得したEJB Homeインターフェースオブジェクトを使用してEJBオブジェクトを取得すると共にEJBメソッド呼び出しを行う（ステップS４５）。
【０１０９】
次に、上記実施形態のRMI over IIOPハンドリング制御部１８０で抑制対象判定が行われる場合の動作について図４のシーケンスチャートに基づいて説明する。
【０１１０】
まず、lookupクライアントは、取得済みのEJBオブジェクトを介してRMIリクエストを送信することにより、EJBメソッドの呼び出しを行う（ステップS７１）。
次いで、RMI over IIOP通信制御部１７０が、EJBメソッド呼び出しのRMIリクエストを受信し、ServerRequestInterceptorの実装クラスであるRMI over IIOPハンドリング制御部１８０を呼び出す（ステップS８１）。
【０１１１】
RMI over IIOPハンドリング制御部１８０は、RMIリクエストに含まれるEJB JNDI名、メソッド名、プロパティに基づきEJBメソッド呼び出しのRMIリクエストが抑制対象から送信されたものであるか否かの判定(抑制対象判定)を行う（ステップS９１：実行抑制判定）。
【０１１２】
ここで、RMI over IIOPハンドリング制御部１８０は、EJBメソッド呼出しのRMIリクエストの送信元を抑制対象と判定した場合(ステップS９１：YES)、lookupクライアントに対して例外通知を返す（ステップS９２）。
また、RMI over IIOPハンドリング制御部１８０は、EJBメソッド呼出しのRMIリクエストの送信元が抑制対象外である場合に、RMIリクエストの実行処理をJAVA EEアプリケーションサーバ１００に予め設定されたEJBコンテナに委譲する(ステップS９１：NO)。
【０１１３】
次いで、EJBコンテナは、EJBメソッドを実行し、lookupクライアントに実行処理結果を返す(ステップS１０１)。EJBクライアントおよびJNDIクライアントは、EJBメソッド呼び出し結果を取得する（ステップS７３）。
【０１１４】
次に、上記実施形態の利用者振り分けポリシー設定部１３０に利用者振り分けポリシークラスが設定された場合に、HTTPリクエストハンドリング制御部１２０で抑制対象判定が行われる動作について図５のシーケンスチャートに基づいて説明する。
【０１１５】
まず、HTTPクライアント１０が、JAVA EEサーバ１００に対して、Webアプリケーションモジュール２１０又は２３０の実行リクエストであるHTTPリクエストを送信する（ステップS１１１）。
次いで、JAVA EEサーバ１００上で予め設定されたWebコンテナがHTTPリクエストを受信（ステップS１２１）し、HTTPハンドリング制御部１２０を呼び出す（ステップS１２２）。
【０１１６】
次いで、HTTPリクエストハンドリング制御部１２０は、利用者振り分けポリシー設定部１３０に予め設定されたインターフェースに実装された利用者振り分けポリシークラスがある場合に、当該インターフェースに基づいてHTTPリクエストを引数とする利用者振り分けポリシークラスのメソッドを呼び出す（ステップS１３１）。
【０１１７】
次いで、利用者振り分けポリシー設定部１３０クラス内では、送り込まれたHTTPリクエストを解析する（ステップS１４１）と共に、利用者独自の振り分けポリシーに基づき、HTTPリクエストの送信元(HTTPクライアント)が実行処理の抑制対象であるか否かの判定を行う。
ここで、実行処理の抑制対象と判定された場合には、抑制対象フラグをセットし（ステップS１４２）、HTTPリクエストハンドリング制御部１２０にHTTPリクエストに対する実行制御を戻す。
【０１１８】
次いで、HTTPリクエストハンドリング制御部１２０は、抑制対象フラグがセットされているか否かに基づき、抑制対象判定を行う（ステップS１３２：実行抑制判定）。
ここで、HTTPリクエストの送信元が抑制対象でない(抑制対象フラグがない)と判定された場合、HTTPリクエストハンドリング制御部１２０は、HTTPリクエストの実行制御をWebコンテナに戻す(ステップS１３２：NO)。
【０１１９】
WebコンテナはHTTPリクエストに応じたWebアプリケーションモジュールを実行（ステップS１２３）し、その実行処理結果を生成すると共にHTTPレスポンスとして、HTTPクライアント１０に送信し（ステップS１２４）、HTTPクライアント１０は、HTTPレスポンスを受信する(ステップS１１２)。
【０１２０】
ここで、HTTPリクエストの送信元が抑制対象である(抑制対象フラグがある)と判定された場合(ステップS１３２：YES)、HTTPリクエストハンドリング制御部１２０は、予め設定された実行処理閉塞状態を通知するWebアプリケーションモジュール２１０にHTTPリクエストを転送し(Forward)、WebアプリケーションモジュールがHTTPリクエストの実行制御をWebコンテナに戻す(ステップS１３３)。
【０１２１】
WebコンテナはForward先のWebアプリケーションモジュール２１０を実行すると共に、その処理結果をHTTPレスポンスとして、HTTPクライアント１０に返し（ステップS１２５）、HTTPクライアント１０は、HTTPレスポンス(抑制状態通知)を受信する(ステップS１１３)。
【０１２２】
尚、ここでは、利用者振り分けポリシー設定部１３０に利用者振り分けポリシークラスが設定された場合について説明したが、利用者振り分けポリシー設定部１６０、１９０利用者振り分けポリシークラスが設定された場合も、JNDI lookup制御部１５０、RMI over IIOPハンドリング制御部１８０でそれぞれ、同様にして、抑制対象判定が行われる。
【０１２３】
ここで、上記ステップS３２、S５１、S９１、およびS１３２における抑制対象判定の動作について図６のフローチャートに基づき説明する。
【０１２４】
先ず、送り込まれたHTTPリクエスト、lookup要求、又はRMIリクエスト(総称として要求情報という)が、実行抑制判定条件テーブル(図７)のアプリケーション名に含まれるアプリケーションに対する実行リクエストであるか否かの判定を行う(ステップS２０１)。
【０１２５】
ここで、要求情報が、実行抑制判定条件テーブルに含まれない実行リクエストである場合は、当該実行リクエストの送信元を非実行抑制対象として判定する(ステップS２０２)。
次いで、アプリケーション名に条件設定があるか否かを判定し(ステップS２０３)、条件設定がない場合は当該実行リクエストの送信元を実行抑制対象として判定する(ステップS２１０)。
【０１２６】
ここで、アプリケーション名に条件設定がある場合は、実行抑制判定条件テーブルに利用者(送信元)キーの設定があるか否かを判定し(ステップS２０４)、利用者キーの設定がある場合は、以降、抑制判定キーとして利用者キーを利用する(ステップS２０５)。また、実行抑制判定条件テーブルに利用者(送信元)キーの設定がない場合は、抑制判定キーとして予め設定されたデフォルトキーが利用される(ステップS２０６)。
【０１２７】
次いで、要求情報に抑制判定キーが含まれるか否かを判定し(ステップS２０７)、含まれない場合は当該要求情報の送信元を非実行抑制対象として判定する(ステップS２０８)。
また、要求情報に抑制判定キーが含まれる場合は、抑制判定キーに設定された値が、実行抑制判定条件テーブルに設定された抑制判定値と合致するか否かを判定し(ステップS２０９)、合致しない場合は、要求情報の送信元を非実行抑制対象として判定し(ステップS２０８)、合致する場合には、要求情報の送信元を実行抑制対象として判定する(ステップS２１０)。
【０１２８】
以上のように、本実施形態では、プロキシサーバなどの他の構成機器を利用することなく、サーバ上のアプリケーションに対する実行要求リクエストを抑制制御可能とする。
又、JAVA EEアプリケーションサーバ上に実装されたWebアプリケーションやEJBそれぞれにおける実行リクエスト(要求情報)に基づき迅速に要求元を特定することができ、このため、実行処理の迅速な抑制制御および抑制対象の変更を行うことができる。
【０１２９】
更に、JAVA EEアプリケーションサーバで実行される業務アプリケーションをEJBコンテナ上でハンドリング制御を行うため、JAVA EEアプリケーションサーバで利用可能なデータベーステーブルなどのリソースを通常のアプリケーションと同様に、実行抑制判定の実行に利用することができる。
【０１３０】
又、予め設定された業務アプリケーションの内部構造は、最小限のロジックの組み入れのみが可能な構造であり、アプリケーション外部に組み込む構造である。このため、JAVA EE標準に準拠した範囲で、JAVA EEアプリケーションサーバに実装されたアプリケーションに対しても、本発明に示される機構を組み込むことができる。
【０１３１】
更に、本実施形態により、各利用者や利用されるアプリケーションの要求に応じるために、JAVA EEアプリケーションサーバの運用システムでは、汎用的な仕様に基づいた標準機能に加えて、実行抑制対象を特定し、要求実行処理を限定する機能を付加することができ、また、利用者による設定により、特定される実行抑制条件を変更することができる。
【産業上の利用可能性】
【０１３２】
本発明は、特定の要求元およびアクセス元からのシステム利用一時制限を制御できるので、ネットワークを介するサービスにおけるサービス提供者から利用者に対する制裁処置としての利用制限制御に適用することができる。
又、サーバ側のシステムメンテナンスにおける特定の利用者群や、時間帯毎の一時的な実行抑制といった用途に適用可能である。
更に、サーバサイド処理の入り口出口情報に基づいて、JAVA EEアプリケーションサーバ上におけるHTTPリクエストに対する処理の性能情報を取得する手法としても適用することができる。
【符号の説明】
【０１３３】
１  サーバ装置
５  ネットワーク
１０  HTTPクライアント
３０  RMIクライアント
１００  JAVA EEアプリケーションサーバ
１１０  セッションオブジェクト
１２０  HTTPリクエストハンドリング制御部
１３０、１６０、１９０  利用者振り分けポリシー設定部
１４０  アプリケーション実行制御情報
１５０  JNDI lookupハンドリング制御部
１７０  RMI over IIOP呼び出し制御部
１８０  RMI over IIOPハンドリング制御部
２１０、２３０  Webアプリケーションモジュール
２２０、２４０  EJBアプリケーションモジュール
【図１】
2009187542.tif 000003
【図２】
2009187542.tif 000004
【図３】
2009187542.tif 000005
【図４】
2009187542.tif 000006
【図５】
2009187542.tif 000007
【図６】
2009187542.tif 000008
【図７】
2009187542.tif 000009
【図８】
2009187542.tif 000010
【図９】
2009187542.tif 000011
【図１０】
2009187542.tif 000012
【図１１】
2009187542.tif 000013
【図１２】
2009187542.tif 000014
【図１３】
2009187542.tif 000015
【図１４】
2009187542.tif 000016