特許 6443059 情報処理装置、情報処理方法、および、プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6443059

(24)【登録日】2018年12月7日

(45)【発行日】2018年12月26日

(54)【発明の名称】情報処理装置、情報処理方法、および、プログラム

(51)【国際特許分類】

   G06F 9/445 20180101AFI20181217BHJP

【ＦＩ】

   G06F9/445 130

【請求項の数】7

【全頁数】17

(21)【出願番号】特願2015-4152(P2015-4152)

(22)【出願日】2015年1月13日

(65)【公開番号】特開2016-130887(P2016-130887A)

(43)【公開日】2016年7月21日

【審査請求日】2017年12月15日

(73)【特許権者】

【識別番号】000004237

【氏名又は名称】日本電気株式会社

(74)【代理人】

【識別番号】100109313

【弁理士】

【氏名又は名称】机 昌彦

(74)【代理人】

【識別番号】100124154

【弁理士】

【氏名又は名称】下坂 直樹

(72)【発明者】

【氏名】要田 計治

【審査官】 塚田 肇

(56)【参考文献】

【文献】 特開２００７−１０２４８０（ＪＰ，Ａ）

【文献】 特開平０６−３４８６３４（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ９／４４５

(57)【特許請求の範囲】

【請求項1】

サービスに対するリクエストに関連する情報と、前記リクエストに対応するアプリケーションプログラムおよびそのバージョンとの関係を表すルールを記憶するルール記憶部と、
前記リクエストを受け付ける通信部と、
前記通信部によって受け付けられたリクエストについて前記ルールを適用することにより、前記リクエストに応答するアプリケーションプログラムおよびそのバージョンを決定するバージョン決定部と、
前記バージョン決定部によって決定されたバージョンのアプリケーションプログラムが前記リクエストに応答するよう制御する応答制御部と、
を備え、
前記ルールは、前記リクエストの受付時期に関する条件と、前記バージョンとの関係を表す情報を含むことを特徴とする情報処理装置。

【請求項2】

前記ルール記憶部は、前記サービスの種類毎に前記ルールを記憶し、
前記バージョン決定部は、前記通信部によって受け付けられたリクエストが要求するサービスの種類に応じたルールから、前記リクエストに関連する情報に応じたルールを適用することを特徴とする請求項１に記載の情報処理装置。

【請求項3】

前記ルールは、前記リクエストに関連するユーザ情報に関する条件と、前記バージョンとの関係を表す情報を含むことを特徴とする請求項１または請求項２に記載の情報処理装置。

【請求項4】

前記ルールは、該ルールに含まれるバージョンのアプリケーションプログラムの実行パスを表す情報を含み、
前記応答制御部は、前記バージョン決定部によって用いられたルールに含まれる実行パスを起動することにより、決定されたバージョンのアプリケーションプログラムが前記リクエストに応答するよう制御することを特徴とする請求項１から請求項３のいずれか１項に記載の情報処理装置。

【請求項5】

前記ルールは、該ルールに含まれるバージョンのアプリケーションプログラムが起動中の実行環境における通信先を表す情報を含み、
前記応答制御部は、前記バージョン決定部によって用いられたルールの示す実行環境における通信先に前記リクエストを転送することにより、決定されたバージョンのアプリケーションプログラムが前記リクエストに応答するよう制御することを特徴とする請求項１から請求項３のいずれか１項に記載の情報処理装置。

【請求項6】

サービスに対するリクエストに関連する情報と、前記リクエストに対応するアプリケーションプログラムおよびそのバージョンとの関係を表すルールを記憶するルール記憶部を用いて、
前記リクエストを受け付け、
受け付けたリクエストについて前記ルールを適用することにより、前記リクエストに応答するアプリケーションプログラムおよびそのバージョンを決定し、
決定したバージョンのアプリケーションプログラムが前記リクエストに応答するよう制御し、
前記ルールに、前記リクエストの受付時期に関する条件と、前記バージョンとの関係を表す情報を含ませる情報処理方法。

【請求項7】

サービスに対するリクエストに関連する情報と、前記リクエストに対応するアプリケーションプログラムおよびそのバージョンとの関係を表すルールを記憶するルール記憶部を用いて、
前記リクエストを受け付ける通信ステップと、
前記通信ステップで受け付けられたリクエストについて前記ルールを適用することにより、前記リクエストに応答するアプリケーションプログラムおよびそのバージョンを決定するバージョン決定ステップと、
前記バージョン決定ステップで決定されたバージョンのアプリケーションプログラムが前記リクエストに応答するよう制御する応答制御ステップと、
前記ルールに、前記リクエストの受付時期に関する条件と、前記バージョンとの関係を表す情報を含ませるステップと
をコンピュータ装置に実行させるプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、情報処理システムにおいて提供されるサービスのバージョンを管理する技術に関する。

【背景技術】

【0002】

情報処理システムにおいて提供されるサービスには、高い可用性を求められるものがある。例えば、ウェブサービスやメールサービスなど、ネットワークを介して公開されるサービスは、利用者からのアクセスに常時対応する必要がある。したがって、このようなサービスには、高い可用性が求められる。高可用性が求められるサービスを提供するアプリケーションプログラムに対するバージョン管理は、サービスを停止せずに行われる必要がある。

【0003】

