図面 (/)

技術 情報処理装置、情報処理方法、および、プログラム

出願人 日本電気株式会社
発明者 要田計治
出願日 2015年1月13日 (5年9ヶ月経過) 出願番号 2015-004152
公開日 2016年7月21日 (4年3ヶ月経過) 公開番号 2016-130887
状態 特許登録済
技術分野 ストアードプログラム
主要キーワード コンテナ型 切り替え時期 ネットワークロード モジュール対 ポート番 作業ユニット ルール判定 バージョンリスト
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2016年7月21日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (10)

課題

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

解決手段

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

概要

背景

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

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

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

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

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

概要

サービスを提供するアプリケーションプログラムのバージョン管理を、高可用性を確保しながらより低コストで実現する技術を提供すること。サービスに対するリクエストに関連する情報と、リクエストに対応するアプリケーションプログラムおよびそのバージョンとの関係を表すルールを記憶するルール記憶部11と、リクエストを受け付け通信部12と、受け付けられたリクエストについてルールを適用することにより、リクエストに応答するアプリケーションプログラムおよびそのバージョンを決定するバージョン決定部13と、決定されたバージョンのアプリケーションプログラムがリクエストに応答するよう制御する応答制御部14とを備える。

目的

また、特許文献1に記載された関連技術は、ユーザ毎に適切なバージョンのアプリケーションプログラムによりサービスを提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

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

請求項2

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

請求項3

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

請求項4

前記ルールは、前記リクエストの受付時期に関する条件と、前記バージョンとの関係を表す情報を含むことを特徴とする請求項1から請求項3のいずれか1項に記載の情報処理装置。

請求項5

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

請求項6

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

請求項7

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

請求項8

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

技術分野

0001

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

背景技術

0002

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

0003

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

0004

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

0005

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

0006

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

先行技術

0007

特開2008−72427号公報
特開2001−134454号公報

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

0008

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

0009

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

0010

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

0011

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

0012

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

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

0013

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

0014

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

0015

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

発明の効果

0016

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

図面の簡単な説明

0017

本発明の第1の実施の形態としての情報処理装置の構成を示すブロック図である。
本発明の第1の実施の形態としての情報処理装置のハードウェア構成の一例を示す図である。
本発明の第1の実施の形態としての情報処理装置の動作を説明するフローチャートである。
本発明の第2の実施の形態としての情報処理装置の構成を示すブロック図である。
本発明の第2の実施の形態においてルール記憶部に記憶されるルールの一例を示す図である。
本発明の第2の実施の形態としての情報処理装置の動作を説明するフローチャートである。
本発明の第3の実施の形態としての情報処理装置の構成を示すブロック図である。
本発明の第3の実施の形態においてルール記憶部に記憶されるルールの一例を示す図である。
本発明の第3の実施の形態としての情報処理装置の動作を説明するフローチャートである。

実施例

0018

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

0019

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

0020

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

0021

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

0022

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

0023

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

0024

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

0025

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

0026

図3では、まず、通信部12は、クライアント90からのリクエストを受け付ける(ステップS1)。

0027

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

0028

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

0029

次に、応答制御部14は、ステップS3で決定したバージョンのアプリケーションプログラムが、ステップS1で受け付けたリクエストに応答するよう制御する(ステップS4)。

0030

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

0031

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

0032

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

0033

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

0034

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

0035

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

0036

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

0037

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

0038

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

0039

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

0040

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

0041

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

0042

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

0043

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

0044

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

0045

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

0046

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

0047

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

0048

図6では、まず、通信部12は、ネットワークポートを監視することにより、クライアント90からのリクエストを受付ける(ステップS21)。

0049

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

0050

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

0051

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

0052

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

0053

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

0054

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

0055

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

0056

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

0057

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

0058

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

0059

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

0060

ここで、リクエストに関連するユーザ情報(認証したユーザのメールアドレス)が、正規表現“*.nec.co.jp”にマッチする場合について説明する。この場合、バージョン決定部23は、条件1が適合するルールとして、ルールID1およびルールID2を候補とする。この場合、次に、バージョン決定部23は、条件2を判定する。もし、リクエスト受付時期が2015年1月1日0:00より前であれば、バージョン決定部23は、条件1に加えて条件2が適合するルールとして、ルールID1を選択する(ステップS22)。その結果、バージョン決定部23は、バージョン1.0.0を決定する(ステップS23)。一方、リクエスト受付時期が2015年1月1日0:00以降であれば、バージョン決定部23は、条件1に加えて条件2が適合するルールとして、ルールID2を選択する(ステップS22)。その結果、バージョン決定部23は、バージョンとして1.0.1を決定する(ステップS23)。

0061

また、リクエストに関連するユーザ情報が、正規表現“*.nec.com”にマッチする場合について説明する。この場合、バージョン決定部23は、条件1が適合するルールとして、ルールID3を適用する(ステップS22)。その結果、バージョン決定部23は、バージョン2.0.0を決定する(ステップS23)。

0062

また、リクエストに関連するユーザ情報が、条件・バージョン対応表に示したいずれの条件1にも該当しない場合について説明する。この場合、バージョン決定部23は、ルールID4を適用する(ステップS22)。その結果、バージョン決定部23は、バージョン2.0.0を決定する(ステップS23)。

0063

そして、バージョン決定部23は、バージョン・実行パス対応表から、ルール判定モジュールおよび決定したバージョンに対応する実行パスおよびオプションを求める。もし、ステップS22でルールID3またはルールID4が適用されていた場合、決定されたバージョンは2.0.0である。そこで、この場合、バージョン決定部23は、ルール判定モジュール「IMAP4.lib」およびバージョン「2.0.0」に対応する実行パス「/V2/mail/bin/imapd」およびオプション無しとの情報を求める(ステップS24)。

0064

次に、応答制御部24は、実行パス「/V2/mail/bin/imapd」を、オプション指定無しで起動する(ステップS25)。そして、応答制御部24は、起動した「/V2/mail/bin/imapd」のプロセスにリクエストを渡す。これにより、「/V2/mail/bin/imapd」のプロセスは、リクエストに対する応答をクライアント90に送信する(ステップS26)。

0065

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

0066

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

0067

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

0068

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

0069

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

0070

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

0071

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

0072

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

0073

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

0074

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

0075

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

0076

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

0077

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

0078

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

0079

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

0080

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

0081

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

0082

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

0083

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

0084

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

0085

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

0086

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

0087

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

0088

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

0089

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

0090

なお、本発明の第2および第3の実施の形態において、サービスの種類として、IMAP4、POP3、SMTP、HTTP、HTTPS等の例を挙げて説明したが、サービスの種類はこれらに限定されない。

0091

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

0092

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

0093

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

0094

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

0095

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

0096

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

0097

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

0098

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

0099

1、2、3情報処理装置
11、21、31ルール記憶部
12通信部
13、23、33バージョン決定部
14、24、34応答制御部
90クライアント
1001 CPU
1002メモリ
1003出力装置
1004入力装置
1005 ネットワークインタフェース

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