資源管理プログラム、資源管理装置及び資源管理方法
【課題】Ｗｅｂサービスアプリケーションから複数のリクエストを受信したとしても、継続するリクエスト間で同一のスレッド資源を引き継ぐ。
【解決手段】Ｗｅｂサービスクライアントアプリケーション３ＡからＷｅｂサービスアプリケーション経由で手続型ＣＯＢＯＬアプリケーションに対する複数のリクエストを受信したとしても、リクエストに使用するセッションを識別するセッションＩＤでスレッド資源を資源管理部５３内で管理することで、資源管理部５３内に管理するセッションＩＤに対応したスレッド資源を使用して、継続するリクエスト間で同一のスレッド資源を引き継ぐことができる。
【解決手段】Ｗｅｂサービスクライアントアプリケーション３ＡからＷｅｂサービスアプリケーション経由で手続型ＣＯＢＯＬアプリケーションに対する複数のリクエストを受信したとしても、リクエストに使用するセッションを識別するセッションＩＤでスレッド資源を資源管理部５３内で管理することで、資源管理部５３内に管理するセッションＩＤに対応したスレッド資源を使用して、継続するリクエスト間で同一のスレッド資源を引き継ぐことができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、資源管理プログラム、資源管理装置及び資源管理方法に関する。
【背景技術】
【０００２】
一般的に企業の在庫管理や財務等の基幹業務を取り扱う基幹系システムでは、多くのサーバアプリケーションがＣＯＢＯＬ（Common Business Oriented Language）で開発されている。更に、近年では、ＷｅｂアプリケーションとしてＪａｖａ（登録商標）アプリケーションのクライアントからサーバ側の手続型のＣＯＢＯＬアプリケーションを呼び出す運用が多くみられる。
【０００３】
例えば、汎用的なＪａｖａＳｅｒｖｌｅｔが、Ｗｅｂブラウザからのリクエストに応じて、ユーザインタフェースＸＭＬソースに基づき、トランザクション処理システム配下のＣＯＢＯＬアプリケーションを呼び出すための電文を自動生成し、トランザクション処理システムで処理された結果を電文として受取り、該受取った電文をユーザインタフェースＸＭＬソースに基づいてＷｅｂブラウザ上で表示するＨＴＭＬを生成し、Ｗｅｂブラウザからの要求のレスポンスとして返送する技術が知られている（特許文献１）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特表２００１−５０９２８６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、従来のサーバでは、継続する複数のリクエストを受信したとしても、複数のリクエストに応じた手続型のアプリケーションの処理を同一スレッド上で実行できるとは限らない。その結果、従来のサーバでは、リクエスト毎に手続型のアプリケーションを実行するに際し、継続するリクエスト間で同一のスレッド資源を引き継ぐことができない。
【０００６】
開示技術は、上記点に鑑みてなされたものであり、セッションが異なる複数のリクエストを受信したとしても、継続するリクエスト間で同一のスレッド資源を引き継ぐことを目的とする。
【課題を解決するための手段】
【０００７】
本願の開示する資源管理プログラムは、一つの態様において、コンピュータに、手続型言語で記述されたプログラムで規定された処理であって、受信した処理要求に要求される処理をスレッドに割り当て、セッションを識別する識別情報とスレッド資源とを予め関連付けて記憶する記憶手段から、前記処理要求についての通信に使用されたセッションを識別する識別情報と関連付けられて記憶されたスレッド資源を読み出し、読み出した前記スレッド資源を用いて、前記スレッドに割り当てた前記処理を実行することを実行させた。
【発明の効果】
【０００８】
本願の一つの態様では、Ｗｅｂサービスアプリケーション等のクライアントから、異なるセッションで複数のリクエストを受信したとしても、継続するリクエスト間で同一のスレッド資源を引き継ぐことができる。
【図面の簡単な説明】
【０００９】
【図１】図１は、実施例１のサーバ装置の内部構成を示す説明図である。
【図２】図２は、実施例２のＷｅｂサービスアプリケーションの利用形態を示す説明図である。
【図３】図３は、Ｗｅｂサービスアプリケーション用サーバ装置の内部構成を示す説明図である。
【図４】図４は、資源管理部内部のテーブル構成を詳細に示す説明図である。
【図５】図５は、Ｗｅｂサービスアプリケーション用サーバ装置の動作を示す説明図である。
【図６】図６は、Ｗｅｂサービスアプリケーション用サーバ装置全体の処理動作を示すフローチャートである。
【図７】図７は、Ｗｅｂサービスアプリケーションの処理動作を示すフローチャートである。
【図８】図８は、手続型ＣＯＢＯＬアプリケーションの処理動作を示すフローチャートである。
【図９】図９は、ＲＴＳの処理動作を示すフローチャートである。
【図１０】図１０は、資源管理プログラムを実行するコンピュータを示す説明図である。
【図１１】図１１は、Ｗｅｂアプリケーションの利用形態を示す説明図である。
【図１２】図１２は、マルチスレッド方式のＷｅｂアプリケーションの利用形態を示す説明図である。
【図１３】図１３は、Ｗｅｂサービスアプリケーションの利用形態を示す説明図である。
【発明を実施するための形態】
【００１０】
本発明の実施形態を説明する前に、図１１〜図１３を用いて、Ｊａｖａアプリケーションが手続型のＣＯＢＯＬアプリケーションを呼び出す形態のＷｅｂアプリケーションについて説明する。
【００１１】
図１１は、Ｗｅｂアプリケーション用サーバ装置(以下、単にサーバと称する)１１０により実行されるソフトウェアの構造を示す。サーバ１１０では、Ｗｅｂブラウザ１２０からインターネット１３０経由のリクエストに応じて、ＣＯＢＯＬアプリケーション１１２を実行する。更に、サーバ１１０のＪａｖａアプリケーション１１１は、Ｗｅｂブラウザ１２０からインターネット１３０経由でリクエストを受信する。
【００１２】
サーバ１１０内のフレームワーク１１３は、Ｊａｖａアプリケーション１１１のリクエストをＣＯＢＯＬアプリケーション１１２のリクエストに変換する機能を備えたソフトウェアである。更に、サーバ１１０のＣＯＢＯＬアプリケーション１１２は、フレームワーク１１３で変換されたリクエストを受信すると、プロセス１１０Ａ上に単一のスレッド１１４及びＣＯＢＯＬランタイムシステム（COBOL Run Time System：以下、単にＲＴＳと称する）１１５を実行する。尚、ＲＴＳ１１５は、スレッド１１４上のＣＯＢＯＬアプリケーション１１２が利用するスレッド資源１１４Ａを作成し、このスレッド資源１１４Ａをスレッド１１４上のＣＯＢＯＬアプリケーション１１２に提供する。
【００１３】
スレッド資源１１４Ａには、データ、使用ファイルやＤＢコネクション等が含まれる。例示として、手続型のＣＯＢＯＬアプリケーション１１２が住所データに基づいて住所録を作成するプログラムであるとした場合、スレッド資源１１４Ａのデータは郵便番号、住所、電話番号などの格納位置及び読み取り位置などを指定するデータなどであり、使用ファイルとは、郵便番号、住所、電話番号などの住所データが列挙されたファイルなどであり、ＤＢコネクションは、使用ファイルを格納したＤＢへのコネクションに関する情報であって良い。
【００１４】
手続型言語で記述されたプログラムに基づく処理においては、記述された命令を逐次的に実行し、処理の結果に応じて変数の内容を変化させる。処理のリクエストが複数ある場合には、複数のリクエスト間で変数の内容が変化している可能性があり、そのためスレッド資源１１４Ａを引き継ぐ必要がある。
【００１５】
プロセス１１０Ａ上のスレッド１１４では、Ｗｅｂブラウザ１２０からのリクエストに応じて、ＲＴＳ１１５から取得したスレッド資源１１４Ａを使用してＣＯＢＯＬアプリケーション１１２を順次実行する。尚、ＣＯＢＯＬアプリケーション１１２が使用するスレッド資源１１４Ａはスレッド単位で管理される。従って、継続するリクエスト間で同一のスレッド資源１１４Ａを引き継ぐような場合には、全てのリクエストに関わるＣＯＢＯＬアプリケーションを同一のスレッド１１４上で実行する必要がある。サーバ１１０では、継続するリクエスト間で同一のスレッド資源１１４Ａを引き継ぐため、全てのリクエストに関わるＣＯＢＯＬアプリケーション１１２を単一のスレッド１１４上で実行する単一スレッド方式を採用している。
【００１６】
しかしながら、サーバ１１０の運用形態は、インターネット１３０を経由して複数のＷｅｂブラウザ１２０からのリクエストを受け付ける必要があるため、プロセス１１０Ａ上に複数のスレッド１１４を実行するマルチスレッド方式を採用するのが一般的である。
【００１７】
マルチスレッド方式を採用するシステムとして、継続するリクエスト間でスレッド資源の一部であるデータを引き継ぎ、この引き継いだデータをクライアント側やサーバ側で保持するシステムがある。図１２は、サーバ２１０により実行されるソフトウェアの構造を示す図である。尚、図１１に示す利用形態と同一構成には同一符号を付すことで、その重複する構成及び動作の説明については省略する。
【００１８】
図１２に示すサーバ２１０は、プロセス２１０Ａ上に複数のスレッド２１４を実行するマルチスレッド方式を採用している。更に、フレームワーク１１３Ａは、Ｊａｖａアプリケーション１１１を通じてＷｅｂブラウザ１２０からのリクエストを受信すると、複数のスレッド２１４の内、リクエストに応じたＣＯＢＯＬアプリケーション１１２を実行するスレッド２１４を割り当てる。そして、ＲＴＳ２１５は、スレッド２１４上のＣＯＢＯＬアプリケーション１１２で利用可能なスレッド資源２１４Ａを作成し、このスレッド資源２１４Ａを、ＣＯＢＯＬアプリケーション１１２を実行するスレッド２１４に提供する。
【００１９】
フレームワーク１１３Ａは、Ｗｅｂブラウザ１３０からのリクエスト“１”を受信した場合に、例えばＣＯＢＯＬアプリケーション１１２を実行するスレッド“Ｘ”を割り当てる。更に、ＲＴＳ２１５は、スレッド“Ｘ”上のＣＯＢＯＬアプリケーション１１２で利用するスレッド資源２１４Ａを作成し、このスレッド資源２１４Ａをスレッド“Ｘ”上のＣＯＢＯＬアプリケーション１１２に提供する。
【００２０】
更に、スレッド“Ｘ”上のＣＯＢＯＬアプリケーション１１２は、スレッド資源２１４Ａを使用してリクエスト“１”に関わる処理を実行し、データ“１”を得て、そのデータ“１”を含めてスレッド資源２１４Ａを更新する。そして、ＣＯＢＯＬアプリケーション１１２は、スレッド資源２１４Ａのうちのデータ“１”をＪａｖａアプリケーション１１１経由でＷｅｂブラウザ１２０に伝送する。
【００２１】
次に、Ｗｅｂブラウザ１２０は、リクエスト“１”に後続するリクエスト“２”を要求する際、リクエスト“２”の他に、データ“１”をＪａｖａアプリケーション１１１経由でフレームワーク１１３Ａに伝送する。フレームワーク１１３Ａは、Ｗｅｂブラウザ１２０からリクエスト“２”及びデータ“１”を受信した場合、例えばＣＯＢＯＬアプリケーション１１２を実行するスレッド“Ｙ”を割り当てる。
【００２２】
更に、ＲＴＳ２１５は、スレッド“Ｙ”上のＣＯＢＯＬアプリケーション１１２で利用するスレッド資源２１４Ａを作成し、このスレッド資源２１４Ａをスレッド“Ｙ”上のＣＯＢＯＬアプリケーション１１２に提供する。スレッド“Ｙ”上のＣＯＢＯＬアプリケーション１１２は、このスレッド資源２１４Ａに継続するリクエスト“１”の応答に含まれるデータ“１”を設定する。つまり、リクエスト“１”で得たデータ“１”がリクエスト“２”にも引き継がれたことになる。
【００２３】
スレッド“Ｙ”上のＣＯＢＯＬアプリケーション１１２は、データ“１”を含むスレッド資源２１４Ａを利用してリクエスト“２”に関わる処理を実行すると、リクエスト“２”のデータ“２”を得る。そして、ＣＯＢＯＬアプリケーション１１２は、そのデータ“２”を含めてスレッド資源２１４Ａを更新する。そして、ＣＯＢＯＬアプリケーション１１２は、今回のデータ“２”及び前回のデータ“１”をＪａｖａアプリケーション１１１経由でＷｅｂブラウザ１２０に伝送する。
【００２４】
次に、Ｗｅｂブラウザ１２０は、リクエスト“２”に後続するリクエスト“３”を要求する際、リクエスト“３”の他に、前々回のデータ“１”及び前回のデータ“２”をＪａｖａアプリケーション１１１経由でフレームワーク１１３Ａに伝送する。フレームワーク１１３Ａは、Ｗｅｂブラウザ１２０からリクエスト“３”、データ“１”及びデータ“２”を受信すると、例えばＣＯＢＯＬアプリケーション１１２を実行するスレッド“Ｚ”を割り当てる。
【００２５】
更に、ＲＴＳ２１５は、スレッド“Ｚ”上のＣＯＢＯＬアプリケーション１１２で利用するスレッド資源２１４Ａを作成し、このスレッド資源２１４Ａをスレッド“Ｚ”上のＣＯＢＯＬアプリケーション１１２に提供する。スレッド“Ｚ”上のＣＯＢＯＬアプリケーション１１２は、このスレッド資源２１４Ａに、前々回のデータ“１”及び前回のデータ“２”を設定する。つまり、リクエスト“１”及びリクエスト“２”で得たデータ”１”及び“２”がリクエスト“３”にも引き継がれたことになる。
【００２６】
スレッド“Ｚ”上のＣＯＢＯＬアプリケーション１１２は、データ“１”及びデータ“２”を含むスレッド資源２１４Ａを利用してリクエスト“３”に関わる処理を実行すると、リクエスト“３”のデータ“３”を得る。そして、ＣＯＢＯＬアプリケーション１１２は、そのデータ“３”を含めてスレッド資源２１４Ａを更新する。そして、ＣＯＢＯＬアプリケーション１１２は、今回のデータ“３”、前回のデータ“２”及び前々回のデータ“１”をＪａｖａアプリケーション１１１経由でＷｅｂブラウザ１２０に伝送する。
【００２７】
サーバ２１０では、継続するリクエスト間でレッド資源２１４Ａの一部であるデータのみを引き継ぐが、同一のスレッド資源２１４Ａを引き継ぐことはできない。
【００２８】
さらに、サーバ２１０のＷｅｂアプリケーションの利用形態では、継続するリクエストの実行回数が増加するに連れてデータ量が増え、Ｊａｖａアプリケーション１１１及びＣＯＢＯＬアプリケーション１１２間のネットワーク上の通信負荷が大きくなる。同様に、Ｗｅｂアプリケーションの利用形態では、Ｊａｖａアプリケーション１１１及びＷｅｂブラウザ１２０間のネットワーク上の通信負荷も大きくなる。つまり、Ｗｅｂアプリケーションの利用形態では、継続するリクエスト間でスレッド資源２１４Ａの一部であるデータを引き継ぐことはできるものの、継続するリクエストの実行回数の増加に応じてネットワーク上の通信負荷が大きくなる。
【００２９】
また、近年ではＷｅｂブラウザを使用しなくても、Ｗｅｂアプリケーションを実行できるＷｅｂサービスアプリケーションが広がりつつある。図１３は、Ｗｅｂサービスアプリケーション用サーバ３２０（以下、単にサーバ３２０と称する）のソフトウェア構成を示す。サーバ３２０では、Ｗｅｂサービスクライアントアプリケーション３１０からのリクエストに応じてマルチスレッド方式で手続型ＣＯＢＯＬアプリケーション３２４を実行する。尚、Ｗｅｂサービスクライアントアプリケーション３１０とは、サーバ３２０に対向したクライアント端末が内蔵するアプリケーションに限定するものではなく、サーバ３２０に対向した意味でのアプリケーションに相当する。
【００３０】
サーバ３２０のフレームワーク３２０Ｂは、Ｗｅｂサービスクライアントアプリケーション３１０からのリクエストを受信すると、プロセス３２０Ａ上に実行する複数のスレッド３２１の内、サーバ側のＷｅｂサービスアプリケーション３２３が実行するスレッド３２１を割り当てる。
【００３１】
Ｗｅｂサービスアプリケーション３２３は、手続型ＣＯＢＯＬアプリケーション３２４を同一スレッド３２１上に呼び出す。更に、手続型ＣＯＢＯＬアプリケーション３２４は、ＲＴＳ３２２に対して利用するスレッド資源３２１Ａの作成を依頼する。そして、ＲＴＳ３２２は、資源作成依頼に応じて、スレッド資源３２１Ａを作成し、そのスレッド資源３２１Ａを手続型ＣＯＢＯＬアプリケーション３２４に提供する。
【００３２】
図１３に示す利用形態では、Ｗｅｂサービスクライアントアプリケーション３１０からのリクエストに応じて、サーバ３２０側の手続型ＣＯＢＯＬアプリケーション３２４が実行される。
【００３３】
しかしながら、上記のサーバ３２０では、Ｗｅｂサービスクライアントアプリケーション３１０から、継続する複数のリクエストを受信したとしても、リクエスト毎にＣＯＢＯＬアプリケーション３２４を同一スレッド３２１上で実行できるとは限らない。その結果、上記のサーバ３２０では、リクエスト毎にＣＯＢＯＬアプリケーション３２４を実行するに際し、継続するリクエスト間で同一のスレッド資源３２１Ａを引き継ぐことができない。
【００３４】
そこで、スレッド資源の一部であるデータをリクエスト間で引き継ぐ図１１の方式をサーバ３２０に採用することも考えられるが、継続するリクエストの実行回数の増加に応じてクライアント及びサーバ間のネットワーク負荷が大きくなってしまう。しかも、その場合、継続するリクエスト間で引き継ぐ資源は、スレッド資源の一部のデータに過ぎず、スレッド資源自体を引き継ぐものではない。
【００３５】
以下、図面に基づいて、本願の開示する資源管理プログラム、資源管理装置及び資源管理方法の実施例を詳細に説明する。尚、本実施例により、開示技術が限定されるものではない。
【実施例１】
【００３６】
図１は、実施例１のサーバ装置（以下、単にサーバと称する）の内部構成を示す説明図である。サーバ１は、複数のスレッドを実行するマルチスレッド方式を採用していても良い。サーバ１は、スレッド割当部１１と、呼出部１２と、資源提供部１３と、セッションＩＤ発行部１４と、資源管理部１５と、処理部１６とを有する。
【００３７】
スレッド割当部１１は、リクエストを受信すると、リクエストにより要求される処理を実行するスレッドを処理部１６に割り当てる。呼出部１２は、同一スレッド上にリクエストに要求された、手続型言語で記述されたアプリケーションを呼び出す。
【００３８】
資源提供部１３は、アプリケーションからの資源要求に応じて、アプリケーションが利用する資源をスレッド上のアプリケーションに提供する。セッションＩＤ発行部１４は、受信したリクエストに使用されたセッションを識別するセッションＩＤを発行する。セッションＩＤ発行部１４は、セッションＩＤの発行を資源判定部１３Ａの判定に応じて行なう。
【００３９】
処理部１６は、スレッド割当部１１に割り当てられたスレッドで、呼出部１２が呼び出したアプリケーションを、資源提供部１３が提供した資源を用いて実行する。サーバ１がマルチスレッド方式を採用している場合、スレッド割当部１１は、処理部１６に複数のスレッドを割り当て可能である。
【００４０】
資源管理部１５は、スレッド上のアプリケーションの実行処理が完了すると、アプリケーションが使用した資源をスレッドから待避させる。更に、資源管理部１５は、待避させた資源を、リクエストに使用されたセッションを識別するセッションＩＤに対応付けて管理する。
【００４１】
資源提供部１３は、資源判定部１３Ａと、資源復元部１３Ｂとを有する。資源判定部１３Ａは、アプリケーションに対して資源を提供する際に、リクエストに使用されたセッションのセッションＩＤを受信すると、セッションＩＤに対応した資源が資源管理部１５にあるか否かを判定する。資源復元部１３Ｂは、資源判定部１３ＡがセッションＩＤに対応した資源があると判定した場合に、当該資源をリクエストに関わるアプリケーション上に復元する。資源判定部１３Ａが、セッションＩＤに対応した資源が資源管理部１５にないと判定した場合に、セッションＩＤ発行部１４にセッションＩＤを発行させる。
【００４２】
実施例１では、複数のセッションのそれぞれにおいてリクエストを受信したとしても、リクエストが使用するセッションのセッションＩＤをキーにして資源を管理し、継続するリクエスト間で同一の資源を引き継ぐことができる。
【実施例２】
【００４３】
図２は、実施例２のＷｅｂサービスアプリケーションの利用形態を示す説明図である。図３は、実施例２のＷｅｂサービスアプリケーション用サーバ装置の内部構成を示す説明図である。図２に示すＷｅｂサービスアプリケーション用サーバ装置(以下、単にサーバと称する)１Ａは、Ｗｅｂサービスクライアントアプリケーション３ＡからＷｅｂサービスアプリケーション４Ａ経由で手続型ＣＯＢＯＬアプリケーション５Ａに対するリクエストを受け付ける。
【００４４】
図２に示すサーバ１Ａのプロセス２０上では、複数のスレッド２１及びＲＴＳ２２を実行している。図３に示すサーバ１Ａは、スレッド割当部３１と、ＣＯＢＯＬ呼出部４１と、ＩＤ発行依頼部４２と、ＩＤ通知部４３と、モード設定部４４と、処理部４５とを有する。スレッド割当部３１は、Ｗｅｂサービスクライアントアプリケーション３Ａからリクエストを受信すると、リクエストに要求される処理、例えば、複数のスレッド２１の内、Ｗｅｂサービスアプリケーション４Ａが実行するスレッド２１を処理部４５に割り当てる。
【００４５】
ＣＯＢＯＬ呼出部４１は、Ｗｅｂサービスアプリケーション４Ａが実行する同一スレッド２１上にリクエストに要求された手続型ＣＯＢＯＬアプリケーション５Ａを呼び出す。ＩＤ発行依頼部４２は、リクエストが使用するセッションを識別するセッションＩＤの発行をＲＴＳ２２に依頼する。尚、セッションは、Ｗｅｂサービスクライアントアプリケーション３Ａ及びＷｅｂサービスアプリケーション４Ａ間のリクエストに使用したセッションに相当する。また、ＩＤ発行依頼部４２は、同一スレッド２１上の手続型ＣＯＢＯＬアプリケーション５Ａの実行が完了すると、同リクエストに使用したセッションＩＤの更新をＲＴＳ２２に依頼する。
【００４６】
ＩＤ通知部４３は、Ｗｅｂサービスクライアントアプリケーション３Ａ又はＲＴＳ２２に対してセッションＩＤを通知する。モード設定部４４は、ＣＯＢＯＬアプリケーション５Ａが利用する資源５Ｂとして、スレッド資源を使用する通常モード又はＥＸＴＥＲＮＡＬ資源を使用するＥＸＴＥＲＮＡＬモードに設定する。
【００４７】
また、サーバ１Ａは、資源提供部５１と、セッションＩＤ発行部５２と、資源管理部５３とを有する。資源提供部５１は、スレッド２１上で実行する手続型ＣＯＢＯＬアプリケーション５Ａからの資源要求に応じて資源５ＢをＣＯＢＯＬアプリケーション５Ａに提供する。セッションＩＤ発行部５２は、スレッド２１上で実行するＷｅｂサービスアプリケーション４ＡのＩＤ発行依頼部４２からのＩＤ発行依頼を受信すると、リクエストに使用されたセッションを識別するセッションＩＤを発行する。セッションＩＤ発行部５２は、ＩＤ発行依頼部４２の更新依頼を受信すると、当該セッションＩＤを更新し、そのセッションＩＤをＷｅｂサービスアプリケーション４Ａに再通知する。
【００４８】
資源管理部５３は、リクエストに使用したセッションを識別するセッションＩＤに対応付けて、当該リクエストに関わる手続型ＣＯＢＯＬアプリケーション５Ａに利用した資源５Ｂを管理する。尚、資源５Ｂは、スレッド資源又はＥＸＴＥＲＮＡＬ資源に相当する。また、処理部４５は、スレッド割当部３１に割り当てられたスレッド２１で、ＣＯＢＯＬ呼出部４１が呼び出した手続型ＣＯＢＯＬアプリケーション５Ａを、資源提供部５１が提供した資源５Ｂを用いて実行する。サーバ１Ａがマルチスレッド方式を採用している場合、スレッド割当部３１は、処理部４５に複数のスレッド２１を割当可能としている。
【００４９】
また、資源提供部５１は、資源判定部６１と、資源復元部６２と、資源作成部６３と、資源待避部６４とを有する。資源判定部６１は、手続型ＣＯＢＯＬアプリケーション５Ａからの資源要求に応じて資源５Ｂを提供する際にリクエストが使用するセッションのセッションＩＤを受信すると、セッションＩＤに対応した資源が資源管理部５３内にあるか否かを判定する。
【００５０】
資源復元部６２は、資源判定部６１にてセッションＩＤに対応した資源がある場合に、資源をリクエストに関わる手続型ＣＯＢＯＬアプリケーション５Ａに復元する。資源作成部６３は、資源判定部６１にてセッションＩＤに対応する資源がない場合に、リクエストに関わる手続型ＣＯＢＯＬアプリケーション５Ａに新たな資源を作成する。資源待避部６４は、スレッド２１上の手続型ＣＯＢＯＬアプリケーション５Ａの実行処理が完了すると、手続型ＣＯＢＯＬアプリケーション５Ａが使用した資源を手続型ＣＯＢＯＬアプリケーション５Ａから待避する。更に、資源待避部６４は、待避した資源をセッションＩＤに対応付けて資源管理部５３に管理する。
【００５１】
図４は、資源管理部５３内部のテーブル構成を詳細に示す説明図である。資源管理部５３は、リクエスト５３Ｃ毎に、セッションＩＤ５３Ａ、資源５３Ｂ及び実行スレッド５３Ｄを管理する。ＲＴＳ２２は、資源管理部５３を参照して、クライアント甲の１回目のリクエストに関し、セッションＩＤが“ＳＥＳＳＩＯＮ Ａ”、資源５３Ｂがスレッド資源“Ａ”の新規作成、実行スレッドが“Ｘ”と認識する。また、ＲＴＳ２２は、クライアント甲の２回目のリクエストに関し、セッションＩＤが“ＳＥＳＳＩＯＮ Ａ”、資源５３Ｂがスレッド資源“Ａ”の復元、実行スレッドが“Ｙ”と認識する。
【００５２】
次に、実施例２のサーバ１Ａの動作について説明する。図５は、サーバ１Ａの動作を示す説明図である。尚、Ｗｅｂサービスアプリケーション４Ａは、例えば、ＣＯＢＯＬ呼出部４１、ＩＤ発行依頼部４２、ＩＤ通知部４３及びモード設定部４４を使用する。更に、ＲＴＳ２２は、例えば、資源提供部５１、セッションＩＤ発行部５２及び資源管理部５３を使用する。図５に示すサーバ１Ａのフレームワーク３０は、Ｗｅｂサービスクライアントアプリケーション３Ａから初回のリクエスト“１”を受信すると、Ｗｅｂサービスアプリケーション４Ａを実行するスレッド２１“Ｘ”を割り当てる。Ｗｅｂサービスアプリケーション４Ａは、同一スレッド２１“Ｘ”上に手続型ＣＯＢＯＬアプリケーション５Ａを呼び出す。手続型ＣＯＢＯＬアプリケーション５Ａは、ＲＴＳ２２から利用する資源５Ｂを取得する。
【００５３】
更に、Ｗｅｂサービスアプリケーション４Ａは、同一スレッド２１“Ｘ”上の手続型ＣＯＢＯＬアプリケーション５Ａの実行が完了すると、初回のリクエスト“１”のセッションを識別するセッションＩＤの発行依頼をＲＴＳ２２に通知する。ＲＴＳ２２は、セッションＩＤを発行し、そのセッションＩＤをＷｅｂサービスアプリケーション４Ａに通知する。更に、ＲＴＳ２２は、スレッド２１“Ｘ”上の手続型ＣＯＢＯＬアプリケーション５Ａの資源５Ｂを待避する。更に、Ｗｅｂサービスアプリケーション４Ａは、セッションＩＤを受信すると、そのセッションＩＤをＷｅｂサービスクライアントアプリケーション３Ａに通知する。
【００５４】
次に、フレームワーク３０は、Ｗｅｂサービスクライアントアプリケーション３Ａから２回目のリクエスト“２”及びセッションＩＤを受信すると、Ｗｅｂサービスアプリケーション４Ａを実行するスレッド２１“Ｙ”を割り当てる。Ｗｅｂサービスアプリケーション４Ａは、Ｗｅｂサービスクライアントアプリケーション３ＡからのセッションＩＤを受信すると、セッションＩＤをＲＴＳ２２に通知する。
【００５５】
更に、Ｗｅｂサービスアプリケーション４Ａは、同一スレッド２１“Ｙ”上に手続型ＣＯＢＯＬアプリケーション５Ａを呼び出す。更に、ＲＴＳ２２は、受信したセッションＩＤに対応する資源５Ｂをスレッド２１“Ｙ”上の手続型ＣＯＢＯＬアプリケーション５Ａに復元する。更に、Ｗｅｂサービスアプリケーション４Ａは、同一スレッド２１“Ｙ”上の手続型ＣＯＢＯＬアプリケーション５Ａの実行が完了すると、現在リクエストである２回目のリクエスト“２”のセッションを識別するセッションＩＤの更新をＲＴＳ２２に依頼する。更に、ＲＴＳ２２は、スレッド２１“Ｙ”上の手続型ＣＯＢＯＬアプリケーション５Ａの資源５Ｂを待避すると共に、更新依頼のセッションＩＤを更新してＷｅｂサービスアプリケーション４Ａに再通知する。更に、Ｗｅｂサービスアプリケーション４Ａは、更新したセッションＩＤをＷｅｂサービスクライアントアプリケーション３Ａに通知する。
【００５６】
図６は、Ｗｅｂサービスアプリケーション全体の処理動作を示すフローチャートである。図６においてＷｅｂサービスクライアントアプリケーション３Ａは、手続型ＣＯＢＯＬアプリケーション５Ａの実行リクエストをサーバ１Ａに要求する(Ｓ１１)。サーバ１Ａのスレッド２１上で実行するＷｅｂサービスアプリケーション４Ａは、セッションＩＤが存在するか否かを判定する(Ｓ１２)。
【００５７】
Ｗｅｂサービスアプリケーション４ＡのＩＤ通知部４３は、セッションＩＤが存在する場合(Ｓ１２肯定)、セッションＩＤをＲＴＳ２２に通知する(Ｓ１３)。更に、Ｗｅｂサービスアプリケーション４ＡのＣＯＢＯＬ呼出部４１は、同一スレッド２１上に手続型ＣＯＢＯＬアプリケーション５Ａを呼び出す(Ｓ１４)。
【００５８】
手続型ＣＯＢＯＬアプリケーション５Ａは、自分で使用する資源５Ｂの作成をＲＴＳ２２に依頼する(Ｓ１５)。ＲＴＳ２２は、セッションＩＤが通知済みであるか否かを判定する(Ｓ１６)。ＲＴＳ２２の資源作成部６３は、セッションＩＤが通知済みでない場合(Ｓ１６否定)、新規の資源５Ｂを手続型ＣＯＢＯＬアプリケーション５Ａ側のスレッド２１上に作成する(Ｓ１７)。
【００５９】
また、ＲＴＳ２２の資源復元部６２は、セッションＩＤが通知済みである場合(Ｓ１６肯定)、セッションＩＤと一致する作成済み資源５Ｂを手続型ＣＯＢＯＬアプリケーション５Ａ側のスレッド２１上に復元する(Ｓ１８)。手続型ＣＯＢＯＬアプリケーション５Ａは、資源５Ｂを使用した手続型ＣＯＢＯＬアプリケーション５Ａの実行処理が完了する(Ｓ１９)。更に、Ｗｅｂサービスアプリケーション４Ａは、手続型ＣＯＢＯＬアプリケーション５Ａの実行処理が完了すると、セッションＩＤが存在するか否かを判定する（Ｓ１９Ａ）。
【００６０】
Ｗｅｂサービスアプリケーション４ＡのＩＤ発行依頼部４２は、セッションＩＤが存在しない場合（Ｓ１９Ａ否定）、新規のリクエストと判断し、リクエストが使用するセッションを識別するセッションＩＤ発行をＲＴＳ２２に依頼する(Ｓ２０)。ＲＴＳ２２のセッションＩＤ発行部５２は、セッションＩＤの発行依頼を受信すると、セッションＩＤを発行し、そのセッションＩＤをＷｅｂサービスアプリケーション４Ａに通知する。更に、ＲＴＳ２２の資源待避部６４は、手続型ＣＯＢＯＬアプリケーション５Ａが使用する資源５Ｂを待避する(Ｓ２１)。尚、資源待避部６４は、資源５Ｂを待避すると、当該リクエストのセッションを識別するセッションＩＤに対応付けて資源５Ｂを資源管理部５３に管理する。
【００６１】
Ｗｅｂサービスアプリケーション４Ａは、ＲＴＳ２２からのセッションＩＤを受信すると、セッションＩＤをＷｅｂサービスクライアントアプリケーション３Ａに通知する(Ｓ２２)。そして、Ｗｅｂサービスクライアントアプリケーション３Ａは、手続型ＣＯＢＯＬアプリケーション５Ａへの実行リクエストを完了し(Ｓ２３)、この処理動作を終了する。
【００６２】
Ｗｅｂサービスアプリケーション４Ａは、セッションＩＤが存在する場合（Ｓ１９Ａ肯定）、そのセッションＩＤの更新をＲＴＳ２２に依頼する（Ｓ２４）。そして、ＲＴＳ２２の資源待避部６４は、ＣＯＢＯＬアプリケーション５Ａが使用する資源５Ｂを待避すると共に、そのセッションＩＤを更新してＷｅｂサービスアプリケーション４Ａに再通知し(Ｓ２５)、Ｓ２２に移行する。
【００６３】
図７は、Ｗｅｂサービスアプリケーション４Ａの処理動作を示すフローチャートである。図７においてＷｅｂサービスアプリケーション４Ａは、セッションＩＤを取得し(Ｓ３１)、セッションＩＤが存在するか否かを判定する(Ｓ３２)。Ｗｅｂサービスアプリケーション４ＡのＩＤ通知部４３は、セッションＩＤが存在する場合(Ｓ３２肯定)、セッションＩＤをＲＴＳ２２に通知する通知ＡＰＩを呼び出す(Ｓ３３)。
【００６４】
Ｗｅｂサービスアプリケーション４ＡのＣＯＢＯＬ呼出部４１は、手続型ＣＯＢＯＬアプリケーション５Ａをロードし(Ｓ３４)、同一スレッド２１上に手続型ＣＯＢＯＬアプリケーション５Ａを呼び出す(Ｓ３５)。更に、Ｗｅｂサービスアプリケーション４ＡのＩＤ発行依頼部４２は、セッションＩＤが発行済みであるか否かを判定する（Ｓ３５Ａ）。ＩＤ発行依頼部４２は、セッションＩＤが発行済みでない場合（Ｓ３５Ａ否定）、リクエストに使用したセッションを識別するセッションＩＤの発行をＲＴＳ２２に依頼する(Ｓ３６)。
【００６５】
Ｗｅｂサービスアプリケーション４ＡのＩＤ通知部４３は、セッションＩＤの発行依頼に対応するセッションＩＤを受信すると、セッションＩＤをＷｅｂサービスクライアントアプリケーション３Ａに通知し(Ｓ３７)、この処理動作を終了する。また、Ｗｅｂサービスアプリケーション４ＡのＩＤ通知部４３は、セッションＩＤが発行済みである場合（Ｓ３５Ａ肯定）、そのセッションＩＤの更新をＲＴＳ２２に依頼し（Ｓ３８）、Ｓ３７に移行する。
【００６６】
図８は、手続型ＣＯＢＯＬアプリケーション５Ａの処理動作を示すフローチャートである。図８において手続型ＣＯＢＯＬアプリケーション５Ａは、Ｗｅｂサービスアプリケーション４Ａの呼出動作に応じて初期化処理を実行し（Ｓ４１）、ＣＯＢＯＬソースに指定された作業領域の獲得をＲＴＳ２２に依頼する(Ｓ４２)。手続型ＣＯＢＯＬアプリケーション５Ａは、ＥＸＴＥＲＮＡＬ句指定のデータがあるか否かを判定する(Ｓ４３)。手続型ＣＯＢＯＬアプリケーション５Ａは、ＥＸＴＥＲＮＡＬ句指定のデータがある場合(Ｓ４３肯定)、ＥＸＴＥＲＮＡＬ句指定の領域の獲得をＲＴＳ２２に依頼する(Ｓ４４)。
【００６７】
手続型ＣＯＢＯＬアプリケーション５Ａは、リクエストに応じた動作処理を実行し、その実行結果に基づき作業域の内容や資源５Ｂを更新し(Ｓ４５)、その実行処理を完了すべく、終了処理を実行する(Ｓ４６)。手続型ＣＯＢＯＬアプリケーション５Ａは、終了処理を実行すると、ＣＯＢＯＬソースに指定された作業域の削除をＲＴＳ２２に依頼し(Ｓ４７)、この処理動作を終了する。
【００６８】
また、手続型ＣＯＢＯＬアプリケーション５Ａは、ＥＸＴＥＲＮＡＬ句指定のデータがない場合(Ｓ４３否定)、リクエストに応じた動作処理を実行すべく、Ｓ４５に移行する。
【００６９】
図９は、ＲＴＳ２２の処理動作を示すフローチャートである。図９においてＲＴＳ２２は、Ｗｅｂサービスアプリケーション４ＡからセッションＩＤを受信したか否かを判定する(Ｓ５１)。ＲＴＳ２２は、セッションＩＤを受信しなかった場合(Ｓ５１否定)、新規セッション状態と判断する(Ｓ５２)。ＲＴＳ２２の資源作成部６３は、新規セッション状態と判断した後、手続型ＣＯＢＯＬアプリケーション５Ａから資源５Ｂの作成依頼を受信すると(Ｓ５３)、スレッド資源／ＥＸＴＥＲＮＡＬ資源を新規作成する(Ｓ５４)。
【００７０】
ＲＴＳ２２は、スレッド資源／ＥＸＴＥＲＮＡＬ資源を新規作成すると、手続型ＣＯＢＯＬアプリケーション５Ａの実行処理に応じて必要な情報を更新し(Ｓ５５)、セッションＩＤの発行依頼又は更新依頼を受信したか否かを判定する(Ｓ５６)。ＲＴＳ２２は、セッションＩＤの発行依頼又は更新依頼を受信した場合(Ｓ５６肯定)、ＥＸＴＥＲＮＡＬ動作モードであるか否かを判定する(Ｓ５７)。
【００７１】
ＲＴＳ２２のセッションＩＤ発行部５２は、ＥＸＴＥＲＮＡＬ動作モードである場合(Ｓ５７肯定)、発行依頼に応じてセッションＩＤを発行し、そのセッションＩＤをＷｅｂサービスアプリケーション４Ａに通知する（Ｓ５８）。また、セッションＩＤ発行部５２は、ＥＸＴＥＲＮＡＬ動作モードである場合(Ｓ５７肯定)、更新依頼に応じてセッションＩＤを更新し、そのセッションＩＤをＷｅｂサービスアプリケーション４Ａに再通知する(Ｓ５８)。更に、ＲＴＳ２２の資源待避部６４は、手続型ＣＯＢＯＬアプリケーション５Ａで使用したＥＸＴＥＲＮＡＬ資源を待避し(Ｓ５８)、この処理動作を終了する。尚、資源管理部５３は、この待避したＥＸＴＥＲＮＡＬ資源をセッションＩＤに対応付けて管理する。
【００７２】
また、ＲＴＳ２２のセッションＩＤ発行部５２は、ＥＸＴＥＲＮＡＬ動作モードでない場合(Ｓ５７否定)、発行依頼に応じてセッションＩＤを発行し、そのセッションＩＤをＷｅｂサービスアプリケーション４Ａに通知する（Ｓ５９）。また、セッションＩＤ発行部５２は、ＥＸＴＥＲＮＡＬ動作モードでない場合(Ｓ５７否定)、更新依頼に応じてセッションＩＤを更新し、そのセッションＩＤをＷｅｂサービスアプリケーション４Ａに再通知する（Ｓ５９）。更に、ＲＴＳ２２の資源待避部６４は、手続型ＣＯＢＯＬアプリケーション５Ａを使用したスレッド資源を待避し(Ｓ５９)、この処理動作を終了する。尚、資源管理部５３は、この待避したスレッド資源をセッションＩＤに対応付けて管理する。
【００７３】
また、ＲＴＳ２２は、セッションＩＤの発行依頼又は更新依頼を受信しなかった場合(Ｓ５６否定)、ＥＸＴＥＲＮＡＬ動作モードであるか否かを判定する(Ｓ６０)。ＲＴＳ２２の資源提供部５１は、ＥＸＴＥＲＮＡＬ動作モードである場合(Ｓ６０肯定)、ＥＸＴＥＲＮＡＬ資源を破棄し(Ｓ６１)、この処理動作を終了する。尚、資源管理部５３は、ＥＸＴＥＲＮＡＬ資源及び、そのセッションＩＤを破棄する。
【００７４】
また、ＲＴＳ２２の資源提供部５１は、ＥＸＴＥＲＮＡＬ動作モードでない場合(Ｓ６０否定)、スレッド資源を破棄し(Ｓ６２)、この処理動作を終了する。尚、資源管理部５３は、スレッド資源及び、そのセッションＩＤを破棄する。
【００７５】
また、ＲＴＳ２２の資源判定部６１は、Ｗｅｂサービスアプリケーション４ＡからセッションＩＤを受信した場合(Ｓ５１肯定)、セッションＩＤが資源管理部５３内に存在するか否かを判定する(Ｓ６３)。ＲＴＳ２２の資源判定部６１は、セッションＩＤが資源管理部５３内に存在しなかった場合(Ｓ６３否定)、セッション切断状態と判断する(Ｓ６４)。ＲＴＳ２２は、セッション切断状態と判断した後、手続型ＣＯＢＯＬアプリケーション５Ａからの資源５Ｂの作成依頼を受信すると(Ｓ６５)、スレッド資源／ＥＸＴＥＲＮＡＬ資源を新規作成すべく、Ｓ５４に移行する。
【００７６】
また、ＲＴＳ２２の資源判定部６１は、セッションＩＤが資源管理部５３内に存在した場合(Ｓ６３肯定)、セッション継続状態と判断する(Ｓ６６)。ＲＴＳ２２は、セッション継続状態と判断した後、ＣＯＢＯＬアプリケーション５Ａからの資源作成依頼を受信すると(Ｓ６７)、ＥＸＴＥＲＮＡＬ動作モードであるか否かを判定する(Ｓ６８)。
【００７７】
ＲＴＳ２２の資源復元部６２は、ＥＸＴＥＲＮＡＬ動作モードである場合(Ｓ６８肯定)、資源管理部５３に管理されたセッションＩＤと一致する作成済みのＥＸＴＥＲＮＡＬ資源を現スレッド２１上に復元し(Ｓ６９)、Ｓ５５に移行する。また、ＲＴＳ２２の資源復元部６２は、ＥＸＴＥＲＮＡＬ動作モードでない場合(Ｓ６８否定)、資源管理部５３に管理されたセッションＩＤと一致する作成済みのスレッド資源を現スレッド２１上に復元し(Ｓ７０)、Ｓ５５に移行する。
【００７８】
実施例２では、Ｗｅｂサービスクライアントアプリケーション３Ａから手続型ＣＯＢＯＬアプリケーション５Ａを実行するリクエストを受信すると、当該リクエスト毎にＷｅｂサービスアプリケーション４Ａを実行するスレッド２１を割り当てる。更に、実施例２では、割り当てられたスレッド２１上に手続型ＣＯＢＯＬアプリケーション５Ａを呼び出し、手続型ＣＯＢＯＬアプリケーション５Ａからの資源要求に応じて利用する資源５Ｂを手続型ＣＯＢＯＬアプリケーション５Ａに提供する。その結果、Ｗｅｂサービスクライアントアプリケーション３Ａから手続型ＣＯＢＯＬアプリケーション５ＡをＷｅｂサービスとして呼び出す場合でも、安定したマルチスレッド方式に対応できる。
【００７９】
実施例２では、手続型ＣＯＢＯＬアプリケーション５Ａの実行処理が完了すると、リクエストが使用するセッションのセッションＩＤを発行し、当該手続型ＣＯＢＯＬアプリケーション５Ａに利用した資源５Ｂを待避する。更に、実施例２では、待避した資源５ＢをセッションＩＤに対応付けて資源管理部５３に管理する。その結果、Ｗｅｂサービスクライアントアプリケーション３Ａから複数のリクエストを受信したとしても、継続するリクエスト間で同一の資源５Ｂを引き継ぐことができる。
【００８０】
更に、実施例２では、リクエスト受信時にリクエストに関わるセッションのセッションＩＤに対応した資源５Ｂがある場合、当該資源５Ｂを手続型ＣＯＢＯＬアプリケーション５Ａ上に復元する。その結果、継続するリクエスト間で同一の資源５Ｂを引き継ぐことができる。
【００８１】
更に、実施例２では、リクエスト受信時にリクエストに関わるセッションのセッションＩＤに対応した資源５Ｂがない場合、手続型ＣＯＢＯＬアプリケーション５Ａ上に資源５Ｂを新規作成する。
【００８２】
更に、実施例２では、ＲＴＳ２２側でセッションＩＤを発行すると、そのセッションＩＤをＷｅｂサービスクライアントアプリケーション３Ａに通知する。その結果、継続するリクエストを実行する場合はセッションＩＤを使用して当該セッションＩＤに対応した資源５Ｂをリクエスト間で引き継ぐことができる。
【００８３】
更に、実施例２では、ＥＸＴＥＲＮＡＬモード時に手続型ＣＯＢＯＬアプリケーション５Ａに対して資源５ＢであるＥＸＴＥＲＮＡＬ資源を提供する場合、セッションＩＤに対応付けてＥＸＴＥＲＮＡＬ資源を資源管理部５３に管理する。
【００８４】
更に、実施例２では、ＥＸＴＥＲＮＡＬモードではない通常モード時に手続型ＣＯＢＯＬアプリケーション５Ａに対して資源５Ｂであるスレッド資源を提供する場合、セッションＩＤに対応付けてスレッド資源を資源管理部５３に管理する。
【００８５】
また、図示した各部の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各部の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。
【００８６】
更に、各装置で行われる各種処理機能は、ＣＰＵ（Central Processing Unit）（又はＭＰＵ（Micro Processing Unit）、ＭＣＵ（Micro Controller Unit）等のマイクロ・コンピュータ）上で、その全部又は任意の一部を実行するようにしても良い。また、各種処理機能は、ＣＰＵ（又はＭＰＵ、ＭＣＵ等のマイクロ・コンピュータ）で解析実行するプログラム上、又はワイヤードロジックによるハードウェア上で、その全部又は任意の一部を実行するようにしても良いことは言うまでもない。
【００８７】
ところで、実施例１及び実施例２で説明した各種の処理は、予め用意されたプログラムをコンピュータで実行することによって実現することができる。そこで、以下に、図１０を用いて、上記実施例と同様の機能を有するプログラムを実行するコンピュータの一例を説明する。
【００８８】
同図に示すように、コンピュータ５００は、ＨＤＤ（Hard Disk Drive）５１０、ＲＡＭ(Random Access Memory)５２０、ＲＯＭ（Read Only Memory）５３０及びＣＰＵ５４０を含み、互いをバス５５０で接続して構成される。
【００８９】
そして、ＲＯＭ５３０には、上記の実施例と同様の機能を発揮するプログラムが予め記憶されている。そのプログラムは、スレッド割当プログラム５３１、呼出プログラム５３２、資源提供プログラム５３３、セッションＩＤ発行プログラム５３４及び資源管理プログラム５３５を含む。更に、資源提供プログラム５３３は、資源判定プログラム５３３Ａ及び資源復元プログラム５３３Ｂを含む。尚、プログラム５３１〜５３５については、図１に示したサーバ１の各構成要素と同様、適宜統合又は分散してもよい。
【００９０】
そして、ＣＰＵ５４０が、これらのプログラム５３１〜５３５をＲＯＭ５３０から読み出して実行することで、各プログラム５３１〜５３５は各種プロセスとして機能するようになる。各種プロセスは、スレッド割当プロセス５４１、ＣＯＢＯＬ呼出プロセス５４２、資源提供プロセス５４３、セッションＩＤ発行プロセス５４４及び資源管理プロセス５４５を含む。更に、資源提供プロセス５４３は、資源判定プロセス５４３Ａ及び資源復元プロセス５４３Ｂを含む。各プロセス５４１〜５４５は、図１に示したスレッド割当部１１、呼出部１２、資源提供部１３、資源判定部１３Ａ、資源復元部１３Ｂ、セッションＩＤ発行部１４及び資源管理部１５に夫々対応する。
【００９１】
ＣＰＵ５４０は、クライアントからアプリケーションを実行するリクエストを受信すると、当該リクエスト毎にスレッドを割り当てる。更に、ＣＰＵ５４０は、割り当てられたスレッド上にアプリケーションを呼び出す。更に、ＣＰＵ５４０は、アプリケーションからの資源要求に応じて、アプリケーションが利用する資源を当該アプリケーションに提供する。更に、ＣＰＵ５４０は、リクエストに使用したセッションを識別するセッションＩＤを発行する。
【００９２】
更に、ＣＰＵ５４０は、スレッド上のアプリケーションの実行処理が完了すると、当該アプリケーションが使用した資源をスレッドから待避する。更に、ＣＰＵ５４０は、この待避した資源を当該リクエストが使用するセッションを識別するセッションＩＤに対応付けて管理する。更に、ＣＰＵ５４０は、アプリケーションからの資源要求に応じて資源を提供する際に、当該リクエストが使用するセッションのセッションＩＤを受信すると、当該セッションＩＤに対応した資源があるか否かを判定する。更に、ＣＰＵ５４０は、セッションＩＤに対応した資源がある場合に、当該資源を当該リクエストに関わるアプリケーション上に復元する。
【００９３】
その結果、クライアントから異なるセッションのそれぞれにおいて複数のリクエストを受信したとしても、同一のセッションを使用した複数の継続するリクエスト間で同一の資源を引き継ぐことができる。
【符号の説明】
【００９４】
１ サーバ
１Ａ サーバ
３Ａ Ｗｅｂサービスクライアントアプリケーション
４Ａ Ｗｅｂサービスアプリケーション
５Ａ 手続型ＣＯＢＯＬアプリケーション
５Ｂ 資源
１１ スレッド割当部
１２ 呼出部
１３ 資源提供部
１３Ａ 資源判定部
１３Ｂ 資源復元部
１４ セッションＩＤ発行部
１５ 資源管理部
１６ 処理部
２１ スレッド
２２ ＲＴＳ
３１ スレッド割当部
４１ ＣＯＢＯＬ呼出部
４４ モード設定部
４５ 処理部
５１ 資源提供部
５２ セッションＩＤ発行部
５３ 資源管理部
６１ 資源判定部
６２ 資源復元部
６３ 資源作成部
６４ 資源待避部
【技術分野】
【０００１】
本発明は、資源管理プログラム、資源管理装置及び資源管理方法に関する。
【背景技術】
【０００２】
一般的に企業の在庫管理や財務等の基幹業務を取り扱う基幹系システムでは、多くのサーバアプリケーションがＣＯＢＯＬ（Common Business Oriented Language）で開発されている。更に、近年では、ＷｅｂアプリケーションとしてＪａｖａ（登録商標）アプリケーションのクライアントからサーバ側の手続型のＣＯＢＯＬアプリケーションを呼び出す運用が多くみられる。
【０００３】
例えば、汎用的なＪａｖａＳｅｒｖｌｅｔが、Ｗｅｂブラウザからのリクエストに応じて、ユーザインタフェースＸＭＬソースに基づき、トランザクション処理システム配下のＣＯＢＯＬアプリケーションを呼び出すための電文を自動生成し、トランザクション処理システムで処理された結果を電文として受取り、該受取った電文をユーザインタフェースＸＭＬソースに基づいてＷｅｂブラウザ上で表示するＨＴＭＬを生成し、Ｗｅｂブラウザからの要求のレスポンスとして返送する技術が知られている（特許文献１）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特表２００１−５０９２８６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、従来のサーバでは、継続する複数のリクエストを受信したとしても、複数のリクエストに応じた手続型のアプリケーションの処理を同一スレッド上で実行できるとは限らない。その結果、従来のサーバでは、リクエスト毎に手続型のアプリケーションを実行するに際し、継続するリクエスト間で同一のスレッド資源を引き継ぐことができない。
【０００６】
開示技術は、上記点に鑑みてなされたものであり、セッションが異なる複数のリクエストを受信したとしても、継続するリクエスト間で同一のスレッド資源を引き継ぐことを目的とする。
【課題を解決するための手段】
【０００７】
本願の開示する資源管理プログラムは、一つの態様において、コンピュータに、手続型言語で記述されたプログラムで規定された処理であって、受信した処理要求に要求される処理をスレッドに割り当て、セッションを識別する識別情報とスレッド資源とを予め関連付けて記憶する記憶手段から、前記処理要求についての通信に使用されたセッションを識別する識別情報と関連付けられて記憶されたスレッド資源を読み出し、読み出した前記スレッド資源を用いて、前記スレッドに割り当てた前記処理を実行することを実行させた。
【発明の効果】
【０００８】
本願の一つの態様では、Ｗｅｂサービスアプリケーション等のクライアントから、異なるセッションで複数のリクエストを受信したとしても、継続するリクエスト間で同一のスレッド資源を引き継ぐことができる。
【図面の簡単な説明】
【０００９】
【図１】図１は、実施例１のサーバ装置の内部構成を示す説明図である。
【図２】図２は、実施例２のＷｅｂサービスアプリケーションの利用形態を示す説明図である。
【図３】図３は、Ｗｅｂサービスアプリケーション用サーバ装置の内部構成を示す説明図である。
【図４】図４は、資源管理部内部のテーブル構成を詳細に示す説明図である。
【図５】図５は、Ｗｅｂサービスアプリケーション用サーバ装置の動作を示す説明図である。
【図６】図６は、Ｗｅｂサービスアプリケーション用サーバ装置全体の処理動作を示すフローチャートである。
【図７】図７は、Ｗｅｂサービスアプリケーションの処理動作を示すフローチャートである。
【図８】図８は、手続型ＣＯＢＯＬアプリケーションの処理動作を示すフローチャートである。
【図９】図９は、ＲＴＳの処理動作を示すフローチャートである。
【図１０】図１０は、資源管理プログラムを実行するコンピュータを示す説明図である。
【図１１】図１１は、Ｗｅｂアプリケーションの利用形態を示す説明図である。
【図１２】図１２は、マルチスレッド方式のＷｅｂアプリケーションの利用形態を示す説明図である。
【図１３】図１３は、Ｗｅｂサービスアプリケーションの利用形態を示す説明図である。
【発明を実施するための形態】
【００１０】
本発明の実施形態を説明する前に、図１１〜図１３を用いて、Ｊａｖａアプリケーションが手続型のＣＯＢＯＬアプリケーションを呼び出す形態のＷｅｂアプリケーションについて説明する。
【００１１】
図１１は、Ｗｅｂアプリケーション用サーバ装置(以下、単にサーバと称する)１１０により実行されるソフトウェアの構造を示す。サーバ１１０では、Ｗｅｂブラウザ１２０からインターネット１３０経由のリクエストに応じて、ＣＯＢＯＬアプリケーション１１２を実行する。更に、サーバ１１０のＪａｖａアプリケーション１１１は、Ｗｅｂブラウザ１２０からインターネット１３０経由でリクエストを受信する。
【００１２】
サーバ１１０内のフレームワーク１１３は、Ｊａｖａアプリケーション１１１のリクエストをＣＯＢＯＬアプリケーション１１２のリクエストに変換する機能を備えたソフトウェアである。更に、サーバ１１０のＣＯＢＯＬアプリケーション１１２は、フレームワーク１１３で変換されたリクエストを受信すると、プロセス１１０Ａ上に単一のスレッド１１４及びＣＯＢＯＬランタイムシステム（COBOL Run Time System：以下、単にＲＴＳと称する）１１５を実行する。尚、ＲＴＳ１１５は、スレッド１１４上のＣＯＢＯＬアプリケーション１１２が利用するスレッド資源１１４Ａを作成し、このスレッド資源１１４Ａをスレッド１１４上のＣＯＢＯＬアプリケーション１１２に提供する。
【００１３】
スレッド資源１１４Ａには、データ、使用ファイルやＤＢコネクション等が含まれる。例示として、手続型のＣＯＢＯＬアプリケーション１１２が住所データに基づいて住所録を作成するプログラムであるとした場合、スレッド資源１１４Ａのデータは郵便番号、住所、電話番号などの格納位置及び読み取り位置などを指定するデータなどであり、使用ファイルとは、郵便番号、住所、電話番号などの住所データが列挙されたファイルなどであり、ＤＢコネクションは、使用ファイルを格納したＤＢへのコネクションに関する情報であって良い。
【００１４】
手続型言語で記述されたプログラムに基づく処理においては、記述された命令を逐次的に実行し、処理の結果に応じて変数の内容を変化させる。処理のリクエストが複数ある場合には、複数のリクエスト間で変数の内容が変化している可能性があり、そのためスレッド資源１１４Ａを引き継ぐ必要がある。
【００１５】
プロセス１１０Ａ上のスレッド１１４では、Ｗｅｂブラウザ１２０からのリクエストに応じて、ＲＴＳ１１５から取得したスレッド資源１１４Ａを使用してＣＯＢＯＬアプリケーション１１２を順次実行する。尚、ＣＯＢＯＬアプリケーション１１２が使用するスレッド資源１１４Ａはスレッド単位で管理される。従って、継続するリクエスト間で同一のスレッド資源１１４Ａを引き継ぐような場合には、全てのリクエストに関わるＣＯＢＯＬアプリケーションを同一のスレッド１１４上で実行する必要がある。サーバ１１０では、継続するリクエスト間で同一のスレッド資源１１４Ａを引き継ぐため、全てのリクエストに関わるＣＯＢＯＬアプリケーション１１２を単一のスレッド１１４上で実行する単一スレッド方式を採用している。
【００１６】
しかしながら、サーバ１１０の運用形態は、インターネット１３０を経由して複数のＷｅｂブラウザ１２０からのリクエストを受け付ける必要があるため、プロセス１１０Ａ上に複数のスレッド１１４を実行するマルチスレッド方式を採用するのが一般的である。
【００１７】
マルチスレッド方式を採用するシステムとして、継続するリクエスト間でスレッド資源の一部であるデータを引き継ぎ、この引き継いだデータをクライアント側やサーバ側で保持するシステムがある。図１２は、サーバ２１０により実行されるソフトウェアの構造を示す図である。尚、図１１に示す利用形態と同一構成には同一符号を付すことで、その重複する構成及び動作の説明については省略する。
【００１８】
図１２に示すサーバ２１０は、プロセス２１０Ａ上に複数のスレッド２１４を実行するマルチスレッド方式を採用している。更に、フレームワーク１１３Ａは、Ｊａｖａアプリケーション１１１を通じてＷｅｂブラウザ１２０からのリクエストを受信すると、複数のスレッド２１４の内、リクエストに応じたＣＯＢＯＬアプリケーション１１２を実行するスレッド２１４を割り当てる。そして、ＲＴＳ２１５は、スレッド２１４上のＣＯＢＯＬアプリケーション１１２で利用可能なスレッド資源２１４Ａを作成し、このスレッド資源２１４Ａを、ＣＯＢＯＬアプリケーション１１２を実行するスレッド２１４に提供する。
【００１９】
フレームワーク１１３Ａは、Ｗｅｂブラウザ１３０からのリクエスト“１”を受信した場合に、例えばＣＯＢＯＬアプリケーション１１２を実行するスレッド“Ｘ”を割り当てる。更に、ＲＴＳ２１５は、スレッド“Ｘ”上のＣＯＢＯＬアプリケーション１１２で利用するスレッド資源２１４Ａを作成し、このスレッド資源２１４Ａをスレッド“Ｘ”上のＣＯＢＯＬアプリケーション１１２に提供する。
【００２０】
更に、スレッド“Ｘ”上のＣＯＢＯＬアプリケーション１１２は、スレッド資源２１４Ａを使用してリクエスト“１”に関わる処理を実行し、データ“１”を得て、そのデータ“１”を含めてスレッド資源２１４Ａを更新する。そして、ＣＯＢＯＬアプリケーション１１２は、スレッド資源２１４Ａのうちのデータ“１”をＪａｖａアプリケーション１１１経由でＷｅｂブラウザ１２０に伝送する。
【００２１】
次に、Ｗｅｂブラウザ１２０は、リクエスト“１”に後続するリクエスト“２”を要求する際、リクエスト“２”の他に、データ“１”をＪａｖａアプリケーション１１１経由でフレームワーク１１３Ａに伝送する。フレームワーク１１３Ａは、Ｗｅｂブラウザ１２０からリクエスト“２”及びデータ“１”を受信した場合、例えばＣＯＢＯＬアプリケーション１１２を実行するスレッド“Ｙ”を割り当てる。
【００２２】
更に、ＲＴＳ２１５は、スレッド“Ｙ”上のＣＯＢＯＬアプリケーション１１２で利用するスレッド資源２１４Ａを作成し、このスレッド資源２１４Ａをスレッド“Ｙ”上のＣＯＢＯＬアプリケーション１１２に提供する。スレッド“Ｙ”上のＣＯＢＯＬアプリケーション１１２は、このスレッド資源２１４Ａに継続するリクエスト“１”の応答に含まれるデータ“１”を設定する。つまり、リクエスト“１”で得たデータ“１”がリクエスト“２”にも引き継がれたことになる。
【００２３】
スレッド“Ｙ”上のＣＯＢＯＬアプリケーション１１２は、データ“１”を含むスレッド資源２１４Ａを利用してリクエスト“２”に関わる処理を実行すると、リクエスト“２”のデータ“２”を得る。そして、ＣＯＢＯＬアプリケーション１１２は、そのデータ“２”を含めてスレッド資源２１４Ａを更新する。そして、ＣＯＢＯＬアプリケーション１１２は、今回のデータ“２”及び前回のデータ“１”をＪａｖａアプリケーション１１１経由でＷｅｂブラウザ１２０に伝送する。
【００２４】
次に、Ｗｅｂブラウザ１２０は、リクエスト“２”に後続するリクエスト“３”を要求する際、リクエスト“３”の他に、前々回のデータ“１”及び前回のデータ“２”をＪａｖａアプリケーション１１１経由でフレームワーク１１３Ａに伝送する。フレームワーク１１３Ａは、Ｗｅｂブラウザ１２０からリクエスト“３”、データ“１”及びデータ“２”を受信すると、例えばＣＯＢＯＬアプリケーション１１２を実行するスレッド“Ｚ”を割り当てる。
【００２５】
更に、ＲＴＳ２１５は、スレッド“Ｚ”上のＣＯＢＯＬアプリケーション１１２で利用するスレッド資源２１４Ａを作成し、このスレッド資源２１４Ａをスレッド“Ｚ”上のＣＯＢＯＬアプリケーション１１２に提供する。スレッド“Ｚ”上のＣＯＢＯＬアプリケーション１１２は、このスレッド資源２１４Ａに、前々回のデータ“１”及び前回のデータ“２”を設定する。つまり、リクエスト“１”及びリクエスト“２”で得たデータ”１”及び“２”がリクエスト“３”にも引き継がれたことになる。
【００２６】
スレッド“Ｚ”上のＣＯＢＯＬアプリケーション１１２は、データ“１”及びデータ“２”を含むスレッド資源２１４Ａを利用してリクエスト“３”に関わる処理を実行すると、リクエスト“３”のデータ“３”を得る。そして、ＣＯＢＯＬアプリケーション１１２は、そのデータ“３”を含めてスレッド資源２１４Ａを更新する。そして、ＣＯＢＯＬアプリケーション１１２は、今回のデータ“３”、前回のデータ“２”及び前々回のデータ“１”をＪａｖａアプリケーション１１１経由でＷｅｂブラウザ１２０に伝送する。
【００２７】
サーバ２１０では、継続するリクエスト間でレッド資源２１４Ａの一部であるデータのみを引き継ぐが、同一のスレッド資源２１４Ａを引き継ぐことはできない。
【００２８】
さらに、サーバ２１０のＷｅｂアプリケーションの利用形態では、継続するリクエストの実行回数が増加するに連れてデータ量が増え、Ｊａｖａアプリケーション１１１及びＣＯＢＯＬアプリケーション１１２間のネットワーク上の通信負荷が大きくなる。同様に、Ｗｅｂアプリケーションの利用形態では、Ｊａｖａアプリケーション１１１及びＷｅｂブラウザ１２０間のネットワーク上の通信負荷も大きくなる。つまり、Ｗｅｂアプリケーションの利用形態では、継続するリクエスト間でスレッド資源２１４Ａの一部であるデータを引き継ぐことはできるものの、継続するリクエストの実行回数の増加に応じてネットワーク上の通信負荷が大きくなる。
【００２９】
また、近年ではＷｅｂブラウザを使用しなくても、Ｗｅｂアプリケーションを実行できるＷｅｂサービスアプリケーションが広がりつつある。図１３は、Ｗｅｂサービスアプリケーション用サーバ３２０（以下、単にサーバ３２０と称する）のソフトウェア構成を示す。サーバ３２０では、Ｗｅｂサービスクライアントアプリケーション３１０からのリクエストに応じてマルチスレッド方式で手続型ＣＯＢＯＬアプリケーション３２４を実行する。尚、Ｗｅｂサービスクライアントアプリケーション３１０とは、サーバ３２０に対向したクライアント端末が内蔵するアプリケーションに限定するものではなく、サーバ３２０に対向した意味でのアプリケーションに相当する。
【００３０】
サーバ３２０のフレームワーク３２０Ｂは、Ｗｅｂサービスクライアントアプリケーション３１０からのリクエストを受信すると、プロセス３２０Ａ上に実行する複数のスレッド３２１の内、サーバ側のＷｅｂサービスアプリケーション３２３が実行するスレッド３２１を割り当てる。
【００３１】
Ｗｅｂサービスアプリケーション３２３は、手続型ＣＯＢＯＬアプリケーション３２４を同一スレッド３２１上に呼び出す。更に、手続型ＣＯＢＯＬアプリケーション３２４は、ＲＴＳ３２２に対して利用するスレッド資源３２１Ａの作成を依頼する。そして、ＲＴＳ３２２は、資源作成依頼に応じて、スレッド資源３２１Ａを作成し、そのスレッド資源３２１Ａを手続型ＣＯＢＯＬアプリケーション３２４に提供する。
【００３２】
図１３に示す利用形態では、Ｗｅｂサービスクライアントアプリケーション３１０からのリクエストに応じて、サーバ３２０側の手続型ＣＯＢＯＬアプリケーション３２４が実行される。
【００３３】
しかしながら、上記のサーバ３２０では、Ｗｅｂサービスクライアントアプリケーション３１０から、継続する複数のリクエストを受信したとしても、リクエスト毎にＣＯＢＯＬアプリケーション３２４を同一スレッド３２１上で実行できるとは限らない。その結果、上記のサーバ３２０では、リクエスト毎にＣＯＢＯＬアプリケーション３２４を実行するに際し、継続するリクエスト間で同一のスレッド資源３２１Ａを引き継ぐことができない。
【００３４】
そこで、スレッド資源の一部であるデータをリクエスト間で引き継ぐ図１１の方式をサーバ３２０に採用することも考えられるが、継続するリクエストの実行回数の増加に応じてクライアント及びサーバ間のネットワーク負荷が大きくなってしまう。しかも、その場合、継続するリクエスト間で引き継ぐ資源は、スレッド資源の一部のデータに過ぎず、スレッド資源自体を引き継ぐものではない。
【００３５】
以下、図面に基づいて、本願の開示する資源管理プログラム、資源管理装置及び資源管理方法の実施例を詳細に説明する。尚、本実施例により、開示技術が限定されるものではない。
【実施例１】
【００３６】
図１は、実施例１のサーバ装置（以下、単にサーバと称する）の内部構成を示す説明図である。サーバ１は、複数のスレッドを実行するマルチスレッド方式を採用していても良い。サーバ１は、スレッド割当部１１と、呼出部１２と、資源提供部１３と、セッションＩＤ発行部１４と、資源管理部１５と、処理部１６とを有する。
【００３７】
スレッド割当部１１は、リクエストを受信すると、リクエストにより要求される処理を実行するスレッドを処理部１６に割り当てる。呼出部１２は、同一スレッド上にリクエストに要求された、手続型言語で記述されたアプリケーションを呼び出す。
【００３８】
資源提供部１３は、アプリケーションからの資源要求に応じて、アプリケーションが利用する資源をスレッド上のアプリケーションに提供する。セッションＩＤ発行部１４は、受信したリクエストに使用されたセッションを識別するセッションＩＤを発行する。セッションＩＤ発行部１４は、セッションＩＤの発行を資源判定部１３Ａの判定に応じて行なう。
【００３９】
処理部１６は、スレッド割当部１１に割り当てられたスレッドで、呼出部１２が呼び出したアプリケーションを、資源提供部１３が提供した資源を用いて実行する。サーバ１がマルチスレッド方式を採用している場合、スレッド割当部１１は、処理部１６に複数のスレッドを割り当て可能である。
【００４０】
資源管理部１５は、スレッド上のアプリケーションの実行処理が完了すると、アプリケーションが使用した資源をスレッドから待避させる。更に、資源管理部１５は、待避させた資源を、リクエストに使用されたセッションを識別するセッションＩＤに対応付けて管理する。
【００４１】
資源提供部１３は、資源判定部１３Ａと、資源復元部１３Ｂとを有する。資源判定部１３Ａは、アプリケーションに対して資源を提供する際に、リクエストに使用されたセッションのセッションＩＤを受信すると、セッションＩＤに対応した資源が資源管理部１５にあるか否かを判定する。資源復元部１３Ｂは、資源判定部１３ＡがセッションＩＤに対応した資源があると判定した場合に、当該資源をリクエストに関わるアプリケーション上に復元する。資源判定部１３Ａが、セッションＩＤに対応した資源が資源管理部１５にないと判定した場合に、セッションＩＤ発行部１４にセッションＩＤを発行させる。
【００４２】
実施例１では、複数のセッションのそれぞれにおいてリクエストを受信したとしても、リクエストが使用するセッションのセッションＩＤをキーにして資源を管理し、継続するリクエスト間で同一の資源を引き継ぐことができる。
【実施例２】
【００４３】
図２は、実施例２のＷｅｂサービスアプリケーションの利用形態を示す説明図である。図３は、実施例２のＷｅｂサービスアプリケーション用サーバ装置の内部構成を示す説明図である。図２に示すＷｅｂサービスアプリケーション用サーバ装置(以下、単にサーバと称する)１Ａは、Ｗｅｂサービスクライアントアプリケーション３ＡからＷｅｂサービスアプリケーション４Ａ経由で手続型ＣＯＢＯＬアプリケーション５Ａに対するリクエストを受け付ける。
【００４４】
図２に示すサーバ１Ａのプロセス２０上では、複数のスレッド２１及びＲＴＳ２２を実行している。図３に示すサーバ１Ａは、スレッド割当部３１と、ＣＯＢＯＬ呼出部４１と、ＩＤ発行依頼部４２と、ＩＤ通知部４３と、モード設定部４４と、処理部４５とを有する。スレッド割当部３１は、Ｗｅｂサービスクライアントアプリケーション３Ａからリクエストを受信すると、リクエストに要求される処理、例えば、複数のスレッド２１の内、Ｗｅｂサービスアプリケーション４Ａが実行するスレッド２１を処理部４５に割り当てる。
【００４５】
ＣＯＢＯＬ呼出部４１は、Ｗｅｂサービスアプリケーション４Ａが実行する同一スレッド２１上にリクエストに要求された手続型ＣＯＢＯＬアプリケーション５Ａを呼び出す。ＩＤ発行依頼部４２は、リクエストが使用するセッションを識別するセッションＩＤの発行をＲＴＳ２２に依頼する。尚、セッションは、Ｗｅｂサービスクライアントアプリケーション３Ａ及びＷｅｂサービスアプリケーション４Ａ間のリクエストに使用したセッションに相当する。また、ＩＤ発行依頼部４２は、同一スレッド２１上の手続型ＣＯＢＯＬアプリケーション５Ａの実行が完了すると、同リクエストに使用したセッションＩＤの更新をＲＴＳ２２に依頼する。
【００４６】
ＩＤ通知部４３は、Ｗｅｂサービスクライアントアプリケーション３Ａ又はＲＴＳ２２に対してセッションＩＤを通知する。モード設定部４４は、ＣＯＢＯＬアプリケーション５Ａが利用する資源５Ｂとして、スレッド資源を使用する通常モード又はＥＸＴＥＲＮＡＬ資源を使用するＥＸＴＥＲＮＡＬモードに設定する。
【００４７】
また、サーバ１Ａは、資源提供部５１と、セッションＩＤ発行部５２と、資源管理部５３とを有する。資源提供部５１は、スレッド２１上で実行する手続型ＣＯＢＯＬアプリケーション５Ａからの資源要求に応じて資源５ＢをＣＯＢＯＬアプリケーション５Ａに提供する。セッションＩＤ発行部５２は、スレッド２１上で実行するＷｅｂサービスアプリケーション４ＡのＩＤ発行依頼部４２からのＩＤ発行依頼を受信すると、リクエストに使用されたセッションを識別するセッションＩＤを発行する。セッションＩＤ発行部５２は、ＩＤ発行依頼部４２の更新依頼を受信すると、当該セッションＩＤを更新し、そのセッションＩＤをＷｅｂサービスアプリケーション４Ａに再通知する。
【００４８】
資源管理部５３は、リクエストに使用したセッションを識別するセッションＩＤに対応付けて、当該リクエストに関わる手続型ＣＯＢＯＬアプリケーション５Ａに利用した資源５Ｂを管理する。尚、資源５Ｂは、スレッド資源又はＥＸＴＥＲＮＡＬ資源に相当する。また、処理部４５は、スレッド割当部３１に割り当てられたスレッド２１で、ＣＯＢＯＬ呼出部４１が呼び出した手続型ＣＯＢＯＬアプリケーション５Ａを、資源提供部５１が提供した資源５Ｂを用いて実行する。サーバ１Ａがマルチスレッド方式を採用している場合、スレッド割当部３１は、処理部４５に複数のスレッド２１を割当可能としている。
【００４９】
また、資源提供部５１は、資源判定部６１と、資源復元部６２と、資源作成部６３と、資源待避部６４とを有する。資源判定部６１は、手続型ＣＯＢＯＬアプリケーション５Ａからの資源要求に応じて資源５Ｂを提供する際にリクエストが使用するセッションのセッションＩＤを受信すると、セッションＩＤに対応した資源が資源管理部５３内にあるか否かを判定する。
【００５０】
資源復元部６２は、資源判定部６１にてセッションＩＤに対応した資源がある場合に、資源をリクエストに関わる手続型ＣＯＢＯＬアプリケーション５Ａに復元する。資源作成部６３は、資源判定部６１にてセッションＩＤに対応する資源がない場合に、リクエストに関わる手続型ＣＯＢＯＬアプリケーション５Ａに新たな資源を作成する。資源待避部６４は、スレッド２１上の手続型ＣＯＢＯＬアプリケーション５Ａの実行処理が完了すると、手続型ＣＯＢＯＬアプリケーション５Ａが使用した資源を手続型ＣＯＢＯＬアプリケーション５Ａから待避する。更に、資源待避部６４は、待避した資源をセッションＩＤに対応付けて資源管理部５３に管理する。
【００５１】
図４は、資源管理部５３内部のテーブル構成を詳細に示す説明図である。資源管理部５３は、リクエスト５３Ｃ毎に、セッションＩＤ５３Ａ、資源５３Ｂ及び実行スレッド５３Ｄを管理する。ＲＴＳ２２は、資源管理部５３を参照して、クライアント甲の１回目のリクエストに関し、セッションＩＤが“ＳＥＳＳＩＯＮ Ａ”、資源５３Ｂがスレッド資源“Ａ”の新規作成、実行スレッドが“Ｘ”と認識する。また、ＲＴＳ２２は、クライアント甲の２回目のリクエストに関し、セッションＩＤが“ＳＥＳＳＩＯＮ Ａ”、資源５３Ｂがスレッド資源“Ａ”の復元、実行スレッドが“Ｙ”と認識する。
【００５２】
次に、実施例２のサーバ１Ａの動作について説明する。図５は、サーバ１Ａの動作を示す説明図である。尚、Ｗｅｂサービスアプリケーション４Ａは、例えば、ＣＯＢＯＬ呼出部４１、ＩＤ発行依頼部４２、ＩＤ通知部４３及びモード設定部４４を使用する。更に、ＲＴＳ２２は、例えば、資源提供部５１、セッションＩＤ発行部５２及び資源管理部５３を使用する。図５に示すサーバ１Ａのフレームワーク３０は、Ｗｅｂサービスクライアントアプリケーション３Ａから初回のリクエスト“１”を受信すると、Ｗｅｂサービスアプリケーション４Ａを実行するスレッド２１“Ｘ”を割り当てる。Ｗｅｂサービスアプリケーション４Ａは、同一スレッド２１“Ｘ”上に手続型ＣＯＢＯＬアプリケーション５Ａを呼び出す。手続型ＣＯＢＯＬアプリケーション５Ａは、ＲＴＳ２２から利用する資源５Ｂを取得する。
【００５３】
更に、Ｗｅｂサービスアプリケーション４Ａは、同一スレッド２１“Ｘ”上の手続型ＣＯＢＯＬアプリケーション５Ａの実行が完了すると、初回のリクエスト“１”のセッションを識別するセッションＩＤの発行依頼をＲＴＳ２２に通知する。ＲＴＳ２２は、セッションＩＤを発行し、そのセッションＩＤをＷｅｂサービスアプリケーション４Ａに通知する。更に、ＲＴＳ２２は、スレッド２１“Ｘ”上の手続型ＣＯＢＯＬアプリケーション５Ａの資源５Ｂを待避する。更に、Ｗｅｂサービスアプリケーション４Ａは、セッションＩＤを受信すると、そのセッションＩＤをＷｅｂサービスクライアントアプリケーション３Ａに通知する。
【００５４】
次に、フレームワーク３０は、Ｗｅｂサービスクライアントアプリケーション３Ａから２回目のリクエスト“２”及びセッションＩＤを受信すると、Ｗｅｂサービスアプリケーション４Ａを実行するスレッド２１“Ｙ”を割り当てる。Ｗｅｂサービスアプリケーション４Ａは、Ｗｅｂサービスクライアントアプリケーション３ＡからのセッションＩＤを受信すると、セッションＩＤをＲＴＳ２２に通知する。
【００５５】
更に、Ｗｅｂサービスアプリケーション４Ａは、同一スレッド２１“Ｙ”上に手続型ＣＯＢＯＬアプリケーション５Ａを呼び出す。更に、ＲＴＳ２２は、受信したセッションＩＤに対応する資源５Ｂをスレッド２１“Ｙ”上の手続型ＣＯＢＯＬアプリケーション５Ａに復元する。更に、Ｗｅｂサービスアプリケーション４Ａは、同一スレッド２１“Ｙ”上の手続型ＣＯＢＯＬアプリケーション５Ａの実行が完了すると、現在リクエストである２回目のリクエスト“２”のセッションを識別するセッションＩＤの更新をＲＴＳ２２に依頼する。更に、ＲＴＳ２２は、スレッド２１“Ｙ”上の手続型ＣＯＢＯＬアプリケーション５Ａの資源５Ｂを待避すると共に、更新依頼のセッションＩＤを更新してＷｅｂサービスアプリケーション４Ａに再通知する。更に、Ｗｅｂサービスアプリケーション４Ａは、更新したセッションＩＤをＷｅｂサービスクライアントアプリケーション３Ａに通知する。
【００５６】
図６は、Ｗｅｂサービスアプリケーション全体の処理動作を示すフローチャートである。図６においてＷｅｂサービスクライアントアプリケーション３Ａは、手続型ＣＯＢＯＬアプリケーション５Ａの実行リクエストをサーバ１Ａに要求する(Ｓ１１)。サーバ１Ａのスレッド２１上で実行するＷｅｂサービスアプリケーション４Ａは、セッションＩＤが存在するか否かを判定する(Ｓ１２)。
【００５７】
Ｗｅｂサービスアプリケーション４ＡのＩＤ通知部４３は、セッションＩＤが存在する場合(Ｓ１２肯定)、セッションＩＤをＲＴＳ２２に通知する(Ｓ１３)。更に、Ｗｅｂサービスアプリケーション４ＡのＣＯＢＯＬ呼出部４１は、同一スレッド２１上に手続型ＣＯＢＯＬアプリケーション５Ａを呼び出す(Ｓ１４)。
【００５８】
手続型ＣＯＢＯＬアプリケーション５Ａは、自分で使用する資源５Ｂの作成をＲＴＳ２２に依頼する(Ｓ１５)。ＲＴＳ２２は、セッションＩＤが通知済みであるか否かを判定する(Ｓ１６)。ＲＴＳ２２の資源作成部６３は、セッションＩＤが通知済みでない場合(Ｓ１６否定)、新規の資源５Ｂを手続型ＣＯＢＯＬアプリケーション５Ａ側のスレッド２１上に作成する(Ｓ１７)。
【００５９】
また、ＲＴＳ２２の資源復元部６２は、セッションＩＤが通知済みである場合(Ｓ１６肯定)、セッションＩＤと一致する作成済み資源５Ｂを手続型ＣＯＢＯＬアプリケーション５Ａ側のスレッド２１上に復元する(Ｓ１８)。手続型ＣＯＢＯＬアプリケーション５Ａは、資源５Ｂを使用した手続型ＣＯＢＯＬアプリケーション５Ａの実行処理が完了する(Ｓ１９)。更に、Ｗｅｂサービスアプリケーション４Ａは、手続型ＣＯＢＯＬアプリケーション５Ａの実行処理が完了すると、セッションＩＤが存在するか否かを判定する（Ｓ１９Ａ）。
【００６０】
Ｗｅｂサービスアプリケーション４ＡのＩＤ発行依頼部４２は、セッションＩＤが存在しない場合（Ｓ１９Ａ否定）、新規のリクエストと判断し、リクエストが使用するセッションを識別するセッションＩＤ発行をＲＴＳ２２に依頼する(Ｓ２０)。ＲＴＳ２２のセッションＩＤ発行部５２は、セッションＩＤの発行依頼を受信すると、セッションＩＤを発行し、そのセッションＩＤをＷｅｂサービスアプリケーション４Ａに通知する。更に、ＲＴＳ２２の資源待避部６４は、手続型ＣＯＢＯＬアプリケーション５Ａが使用する資源５Ｂを待避する(Ｓ２１)。尚、資源待避部６４は、資源５Ｂを待避すると、当該リクエストのセッションを識別するセッションＩＤに対応付けて資源５Ｂを資源管理部５３に管理する。
【００６１】
Ｗｅｂサービスアプリケーション４Ａは、ＲＴＳ２２からのセッションＩＤを受信すると、セッションＩＤをＷｅｂサービスクライアントアプリケーション３Ａに通知する(Ｓ２２)。そして、Ｗｅｂサービスクライアントアプリケーション３Ａは、手続型ＣＯＢＯＬアプリケーション５Ａへの実行リクエストを完了し(Ｓ２３)、この処理動作を終了する。
【００６２】
Ｗｅｂサービスアプリケーション４Ａは、セッションＩＤが存在する場合（Ｓ１９Ａ肯定）、そのセッションＩＤの更新をＲＴＳ２２に依頼する（Ｓ２４）。そして、ＲＴＳ２２の資源待避部６４は、ＣＯＢＯＬアプリケーション５Ａが使用する資源５Ｂを待避すると共に、そのセッションＩＤを更新してＷｅｂサービスアプリケーション４Ａに再通知し(Ｓ２５)、Ｓ２２に移行する。
【００６３】
図７は、Ｗｅｂサービスアプリケーション４Ａの処理動作を示すフローチャートである。図７においてＷｅｂサービスアプリケーション４Ａは、セッションＩＤを取得し(Ｓ３１)、セッションＩＤが存在するか否かを判定する(Ｓ３２)。Ｗｅｂサービスアプリケーション４ＡのＩＤ通知部４３は、セッションＩＤが存在する場合(Ｓ３２肯定)、セッションＩＤをＲＴＳ２２に通知する通知ＡＰＩを呼び出す(Ｓ３３)。
【００６４】
Ｗｅｂサービスアプリケーション４ＡのＣＯＢＯＬ呼出部４１は、手続型ＣＯＢＯＬアプリケーション５Ａをロードし(Ｓ３４)、同一スレッド２１上に手続型ＣＯＢＯＬアプリケーション５Ａを呼び出す(Ｓ３５)。更に、Ｗｅｂサービスアプリケーション４ＡのＩＤ発行依頼部４２は、セッションＩＤが発行済みであるか否かを判定する（Ｓ３５Ａ）。ＩＤ発行依頼部４２は、セッションＩＤが発行済みでない場合（Ｓ３５Ａ否定）、リクエストに使用したセッションを識別するセッションＩＤの発行をＲＴＳ２２に依頼する(Ｓ３６)。
【００６５】
Ｗｅｂサービスアプリケーション４ＡのＩＤ通知部４３は、セッションＩＤの発行依頼に対応するセッションＩＤを受信すると、セッションＩＤをＷｅｂサービスクライアントアプリケーション３Ａに通知し(Ｓ３７)、この処理動作を終了する。また、Ｗｅｂサービスアプリケーション４ＡのＩＤ通知部４３は、セッションＩＤが発行済みである場合（Ｓ３５Ａ肯定）、そのセッションＩＤの更新をＲＴＳ２２に依頼し（Ｓ３８）、Ｓ３７に移行する。
【００６６】
図８は、手続型ＣＯＢＯＬアプリケーション５Ａの処理動作を示すフローチャートである。図８において手続型ＣＯＢＯＬアプリケーション５Ａは、Ｗｅｂサービスアプリケーション４Ａの呼出動作に応じて初期化処理を実行し（Ｓ４１）、ＣＯＢＯＬソースに指定された作業領域の獲得をＲＴＳ２２に依頼する(Ｓ４２)。手続型ＣＯＢＯＬアプリケーション５Ａは、ＥＸＴＥＲＮＡＬ句指定のデータがあるか否かを判定する(Ｓ４３)。手続型ＣＯＢＯＬアプリケーション５Ａは、ＥＸＴＥＲＮＡＬ句指定のデータがある場合(Ｓ４３肯定)、ＥＸＴＥＲＮＡＬ句指定の領域の獲得をＲＴＳ２２に依頼する(Ｓ４４)。
【００６７】
手続型ＣＯＢＯＬアプリケーション５Ａは、リクエストに応じた動作処理を実行し、その実行結果に基づき作業域の内容や資源５Ｂを更新し(Ｓ４５)、その実行処理を完了すべく、終了処理を実行する(Ｓ４６)。手続型ＣＯＢＯＬアプリケーション５Ａは、終了処理を実行すると、ＣＯＢＯＬソースに指定された作業域の削除をＲＴＳ２２に依頼し(Ｓ４７)、この処理動作を終了する。
【００６８】
また、手続型ＣＯＢＯＬアプリケーション５Ａは、ＥＸＴＥＲＮＡＬ句指定のデータがない場合(Ｓ４３否定)、リクエストに応じた動作処理を実行すべく、Ｓ４５に移行する。
【００６９】
図９は、ＲＴＳ２２の処理動作を示すフローチャートである。図９においてＲＴＳ２２は、Ｗｅｂサービスアプリケーション４ＡからセッションＩＤを受信したか否かを判定する(Ｓ５１)。ＲＴＳ２２は、セッションＩＤを受信しなかった場合(Ｓ５１否定)、新規セッション状態と判断する(Ｓ５２)。ＲＴＳ２２の資源作成部６３は、新規セッション状態と判断した後、手続型ＣＯＢＯＬアプリケーション５Ａから資源５Ｂの作成依頼を受信すると(Ｓ５３)、スレッド資源／ＥＸＴＥＲＮＡＬ資源を新規作成する(Ｓ５４)。
【００７０】
ＲＴＳ２２は、スレッド資源／ＥＸＴＥＲＮＡＬ資源を新規作成すると、手続型ＣＯＢＯＬアプリケーション５Ａの実行処理に応じて必要な情報を更新し(Ｓ５５)、セッションＩＤの発行依頼又は更新依頼を受信したか否かを判定する(Ｓ５６)。ＲＴＳ２２は、セッションＩＤの発行依頼又は更新依頼を受信した場合(Ｓ５６肯定)、ＥＸＴＥＲＮＡＬ動作モードであるか否かを判定する(Ｓ５７)。
【００７１】
ＲＴＳ２２のセッションＩＤ発行部５２は、ＥＸＴＥＲＮＡＬ動作モードである場合(Ｓ５７肯定)、発行依頼に応じてセッションＩＤを発行し、そのセッションＩＤをＷｅｂサービスアプリケーション４Ａに通知する（Ｓ５８）。また、セッションＩＤ発行部５２は、ＥＸＴＥＲＮＡＬ動作モードである場合(Ｓ５７肯定)、更新依頼に応じてセッションＩＤを更新し、そのセッションＩＤをＷｅｂサービスアプリケーション４Ａに再通知する(Ｓ５８)。更に、ＲＴＳ２２の資源待避部６４は、手続型ＣＯＢＯＬアプリケーション５Ａで使用したＥＸＴＥＲＮＡＬ資源を待避し(Ｓ５８)、この処理動作を終了する。尚、資源管理部５３は、この待避したＥＸＴＥＲＮＡＬ資源をセッションＩＤに対応付けて管理する。
【００７２】
また、ＲＴＳ２２のセッションＩＤ発行部５２は、ＥＸＴＥＲＮＡＬ動作モードでない場合(Ｓ５７否定)、発行依頼に応じてセッションＩＤを発行し、そのセッションＩＤをＷｅｂサービスアプリケーション４Ａに通知する（Ｓ５９）。また、セッションＩＤ発行部５２は、ＥＸＴＥＲＮＡＬ動作モードでない場合(Ｓ５７否定)、更新依頼に応じてセッションＩＤを更新し、そのセッションＩＤをＷｅｂサービスアプリケーション４Ａに再通知する（Ｓ５９）。更に、ＲＴＳ２２の資源待避部６４は、手続型ＣＯＢＯＬアプリケーション５Ａを使用したスレッド資源を待避し(Ｓ５９)、この処理動作を終了する。尚、資源管理部５３は、この待避したスレッド資源をセッションＩＤに対応付けて管理する。
【００７３】
また、ＲＴＳ２２は、セッションＩＤの発行依頼又は更新依頼を受信しなかった場合(Ｓ５６否定)、ＥＸＴＥＲＮＡＬ動作モードであるか否かを判定する(Ｓ６０)。ＲＴＳ２２の資源提供部５１は、ＥＸＴＥＲＮＡＬ動作モードである場合(Ｓ６０肯定)、ＥＸＴＥＲＮＡＬ資源を破棄し(Ｓ６１)、この処理動作を終了する。尚、資源管理部５３は、ＥＸＴＥＲＮＡＬ資源及び、そのセッションＩＤを破棄する。
【００７４】
また、ＲＴＳ２２の資源提供部５１は、ＥＸＴＥＲＮＡＬ動作モードでない場合(Ｓ６０否定)、スレッド資源を破棄し(Ｓ６２)、この処理動作を終了する。尚、資源管理部５３は、スレッド資源及び、そのセッションＩＤを破棄する。
【００７５】
また、ＲＴＳ２２の資源判定部６１は、Ｗｅｂサービスアプリケーション４ＡからセッションＩＤを受信した場合(Ｓ５１肯定)、セッションＩＤが資源管理部５３内に存在するか否かを判定する(Ｓ６３)。ＲＴＳ２２の資源判定部６１は、セッションＩＤが資源管理部５３内に存在しなかった場合(Ｓ６３否定)、セッション切断状態と判断する(Ｓ６４)。ＲＴＳ２２は、セッション切断状態と判断した後、手続型ＣＯＢＯＬアプリケーション５Ａからの資源５Ｂの作成依頼を受信すると(Ｓ６５)、スレッド資源／ＥＸＴＥＲＮＡＬ資源を新規作成すべく、Ｓ５４に移行する。
【００７６】
また、ＲＴＳ２２の資源判定部６１は、セッションＩＤが資源管理部５３内に存在した場合(Ｓ６３肯定)、セッション継続状態と判断する(Ｓ６６)。ＲＴＳ２２は、セッション継続状態と判断した後、ＣＯＢＯＬアプリケーション５Ａからの資源作成依頼を受信すると(Ｓ６７)、ＥＸＴＥＲＮＡＬ動作モードであるか否かを判定する(Ｓ６８)。
【００７７】
ＲＴＳ２２の資源復元部６２は、ＥＸＴＥＲＮＡＬ動作モードである場合(Ｓ６８肯定)、資源管理部５３に管理されたセッションＩＤと一致する作成済みのＥＸＴＥＲＮＡＬ資源を現スレッド２１上に復元し(Ｓ６９)、Ｓ５５に移行する。また、ＲＴＳ２２の資源復元部６２は、ＥＸＴＥＲＮＡＬ動作モードでない場合(Ｓ６８否定)、資源管理部５３に管理されたセッションＩＤと一致する作成済みのスレッド資源を現スレッド２１上に復元し(Ｓ７０)、Ｓ５５に移行する。
【００７８】
実施例２では、Ｗｅｂサービスクライアントアプリケーション３Ａから手続型ＣＯＢＯＬアプリケーション５Ａを実行するリクエストを受信すると、当該リクエスト毎にＷｅｂサービスアプリケーション４Ａを実行するスレッド２１を割り当てる。更に、実施例２では、割り当てられたスレッド２１上に手続型ＣＯＢＯＬアプリケーション５Ａを呼び出し、手続型ＣＯＢＯＬアプリケーション５Ａからの資源要求に応じて利用する資源５Ｂを手続型ＣＯＢＯＬアプリケーション５Ａに提供する。その結果、Ｗｅｂサービスクライアントアプリケーション３Ａから手続型ＣＯＢＯＬアプリケーション５ＡをＷｅｂサービスとして呼び出す場合でも、安定したマルチスレッド方式に対応できる。
【００７９】
実施例２では、手続型ＣＯＢＯＬアプリケーション５Ａの実行処理が完了すると、リクエストが使用するセッションのセッションＩＤを発行し、当該手続型ＣＯＢＯＬアプリケーション５Ａに利用した資源５Ｂを待避する。更に、実施例２では、待避した資源５ＢをセッションＩＤに対応付けて資源管理部５３に管理する。その結果、Ｗｅｂサービスクライアントアプリケーション３Ａから複数のリクエストを受信したとしても、継続するリクエスト間で同一の資源５Ｂを引き継ぐことができる。
【００８０】
更に、実施例２では、リクエスト受信時にリクエストに関わるセッションのセッションＩＤに対応した資源５Ｂがある場合、当該資源５Ｂを手続型ＣＯＢＯＬアプリケーション５Ａ上に復元する。その結果、継続するリクエスト間で同一の資源５Ｂを引き継ぐことができる。
【００８１】
更に、実施例２では、リクエスト受信時にリクエストに関わるセッションのセッションＩＤに対応した資源５Ｂがない場合、手続型ＣＯＢＯＬアプリケーション５Ａ上に資源５Ｂを新規作成する。
【００８２】
更に、実施例２では、ＲＴＳ２２側でセッションＩＤを発行すると、そのセッションＩＤをＷｅｂサービスクライアントアプリケーション３Ａに通知する。その結果、継続するリクエストを実行する場合はセッションＩＤを使用して当該セッションＩＤに対応した資源５Ｂをリクエスト間で引き継ぐことができる。
【００８３】
更に、実施例２では、ＥＸＴＥＲＮＡＬモード時に手続型ＣＯＢＯＬアプリケーション５Ａに対して資源５ＢであるＥＸＴＥＲＮＡＬ資源を提供する場合、セッションＩＤに対応付けてＥＸＴＥＲＮＡＬ資源を資源管理部５３に管理する。
【００８４】
更に、実施例２では、ＥＸＴＥＲＮＡＬモードではない通常モード時に手続型ＣＯＢＯＬアプリケーション５Ａに対して資源５Ｂであるスレッド資源を提供する場合、セッションＩＤに対応付けてスレッド資源を資源管理部５３に管理する。
【００８５】
また、図示した各部の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各部の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。
【００８６】
更に、各装置で行われる各種処理機能は、ＣＰＵ（Central Processing Unit）（又はＭＰＵ（Micro Processing Unit）、ＭＣＵ（Micro Controller Unit）等のマイクロ・コンピュータ）上で、その全部又は任意の一部を実行するようにしても良い。また、各種処理機能は、ＣＰＵ（又はＭＰＵ、ＭＣＵ等のマイクロ・コンピュータ）で解析実行するプログラム上、又はワイヤードロジックによるハードウェア上で、その全部又は任意の一部を実行するようにしても良いことは言うまでもない。
【００８７】
ところで、実施例１及び実施例２で説明した各種の処理は、予め用意されたプログラムをコンピュータで実行することによって実現することができる。そこで、以下に、図１０を用いて、上記実施例と同様の機能を有するプログラムを実行するコンピュータの一例を説明する。
【００８８】
同図に示すように、コンピュータ５００は、ＨＤＤ（Hard Disk Drive）５１０、ＲＡＭ(Random Access Memory)５２０、ＲＯＭ（Read Only Memory）５３０及びＣＰＵ５４０を含み、互いをバス５５０で接続して構成される。
【００８９】
そして、ＲＯＭ５３０には、上記の実施例と同様の機能を発揮するプログラムが予め記憶されている。そのプログラムは、スレッド割当プログラム５３１、呼出プログラム５３２、資源提供プログラム５３３、セッションＩＤ発行プログラム５３４及び資源管理プログラム５３５を含む。更に、資源提供プログラム５３３は、資源判定プログラム５３３Ａ及び資源復元プログラム５３３Ｂを含む。尚、プログラム５３１〜５３５については、図１に示したサーバ１の各構成要素と同様、適宜統合又は分散してもよい。
【００９０】
そして、ＣＰＵ５４０が、これらのプログラム５３１〜５３５をＲＯＭ５３０から読み出して実行することで、各プログラム５３１〜５３５は各種プロセスとして機能するようになる。各種プロセスは、スレッド割当プロセス５４１、ＣＯＢＯＬ呼出プロセス５４２、資源提供プロセス５４３、セッションＩＤ発行プロセス５４４及び資源管理プロセス５４５を含む。更に、資源提供プロセス５４３は、資源判定プロセス５４３Ａ及び資源復元プロセス５４３Ｂを含む。各プロセス５４１〜５４５は、図１に示したスレッド割当部１１、呼出部１２、資源提供部１３、資源判定部１３Ａ、資源復元部１３Ｂ、セッションＩＤ発行部１４及び資源管理部１５に夫々対応する。
【００９１】
ＣＰＵ５４０は、クライアントからアプリケーションを実行するリクエストを受信すると、当該リクエスト毎にスレッドを割り当てる。更に、ＣＰＵ５４０は、割り当てられたスレッド上にアプリケーションを呼び出す。更に、ＣＰＵ５４０は、アプリケーションからの資源要求に応じて、アプリケーションが利用する資源を当該アプリケーションに提供する。更に、ＣＰＵ５４０は、リクエストに使用したセッションを識別するセッションＩＤを発行する。
【００９２】
更に、ＣＰＵ５４０は、スレッド上のアプリケーションの実行処理が完了すると、当該アプリケーションが使用した資源をスレッドから待避する。更に、ＣＰＵ５４０は、この待避した資源を当該リクエストが使用するセッションを識別するセッションＩＤに対応付けて管理する。更に、ＣＰＵ５４０は、アプリケーションからの資源要求に応じて資源を提供する際に、当該リクエストが使用するセッションのセッションＩＤを受信すると、当該セッションＩＤに対応した資源があるか否かを判定する。更に、ＣＰＵ５４０は、セッションＩＤに対応した資源がある場合に、当該資源を当該リクエストに関わるアプリケーション上に復元する。
【００９３】
その結果、クライアントから異なるセッションのそれぞれにおいて複数のリクエストを受信したとしても、同一のセッションを使用した複数の継続するリクエスト間で同一の資源を引き継ぐことができる。
【符号の説明】
【００９４】
１ サーバ
１Ａ サーバ
３Ａ Ｗｅｂサービスクライアントアプリケーション
４Ａ Ｗｅｂサービスアプリケーション
５Ａ 手続型ＣＯＢＯＬアプリケーション
５Ｂ 資源
１１ スレッド割当部
１２ 呼出部
１３ 資源提供部
１３Ａ 資源判定部
１３Ｂ 資源復元部
１４ セッションＩＤ発行部
１５ 資源管理部
１６ 処理部
２１ スレッド
２２ ＲＴＳ
３１ スレッド割当部
４１ ＣＯＢＯＬ呼出部
４４ モード設定部
４５ 処理部
５１ 資源提供部
５２ セッションＩＤ発行部
５３ 資源管理部
６１ 資源判定部
６２ 資源復元部
６３ 資源作成部
６４ 資源待避部
【特許請求の範囲】
【請求項１】
コンピュータに、
手続型言語で記述されたプログラムで規定された処理であって、受信した処理要求に要求される処理をスレッドに割り当て、
セッションを識別する識別情報とスレッド資源とを予め関連付けて記憶する記憶手段から、前記処理要求についての通信に使用されたセッションを識別する識別情報と関連付けられて記憶されたスレッド資源を読み出し、
読み出した前記スレッド資源を用いて、前記スレッドに割り当てた前記処理を実行すること
を実行させることを特徴とする資源管理プログラム。
【請求項２】
前記コンピュータに、さらに、
前記処理の終了後に、前記スレッド資源を、前記処理要求についての通信に使用されたセッション識別する識別情報に関連付けて前記記憶手段に記憶すること
を実行させることを特徴とする請求項１に記載の資源管理プログラム。
【請求項３】
前記コンピュータに、
前記記憶手段に前記処理要求についての通信に使用されたセッションを識別する識別情報が記憶されていない場合に、新たにスレッド資源を作成すること
を実行させることを特徴とする請求項１又は２に記載の資源管理プログラム。
【請求項４】
前記コンピュータに、
前記アプリケーションのソースプログラムで処理に用いるスレッド資源を指定している場合には、指定されたスレッド資源を用いて前記処理を実行すること
を実行させることを特徴とする請求項１〜３のいずれか１つに記載の資源管理プログラム。
【請求項５】
手続型言語で記述されたプログラムで規定された処理であって、受信した処理要求に要求される処理をスレッドに割り当てるスレッド割当部と、
セッションを識別する識別情報とスレッド資源とを予め関連付けて記憶する記憶部と、
前記記憶部から、前記処理要求についての通信に使用されたセッションを識別する識別情報と関連付けられて記憶されたスレッド資源を読み出す資源提供部と、
前記読み出した前記スレッド資源を用いて、前記スレッドに割り当てた前記処理を実行する処理部と
を有することを特徴とする資源管理装置。
【請求項６】
手続型言語で記述されたプログラムで規定された処理であって、受信した処理要求に要求される処理をスレッドに割り当て、
セッションを識別する識別情報とスレッド資源とを予め関連付けて記憶する記憶手段から、前記処理要求についての通信に使用されたセッションを識別する識別情報と関連付けられて記憶されたスレッド資源を読み出し、
読み出した前記スレッド資源を用いて、前記スレッドに割り当てた前記処理を実行することを特徴とする資源管理方法。
【請求項１】
コンピュータに、
手続型言語で記述されたプログラムで規定された処理であって、受信した処理要求に要求される処理をスレッドに割り当て、
セッションを識別する識別情報とスレッド資源とを予め関連付けて記憶する記憶手段から、前記処理要求についての通信に使用されたセッションを識別する識別情報と関連付けられて記憶されたスレッド資源を読み出し、
読み出した前記スレッド資源を用いて、前記スレッドに割り当てた前記処理を実行すること
を実行させることを特徴とする資源管理プログラム。
【請求項２】
前記コンピュータに、さらに、
前記処理の終了後に、前記スレッド資源を、前記処理要求についての通信に使用されたセッション識別する識別情報に関連付けて前記記憶手段に記憶すること
を実行させることを特徴とする請求項１に記載の資源管理プログラム。
【請求項３】
前記コンピュータに、
前記記憶手段に前記処理要求についての通信に使用されたセッションを識別する識別情報が記憶されていない場合に、新たにスレッド資源を作成すること
を実行させることを特徴とする請求項１又は２に記載の資源管理プログラム。
【請求項４】
前記コンピュータに、
前記アプリケーションのソースプログラムで処理に用いるスレッド資源を指定している場合には、指定されたスレッド資源を用いて前記処理を実行すること
を実行させることを特徴とする請求項１〜３のいずれか１つに記載の資源管理プログラム。
【請求項５】
手続型言語で記述されたプログラムで規定された処理であって、受信した処理要求に要求される処理をスレッドに割り当てるスレッド割当部と、
セッションを識別する識別情報とスレッド資源とを予め関連付けて記憶する記憶部と、
前記記憶部から、前記処理要求についての通信に使用されたセッションを識別する識別情報と関連付けられて記憶されたスレッド資源を読み出す資源提供部と、
前記読み出した前記スレッド資源を用いて、前記スレッドに割り当てた前記処理を実行する処理部と
を有することを特徴とする資源管理装置。
【請求項６】
手続型言語で記述されたプログラムで規定された処理であって、受信した処理要求に要求される処理をスレッドに割り当て、
セッションを識別する識別情報とスレッド資源とを予め関連付けて記憶する記憶手段から、前記処理要求についての通信に使用されたセッションを識別する識別情報と関連付けられて記憶されたスレッド資源を読み出し、
読み出した前記スレッド資源を用いて、前記スレッドに割り当てた前記処理を実行することを特徴とする資源管理方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公開番号】特開２０１２−４８６７４（Ｐ２０１２−４８６７４Ａ）
【公開日】平成２４年３月８日（２０１２．３．８）
【国際特許分類】
【出願番号】特願２０１０−１９２８１５（Ｐ２０１０−１９２８１５）
【出願日】平成２２年８月３０日（２０１０．８．３０）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成２４年３月８日（２０１２．３．８）
【国際特許分類】
【出願日】平成２２年８月３０日（２０１０．８．３０）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]