例えば、このようなサービスを提供するアプリケーションプログラムは、連携する外部環境の変化への追随、セキュリティ脆弱性への対応、ソフトウェア自身のバグの改修等のため、頻繁にバージョンアップされる。この場合、高可用性を確保するため、サービスを停止することなくアプリケーションプログラムをバージョンアップすることが必要となる。このような場合、一般的には、バージョンアップ前後のアプリケーションプログラムがそれぞれインストールされた複数のサーバを用いて、ネットワークロードバランサによる通信制御によってバージョンアップが行われる。この場合、用意される複数のサーバは、１つのオペレーティングシステム上で稼働する複数の仮想マシンにより実現される場合もある。

【0004】

また、ＳａａＳ（Software as a Service）のようなサービスは、１つの情報処理システム上で、複数のテナントに分かれて提供されることがある。このような情報処理システムは、テナントによって異なるバージョンのサービスを提供したいことがある。例えば、あるテナントのユーザに対しては、サービスのバージョン１．１を提供したいが、他のテナントのユーザに対しては、バージョン１．２を提供したい、といったケースである。このような場合、一般的には、異なるバージョンのアプリケーションプログラムがそれぞれインストールされた複数のサーバを用いて、異なるバージョンのサービスが提供される。

【0005】

このようなサービスのバージョン管理に関連する技術の一例が、特許文献１に記載されている。特許文献１に記載された関連技術では、デバイスを含むクライアントが、デバイス情報とクライアント情報とをサーバに送信し、サーバが、デバイス情報に対応するアプリケーションプログラムをクライアントに送信する。このとき、この関連技術は、サーバにおいて、ユーザ毎に、デバイス情報に対応して利用可能なアプリケーションプログラムのバージョンリストを記憶しておく。そして、この関連技術は、サーバまたはクライアントに、利用可能なアプリケーションプログラムのバージョンリストを表示する。これにより、サーバは、サーバまたはクライアントにより選択されたバージョンのアプリケーションプログラムを、クライアントに送信する。

【0006】

また、このようなサービスのバージョン管理に関連する他の技術の一例が、特許文献２に記載されている。特許文献２に記載された関連技術では、作業ユニットの少なくとも一部の構成要素が更新されると、更新された構成要素は、作業ユニットの残りの構成要素が更新されるまで、更新される前の古いバージョンの構成要素をエミュレートする。

【先行技術文献】

【特許文献】

【0007】

【特許文献1】特開２００８−７２４２７号公報

【特許文献2】特開２００１−１３４４５４号公報

【発明の概要】

【発明が解決しようとする課題】

【0008】

しかしながら、上述の関連技術には、以下の課題がある。

【0009】

まず、アプリケーションプログラムのバージョン管理のために複数のサーバを用意する一般的な手法は、複数のサーバの構築・運用にコストがかかるという課題がある。

【0010】

また、特許文献１に記載された関連技術は、ユーザ毎に適切なバージョンのアプリケーションプログラムによりサービスを提供するために、あらかじめユーザ毎に、利用可能なバージョンリストを記憶しておく必要がある。このため、この関連技術は、事前準備にコストがかかるという課題がある。また、この関連技術では、アプリケーションプログラムは、クライアント側で実行されることが前提となっている。そのため、この関連技術は、適切なバージョンのアプリケーションプログラムを、サーバからクライアントに送信する。したがって、この関連技術を、サービスを提供するサーバ上で稼働するアプリケーションプログラムのバージョン管理に適用することは難しい。

【0011】

また、特許文献２に記載された関連技術は、古いバージョンをエミュレートできるアプリケーションプログラムであることが前提となる。そのため、この関連技術は、古いバージョンをエミュレートできないアプリケーションプログラムのバージョン管理に適していない。

【0012】

本発明は、上述の課題を解決するためになされたものである。すなわち、本発明は、サービスを提供するアプリケーションプログラムのバージョン管理を、高可用性を確保しながらより低コストで実現する技術を提供することを目的とする。

【課題を解決するための手段】

【0013】

本発明の情報処理装置は、サービスに対するリクエストに関連する情報と、前記リクエストに対応するアプリケーションプログラムおよびそのバージョンとの関係を表すルールを記憶するルール記憶部と、前記リクエストを受け付ける通信部と、前記通信部によって受け付けられたリクエストについて前記ルールを適用することにより、前記リクエストに応答するアプリケーションプログラムおよびそのバージョンを決定するバージョン決定部と、前記バージョン決定部によって決定されたバージョンのアプリケーションプログラムが前記リクエストに応答するよう制御する応答制御部と、を備える。

【0014】

また、本発明の情報処理方法は、サービスに対するリクエストに関連する情報と、前記リクエストに対応するアプリケーションプログラムおよびそのバージョンとの関係を表すルールを記憶するルール記憶部を用いて、前記リクエストを受け付け、受け付けたリクエストについて前記ルールを適用することにより、前記リクエストに応答するアプリケーションプログラムおよびそのバージョンを決定し、決定したバージョンのアプリケーションプログラムが前記リクエストに応答するよう制御する。

【0015】

