(57)【要約】【課題】リクエストを処理する計算機のアプリケーションを更新した場合に、リクエストが保持するセッションなどのパラメータに応じて、更新前のアプリケーションと更新後のアプリケーションに処理を振り分けることを課題とする。【解決手段】本発明において、計算機４は、クライアント１からリクエストを受信した場合、当該リクエストに含まれるパラメータごとに、対応する判定フィルタを用いて更新前のアプリケーションと更新後のアプリケーションとで当該リクエストの処理結果が異なるか否かを判定し、すべてのパラメータについて処理結果が異ならないと判定したときは、更新後のアプリケーションで当該リクエストを処理し、少なくともいずれかのパラメータについて処理結果が異なると判定したときは、更新前のアプリケーションで当該リクエストを処理することができる。【選択図】図１
2010097525.tif 000002
【特許請求の範囲】
【請求項１】
リクエストを送信するコンピュータ装置であるクライアントと、前記クライアントからリクエストを受信してレスポンスを送信する１台以上の計算機と、前記計算機に配備されたリクエスト対応用のアプリケーションを管理する計算機管理装置と、が互いにネットワークで接続される計算機システムであって、
前記計算機管理装置は、前記計算機に配備されたアプリケーションを更新する場合、前記計算機に対して、更新前のアプリケーションに加えて更新後のアプリケーションを配備するとともに、リクエストに含まれるパラメータごとに前記更新前のアプリケーションと前記更新後のアプリケーションとでリクエストの処理結果が異なるか否かを判定するための判定フィルタを生成して配備する
ことを特徴とする計算機システム。
【請求項２】
前記計算機は、
前記クライアントからリクエストを受信した場合、当該リクエストに含まれるパラメータを抽出し、当該パラメータごとに、対応する前記判定フィルタを用いて前記更新前のアプリケーションと前記更新後のアプリケーションとで当該リクエストの処理結果が異なるか否かを判定し、
すべてのパラメータについて前記処理結果が異ならないと判定したときは、前記更新後のアプリケーションで当該リクエストを処理し、
少なくともいずれかのパラメータについて前記処理結果が異なると判定したときは、前記更新前のアプリケーションで当該リクエストを処理する
ことを特徴とする請求項１に記載の計算機システム。
【請求項３】
リクエストを送信するコンピュータ装置であるクライアントと、前記クライアントからリクエストを受信してレスポンスを送信する１台以上の計算機と、前記計算機に配備されたリクエスト対応用のアプリケーションを管理する計算機管理装置と、が互いにネットワークで接続される計算機システムにおけるアプリケーション更新方法であって、
前記計算機管理装置は、前記計算機に配備されたアプリケーションを更新する場合、前記計算機に対して、更新前のアプリケーションに加えて更新後のアプリケーションを配備するとともに、リクエストに含まれるパラメータごとに前記更新前のアプリケーションと前記更新後のアプリケーションとでリクエストの処理結果が異なるか否かを判定するための判定フィルタを生成して配備する
ことを特徴とするアプリケーション更新方法。
【請求項４】
前記計算機は、
前記クライアントからリクエストを受信した場合、当該リクエストに含まれるパラメータを抽出し、当該パラメータごとに、対応する前記判定フィルタを用いて前記更新前のアプリケーションと前記更新後のアプリケーションとで当該リクエストの処理結果が異なるか否かを判定し、
すべてのパラメータについて前記処理結果が異ならないと判定したときは、前記更新後のアプリケーションで当該リクエストを処理し、
少なくともいずれかのパラメータについて前記処理結果が異なると判定したときは、前記更新前のアプリケーションで当該リクエストを処理する
ことを特徴とする請求項３に記載のアプリケーション更新方法。
【請求項５】
リクエストを送信するコンピュータ装置であるクライアントと、前記クライアントからリクエストを受信してレスポンスを送信する１台以上の計算機と、前記計算機に配備されたリクエスト対応用のアプリケーションを管理する計算機管理装置と、が互いにネットワークで接続される計算機システムにおける前記計算機管理装置であって、
前記計算機に配備されたアプリケーションを更新する場合の更新後のアプリケーションを記憶する記憶部と、
前記計算機に配備されたアプリケーションを更新する場合、前記計算機に対して、更新前のアプリケーションに加えて前記記憶部に記憶した更新後のアプリケーションを配備するとともに、リクエストに含まれるパラメータごとに前記更新前のアプリケーションと前記更新後のアプリケーションとでリクエストの処理結果が異なるか否かを判定するための判定フィルタを生成して配備する処理部と、
を備えることを特徴とする計算機管理装置。
【請求項６】
リクエストを送信するコンピュータ装置であるクライアントと、前記クライアントからリクエストを受信してレスポンスを送信する１台以上の計算機と、前記計算機に配備されたリクエスト対応用のアプリケーションを管理する計算機管理装置と、が互いにネットワークで接続される計算機システムにおいて、前記計算機に配備されたアプリケーションを更新する場合の更新後のアプリケーションを記憶する記憶部と、処理部と、を有する前記計算機管理装置によるアプリケーション更新方法であって、
前記計算機管理装置の処理部は、
前記計算機に配備されたアプリケーションを更新する場合、前記計算機に対して、更新前のアプリケーションに加えて前記記憶部に記憶した更新後のアプリケーションを配備するとともに、リクエストに含まれるパラメータごとに前記更新前のアプリケーションと前記更新後のアプリケーションとでリクエストの処理結果が異なるか否かを判定するための判定フィルタを生成して配備する
ことを特徴とするアプリケーション更新方法。
【請求項７】
請求項６に記載のアプリケーション更新方法をコンピュータに実行させるためのアプリケーション更新プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インターネットなどのネットワーク上でアプリケーションサービスを実行する計算機に対するアプリケーションの更新（設定の変更）の技術に関する。
【背景技術】
【０００２】
近年、Ｗｅｂ技術の進歩により、アプリケーションは、Ｗｅｂアプリケーションとして計算機に実装される場合が増えている。
Ｗｅｂアプリケーションは、一度公開した後にも、機能修正や追加などのバージョンアップや、状況に応じてアプリケーションの設定を適切に変更するなどの保守作業を行う必要がある。このバージョンアップや設定の変更は、Ｗｅｂアプリケーションを入れ替えることによって行う。
【０００３】
Ｗｅｂアプリケーションの入れ替えは、Ｗｅｂアプリケーションを一旦停止して、Ｗｅｂアプリケーションを入れ替え、再度Ｗｅｂアプリケーションを開始することで実現できる。しかし、この方法では、一時的にアプリケーションサービスを中断することになってしまう。
この問題に対し、ユーザ（クライアント）からのリクエストの受付を停止することなく、Ｗｅｂアプリケーションを代替のＷｅｂアプリケーションに入れ替える方法が知られている（例えば、特許文献１参照）。
【特許文献１】特開２００６−３３８０６９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかし、上記の特許文献１の技術では、特定のタイミングでＷｅｂアプリケーションを代替のＷｅｂアプリケーションに入れ替え、以降のリクエストを全て代替のＷｅｂアプリケーションで処理する。そのため、入れ替え前のＷｅｂアプリケーションで実行させたいリクエストを受信しても、代替のＷｅｂアプリケーションで実行されるという問題がある。
【０００５】
上記の問題が発生する場合の一つとして、Ｗｅｂアプリケーションの設定を変更して入れ替えた場合がある。設定は、変更すると、アプリケーションの入れ替え前後で、アプリケーションの実行結果が変化する可能性があるものを含む。例えば、接続先のデータベースに関する設定がある。接続先のデータベースを変更した場合、アプリケーションの実行結果が変わる可能性があり、一連のセッションにおける処理の途中でアプリケーションを入れ替えてしまうと、不正な処理となる場合がある。このような場合、アプリケーション入れ替え前からセッション継続中のリクエストに対しては、古い設定で動作するアプリケーションで処理を実行させるべきである。
【０００６】
そこで、本発明は、前記した問題に鑑みてなされたものであり、計算機においてアプリケーションを更新（設定の変更）した場合に、リクエストが保持するセッションなどのパラメータに応じて、古い設定で動作する（更新前の）アプリケーションと新しい設定で動作する（更新後の）アプリケーションに処理を振り分けることを課題とする。
【課題を解決するための手段】
【０００７】
前記課題を解決するために、本発明は、リクエストを送信するコンピュータ装置であるクライアントと、クライアントからリクエストを受信してレスポンスを送信する１台以上の計算機と、計算機に配備されたリクエスト対応用のアプリケーションを管理する計算機管理装置と、が互いにネットワークで接続される計算機システムである。
計算機管理装置は、計算機に配備されたアプリケーションを更新する場合、計算機に対して、更新前のアプリケーションに加えて更新後のアプリケーションを配備するとともに、リクエストに含まれるパラメータごとに更新前のアプリケーションと更新後のアプリケーションとでリクエストの処理結果が異なるか否かを判定するための判定フィルタを生成して配備する。
その他の手段については後記する。
【発明の効果】
【０００８】
本発明によれば、計算機においてアプリケーションを更新（設定の変更）した場合に、リクエストが保持するセッションなどのパラメータに応じて、古い設定で動作する（更新前の）アプリケーションと新しい設定で動作する（更新後の）アプリケーションに処理を振り分けることができる。
【発明を実施するための最良の形態】
【０００９】
以下、図面を参照（言及図以外の図も適宜参照）して、本発明を実施するための最良の形態（以下、実施形態という。）について説明する。図１は、本発明の実施形態を適用する計算機システムを示す構成図である。
計算機システムＳは、クライアント１、負荷分散装置２、計算機管理装置３、複数台の計算機４から構成され、それぞれネットワークで接続されている。
【００１０】
クライアント１は、ユーザが使用するコンピュータ装置であり、計算機４に対してリクエスト（要求）を送信する。複数のリクエストにわたって、同じセッション情報を継続する。リクエストは上記セッションを識別するためのセッションＩＤ（IDentification）や、クライアント１と計算機４間の認証に用いるユーザ名およびパスワードなどのパラメータを保持する（含んでいる）。
【００１１】
クライアント１から送信されたリクエストは、負荷分散装置２が受信する。負荷分散装置２は、従来の分配方法（レスポンス時間に応じて転送するなど）を用いて、ネットワークで接続されている計算機４へリクエストを振り分ける。
リクエストを受信した計算機４は、リクエストを処理し、負荷分散装置２へレスポンスを送信する。
レスポンスを受信した負荷分散装置２は、クライアント１へレスポンスを転送する。
【００１２】
クライアント１は、ＣＰＵ（Central Processing Unit）１１、メモリ１２、通信インタフェース１３を備えて構成される。
負荷分散装置２は、ＣＰＵ２１、メモリ２２、通信インタフェース２３を備えて構成される。
計算機管理装置３は、ＣＰＵ３１（処理部）、メモリ３２（記憶部）、通信インタフェース３３、ハードディスク３４（記憶部）、入力装置３５を備えて構成される。
【００１３】
メモリ３２は、オペレーティングシステム３２１、計算機管理部３２２を記憶している。
計算機管理部３２２は、差分項目解析処理部３２２１、設定ファイル生成処理部３２２２、設定管理部３２２３、インポート処理部３２２４から構成され、計算機システムＳの構成を管理する役割を担当する。これらは、計算機システムＳに接続されている負荷分散装置２や計算機４の台数およびネットワーク上のアドレスを管理している（詳細は後記）。また、入力装置３５からの入力に応じ、差分項目解析処理部３２２１、設定ファイル生成処理部３２２２、設定管理部３２２３、インポート処理部３２２４による処理を行い、計算機４にアプリケーションのインポート処理（他のアプリケーション（ソフトウェア）で作成したファイルを読み込み、データを変換して利用できるようにする処理）および入れ替え処理を指示する。計算機管理部３２２は、オペレーティングシステム３２１上で実行される。なお、本実施形態において、アプリケーションは、例えば、Ｗｅｂアプリケーションである。Ｗｅｂアプリケーションは、例えば、Ｊａｖａ（登録商標）ＶＭ（Virtual Machine）上や、Ｊａｖａ（登録商標）ＶＭで動作するミドルウェア上で動作する。
【００１４】
ハードディスク３４は、設定項目分類定義ファイル９０を記憶している。
設定項目分類定義ファイル９０は、アプリケーションの各設定項目とそれに影響のあるリクエストのパラメータの対応付けが記述されたファイルである。
計算機４にアプリケーションをインポートする場合、アプリケーションの開発者または運用者は、インポートする（アプリケーションの）パッケージ３４１に設定ファイル９５１（詳細は図８）を含ませ、入力装置３５を用いてインポート処理の指示を入力する。設定管理部３２２３は、アプリケーションの設定を管理する役割を担当し、設定ファイル９５１および後記する差分適用後の設定ファイル９５３（詳細は図１０）を、設定管理テーブル９１に登録する。登録後、インポート処理部３２２４が、計算機４にインポート処理を指示する。
【００１５】
計算機４で動作しているアプリケーションを入れ替える場合、アプリケーションの開発者または運用者は、入れ替えるパッケージ３４２に差分設定ファイル９５２（詳細は図９）を含ませ、入力装置３５を用いて入れ替え処理の指示を入力する。差分項目解析処理部３２２１は、設定項目分類定義ファイル９０を参照し、差分設定ファイル９５２に記述されている設定項目に影響のあるリクエストのパラメータを解析（特定）する役割を担当する。設定ファイル生成処理部３２２２は、差分設定ファイル９５２と、設定管理テーブル９１に登録されている現在の設定を融合し、差分適用後の設定ファイル９５３を生成する。生成した差分適用後の設定ファイル９５３は、設定管理部３２２３により、設定管理テーブル９１に登録される。この登録後、インポート処理部３２２４が、計算機４に入れ替え処理を指示する。
【００１６】
計算機４は、ＣＰＵ４１、メモリ４２、通信インタフェース４３を備えて構成される。
メモリ４２は、オペレーティングシステム４２１、Ｊａｖａ（登録商標）ＶＭ４２２、アプリケーション実行部４２３を記憶している。
Ｊａｖａ（登録商標）ＶＭ４２２は、アプリケーション実行部４２３の実行環境であり、オペレーティングシステム４２１上で実行される。
アプリケーション実行部４２３は、アプリケーションの実行環境で、例えばミドルウェアであり、Ｊａｖａ（登録商標）ＶＭ４２２上で実行される。
【００１７】
図２は、図１のハードディスク３４が記憶している設定項目分類定義ファイル９０の一例を示す構成図である。
設定項目分類定義ファイル９０は、設定項目とリクエストの保持するパラメータを対応付けて管理する。リクエストの保持するパラメータの例として、セッション、Authorizationヘッダ、Content-Typeヘッダ、Accept-Charsetヘッダなどがある。
【００１８】
列９０１には、アプリケーションの設定の設定項目名を登録する。
列９０２から列９０５には、各パラメータが列９０１に登録されている設定項目に影響があるかどうかを登録する。「○」の場合、設定項目の設定を変更してアプリケーションを入れ替えた場合、当該パラメータを保持したリクエストを受信すると、入れ替え前と入れ替え後で、実行結果が異なる可能性があることを示す。「×」の場合、実行結果が異なる可能性がないことを示す。
【００１９】
行９０６は、設定項目「/war/description」に影響のあるパラメータは存在しないことを示している（すべて「×」である）。このような設定項目の場合、アプリケーションを入れ替えたとしても、入れ替え前後で実行結果に影響がないため、すべてのリクエストを新しい設定で実行して問題がない。
行９０７は、設定項目「/war/resource」はセッションのパラメータに影響を受けることを示している（セッションだけ「○」となっている）。このような設定項目の場合、入れ替え前後で実行結果に影響があるため、アプリケーション入れ替え前からセッション継続中のリクエストを受信した場合に、古い設定で実行する必要がある。セッション継続中ではない場合は、新しい設定で実行して問題がない。
その他の行についても同様であるので、説明を省略する。
【００２０】
図３は、図１の設定管理部３２２３が有する設定管理テーブル９１の一例を示す構成図である。
設定管理テーブル９１は、アプリケーション名と、アプリケーションのコンテキストルート（コンテキストパス）および実行中のアプリケーションの設定ファイルを対応付けて管理する。
列９１１には、アプリケーション名を登録する。
列９１２には、列９１１のアプリケーション名に対応したアプリケーションのコンテキストルートを登録する。
列９１３には、列９１１のアプリケーション名に対応した設定ファイルを登録する。
【００２１】
行９１４は、アプリケーション名「App」であるアプリケーションのコンテキストルートは「/App」であり、設定ファイル「conf_App.xml」の設定で動作していることを示している。
【００２２】
図４は、図１のメモリ４２が記憶しているアプリケーション実行部４２３の詳細を示す構成図である。
アプリケーション実行部４２３は、アプリケーション管理部４２３１、デプロイ処理部４２３２、セッション管理部４２３３、コンテナ４２３４から構成される。
コンテナ４２３４上では、実行対象プログラム５が実行される。一つの実行対象プログラム５は、リクエスト転送部５１、古い設定で動作する業務処理部５２、新しい設定で動作する業務処理部５３から構成される。なお、以下、単に「業務処理部」というときは、古い設定で動作する業務処理部５２、および、新しい設定で動作する業務処理部５３の両方、あるいは、両方ありえる場合のいずれかを指すものとする。
業務処理部は、アプリケーションに含まれる業務処理を実行する役割を担当する。古い設定で動作する業務処理部５２、および、新しい設定で動作する業務処理部５３は、異なる設定で動作している。
【００２３】
リクエスト転送部５１は、リクエストを受信し、業務処理部へ転送する役割を担当し、自身が含まれる実行対象プログラム５内で動作する業務処理部を管理する転送先管理テーブル９４と、業務処理部のいずれにリクエストを転送するのか判定する処理を行う転送先判定フィルタ５１１を有している。転送先判定フィルタ５１１は、リクエストのパラメータに対応して存在し、例えば、セッションのパラメータに対応した判定処理を行うセッション判定フィルタ５１１１などがある（セッション以外のパラメータに対応した判定処理を行う判定フィルタについては、図示と説明を省略する）。
【００２４】
図１の負荷分散装置２から計算機４にリクエストが送信されると、リクエスト転送部５１がリクエストを受信する。リクエスト転送部５１は、転送先管理テーブル９４を参照し、転送先判定フィルタ５１１による判定処理の結果でリクエストを特定の業務処理部へ転送する。リクエストを受信した一方の業務処理部は業務処理を実行し、レスポンスをリクエスト転送部５１へ送信する。レスポンスを受信したリクエスト転送部５１は、レスポンスを負荷分散装置２へ送信する。
【００２５】
アプリケーション管理部４２３１は、コンテナ４２３４上で実行される実行対象プログラム５の生成や管理の役割を担当する。アプリケーション管理部４２３１は、図１のインポート処理部３２２４からインポート処理の指示および入れ替え処理の指示を受信すると、リクエスト転送部５１および業務処理部を生成する。生成したリクエスト転送部５１と業務処理部は、デプロイ処理部４２３２により、コンテナ４２３４にデプロイ（配備）される。また、生成したリクエスト転送部５１と業務処理部は、アプリケーション管理テーブル９２に登録され、管理される。
【００２６】
セッション管理部４２３３は、セッション情報を管理する役割を担当する。保持するセッション情報は、セッション管理テーブル９３に登録され、管理される。転送先判定フィルタ５１１の一つであるセッション判定フィルタ５１１１の判定処理では、セッション管理テーブル９３の情報を元に、業務処理部のいずれかへの振り分け判定を行う。
【００２７】
図５は、図４のアプリケーション管理部４２３１が有するアプリケーション管理テーブル９２の一例を示した構成図である。
アプリケーション管理テーブル９２は、実行対象プログラム５のコンテキストルート、リクエスト転送部、接尾辞、業務処理部を対応付けて管理する。
【００２８】
列９２１には、実行対象プログラム５のコンテキストルートを登録する。
列９２２には、列９２１のコンテキストルートの実行対象プログラム５に対応するリクエスト転送部５１を登録する。一つの実行対象プログラム５には、一つのリクエスト転送部５１が含まれるため、列９２１と列９２２は一対一に対応する。
列９２４には、列９２１のコンテキストルートの実行対象プログラム５に対応する業務処理部を登録する。一つの実行対象プログラム５には、複数の業務処理部が含まれるため、列９２１と列９２４は一対多に対応する。
【００２９】
列９２３には、リクエスト転送部５１が業務処理部を生成する場合に、生成する業務処理部のコンテキストルートに接尾辞として付加する値を登録する。リクエスト転送部５１が業務処理部を生成する場合、列９２３の値を取得し、取得した値をインクリメントする。列９２１に登録されているコンテキストルートにインクリメント後の値を付加した文字列を、生成する業務処理部のコンテキストルートとする。その後、列９２３の値を、インクリメントした値で更新する。上記処理は、生成する業務処理部のコンテキストルートの重複を防ぐことを目的としている。
行９２５は、コンテキストルート「/App」に対応するリクエスト転送部５１は「App_rs.ear」であり、業務処理部には、「App_1.ear」と「App_2.ear」が存在し、最後に生成した業務処理部の接尾辞は「2」であることを示している。
【００３０】
図６は、図４のセッション管理部４２３３が有するセッション管理テーブル９３の一例を示した構成図である。
セッション管理テーブル９３は、セッションＩＤ、生成時刻、最終アクセス時刻、有効／無効を対応付けて管理する。
【００３１】
列９３１には、セッションのセッションＩＤを登録する。セッションＩＤは、リクエストに付加される情報であり、複数のリクエストに同一のセッションＩＤを付加することで、リクエスト間でセッションを継続できる。
列９３２には、列９３１のセッションＩＤを持つセッションの生成時刻を登録する。
列９３３には、列９３１のセッションＩＤを持つセッションへの最終アクセス時刻を登録する。
列９３４には、列９３１のセッションＩＤを持つセッションが有効か無効かを登録する。セッション管理部４２３３は、一定時間セッションへのアクセスがないと、当該セッションを無効と登録する。
【００３２】
行９３５は、セッションＩＤが「1」であるセッションは、「2008/06/03 07:00」に生成され、最後にアクセスされた時刻は「2008/06/03 07:00」であり、セッションは「無効」になっていることを示している。
行９３６は、セッションＩＤが「2」であるセッションは、「2008/06/03 07:00」に生成され、最後にアクセスされた時刻は「2008/06/03 15:00」であり、セッションは「有効」になっていることを示している。
【００３３】
図７は、図４のリクエスト転送部５１が有する転送先管理テーブル９４の一例を示す構成図である。
転送先管理テーブル９４は、転送先コンテキストルートと転送先判定フィルタを対応付けて管理する。上に登録されているレコードほど、古いレコードとなる。
列９４１には、転送先となる業務処理部のコンテキストルートを登録する。
列９４２には、列９４１のコンテキストルートに転送するかどうかを判定する場合に利用する転送先判定フィルタ５１１を登録する。一つの転送先コンテキストルートに対して、複数の転送先判定フィルタが存在するため、列９４１と列９４２は、一対多に対応する。
【００３４】
リクエスト転送部５１がリクエストを受信すると、転送先管理テーブル９４を参照し、転送先を判定する。リクエスト転送部５１は、転送先管理テーブル９４を上から順番に走査し、列９４２に登録されている転送先判定フィルタ５１１で判定処理を行う。転送先判定フィルタ５１１での判定処理において、一つでも「転送の必要あり」と判定された場合、当該転送先判定フィルタに対応する転送先コンテキストルートに、リクエストを転送する。
行９４３は、コンテキストルート「/App_1」の業務処理部にリクエストを転送するかどうかを判定するためには、セッション判定フィルタとAuthorizationヘッダ判定フィルタによる判定処理を行う必要があることを示している。
【００３５】
行９４４は、コンテキストルート「/App_2」の業務処理部には、転送先判定フィルタが登録されていないことを示している。転送先管理テーブル９４の末尾（最下行）のレコードは、最も新しいレコードであり、最新の設定で動作する業務処理部に関する情報が登録されている。末尾（最下行）のレコードの列９４２には何も登録しない。列９４２に何も登録されていない場合、リクエスト転送部５１は、必ず対応する転送先コンテキストルートにリクエストを転送する。
転送先管理テーブル９４の更新処理に関しては図１７、図１８で説明する。
【００３６】
図８は、インポートするパッケージ３４１に含まれる設定ファイル９５１の一例を示す構成図である。
設定ファイル９５１はＸＭＬ（eXtensible Markup Language）形式で記述される。
行番号１のタグ「war」は、設定ファイル９５１のルート要素である。
行番号２のタグ「description」は、当該アプリケーションを利用する人間向けの説明を記述するための設定である。これは、運用上利用する設定であり、アプリケーションの動作に影響を与える設定ではないため、この設定（変更）に影響のあるリクエストのパラメータは存在しない（図２参照）。
【００３７】
行番号３のタグ「security-role」は、当該アプリケーションの実行を許可するユーザを指定するための設定である。当該アプリケーションを実行する場合には、クライアント１と計算機４の間で認証が必要になる。認証方法の一例であるBasic認証では、リクエストにAuthorizationヘッダを付加することで行われる。したがって、Basic認証を用いる場合には、当該設定は、Authorizationヘッダに影響を受ける（図２参照。設定項目分類定義ファイル９０の「/war/security-role」の行において、「Authorizationヘッダ」だけ「○（影響あり）」になっている）。
【００３８】
行番号４のタグ「resource」は、当該アプリケーションに接続する資源情報を指定するための設定である。資源には、例えば接続するデータベースなどが含まれる。接続先のデータベースを変更した場合、変更の前後で、アプリケーションの実行結果が変わってしまう可能性がある。複数のリクエストにまたがる一連の処理を実行する場合、どちらか片方のデータベースで処理されるならば、一連の処理を正常に実行できる。しかし、一連の処理の途中で接続先のデータベースが変更されてしまうと、内部状態に矛盾が生じ、不正な処理となってしまう可能性がある。つまり、セッション継続中は接続する資源を変更してはならず、当該設定は、セッションに影響を受ける（図２参照。設定項目分類定義ファイル９０の「/war/resource」の行において、「セッション」だけ「○（影響あり）」になっている）。
【００３９】
行番号５のタグ「request-encoding」は、リクエストとして送信されてくるメッセージを処理する際に使用するエンコーディングを指定するための設定である。リクエストに、Content-Typeヘッダが付加され、明示的にエンコーディングが指定されている場合は、当該設定より優先される。当該設定を変更した場合、明示的にエンコーディングを指定されているリクエストでは問題ないが、明示的な指定がないリクエストの場合、変更前と変更後で処理エンコーディングが変わってしまい、正常に処理できない可能性がある。したがって、当該設定は、Content-Typeヘッダに影響を受ける（図２参照。設定項目分類定義ファイル９０の「/war/request-encoding」の行において、「Content-Typeヘッダ」だけ「○（影響あり）」になっている）。
【００４０】
行番号６のタグ「response-encoding」は、レスポンスとして送信するメッセージのエンコーディングを指定するための設定である。リクエストに、Accept-Charsetヘッダが付加され、明示的に受け入れ可能なエンコーディングが指定されている場合は、当該設定より優先される。当該設定を変更した場合、明示的にエンコーディングを指定されているリクエストでは問題ないが、明示的な指定がないリクエストの場合、変更前と変更後でレスポンスのエンコーディングが変わってしまい、レスポンスを受信したクライアント１が正常に処理できない可能性がある。したがって、当該設定は、Accept-Charsetヘッダに影響を受ける（図２参照。設定項目分類定義ファイル９０の「/war/response-encoding」の行において、「Accept-Charsetヘッダ」だけ「○（影響あり）」になっている）。
【００４１】
図９は、入れ替えるパッケージ３４２に含める差分設定ファイル９５２の一例を示す構成図である。
差分設定ファイル９５２には、現在動作している設定から変更した設定項目のみを記述する。
行番号２では、現在動作している設定から、「resource」の設定のみを変更することを示している。
【００４２】
図１０は、図１の設定ファイル生成処理部３２２２が生成する差分適用後の設定ファイル９５３の一例を示す構成図である。
差分適用後の設定ファイル９５３は、設定ファイル９５１と差分設定ファイル９５２を融合したファイルである。図８と図９の例で示した設定ファイル９５１と差分設定ファイル９５２の場合、設定ファイル生成処理部３２２２は、設定ファイル９５１に対して行番号４の「resource」の設定項目のみを上書した差分適用後の設定ファイル９５３を生成する。
【００４３】
図１１は、計算機システムにおける、アプリケーションのインポート処理の概要を示す図である。
アプリケーションをインポートするには、計算機管理装置３の入力装置３５を用いて、インポート処理の要求を入力し、インポートするパッケージ３４１とインポート処理要求を設定管理部３２２３に送信する（ステップＳ１０）。
インポート処理要求を受信した設定管理部３２２３は、インポートするパッケージ３４１に含まれる設定ファイル９５１を設定管理テーブル９１に登録する。登録後、インポート処理部３２２４へインポートするパッケージ３４１を送信し、インポート処理を指示する（ステップＳ１１）。そのために、図１４に示すフローチャートを実行する（詳細は後記）。
【００４４】
インポート処理を指示されたインポート処理部３２２４は、インポートするパッケージ３４１をアプリケーション管理部４２３１に送信し、インポート処理を要求する（ステップＳ１２）。そのために、図１５に示すフローチャートを実行する（詳細は後記）。
インポート処理を指示されたアプリケーション管理部４２３１は、リクエスト転送部５１と古い設定で動作する業務処理部５２を生成し、アプリケーション管理テーブル９２を更新する。また、デプロイ処理部４２３２を利用し（ステップＳ１３）、生成したリクエスト転送部５１と古い設定で動作する業務処理部５２をコンテナ４２３４へデプロイする（ステップＳ１４，１５）。デプロイ完了後、アプリケーション管理部４２３１は、リクエスト転送部５１へ、リクエストの転送先である古い設定で動作する業務処理部５２のコンテキストルートを通知する（ステップＳ１６）。そのために、図１６に示すフローチャートを実行する（詳細は後記）。
古い設定で動作する業務処理部５２のコンテキストルートを通知されたリクエスト転送部５１は、転送先管理テーブル９４を更新する。
以上により、計算機システムＳにおける、アプリケーションのインポート処理は完了となる。
【００４５】
図１２は、計算機システムにおける、アプリケーション入れ替え処理の概要を示す図である。
アプリケーションを入れ替えるには、計算機管理装置３の入力装置３５を用いて、入れ替え処理の要求を入力し、入れ替えるパッケージ３４２と入れ替え処理要求を差分項目解析処理部３２２１に送信する（ステップＳ２０）。なお、以下において、単に「パッケージ」というときは、インポートするパッケージ３４１と入れ替えるパッケージ３４２の両方、あるいは、両方ありえる場合のいずれかのことを指すものとする。
入れ替え処理要求を受信した差分項目解析処理部３２２１は、入れ替えるパッケージ３４２に含まれる差分設定ファイル９５２に記述されている設定項目に影響のあるリクエストのパラメータを解析し、入れ替えるパッケージ３４２を設定ファイル生成処理部３２２２へ送信する（ステップＳ２１）。そのために、図１３で示すフローチャートを実行する（詳細は後記）。
【００４６】
設定ファイル生成処理部３２２２は、入れ替えようとしているアプリケーションの現在の設定ファイルを設定管理部３２２３へ問い合わせる。問い合わせを受けた設定管理部３２２３は、設定管理テーブル９１を検索し、当該アプリケーションの設定ファイルを設定ファイル生成処理部３２２２へ通知する。問い合わせ後、設定ファイル生成処理部３２２２は、現在の設定ファイルと差分設定ファイル９５２から、差分適用後の設定ファイル９５３を生成し、差分設定ファイル９５２を、生成した差分適用後の設定ファイル９５３に置き換え、入れ替えるパッケージ３４２を設定管理部３２２３へ送信する（ステップＳ２２）。
【００４７】
設定管理部３２２３は、設定管理テーブル９１の当該アプリケーションのレコードを、入れ替えるパッケージ３４２に含まれる差分設定ファイル９５２に更新する。更新後、インポート処理部３２２４へ入れ替えるパッケージ３４２と変更する設定に影響のあるリクエストのパラメータを送信し、入れ替え処理を指示する（ステップＳ２３）。そのために、図１４で示すフローチャートを実行する（詳細は後記）。
入れ替え処理を指示されたインポート処理部３２２４は、入れ替えるパッケージ３４２をアプリケーション管理部４２３１に送信し、入れ替え処理を要求する（ステップＳ２４）。そのために、図１５に示すフローチャートを実行する。
【００４８】
入れ替え処理を指示されたアプリケーション管理部４２３１は、新しい設定で動作する業務処理部５３を生成し、アプリケーション管理テーブル９２を更新する。また、アプリケーション管理部４２３１は、デプロイ処理部４２３２を利用し（ステップＳ２５）、生成した新しい設定で動作する業務処理部５３をコンテナ４２３４へデプロイする（ステップＳ２６）。デプロイ完了後、アプリケーション管理部４２３１は、リクエスト転送部５１へ、リクエストの転送先である新しい設定で動作する業務処理部５３のコンテキストルートと、変更する設定項目に影響のあるリクエストのパラメータを通知する（ステップＳ２７）。そのために、図１６に示すフローチャートを実行する（詳細は後記）。
【００４９】
新しい設定で動作する業務処理部５３のコンテキストルートとリクエストのパラメータを通知されたリクエスト転送部５１は、転送先管理テーブル９４を更新する。
以上により、計算機システムＳにおける、アプリケーションの入れ替え処理は完了となる。
【００５０】
図１３は、差分項目解析処理部３３２１が実行する、差分設定ファイル９５２に記述されている設定項目に影響のあるリクエストのパラメータを解析する処理を示すフローチャートである。なお、動作主体が差分項目解析処理部３３２１である旨の記載は省略する。
ステップＳ３００において、インポート処理部３２２４から送信された入れ替えるパッケージ３４２を解凍する。
ステップＳ３０１において、解凍されたファイル群に含まれる差分設定ファイル９５２を読み込む。
【００５１】
ステップＳ３０２〜Ｓ３０４において、差分設定ファイル９５２に記述されている各設定項目をキーとして以下に示す処理を行う。設定項目分類定義ファイル９０（図２参照）の列９０１から、当該設定項目を検索し、発見したレコードの列９０２〜９０５を参照し、値が「○」になっているパラメータを検索結果に加える。以上により、検索結果には、差分設定ファイル９５２に記述されている全ての設定項目に影響のあるリクエストのパラメータが含まれる。つまり、処理中の設定項目に影響するリクエストのパラメータを取得することができる。
ステップＳ３０５において、ステップＳ３０２〜Ｓ３０４での検索結果（取得したリクエストのパラメータ）をインポート処理部３２２４へ送信する。
【００５２】
図１４は、設定管理部３２２３が実行する、設定ファイル９５１および差分適用後の設定ファイル９５３を設定管理テーブル９１に登録する処理を示すフローチャートである。なお、動作主体が設定管理部３２２３である旨の記載は省略する。
【００５３】
ステップＳ３１０において、アプリケーションのパッケージが解凍済みかどうか判定する。アプリケーションのインポート処理の場合は未解凍のインポートするパッケージ３４１であり（ステップＳ３１０でＮｏ）、ステップＳ３１１へ進む。アプリケーションの入れ替え処理の場合は、差分項目解析処理部３２２１の処理において、既に入れ替えるパッケージ３４２が解凍されているため（ステップＳ３１０でＹｅｓ）、再度解凍する必要はなく、ステップＳ３１２へ進む。
【００５４】
ステップＳ３１１において、インポートするパッケージ３４１の解凍を行う。
ステップＳ３１２において、解凍されたファイル群に含まれる設定ファイル９５１または差分適用後の設定ファイル９５３を取得する。インポート処理の場合、設定管理テーブル９１には当該アプリケーションのレコードは存在しないため、新規にレコードを追加し、列９１１にアプリケーション名を、列９１２にコンテキストルートを、列９１３に設定ファイル９５１を登録する。入れ替え処理の場合、設定管理テーブル９１には、既に当該アプリケーションのレコードが存在するため、入れ替え対象のアプリケーション名をキーに列９１１を検索し、発見したレコードの列９１３に、差分適用後の設定ファイル９５３を上書き登録する。
ステップＳ３１３において、解凍されているファイル群を再パッケージ化する。
ステップＳ３１４において、パッケージをインポート処理部３２２４に送信する。
【００５５】
図１５は、インポート処理部３２２４が実行する、アプリケーション管理部４２３１にアプリケーションのインポート処理および入れ替え処理を要求する処理を示すフローチャートである。なお、動作主体がインポート処理部３２２４である旨の記載は省略する。
ステップＳ３２０において、設定管理部３２２３からインポートするパッケージ３４１または入れ替えるパッケージ３４２を受信する。
ステップＳ３２１において、ステップＳ３２０で受信したパッケージをアプリケーション管理部４２３１に送信する。
【００５６】
ステップＳ３２２において、インポート処理および入れ替え処理の起点となる、入力装置３５からの入力内容を判定し、アプリケーション管理部４２３１にインポート処理を要求するのか入れ替え処理を要求するのかを決定する。入力内容がインポート処理要求だった場合（ステップＳ３２２で「インポート処理要求」）、ステップＳ３２６へ進む。入力内容が入れ替え処理要求だった場合（ステップＳ３２２で「入れ替え処理要求」）、ステップＳ３２３へ進む。
【００５７】
ステップＳ３２３において、差分項目解析処理部３２２１の処理で解析した、変更する設定に影響のあるリクエストのパラメータを受信する。
ステップＳ３２４において、ステップＳ３２３で受信したパラメータをアプリケーション管理部４２３１に送信する。影響のあるパラメータが存在しない場合、影響のあるパラメータが存在しないことを意味するデータを送信する。
ステップＳ３２５において、アプリケーション管理部４２３１に入れ替え処理を指示する。
ステップＳ３２６において、アプリケーション管理部４２３１にインポート処理を指示する。インポート処理の場合、入れ替え処理と異なり、影響のあるパラメータは送信しない。
【００５８】
図１６は、アプリケーション管理部４２３１が実行する、リクエスト転送部５１の生成とデプロイ、業務処理部の生成とデプロイ、および、アプリケーション管理テーブル９２の更新処理を示すフローチャートである。なお、動作主体がアプリケーション管理部４２３１である旨の記載は省略する。
ステップＳ３３０において、インポート処理部３２２４から、インポート処理もしくは入れ替え処理の指示を受信する。また、アプリケーションのパッケージおよび影響のあるリクエストのパラメータを受信する。
【００５９】
ステップＳ３３１において、ステップＳ３３０で受信した処理の指示を判定する。処理の指示がインポート処理の場合（ステップＳ３３１で「インポート処理要求」）、ステップＳ３３２に進む。処理の指示が入れ替え処理の場合（ステップＳ３３１で「入れ替え処理要求」）、ステップＳ３３７へ進む。
ステップＳ３３２において、アプリケーション管理テーブル９２に新規にレコードを追加し、列９２１にアプリケーションのコンテキストルートを登録する。
ステップＳ３３３において、ステップＳ３３２で追加したレコードの列９２３の接尾辞に「0」を登録する。
【００６０】
ステップＳ３３４において、リクエスト転送部５１を生成する。リクエスト転送部５１は、インポートするアプリケーションのコンテキストルートと同じコンテキストルートを持つ。例えば、インポートするアプリケーションのコンテキストルートが「/App」の場合、リクエスト転送部５１のコンテキストルートも同じ「/App」にする。インポートするアプリケーションのコンテキストルートと同じコンテキストルートとすることで、インポートするアプリケーションに対して送信されたリクエストは、すべてリクエスト転送部５１に割り当てられるようになる。リクエスト転送部５１は、アプリケーション実行部４２３を開発するベンダが予め用意する雛形を複製し、コンテキストルートを変更することで生成される。
【００６１】
ステップＳ３３５において、ステップＳ３３４で生成したリクエスト転送部５１をステップＳ３３２で追加したレコードの列９２２に登録する。
ステップＳ３３６において、デプロイ処理部４２３２を利用し、ステップＳ３３４で生成したリクエスト転送部５１をコンテナ４２３４へデプロイする。
【００６２】
ステップＳ３３７において、インポートもしくは入れ替えるアプリケーションのコンテキストルートをキーとして、アプリケーション管理テーブル９２を検索し、当該アプリケーションのレコードを取得する。
ステップＳ３３８において、ステップＳ３３７で取得したレコードの列９２３に登録されている接尾辞の値を取得する。
ステップＳ３３９において、業務処理部を生成する。生成する業務処理部のコンテキストルートは、当該アプリケーションのコンテキストルートに「_」とステップＳ３３８で取得した接尾辞の値をインクリメントした値を付加した値に設定する。当該アプリケーションのコンテキストルートが「/App」、接尾辞が「2」だった場合、生成する業務処理部のコンテキストルートは「/App_3」となる。業務処理部は、ステップＳ３３０で受信したパッケージを複製し、コンテキストルートを変更することで生成される。
【００６３】
ステップＳ３４０において、ステップＳ３３７で取得したレコードの列９２４に、ステップＳ３３９で生成した業務処理部を追加登録する。
ステップＳ３４１において、ステップＳ３３７で取得したレコードの列９２３に、ステップＳ３３８で取得した接尾辞の値をインクリメントした値を上書き登録する。
ステップＳ３４２において、デプロイ処理部４２３２を利用し、ステップＳ３３９で生成した業務処理部をコンテナ４２３４へデプロイする。
ステップＳ３４３において、ステップＳ３３７で取得したレコードに登録されているリクエスト転送部５１に、ステップＳ３３９で生成した業務処理部のコンテキストルートと、ステップＳ３３０で受信した影響のあるリクエストのパラメータを送信する。
【００６４】
図１７は、リクエスト転送部５１が実行する、転送先管理テーブル９４の更新処理を示すフローチャートである。なお、動作主体がリクエスト転送部５１である旨の記載は省略する。
ステップＳ３５０において、アプリケーション管理部４２３１から、業務処理部のコンテキストルートと影響のあるリクエストのパラメータを受信する。
ステップＳ３５１において、ステップＳ３５０で受信したリクエストのパラメータが存在するかどうかを判定する。本処理が、インポート処理の延長で呼び出されている場合、影響のあるリクエストのパラメータは送信されてこないため、判定は「Ｎｏ」になる。入れ替え処理の延長で呼び出されている場合で、実際に影響のあるパラメータが存在する場合には、パラメータのデータが送信されてくるため、判定は「Ｙｅｓ」になる。影響のあるパラメータが存在しない場合には、パラメータが存在しないことを意味するデータが送信され、この場合も判定は「Ｙｅｓ」になる。つまり、インポート処理の延長で呼び出されている場合には「Ｎｏ」になり、ステップＳ３５５へ進む。入れ替え処理の延長で呼び出されている場合には「Ｙｅｓ」になり、ステップＳ３５２へ進む。
【００６５】
ステップＳ３５２〜Ｓ３５４において、ステップＳ３５０で受信した影響のあるリクエストの各パラメータに対して、対応する転送先判定フィルタ５１１を生成する。例えば、影響のあるパラメータがセッションの場合には、セッション判定フィルタ５１１１を生成する。影響のあるパラメータが存在しない場合には、判定処理で、必ず「転送の必要なし」と判定するフィルタを生成する。また、転送先管理テーブル９４に登録されている末尾（最下行）のレコードの列９４２に、ステップＳ３５３で生成した転送先判定フィルタ５１１を追加登録する。末尾のレコードとは、最新の設定で動作している業務処理部のレコードである。
【００６６】
ステップＳ３５５において、転送先管理テーブル９４の末尾（最下行）に新しくレコードを追加し、当該レコードの列９４１に、ステップＳ３５０で受信した業務処理部のコンテキストルートを登録する。
【００６７】
図１８は、図１７のフローチャートによって更新される転送先管理テーブル９４の状態を示す図である。
まず、コンテキストルート「/App」のアプリケーションをインポートする場合の例を示す。コンテキストルート「/App」のアプリケーションをインポートする場合、アプリケーション管理部４２３１から、リクエスト転送部５１に対して、業務処理部のコンテキストルート「/App_1」が送信されてくる。
【００６８】
転送先管理テーブル９４の初期状態は、初期状態の転送先管理テーブル９６１のように、何もレコードが存在しない状態である。
インポート処理の延長で図１７のフローチャートが実行された場合、図１７のステップＳ３５１で、「Ｎｏ」と判定され、ステップＳ３５５へ進む。ステップＳ３５５では、初期状態の転送先管理テーブル９６１の末尾（最下行）にレコードを追加し、転送先コンテキストルートに「/App_1」を登録する。その結果、インポート処理後の転送先管理テーブル９６２の状態へ遷移する。
【００６９】
続いて、上記の処理後に、セッションに影響を受ける設定を変更し、コンテキストルート「/App」のアプリケーションを入れ替える場合の例を示す。この場合、アプリケーション管理部４２３１から、リクエスト転送部５１に対して、業務処理部のコンテキストルート「/App_2」と、影響のあるパラメータとして「セッション」が送信されてくる。
入れ替え処理の延長で図１７のフローチャートが実行された場合、図１７のステップＳ３５１で、「Ｙｅｓ」と判定され、ステップＳ３５２へ進む。ステップＳ３５２〜Ｓ３５４では、セッション判定フィルタ５１１１を生成し、インポート処理後の転送先管理テーブル９６２の末尾（最下行）に登録されているレコードを更新する。その結果、コンテキストルート「/App_1」に対応する転送先判定フィルタ５１１として、セッション判定フィルタ５１１１が登録される。その後、ステップＳ３５５で、インポート処理後の転送先管理テーブル９６２の末尾（最下行）にレコードを追加し、コンテキストルートに「/App_2」を登録する。その結果、入れ替え処理後の転送先管理テーブル９６３の状態へ遷移する。
【００７０】
図１９は、図１７のフローチャートのステップＳ３５３で実行されるセッション判定フィルタ５１１１の生成処理の一例を示すフローチャートである。なお、動作主体がリクエスト転送部５１である旨の記載は省略する。
ステップＳ３６０において、セッション判定フィルタ５１１１のオブジェクトを生成する。
ステップＳ３６１において、ステップＳ３６０で生成したセッション判定フィルタ５１１１のオブジェクトに現在時刻を通知し、セッション判定フィルタ５１１１の生成時刻変数を更新する。生成時刻変数は、セッション判定フィルタ５１１１で実行される判定処理で利用される。
【００７１】
図２０は、計算機システムにおいて、リクエストを処理する流れを示すシーケンス図である。
ステップＳ４０において、クライアント１から計算機４のリクエスト転送部５１にリクエストが送信される。
ステップＳ４１において、リクエスト転送部５１は、どの業務処理部へリクエストを転送するべきかを判定する転送先判定処理を行う。そのために、図２１に示すフローチャートを実行する（詳細は後記）。
ステップＳ４２において、ステップＳ４１の判定処理の結果に応じて（パラメータがあるかによって）、リクエストを転送する業務処理部を切り替える。
【００７２】
ステップＳ４２の判定処理の結果が、例えば「/App_1」の場合（Ｙｅｓ）、ステップＳ４３において、リクエスト転送部５１は、古い設定で動作する業務処理部５２へリクエストを転送する。ステップＳ４４において、古い設定で動作する業務処理部５２は、業務処理を実行し、レスポンスを送信する。
【００７３】
ステップＳ４１の判定処理の結果が、例えば「/App_2」の場合（Ｎｏ）、ステップＳ４５において、リクエスト転送部５１は、新しい設定で動作する業務処理部５３へリクエストを転送する。ステップＳ４６において、新しい設定で動作する業務処理部５３は、業務処理を実行し、レスポンスを送信する。
【００７４】
ステップＳ４７において、リクエスト転送部５１は、業務処理部から受信したレスポンスをクライアント１へ転送する。
以上により、計算機システムＳにおけるリクエスト処理は完了する。
【００７５】
図２１は、図２０のリクエスト転送部５１がステップＳ４１で実行する、転送先判定処理を示すフローチャートである。なお、動作主体がリクエスト転送部５１である旨の記載は省略する。
ステップＳ４１０において、転送先管理テーブル９４に登録されている転送先に対して、上から順に、ステップＳ４１１の処理を繰り返す。転送先管理テーブル９４は、古いレコードほど上に登録されているため、古い転送先から順に繰り返すことになる。
ステップＳ４１１において、処理中の転送先に対応する各転送先判定フィルタ５１１に対して、ステップＳ４１２，Ｓ４１３の処理を繰り返す。
【００７６】
ステップＳ４１２において、処理中の転送先判定フィルタ５１１による転送先判定処理を実行し、処理中の転送先にリクエストを転送する必要があるかどうかを判定する。例えば、転送先判定フィルタ５１１がセッション判定フィルタの場合、図２２に示すフローチャートを実行する（詳細は後記）。
ステップＳ４１３において、ステップＳ４１２における判定結果で処理を分岐する。判定結果が「転送の必要なし」の場合、ステップＳ４１１の繰り返し処理を継続する。判定結果が「転送の必要あり」の場合、ステップＳ４１１およびステップＳ４１０の繰り返し処理を抜け、ステップＳ４１５に進む。
したがって、転送先管理テーブル９４に登録されている転送先判定フィルタ５１１による判定処理の結果が全て「転送の必要なし」だった場合、ステップＳ４１４に進み、一つでも「転送の必要あり」のだった場合には、ステップＳ４１５に進むことになる。
【００７７】
ステップＳ４１４において、転送先管理テーブル９４の末尾の転送先を判定処理結果とする。転送先管理テーブル９４の末尾（最下行）の転送先とは、最新の設定で動作する業務処理部である。
ステップＳ４１５において、ステップＳ４１２で「転送の必要あり」と判定した転送先判定フィルタ５１１に対応する転送先を判定処理結果とする。
【００７８】
図２２は、図２１のステップＳ４１２で実行される転送先判定フィルタ５１１による転送先判定処理の一例である、セッション判定フィルタ５１１１における転送先判定処理を示すフローチャートである。なお、動作主体がリクエスト転送部５１である旨の記載は省略する。
【００７９】
ステップＳ４１２１において、処理中のリクエストに付加されているセッションＩＤを取得する。
ステップＳ４１２２において、セッション管理部４２３３に、当該セッションＩＤのセッションのセッション生成時刻を問い合わせる。問い合わせを受けセッション管理テーブル９３を検索したセッション管理部４２３３から、該当するセッションの生成時刻（セッション生成時刻）を取得する。
【００８０】
ステップＳ４１２３において、ステップＳ４１２２で取得したセッション生成時刻を判定する。セッション生成時刻が、処理を実行中のセッション判定フィルタ５１１１の生成時刻よりも後の場合（ステップＳ４１２３で「セッション判定フィルタの生成時刻より後」）、ステップＳ４１２５へ進む。セッション生成時刻がセッション判定フィルタ５１１１の生成時刻よりも前の場合（ステップＳ４１２３で「セッション判定フィルタの生成時刻より前」）、ステップＳ４１２４へ進む。セッション判定フィルタ５１１１の生成時刻とは、図１９で示した、セッション判定フィルタ５１１１の生成時に設定した変数であり、アプリケーションの入れ替え処理が実行された時刻を記録している。
【００８１】
ステップＳ４１２４において、判定処理結果を「転送の必要あり」とする。処理中のリクエストのセッション生成時刻がセッション判定フィルタ５１１１の生成時刻よりも前ということは、アプリケーション入れ替え処理よりも前にセッションが生成されたことを示している。セッション継続中にリクエストを処理する業務処理部を変更すると、実行結果に影響を与える可能性があるため、古い設定で動作する業務処理部５２にリクエストを転送する必要がある。
【００８２】
ステップＳ４１２５において、判定処理結果を「転送の必要なし」とする。セッション生成時刻がセッション判定フィルタ５１１１の生成時刻よりも後ということは、アプリケーション入れ替え処理の後にセッションが生成されたことを示している。このセッション中に古い設定で動作する業務処理部５２での処理を行っていないため、古い設定で動作する業務処理部５２へリクエストを転送する必要がない。
【００８３】
このように、本実施形態の計算機システムＳによれば、計算機管理装置３が、計算機４に配備されたアプリケーションを更新する場合、計算機４に対して、更新前のアプリケーションに加えて更新後のアプリケーションを配備するとともに、リクエストに含まれるパラメータごとに更新前のアプリケーションと更新後のアプリケーションとでリクエストの処理結果が異なるか否かを判定するための判定フィルタを生成して配備する。
【００８４】
これにより、計算機４は、クライアント１からリクエストを受信した場合、当該リクエストに含まれるパラメータごとに、対応する判定フィルタを用いて更新前の（古い設定で動作する）アプリケーションと更新後の（新しい設定で動作する）アプリケーションとで当該リクエストの処理結果が異なるか否かを判定し、すべてのパラメータについて処理結果が異ならないと判定したときは、更新後のアプリケーションで当該リクエストを処理し、少なくともいずれかのパラメータについて処理結果が異なると判定したときは、更新前のアプリケーションで当該リクエストを処理することができる。すなわち、アプリケーションが更新（設定の変更）された場合でも、アプリケーションサービスを中断することなくリクエストを受け付け、リクエストが保持するセッションなどのパラメータに応じて、更新前のアプリケーションによる処理と更新後のアプリケーションによる処理を適切に使い分け、正常に処理することができる。
【００８５】
また、計算機管理装置３を構成するコンピュータに実行させるためのアプリケーション更新プログラムを作成し、コンピュータにインストールすることにより、コンピュータは、そのアプリケーション更新プログラムに基づいた各機能を実現することができる。
【００８６】
以上で実施形態の説明を終えるが、本発明の態様はこれらに限定されるものではない。例えば、本実施形態では、リクエストの保持するパラメータのうち、主にセッションについて説明したが、Authorizationヘッダなどの他のパラメータについても同様に本発明を適用することができる。つまり、例えば、１つのセッション内の処理に限定されず、認証済み情報を複数のセッションにわたって継続保持しておく必要がある場合などにも適用することができる。その他、ハードウェア、プログラム等の具体的な構成について、本発明の主旨を逸脱しない範囲で適宜変更が可能である。
【図面の簡単な説明】
【００８７】
【図１】本発明の実施形態を適用する計算機システムの構成図である。
【図２】本発明の実施形態に関する差分項目解析処理部３２２１において利用される、設定項目分類定義ファイル９０の一例を示す構成図である。
【図３】本発明の実施形態に関する設定管理部３２２３において利用される、設定管理テーブル９１の一例を示す構成図である。
【図４】本発明の実施形態に関するアプリケーション実行部４２３の詳細を示す構成図である。
【図５】本発明の実施形態に関するアプリケーション管理部４２３１において利用される、アプリケーション管理テーブル９２の一例を示した構成図である。
【図６】本発明の実施形態に関するセッション管理部４２３３において利用される、セッション管理テーブル９３の一例を示した構成図である。
【図７】本発明の実施形態に関するリクエスト転送部５１において利用される、転送先管理テーブル９４の一例を示す構成図である。
【図８】本発明の実施形態に関する入力装置３５を用いて入力される、インポートするパッケージ３４１に含まれる設定ファイル９５１の一例を示す構成図である。
【図９】本発明の実施形態に関する入力装置３５を用いて入力される、入れ替えるパッケージ３４２に含まれる差分設定ファイル９５２の一例を示す構成図である。
【図１０】本発明の実施形態に関する設定ファイル生成処理部３２２２が生成する、差分適用後の設定ファイル９５３の一例を示す構成図である。
【図１１】本発明の実施形態における、アプリケーションのインポート処理の概要を示す図である。
【図１２】本発明の実施形態における、アプリケーション入れ替え処理の概要を示す図である。
【図１３】本発明の実施形態に関する差分項目解析処理部３３２１が実行する、変更する設定に影響のあるリクエストのパラメータを解析する処理を示すフローチャートである。
【図１４】本発明の実施形態に関する設定管理部３２２３が実行する、設定ファイル９５１および差分適用後の設定ファイル９５３を設定管理テーブル９１に登録する処理を示すフローチャートである。
【図１５】本発明の実施形態に関するインポート処理部３２２４が実行する、アプリケーション管理部４２３１にアプリケーションのインポート処理および入れ替え処理を要求する処理を示すフローチャートである。
【図１６】本発明の実施形態に関するアプリケーション管理部４２３１が実行する、リクエスト転送部５１の生成とデプロイ、業務処理部の生成とデプロイ、およびアプリケーション管理テーブル９２の更新処理を示すフローチャートである。
【図１７】本発明の実施形態に関するリクエスト転送部５１が実行する、転送先管理テーブル９４の更新処理を示すフローチャートである。
【図１８】本発明の実施形態に関するリクエスト転送部５１によって更新される、転送先管理テーブル９４の状態遷移の一例を示す図である。
【図１９】本発明の実施形態に関するリクエスト転送部５１が実行する、セッション判定フィルタ５１１１の生成処理を示すフローチャートである。
【図２０】本発明の実施形態における、リクエストを処理する流れを示すシーケンス図である。
【図２１】本発明の実施形態におけるリクエスト転送部５１が実行する、転送先判定処理を示すフローチャートである。
【図２２】本発明の実施形態における転送先判定フィルタ５１１による転送先判定処理の一例である、セッション判定フィルタ５１１１における転送先判定処理を示すフローチャートである。
【符号の説明】
【００８８】
１        クライアント
２        負荷分散装置
３        計算機管理装置
３１      ＣＰＵ（処理部）
３２      メモリ（記憶部）
３４      ハードディスク（記憶部）
４        計算機
Ｓ        計算機システム
【図１】
2010097525.tif 000003
【図２】
2010097525.tif 000004
【図３】
2010097525.tif 000005
【図４】
2010097525.tif 000006
【図５】
2010097525.tif 000007
【図６】
2010097525.tif 000008
【図７】
2010097525.tif 000009
【図８】
2010097525.tif 000010
【図９】
2010097525.tif 000011
【図１０】
2010097525.tif 000012
【図１１】
2010097525.tif 000013
【図１２】
2010097525.tif 000014
【図１３】
2010097525.tif 000015
【図１４】
2010097525.tif 000016
【図１５】
2010097525.tif 000017
【図１６】
2010097525.tif 000018
【図１７】
2010097525.tif 000019
【図１８】
2010097525.tif 000020
【図１９】
2010097525.tif 000021
【図２０】
2010097525.tif 000022
【図２１】
2010097525.tif 000023
【図２２】
2010097525.tif 000024