また、本発明のプログラムは、サービスに対するリクエストに関連する情報と、前記リクエストに対応するアプリケーションプログラムおよびそのバージョンとの関係を表すルールを記憶するルール記憶部を用いて、前記リクエストを受け付ける通信ステップと、前記通信ステップで受け付けられたリクエストについて前記ルールを適用することにより、前記リクエストに応答するアプリケーションプログラムおよびそのバージョンを決定するバージョン決定ステップと、前記バージョン決定ステップで決定されたバージョンのアプリケーションプログラムが前記リクエストに応答するよう制御する応答制御ステップと、をコンピュータ装置に実行させる。

【発明の効果】

【0016】

本発明は、サービスを提供するアプリケーションプログラムのバージョン管理を、高可用性を確保しながらより低コストで実現する技術を提供することができる。

【図面の簡単な説明】

【0017】

【図1】本発明の第１の実施の形態としての情報処理装置の構成を示すブロック図である。

【図2】本発明の第１の実施の形態としての情報処理装置のハードウェア構成の一例を示す図である。

【図3】本発明の第１の実施の形態としての情報処理装置の動作を説明するフローチャートである。

【図4】本発明の第２の実施の形態としての情報処理装置の構成を示すブロック図である。

【図5】本発明の第２の実施の形態においてルール記憶部に記憶されるルールの一例を示す図である。

【図6】本発明の第２の実施の形態としての情報処理装置の動作を説明するフローチャートである。

【図7】本発明の第３の実施の形態としての情報処理装置の構成を示すブロック図である。

【図8】本発明の第３の実施の形態においてルール記憶部に記憶されるルールの一例を示す図である。

【図9】本発明の第３の実施の形態としての情報処理装置の動作を説明するフローチャートである。

【発明を実施するための形態】

【0018】

以下、本発明の実施の形態について、図面を参照して詳細に説明する。

【0019】

（第１の実施の形態）
本発明の第１の実施の形態としての情報処理装置１の機能ブロック構成を図１に示す。図１において、情報処理装置１は、ルール記憶部１１と、通信部１２と、バージョン決定部１３と、応答制御部１４とを備える。また、情報処理装置１は、ネットワークを介してクライアント９０に接続される。情報処理装置１は、クライアント９０からのリクエストに応じて、サービスを提供する。また、情報処理装置１は、サービスを提供するための１つ以上のバージョンのアプリケーションプログラムを含む。各アプリケーションプログラムは、クライアント９０からのリクエストに応じた応答をクライアント９０に対して送信する機能を有する。

【0020】

ここで、情報処理装置１は、図２に示すようなハードウェア要素によって構成可能である。図２において、情報処理装置１は、ＣＰＵ（Central Processing Unit）１００１、メモリ１００２、出力装置１００３、入力装置１００４、および、ネットワークインタフェース１００５を含む。メモリ１００２は、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、補助記憶装置（ハードディスク等）等によって構成される。出力装置１００３は、ディスプレイ装置やプリンタ等のように、情報を出力する装置によって構成される。入力装置１００４は、キーボードやマウス等のように、ユーザ操作の入力を受け付ける装置によって構成される。ネットワークインタフェース１００５は、インターネット、ＬＡＮ（Local Area Network）、公衆回線網、無線通信網またはこれらの組合せ等によって構成されるネットワークに接続するインタフェースである。この場合、情報処理装置１の各機能ブロックは、メモリ１００２に格納されるコンピュータ・プログラムを読み込んで実行するとともに他の各部を制御するＣＰＵ１００１によって構成される。なお、情報処理装置１およびその各機能ブロックのハードウェア構成は、上述の構成に限定されない。

【0021】

ルール記憶部１１は、サービスに対するリクエストに関連する情報と、リクエストに対応するアプリケーションプログラムおよびそのバージョンとの関係を表すルールを記憶する。

【0022】

通信部１２は、クライアント９０からのリクエストを受け付ける。具体的には、通信部１２は、情報処理装置１のネットワークポートを監視することにより、ネットワークポートに届くリクエストを受け付ければよい。

【0023】

バージョン決定部１３は、通信部１２によって受け付けられたリクエストについて上述のルールを適用することにより、リクエストに応答するアプリケーションプログラムおよびそのバージョンを決定する。

【0024】

応答制御部１４は、バージョン決定部１３によって決定されたバージョンのアプリケーションプログラムがリクエストに応答するよう制御する。例えば、応答制御部１４は、決定されたバージョンのアプリケーションプログラムを起動してリクエストに応答させてもよい。

【0025】

以上のように構成された情報処理装置１の動作について、図３を参照して説明する。

【0026】

図３では、まず、通信部１２は、クライアント９０からのリクエストを受け付ける（ステップＳ１）。

【0027】

次に、バージョン決定部１３は、ルール記憶部１１に記憶されたルールのうち、受け付けられたリクエストに関連する情報に適合するルールを検索する（ステップＳ２）。

【0028】

次に、バージョン決定部１３は、適合するルールの示すアプリケーションプログラムおよびそのバージョンを決定する（ステップＳ３）。

【0029】

次に、応答制御部１４は、ステップＳ３で決定したバージョンのアプリケーションプログラムが、ステップＳ１で受け付けたリクエストに応答するよう制御する（ステップＳ４）。

【0030】

以上で、情報処理装置１は動作を終了する。

【0031】

次に、本発明の第１の実施の形態の効果について述べる。

【0032】

本発明の第１の実施の形態としての情報処理装置は、サービスを提供するアプリケーションプログラムのバージョン管理を、高可用性を確保しながらより低コストで実現する。

【0033】

その理由について述べる。本実施の形態は、ルール記憶部に、サービスに対するリクエストに関連する情報と、リクエストに対応するアプリケーションプログラムおよびそのバージョンとの関係を表すルールを記憶しておく。そして、通信部によりクライアントからのリクエストが受け付けられると、バージョン決定部が、受け付けられたリクエストに上述のルールを適用することにより、リクエストに応答するアプリケーションプログラムおよびそのバージョンを決定する。これにより、応答制御部が、決定されたバージョンのアプリケーションプログラムを、リクエストに応答させるよう制御するからである。例えば、応答制御部は、決定されたバージョンのアプリケーションプログラムを起動してリクエストに応答させるからである。

【0034】

これにより、本実施の形態は、リクエストに関連する情報に応じたバージョンのアプリケーションプログラムでリクエストに常時応答することを、１つのオペレーティングシステム上で、仮想マシンを用いることなく実現できる。したがって、本実施の形態は、複数のバージョンのアプリケーションプログラムのいずれかによる常時応答のために、複数のサーバを用意してそれぞれに異なるバージョンのアプリケーションプログラムを起動させる必要がない。また、本実施の形態は、複数のバージョンのアプリケーションプログラムのいずれかによる常時応答のために、クライアント毎にバージョンリストをあらかじめ記憶しておく必要がない。また、本実施の形態は、複数のバージョンのアプリケーションプログラムのいずれかによる常時応答のために、新しいバージョンのアプリケーションプログラムにより古いバージョンをエミュレートする必要がない。したがって、本実施の形態は、リクエストに関連する情報に応じたバージョンのアプリケーションプログラムによりリクエストに常時応答することを、低コストで実現できる。

【0035】

（第２の実施の形態）
次に、本発明の第２の実施の形態について図面を参照して詳細に説明する。なお、本実施の形態の説明において参照する各図面において、本発明の第１の実施の形態と同一の構成および同様に動作するステップには同一の符号を付して本実施の形態における詳細な説明を省略する。

【0036】

本実施の形態としての情報処理装置２は、１種類以上のサービスをクライアント９０に対して提供する。具体的には、情報処理装置２は、ネットワークポートに届くリクエストに対して、ポート番号に応じた種類のサービスを提供する。サービスとしては、例えば、メールサービスや、ウェブサービス等が挙げられる。ただし、情報処理装置２が提供するサービスの種類はこれらに限らない。また、情報処理装置２は、これらの各サービスを提供するアプリケーションプログラムを含む。１種類のサービスにつき、１つ以上のバージョンのアプリケーションプログラムが含まれる場合がある。各アプリケーションプログラムは、クライアント９０からのリクエストに応じた応答をクライアント９０に対して送信する機能を有する。また、クライアント９０は、ネットワークを介して情報処理装置２にリクエストを発行することにより、情報処理装置２からサービスを受ける。クライアント９０上では、提供されるサービスに応じたクライアントプログラムが動作する。クライアントプログラムとしては、例えば、メールサービスにアクセスするメールクライアントや、ウェブサービスにアクセスするブラウザなどが挙げられる。ただし、クライアント９０で動作するクライアントプログラムの種類はこれらに限らない。

【0037】

まず、情報処理装置２の機能ブロック構成を図４に示す。図４において、情報処理装置２は、本発明の第１の実施の形態としての情報処理装置１に対して、ルール記憶部１１に替えてルール記憶部２１と、バージョン決定部１３に替えてバージョン決定部２３と、応答制御部１４に替えて応答制御部２４とを備える点が異なる。ここで、情報処理装置２およびその各機能ブロックは、図２を参照して説明した本発明の第１の実施の形態としての情報処理装置１と同一のハードウェア要素によって構成可能である。なお、情報処理装置２およびその各機能ブロックのハードウェア構成は、上述の構成に限定されない。

【0038】

ルール記憶部２１は、サービスに対するリクエストに関連する情報と、リクエストに対応するアプリケーションプログラムおよびそのバージョンとの関係を表すルールを記憶する。詳細には、ルールは、リクエストに関連するユーザ情報に関する条件と、アプリケーションプログラムのバージョンとの関係を表す情報を含む。また、ルールは、リクエストの受付時期に関する条件と、アプリケーションプログラムのバージョンとの関係を表す情報を含む。また、ルールは、そのルールに含まれるバージョンのアプリケーションプログラムの実行パスを表す情報を含む。

【0039】

また、ルール記憶部２１は、上述のようなルールとして、サービスの種類毎にあらかじめ定められたルールを記憶する。

【0040】

ルール記憶部２１に記憶される情報の一例を図５に示す。図５において、ルールは、ポート番号・ルール判定モジュール対応表と、条件・バージョン対応表と、バージョン・実行パス対応表とからなる。

【0041】

ポート番号・ルール判定モジュール対応表は、ポート番号と、ルール判定モジュールとの対応関係を表す。ルール判定モジュールは、ポート番号に対応するサービスの種類に応じたルールを検索する機能を持つ。このポート番号・ルール判定モジュール対応表により、ルール記憶部２１は、サービスの種類毎にあらかじめ定められたルールを呼び出す。例えば、図５では、ポート番号１４３に対して、ルール判定モジュール「IMAP4.lib」が対応付けられている。なお、図５において、ＩＭＡＰ４は、ＩＭＡＰ（Internet Message Access Protocol）４に基づくメール管理サービスを表す。また、ＰＯＰ３は、ＰＯＰ（Post Office Protocol）３に基づくメール受信サービスを表す。また、ＳＭＴＰは、ＳＭＴＰ（Simple Mail Transfer Protocol）に基づくメール転送サービスを表す。また、ＨＴＴＰは、ＨＴＴＰ（Hypertext Transfer Protocol）に基づくウェブデータ転送サービスを表す。また、ＨＴＴＰＳは、ＨＴＴＰＳ（Hypertext Transfer Protocol Secure）に基づくウェブデータ転送サービスを表す
また、条件・バージョン対応表は、リクエストに関連するユーザ情報に関する条件１と、リクエストの受付時期に関する条件２と、バージョンとの対応関係を表す。条件・バージョン対応表は、ルール判定モジュール毎に用意される。図５に示した条件・バージョン対応表は、ルール判定モジュール「IMAP4.lib」によって用いられる対応表の一例である。また、リクエストに関連するユーザ情報とは、例えば、リクエスト受付時の認証処理により得られるユーザのメールアドレスであってもよい。例えば、図５では、ユーザ情報が正規表現「*.nec.co.jp」にマッチするという条件１に対して、バージョン「１．０．０」が対応付けられている。また、例えば、上述の条件１と、２０１５年１月１日０時０分以降であることを表す「From 2015/1/1 0:00」という条件２との組合せに対して、バージョン「１．０．１」が対応付けられている。

【0042】

また、バージョン・実行パス対応表は、ルール判定モジュールによって決定されたバージョンと、そのバージョンのアプリケーションプログラムの実行パスとの対応関係を表す。例えば、図５では、ルール判定モジュール「IMAP4.lib」によって決定されたバージョン「１．０．０」に対して、実行パス「/mail/bin/imapd」が対応付けられている。また、この例では、バージョンに対して、実行パスに加えて、起動時のオプションを表す情報も対応付けられている。

【0043】

バージョン決定部２３は、通信部１２によって受け付けられたリクエストについて、リクエストに関連するユーザ情報、および、リクエストの受付時期に基づいて、ルール記憶部１１から適合するルールを検索する。そして、バージョン決定部２３は、適合するルールの示すアプリケーションプログラムおよびそのバージョンを決定する。

【0044】

例えば、図５に示した情報がルール記憶部２１に記憶されているとする。この場合、バージョン決定部２３は、受け付けられたリクエストが届いたポート番号に対応するルール判定モジュールを、ポート・ルール判定モジュール対応表から求める。そして、バージョン決定部２３は、該当するルール判定モジュールに対応する条件・バージョン対応表において、リクエストに関連するユーザ情報およびルール受付時期が合致する条件１および条件２に対応付けられたバージョンを決定すればよい。なお、図５において、条件１または条件２が空欄の行は、ユーザ情報または受付時期に関する条件が設定されていない（どのようなユーザ情報または受付情報でも合致する）ことを表す。そして、バージョン決定部２３は、バージョン・実行パス対応表において、適用したルール判定モジュールおよび決定したバージョンに対応する実行パスおよびオプションを求めればよい。

【0045】

応答制御部２４は、バージョン決定部２３によって決定されたバージョンのアプリケーションプログラムがリクエストに応答するよう制御する。具体的には、応答制御部２４は、バージョン決定部２３によって求められた実行パスの示すアプリケーションプログラムを起動する。そして、応答制御部２４は、起動したアプリケーションプログラムに、リクエストを渡せばよい。

【0046】

なお、通信部１２、バージョン決定部２３、および、応答制御部２４は、例えば、ｉｎｅｔｄ（アイネットディー）に代表されるスーパーサーバ型デーモンを拡張することにより実現されてもよい。ただし、これらの機能ブロックの実現するために採用可能なベース技術を限定するものではない。

【0047】

以上のように構成された情報処理装置２の動作について、図６を参照して説明する。

【0048】

図６では、まず、通信部１２は、ネットワークポートを監視することにより、クライアント９０からのリクエストを受付ける（ステップＳ２１）。

【0049】

次に、バージョン決定部２３は、受け付けられたリクエストが要求するサービスの種類に応じたルールから、リクエストに関連するユーザ情報およびリクエスト受付時期が適合するルールを検索する（ステップＳ２２）。

【0050】

例えば、前述のように、バージョン決定部２３は、図５に示したポート番号・ルール判定モジュール対応表に基づいて、リクエストが届いたネットワークポートのポート番号に対応するルール判定モジュールを特定する。そして、バージョン決定部２３は、特定したルール判定モジュールに応じた条件・バージョン対応表を用いて、リクエストに関連するユーザ情報およびリクエスト受付時期が適合するルールを検索すればよい。

【0051】

次に、バージョン決定部２３は、適合するルールに基づいて、リクエストに応答するアプリケーションプログラムのバージョンを決定する（ステップＳ２３）。

【0052】

次に、バージョン決定部２３は、適合するルールに基づいて、決定されたバージョンのアプリケーションプログラムに対応する実行パスを求める（ステップＳ２４）。

【0053】

前述のように、このとき、バージョン決定部２３は、起動時に指定するオプションを表す情報を併せて取得してもよい。

【0054】

次に、応答制御部２４は、求められた実行パスを用いて、決定されたバージョンのアプリケーションプログラムを実行する（ステップＳ２５）。

【0055】

もし、ステップＳ２４でオプションを表す情報が取得されている場合、応答制御部２４は、実行パスにオプションを付加して実行すればよい。

【0056】

次に、応答制御部２４は、起動したアプリケーションプログラムに、リクエストを渡すことにより応答させる（ステップＳ２６）。

【0057】

以上で、情報処理装置２は、動作を終了する。

【0058】

次に、情報処理装置２の動作を具体例で示す。ここでは、ルール記憶部２１に、図５に示した情報が記憶されているとする。また、ステップＳ２１において、ポート１４３にリクエストが届いたとする。

【0059】

そこで、バージョン決定部２３は、ポート番号・ルール判定モジュール対応表から、ポート番号１４３に対応するルール判定モジュール「IMAP4.lib」を特定する。そして、バージョン決定部２３は、ルール判定モジュール「IMAP4.lib」に対応する条件・バージョン対応表を用いて検索を行う。

【0060】

ここで、リクエストに関連するユーザ情報（認証したユーザのメールアドレス）が、正規表現“*.nec.co.jp”にマッチする場合について説明する。この場合、バージョン決定部２３は、条件１が適合するルールとして、ルールＩＤ１およびルールＩＤ２を候補とする。この場合、次に、バージョン決定部２３は、条件２を判定する。もし、リクエスト受付時期が２０１５年１月１日０：００より前であれば、バージョン決定部２３は、条件１に加えて条件２が適合するルールとして、ルールＩＤ１を選択する（ステップＳ２２）。その結果、バージョン決定部２３は、バージョン１．０．０を決定する（ステップＳ２３）。一方、リクエスト受付時期が２０１５年１月１日０：００以降であれば、バージョン決定部２３は、条件１に加えて条件２が適合するルールとして、ルールＩＤ２を選択する（ステップＳ２２）。その結果、バージョン決定部２３は、バージョンとして１．０．１を決定する（ステップＳ２３）。

【0061】

また、リクエストに関連するユーザ情報が、正規表現“*.nec.com”にマッチする場合について説明する。この場合、バージョン決定部２３は、条件１が適合するルールとして、ルールＩＤ３を適用する（ステップＳ２２）。その結果、バージョン決定部２３は、バージョン２．０．０を決定する（ステップＳ２３）。

【0062】

また、リクエストに関連するユーザ情報が、条件・バージョン対応表に示したいずれの条件１にも該当しない場合について説明する。この場合、バージョン決定部２３は、ルールＩＤ４を適用する（ステップＳ２２）。その結果、バージョン決定部２３は、バージョン２．０．０を決定する（ステップＳ２３）。

【0063】

そして、バージョン決定部２３は、バージョン・実行パス対応表から、ルール判定モジュールおよび決定したバージョンに対応する実行パスおよびオプションを求める。もし、ステップＳ２２でルールＩＤ３またはルールＩＤ４が適用されていた場合、決定されたバージョンは２．０．０である。そこで、この場合、バージョン決定部２３は、ルール判定モジュール「IMAP4.lib」およびバージョン「２．０．０」に対応する実行パス「/V2/mail/bin/imapd」およびオプション無しとの情報を求める（ステップＳ２４）。

【0064】

次に、応答制御部２４は、実行パス「/V2/mail/bin/imapd」を、オプション指定無しで起動する（ステップＳ２５）。そして、応答制御部２４は、起動した「/V2/mail/bin/imapd」のプロセスにリクエストを渡す。これにより、「/V2/mail/bin/imapd」のプロセスは、リクエストに対する応答をクライアント９０に送信する（ステップＳ２６）。

【0065】

以上で、具体例の説明を終了する。

【0066】

次に、本発明の第２の実施の形態の効果について述べる。

【0067】

本発明の第２の実施の形態としての情報処理装置は、サービスを提供するアプリケーションプログラムのバージョン管理を、高可用性を確保しながらより低コストで実現する。

【0068】

その理由について述べる。本実施の形態は、ルール記憶部に、リクエストに関連するユーザ情報に関する条件と、リクエスト受付時期に関する条件と、リクエストに対応するバージョンのアプリケーションプログラムの実行パスとの関係を表すルールを記憶しておく。また、本実施の形態は、ルール記憶部に、そのようなルールを、サービスの種類毎に記憶しておく。そして、通信部によりクライアントからのリクエストが受け付けられると、バージョン決定部が、リクエストが要求するサービスの種類に応じたルールから、そのリクエストに関連するユーザ情報および受付時期に適合するルールを検索する。そして、バージョン決定部は、適合するルールの示すアプリケーションプログラムおよびそのバージョンを決定し、その実行パスを得る。これにより、応答制御部が、決定されたバージョンのアプリケーションプログラムの実行パスを起動し、起動したアプリケーションプログラムに、リクエストに応答させるからである。

【0069】

これにより、本実施の形態は、ユーザ条件と、提供するアプリケーションプログラムとして適切なバージョンとを紐づけることができる。そのため、本実施の形態は、１つのオペレーティングシステム上で、複数のバージョンのアプリケーションプログラムを管理しながら、サービスを停止することなく、ユーザ条件に応じた適切なバージョンのアプリケーションプログラムを提供することができる。

【0070】

また、これにより、本実施の形態は、リクエストの受付時期と、提供するアプリケーションプログラムとして適切なバージョンとを紐づけることができる。つまり、本実施の形態は、１つのオペレーティングシステム上で、サービスを停止することなく、条件として設定した新バージョン適用時期に、アプリケーションプログラムのバージョンアップを行うことができる。

【0071】

また、これにより、本実施の形態は、ユーザ条件に応じて提供バージョンを管理することができる。その結果、本実施の形態は、１つのオペレーティングシステム上で、異なる契約形態のサービスを提供することができる。

【0072】

（第３の実施の形態）
次に、本発明の第３の実施の形態について図面を参照して詳細に説明する。なお、本実施の形態の説明において参照する各図面において、本発明の第１または第２の実施の形態と同一の構成および同様に動作するステップには同一の符号を付して本実施の形態における詳細な説明を省略する。

【0073】

ここで、前述の本発明の第２の実施の形態では、リクエストに応答するバージョンのアプリケーションプログラムをその都度起動していた。これに対して、本実施の形態は、アプリケーションプログラムの各バージョンを常時起動しておくケースに対応する。このような環境は、アプリケーションプログラムを実行単位で仮想化するコンテナ型仮想化技術を用いて実現可能である。コンテナ型仮想化とは、オペレーティングシステム環境全体を仮想化するのではなく、アプリケーションプログラムの実行環境単位で仮想化を行う技術である。この技術により、１つのオペレーティングシステム上で複数バージョンのアプリケーションプログラムの実行環境を実現することができる。１つのアプリケーションプログラムの実行環境は、「コンテナ」と呼ばれる。

【0074】

まず、本発明の第３の実施の形態としての情報処理装置３の構成を図７に示す。図７において、情報処理装置３は、本発明の第２の実施の形態としての情報処理装置２に対して、ルール記憶部２１に替えてルール記憶部３１と、バージョン決定部２３に替えてバージョン決定部３３と、応答制御部２４に替えて応答制御部３４とを備える点が異なる。ここで、情報処理装置３およびその各機能ブロックは、図２を参照して説明した本発明の第１の実施の形態としての情報処理装置１と同一のハードウェア要素によって構成可能である。なお、情報処理装置３およびその各機能ブロックのハードウェア構成は、上述の構成に限定されない。

【0075】

また、情報処理装置３は、図７に示すように、１つ以上のコンテナを含む。各コンテナ上では、クライアント９０に対してサービスを提供する任意のアプリケーションプログラムの任意のバージョンが稼働中である。１つのコンテナ上で稼働するアプリケーションプログラムは、１つ以上あってもよい。ただし、１つのコンテナ上では、１種類のサービスについて１つのバージョンのアプリケーションプログラムが稼働する。

【0076】

ルール記憶部３１は、本発明の第２の実施の形態のルール記憶部２１と略同様のルールを記憶する。ただし、ルール記憶部３１は、ルールに、該当するバージョンのアプリケーションプログラムの実行パスを含む代わりに、該当するバージョンのアプリケーションプログラムに対応するコンテナにおける通信先を表す情報を含む。例えば、ルール記憶部３１は、該当するバージョンのアプリケーションプログラムに対応するコンテナによってリクエストが受け付けられるポート番号を含んでいてもよい。

【0077】

例えば、ルール記憶部３１は、図５に示したポート番号・ルール判定モジュール対応表、条件・バージョン対応表、および、バージョン・実行パス対応表のうち、バージョン・実行パス対応表に替えて、バージョン・コンテナ対応表を記憶してもよい。バージョン・コンテナ対応表の一例を図８示す。図８において、例えば、ルール判定モジュール「IMAP4.lib」およびバージョン「１．０．０」に対しては、コンテナ１．０．０のポート「５０１４３」が対応付けられている。なお、図８に示すように、異なる種類のサービスであれば、同一のコンテナの異なるポートで対応可能である。

【0078】

バージョン決定部３３は、本発明の第２の実施の形態のバージョン決定部２３と略同様に機能するよう構成される。ただし、バージョン決定部３３は、リクエストに応答するバージョンのアプリケーションプログラムについて、その実行パスを決定する代わりに、そのコンテナにおける通信先（ポート番号）を決定する。例えば、バージョン決定部３３は、上述のバージョン・コンテナ対応表を参照することにより、該当するコンテナにおける通信先を決定すればよい。

【0079】

応答制御部３４は、バージョン決定部３３によって求められたコンテナにおける通信先に、リクエストを転送する。例えば、応答制御部３４は、ＮＡＰＴ（Network Address Port Translation)技術を用いて、リクエストを転送してもよい。

【0080】

以上のように構成された情報処理装置３の動作について、図９を参照して説明する。

【0081】

図９に示すように、情報処理装置３は、ステップＳ２１〜Ｓ２３まで、本発明の第２の実施の形態と同様に動作して、リクエストに応答するアプリケーションプログラムのバージョンを決定する。

【0082】

次に、バージョン決定部３３は、決定したバージョンのアプリケーションプログラムに対応するコンテナにおける通信先を求める（ステップＳ３４）。

【0083】

前述のように、例えば、バージョン決定部３３は、バージョン・コンテナ対応表を参照することにより、該当するコンテナにおける通信先を決定すればよい。

【0084】

次に、応答制御部３４は、コンテナにおける通信先に、リクエストを転送する（ステップＳ３５）。これにより、該当するコンテナで稼働する該当バージョンのアプリケーションプログラムは、リクエストに対する応答をクライアント９０に送信する。

【0085】

以上で、情報処理装置３は、動作を終了する。

【0086】

次に、本発明の第３の実施の形態の効果について述べる。

【0087】

本発明の第３の実施の形態としての情報処理装置は、サービスを提供するアプリケーションプログラムのバージョン管理を、高可用性を確保しながらより低コストで実現する。

【0088】

その理由について述べる。本実施の形態は、ルール記憶部に、本発明の第２の実施の形態と同様な構成のルールのうち、実行パスを表す情報に替えて、該当するバージョンのアプリケーションプログラムのコンテナにおける通信先を表す情報を含めて記憶しておく。そして、バージョン決定部が、リクエストに関連する情報が適合するルールの示すバージョンのアプリケーションプログラムについて、そのコンテナにおける通信先を表す情報を求める。そして、応答制御部が、リクエストを、コンテナにおける通信先に転送する。

【0089】

これにより、本実施の形態では、複数のバージョンのアプリケーションプログラムがコンテナにより同時に稼働中の環境においても、ユーザ条件やリクエスト受付時期に応じて適切なバージョンのアプリケーションプログラムが、リクエストに応答可能となる。例えば、本実施の形態は、あるコンテナにおいてサービスを提供中のアプリケーションプログラムのバージョンアップを行う際、次のように対応可能となる。すなわち、本実施の形態は、バージョンアップしたアプリケーションプログラムを稼働させるコンテナを起動し、旧コンテナから新コンテナへの切り替え時期を条件に設定したルールを記憶しておけばよい。これにより、本実施の形態は、クライアントからの通信を、バージョンアップに伴い旧コンテナから新コンテナへつなぎ直す必要がない。このように、本実施の形態は、サービスを提供中のクライアントとの通信に影響なく、バージョンアップを行うことができる。

【0090】

なお、本発明の第２および第３の実施の形態において、サービスの種類として、ＩＭＡＰ４、ＰＯＰ３、ＳＭＴＰ、ＨＴＴＰ、ＨＴＴＰＳ等の例を挙げて説明したが、サービスの種類はこれらに限定されない。

【0091】

また、本発明の第２および第３の実施の形態において、ルールが、ポート番号・ルール判別モジュール対応表、条件・バージョン対応表、および、バージョン・実行パス対応表またはバージョン・コンテナ対応表からなる例を中心に説明した。ただし、ルールのデータ構造はこれらに限らない。ルールは、リクエストに関連する情報と、アプリケーションプログラムおよびそのバージョンとの関係を表す情報であれば、その他のデータ構造であってもよい。また、ルールは、サービスの種類に応じたルールを特定可能であれば、その他のデータ構造であってもよい。また、ルールは、アプリケーションプログラムのバージョンと、実行パスまたはコンテナとの関係を表す情報を含んでいれば、その他のデータ構造であってもよい。

【0092】

また、本発明の第２および第３の実施の形態において、ルールが、リクエストに関連するユーザ情報およびリクエスト受付時期にそれぞれ関する条件を含む例を中心に説明した。これに限らず、ルールは、これらの条件に替えて、あるいは、これらの条件に加えて、リクエストに関連するその他の情報に関する条件を含んでいてもよい。

【0093】

また、本発明の第２および第３の実施の形態において、バージョン決定部は、複数の条件が全て満たされるルールを適用する例を中心に説明した。これに限らず、バージョン決定部は、複数の条件のいずれかが満たされるルールを適用するようにしてもよい。その他、バージョン決定部は、複数の条件のその他の論理的な組合せが満たされるか否かにより、そのルールを適用するか否かを判定してもよい。

【0094】

また、上述した本発明の各実施の形態において、情報処理装置の各機能ブロックが、記憶装置またはＲＯＭに記憶されたコンピュータ・プログラムを実行するＣＰＵによって実現される例を中心に説明した。これに限らず、各機能ブロックの一部、全部、または、それらの組み合わせが専用のハードウェアにより実現されていてもよい。

【0095】

また、上述した本発明の各実施の形態において、情報処理装置の機能ブロックは、複数の装置に分散されて実現されてもよい。

【0096】

また、上述した本発明の各実施の形態において、各フローチャートを参照して説明した情報処理装置の動作を、本発明のコンピュータ・プログラムとしてコンピュータの記憶装置（記憶媒体）に格納しておく。そして、係るコンピュータ・プログラムを当該ＣＰＵが読み出して実行するようにしてもよい。そして、このような場合において、本発明は、係るコンピュータ・プログラムのコードあるいは記憶媒体によって構成される。

【0097】

また、上述した各実施の形態は、適宜組み合わせて実施されることが可能である。

【0098】

また、本発明は、上述した各実施の形態に限定されず、様々な態様で実施されることが可能である。

【符号の説明】

【0099】

１、２、３ 情報処理装置
１１、２１、３１ ルール記憶部
１２ 通信部
１３、２３、３３ バージョン決定部
１４、２４、３４ 応答制御部
９０ クライアント
１００１ ＣＰＵ
１００２ メモリ
１００３ 出力装置
１００４ 入力装置
１００５ ネットワークインタフェース

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】