(57)【要約】      （修正有）【課題】障害の予兆や障害発生に適応してエラーを発生させずかつ性能を落とさないコンポーネント入替技術を提供する。【解決手段】予めコンポーネント毎に代替コンポーネントと障害が発生することを予兆する条件を定義し、各コンポーネントの状態や運用基盤自身の状態の監視結果を元に前記条件が成立するかどうか判定し、あるコンポーネントＡの条件が成立した場合は、代替コンポーネントＡｓの実体をアプリケーション運用基盤上に生成し、その実体のインタフェースとその実体を一意に識別する名前Ａｓの組をネームサーバに登録し、ネームサーバの入替え機能により現在運用中のコンポーネントの名前Ａと新規に登録した代替コンポーネントの名前Ａｓのインターフェース部分を入替え、以後、名前Ａで代替コンポーネントＡｓの実体のインタフェースが得られるようにし、コンポーネントＡに対する通信を、代替コンポーネントＡｓに送るように通信先を入替える。【選択図】図１
2006338069.tif 000002
【特許請求の範囲】
【請求項１】
複数のソフトウェア部品（以後コンポーネント）から構成されるコンポーネントソフトウェアの運用方法であって、該コンポーネントソフトウェアを実行している最中に、一つまたは複数のコンポーネントを他のコンポーネントと入替えることを特徴とするコンポーネントソフトウェアの運用方法。
【請求項２】
請求項１記載のコンポーネントソフトウェアの運用方法であって、各コンポーネント毎に入替え条件を定めておき、あるコンポーネントにおいて概コンポーネントの入替え条件が成立した場合に、概コンポーネントの入替えを行うことを特徴とするコンポーネントソフトウェアの運用方法。
【請求項３】
請求項１記載のコンポーネントソフトウェアの運用方法であって、他のソフトウェアやユーザからの指示があった場合に、該指示によって指定されたコンポーネントの入替えを行うことを特徴とするコンポーネントソフトウェアの運用方法。
【請求項４】
複数のソフトウェア部品（以後コンポーネント）から構成されるコンポーネントソフトウェアの運用方法であって、あらかじめコンポーネント毎に代替コンポーネントを定義しておき、第１のコンポーネントの入替え条件が成立した場合、あるいは、他のソフトウェアやユーザから該第１のコンポーネントの入替え指示があった場合に、該第１のコンポーネントＡの代替である第２のコンポーネントを起動し、該第２のコンポーネントの起動が完了すると、以後該第１のコンポーネントに対する処理要求(以後メソッド呼び出し)は、該第１のコンポーネントの代わりに該第２のコンポーネントを用いて実行し、該第１のコンポーネントは終了させることを特徴とするコンポーネントソフトウェアの運用方法。
【請求項５】
前記第２のコンポーネントの起動が完了すると、以後前記第１のコンポーネントに対する新規のメソッド呼び出しはすべて前記第２のコンポーネントを用いて実行し、既に該前記第１のコンポーネントで実行中のメソッド呼び出しは引き続き前記第１のコンポーネントで実行し、前記第１のコンポーネントで実行中のすべてのメソッド呼び出しが完了したら、前記第１のコンポーネントを終了させることを特徴とするコンポーネントソフトウェアの運用方法。
【請求項６】
前記第２のコンポーネントの起動を、あらかじめ運用の開始前に行っておくことを特徴とする請求項４記載のコンポーネントソフトウェアの運用方法。
【請求項７】
前記第１のコンポーネントの代替コンポーネントとして前記第１のコンポーネントそのもを用い、該代替コンポーネントを起動する際は、前記第１のコンポーネントの他に同一のコンポーネントを重複して起動することを特徴とする請求項４記載のコンポーネントソフトウェアの運用方法。
【請求項８】
前記第１のコンポーネントのクライアントが、該第１のコンポーネントの代替コンポーネントの起動が完了する前に、該第１のコンポーネントのメソッドを呼び出すために該コンポーネントＡのリモート参照（ＲＡ）を取得し、該代替コンポーネントの起動が完了した後に、該リモート参照ＲＡを使用して該第１のコンポーネントのメソッドを呼び出すと、該メソッドの実行は、該第１のコンポーネントの代わりに前記代替コンポーネントで処理されることを特徴とする請求項４記載のコンポーネントソフトウェアの運用方法。
【請求項９】
請求項１記載のコンポーネントソフトウェアの運用方法であって、ユーザまたは他のソフトウェアからコンポーネントの入替え機能停止の指示があると、それ以後、コンポーネントの入替えを行わないことを特徴とするコンポーネントソフトウェアの運用方法。
【請求項１０】
コンポーネントソフトウェアを運用するコンポーネントソフトウェア運用基盤であって、既に配備されているコンポーネントと同一コンポーネントを重複して配備する機能を有するデプロイヤを備えることを特徴とするコンポーネントソフトウェア運用基盤。
【請求項１１】
請求項１０記載のコンポーネントソフトウェア運用基盤であって、前記デプロイヤが第１のコンポーネントを配備する場合、まだ該第１のコンポーネントが前記運用基盤上に配備されていない場合は、単に該第１のコンポーネントの実体を該運用基盤上に生成し、既に該第１のコンポーネントが該運用基盤上に配備済みである場合は、該第１のコンポーネントの別の実体を該運用基盤に生成することを特徴とするコンポーネントソフトウェア運用基盤。
【請求項１２】
各コンポーネントと対になって、該コンポーネントのクライアントからの該コンポーネントに対するソッド呼び出しを受信する受信部を有するコンポーネントソフトウェア運用基盤であって、第１のコンポーネントの該受信部が該第１のコンポーネントのクライアントからメソッド呼び出しを受信すると、初期状態では該第１のコンポーネントで該メソッドを実行し、該受信部に対してメソッドの実行先を該第１のコンポーネントから別の第２のコンポーネントに切り替えを指示すると、それ以後、該第２のコンポーネントで該メソッドを実行する切り替え機能を備えた受信部を有するコンポーネントソフトウェア運用基盤。
【請求項１３】
名前とオブジェクトの組をエントリとして記録するネームサーバを備えたコンポーネントソフトウェア運用基盤であって、該ネームサーバは、該ネームサーバに登録されている二つのエントリのオブジェクト部分をアトミックに入替える機能を有することを特徴とするコンポーネントソフトウェア運用基盤。
【請求項１４】
コンポーネントを前記コンポーネントソフトウエア運用基盤上に配置するデプロイヤを更に備え、
該デプロイヤは、第１のコンポーネントを配備する場合、まだ該第１のコンポーネントが前記運用基盤上に配備されていない場合、該第１のコンポーネントの実体を前記運用基盤上に生成し、該第１のコンポーネントの名前Ａと、実体のリモート参照RＡを組（Ａ、ＲＡ）として該ネームサーバに登録し、既に該第１のコンポーネントが該運用基盤上に配備済みである場合、まず該第１のコンポーネントの別の実体を該運用基盤に生成し、該第１のコンポーネントの名前Ａと重複しない別の名前Aspreと、生成した既実体のリモート参照（（ＲAspare）を組（Ａspare、 ＲAspare）として該ネームサーバに登録する機能を備えることを特徴とする請求項１３記載のコンポーネントソフトウェア運用基盤。
【請求項１５】
各コンポーネントと対になってコンポーネントのクライアントからの該コンポーネントに対するメソッド呼び出しを受信する受信部と制御部を備え、
ある第１のコンポーネントに対応する受信部は、該第１のコンポーネントのクライアントからメソッド呼び出しを受信すると、初期状態では該第１のコンポーネントで該メソッドを実行し、該受信部に対してメソッドの実行先を該第１のコンポーネントから別の第２のコンポーネントに切り替えを指示すると、それ以後、該第２のコンポーネントで該第１のコンポーネントに対するメソッド呼び出しを実行する切り替え機能を備え、
前記制御部は、該第１のコンポーネントがデプロイヤによって実体として該運用基盤に配備され、該第１のコンポーネントの名前Aと、該実体のリモート参照ＲAの組(A、ＲA)が該ネームサーバに登録されている状況において、該第１のコンポーネントの入替え指示を受けると、該第１のコンポーネントの代替である第２のコンポーネントをデプロイヤに指示して前記コンポーネントソフトウェア運用基盤上に配備し、該第２のコンポーネントの実体を該運用基盤に生成すると共に、該第２のコンポーネントの名前Ｂと実体のリモート参照ＲＢの組を該ネームサーバに登録し、該ネームサーバのエントリ入替え機能を呼び出して、該ネームサーバに登録されている名前がＡであるエントリと、該第２のコンポーネントの配備の際に新規に登録された名前がＢであるエントリのオブジェクト部分をアトミックに入替え、それと共に、該第１のコンポーネントの該受信部に対しメソッド実行先として該第１のコンポーネントの代わりに該第２のコンポーネントに切り替えるように指示し、該第１のコンポーネントで実行中のメソッド呼び出しがすべて完了するのを待って、該第１のコンポーネントの実行を終了させ、最後に前記ネームサーバに対して名前がＢであるエントリを削除させるコンポーネント入替え機能を備えることを特徴とする請求項１４記載のコンポーネントソフトウェア運用基盤。
【請求項１６】
請求項１５に記載のコンポーネントソフトウェア運用基盤であって、各コンポーネントの状態、該コンポーネントソフトウェア運用基盤の状態、該運用基盤を実行するOS等の状態を監視する監視部と、該監視部によって取得された各種の状態を元に、あらかじめ各コンポーネント毎に定めておいた入替え条件が成立するかどうか判定する判定部を更に備え、該判定部は一つまたは複数のコンポーネントの判定条件が成り立ったことを検出すると、該制御部に対し該入替え条件の成立した一つまたは複数のコンポーネントの入替えを指示することを特徴とするコンポーネントソフトウェア運用基盤。
【請求項１７】
コンポーネントの入替え機能を有効にするか無効にするかどちらかを指定するインタフェースを備えた請求項１０乃至請求項１６のいずれひとつに記載のコンポーネントソフトウェア運用基盤。
【請求項１８】
複数のコンポーネントから構成されるコンポーネントソフトウェアの各コンポーネント毎に、該コンポーネントの代替となるコンポーネントと該コンポーネントの入替え条件を指定するインタフェースを有するコンポーネントソフトウェア運用基盤。
【請求項１９】
名前とオブジェクトを組みとして管理するネームサービスのＡＰＩ(Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ)であって、２つの名前（A、B）を引数として取り、名前A、Bに対応するエントリがネームサーバに共に存在する場合、名前Aに対応するエントリのオブジェクトと名前Bのオブジェクトをアトミックに入替える機能を提供するネームサービスのＡＰＩ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のソフトウェア部品(以後コンポーネント)から構成されるコンポーネントソフトウェアを高可用運用する運用方法及びコンポーネントソフトウェア運用基盤に関するものである。
【背景技術】
【０００２】
オンラインショッピングサイトや、あるいは社内情報処理システムにおいて、クライアントとしてWebブラウザを用いるＷｅｂアプリケーションの利用が急速に広まっている。昨今のWebアプリケーションは、迅速な開発や柔軟な機能変更という観点から、複数の小規模なソフトウェアコンポーネントを組み合わせるコンポーネント型構成を採っている。このコンポーネントアプリケーションのための基盤技術としてＪ２ＥＥ（Ｊａｖａ２  Ｅｎｔｅｒｐｒｉｓｅ  Ｅｄｉｔｉｏｎ）（ＪａｖａはSun Microsystems社の登録商標）や．NETがあり、これらを用いてWebアプリケーションを開発することが一般的となっている。Ｊ２ＥＥや．NETは、WebアプリケーションのためのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）を提供し、Webアプリケーションの開発者はこれらのAPIを用いてWebアプリケーションを構築する。これらのＡＰＩを用いて構築されたWebアプリケーションはＪ２ＥＥサーバや．NETサーバと呼ばれるアプリケーション運用基盤上で実行される。以下ではＪ２ＥＥを例として、コンポーネントアプリケーションとその運用基盤について説明する。
【０００３】
Ｊ２ＥＥにおけるコンポーネントはＥＪＢ（Ｅｎｔｅｒｐｒｉｓｅ  Ｊａｖａ  Ｂｅａｎ）と呼ばれる。主なＥＪＢにセッションビーンとエンティティビーンがある。セッションビーンはユーザのセッションに対応して処理を行うＥＪＢであり、エンティティビーンはユーザのセッションとは無関係に永続するデータを表すＥＪＢである。エンティティビーンのデータは通常データベースに格納される。ＥＪＢはＪ２ＥＥのＡＰＩに則りＪａｖａ言語で記述されたコンポーネントである。ＥＪＢはＥＪＢを他のEJB等の外部からリモート参照するために、リモートインタフェースとローカルインタフェースという2つのインタフェースをサポートしている。リモートインタフェースはリモートマシーン上に配備されたＥＪＢの呼び出しに主に用いられる。一方、ローカルインタフェースは同一Ｊ２ＥＥサーバ上に配備されたローカルＥＪＢとの通信に用いられる。どちらのインタフェースが使えるかは、ＥＪＢの実装に依存する。
【０００４】
公知技術のコンポーネントソフトウェア運用基盤の構成をＪ２ＥＥサーバを例に図２に示す。１００はコンポーネントソフトウェア運用基盤Ｓ、１１０はデプロイヤ、３００、３２０はEJBを実行する実行環境であるコンテナ、３１０，３３０はコンテナ間のメソッド呼び出しを受信するリモート受信部、３３１はコンテナ間のメソッド呼び出しを送信するリモート送信部、４００はネームサーバである。２００はファイルシステムであり、ここに２１０や２１１のＥＪＢクラスファイルを配置する。図２の例では、Ｊ２ＥＥサーバには2つのＥＪＢ  Ａ、ＥＪＢ  Ｂが配備されている。なお、本図ではアプリケーション運用基盤は一つしかないが、複数のアプリケーション運用基盤を用意して、そのそれぞれにEJBを分散配備して一つのアプリケーションを構築することもできる。以下、図２の各構成要素について説明する。
【０００５】
(ネームサーバ)
ネームサーバ４００はＪＮＤＩ（Ｊａｖａ  Ｎａｍｉｎｇ  ａｎｄ  Ｄｉｒｅｃｔｏｒｙ  Ｉｎｔｅｒｆａｃｅ）APIをサポートする名前とオブジェクトの対応関係を管理するサーバである。ネームサーバ４００はテーブル４０１と制御部４０２を持つ。テーブル４０１は名前４１１とオブジェクト４１２の欄を持つ。制御部４０２はＪＮＤＩ  ＡＰＩをクライアントに提供し、各ＡＰＩの機能を実現する。ネームサーバの主要なAPIとして、以下の4つがある。
【０００６】
（1）ｂｉｎｄ
（2）ｌｏｏｋｕｐ
（3）ｒｅｂｉｎｄ
（4）ｕｎｂｉｎｄ
ｂｉｎｄは名前ＮとオブジェクトＯの組（Ｎ、Ｏ）をネームサーバ４００に登録し、ｌｏｏｋｕｐは名前Ｎでネームサーバ４００を引いて名前Ｎに対応するオブジェクトＯを取り出し、ｒｅｂｉｎｄは名前ＮとオブジェクトＯの組（Ｎ、Ｏ）のオブジェクト部分をＯからＯｎに変更し、ｕｎｂｉｎｄは名前Ｎのエントリ（Ｎ、Ｏ）をネームサーバから取り除く。図２のネームサーバ４００のテーブル４０１には2つのエントリ４２１と４２２が登録されている。図１ではネームサーバ４００はアプリケーション運用基盤中に存在しているが、アプリケーション運用基盤とは独立して存在する場合もある。
【０００７】
(デプロイヤ)
デプロイヤ１１０はＥＪＢをファイルシステムから読み込んで、それを元にＥＪＢのコンテナと、リモート送受信部を生成する。この動作を配備(デプロイ)と呼ぶ。例えばＥＪＢ  Ａを配備する場合、デプロイヤ１１０はファイルシステム２００からEJB  Ａのクラスファイル２１０を読み込み、ＥＪＢ  Ａのコンテナ３００、リモートＡ受信部３１０、リモートＡ送信部３１１を生成する。そして、ＥＪＢ  Ａの名前Ａとコンテナ３００のリモートインタフェースＩｎｔＣｏｎＡの組（Ａ、ＩｎｔＣｏｎＡ）をネームサーバ４００のｂｉｎｄ APIを呼び出してネームサーバ４００に登録する。登録されたエントリは４２１である。同様にＥＪＢ  Ｂを配備すると、ファイルシステム２００からＥＪＢ  Ｂのクラスファイル２１１を読み込み、ＥＪＢ  Ｂのコンテナ３２０、リモートＢ受信部３３０、リモートＢ送信部（リモートＢ送信部は以後使用しないので図２には示していない）を生成する。そして、コンポーネントＢの名前Ｂとコンテナ３２０のリモートインタフェースＩｎｔＣｏｎＢの組（Ｂ、ＩｎｔＣｏｎＢ）をネームサーバ４００のｂｉｎｄ APIを呼び出して登録する。登録されたエントリは４２２である。
【０００８】
デプロイヤは配備したＥＪＢの配備解除(アンデプロイ)機能を持つ。配備解除は、まず当該ＥＪＢのコンテナ上で動作するＥＪＢインスタンスを破棄し、コンテナとリモート受信部、リモート送信部を破棄する。
【０００９】
(コンテナ)
コンテナ３００、コンテナ３２０はそれぞれEJB  Aのインスタンス３０１、EJB  Bのインスタンス３２１の実行をサポートする実行環境である。クライアントからのcreateメソッド呼び出しに従ってインスタンス３０１、３２１を生成する。
【００１０】
(リモート受信部・リモート送信部)
リモートＡ受信部３１０とリモートＡ送信部３１１はペアとなっておりクライアントからのＥＪＢ  Ａのリモートメソッド呼び出しのための通信をサポートする。同様にリモートＢ受信部３３０とリモートＢ送信部（図２中には記述無し）はペアとなっておりクライアントからのＥＪＢ  Ｂのリモートメソッド呼び出しのための通信をサポートする。これらの通信は一般的にＲＭＩ−ＩＩＯＰなどのプロトコルが使用される。一般的にリモート受信部（３１０、３３０）はＲＭＩのスケルトン、リモート送信部（３１１）はＲＭＩのスタブである。これらリモート受信部とリモート送信部のペアはＥＪＢデプロイ時にＪ２ＥＥサーバによって自動的に生成されるか、あるいは、はじめからＪ２ＥＥサーバに組み込まれているかのどちらかである。
【００１１】
(ファイルシステムとクラスファイル)
ファイルシステム２００はコンポーネントソフトウェア運用基盤１００のが動作するＯＳのファイルシステムである。
【００１２】
(クラスファイル)
クラスファイル２１０、２１１はＪａｖａのオブジェクトファイルであり、Ｊａｖａで記述されたソースコードをＪａｖａコンパイラでコンパイルして得られる。あるいは、コンパイルして得られたオブジェクトファイルとそれを配備するデプロイメントデスクリプタをＪＡＲファイルとしてアーカイブしたものである。
【００１３】
次に図２において、EJB  Bのインスタンス３２１がEJB  AのメソッドｍｅｔｈｏｄＸを呼び出す場合を例としてEJB間のメソッド呼び出しを説明する。ＥＪＢ  ＢにおけるEJB  AのメソッドｍｅｔｈｏｄＸを呼び出すコードは一般に図３のようになる。まず図３の１〜２行目でＪＮＤＩのｌｏｏｋｕｐ  ＡＰＩを用いてネームサーバ４００を参照し、名前Aに対応するＥＪＢ  ＡのコンテナＡのリモートインタフェースを取得する（これをホームインタフェースと呼ぶ）。次に3行目でＥＪＢ  Ａのホームインタフェースのｃｒｅａｔｅメソッドを呼び出す。このリモートホームインタフェースのメソッドｃｒｅａｔｅの呼び出しは、コンテナB３２０、リモートＡ送信部３１１、リモートＡ受信部３１０を経由してコンテナA３００に到達する。コンテナA３００はcreateメソッド呼び出しを受けると、EJB  Aのインスタンス３０１を一つ生成し、このEJB  Aのインスタンス３０１のリモートインタフェース（これをコンポーネントインタフェースと呼ぶ）を返り値として、リモートＡ受信部３１０、リモートＡ送信部３１１、コンテナB３２０を経由しEJB  Bのインスタンス３２１に返し、ＥＪＢ  Ｂのインスタンス３２１がそれを受け取る。最後に、EJB  Bのインスタンス３２１は4行目で、EJB  Aのコンポーネントインタフェースに対しメソッドｍｅｔｈｏｄＸを呼び出すと、そのメソッド呼び出しは、コンテナB３２０、リモートＡ送信部３１１、リモートＡ受信部３１０、コンテナA３００を経由し、EJB  Aのインスタンス３０１に到達する。呼び出しを受けたEJB  Aのインスタンス３０１はメソッドｍｅｔｈｏｄＸを実行し、その結果をコンテナA３００、リモートＡ受信部３１０、リモートＡ送信部３１１、コンテナB３２０を経由して、EJB  Bのインスタンス３２１に返す。
【００１４】
上記の説明では、ＥＪＢ  ＡのクライアントであるＥＪＢ  ＢがＥＪＢ  Ａのホームインタフェースを使用してコンテナＡ３００と通信する場合、及び、コンポーネントインタフェースを使用してＥＪＢ  Ａのインスタンス３０１と通信する場合の両方において、同一のリモート送信部３１１とリモート受信部３１０を使用するものとした。このような通信を実現するため、リモート送信部とリモート受信部を通るリモートメソッド呼び出しのためのメッセージは図１７  １１００のように構成される。１１０１はアクセス対象を示す対象識別子、１１０２は呼び出すメソッド、１１０３はメソッド１１０２のメソッド引数リスト１１０３である。対象識別子はコンテナＩＤまたはＥＪＢインスタンスＩＤである。リモート受信部（３１０、３３０）はメッセージ１１００の対象識別子１１０１がコンテナＩＤである場合は、コンテナに対してメソッド呼び出しを実行し、ＥＪＢインスタンスＩＤである場合には、当該ＥＪＢインスタンスのメソッド呼び出しを実行する。なお、Ｊ２ＥＥサーバの実装によっては、ホームインタフェース用とコンポーネントインタフェース用の２種類のリモート送信部、リモート受信部を用いる場合もある。
【００１５】
以上EJBがリモートインタフェースを提供する場合について説明したが、ローカルインタフェースを提供する場合、リモート受信部、リモート送信部の代わりに、ローカル受信部、ローカル送信部が用いられ、同一Ｊ２ＥＥサーバ内に特化されて最適化された低コスト通信が可能となる。
【００１６】
さて、これらのWebアプリケーションサイトの普及とともにサイト間の競争が激化しており、各サイトとも顧客の嗜好に合わせ迅速な機能修正や追加に追われている。迅速な機能の修正や追加は、すなわち開発とテストを限られた時間内で行うことを意味しており、必ずしも十分なテストができるとは限らない。従って、実際に顧客にサービスを提供する実運用を開始した後のWebアプリケーションにおいても、バグが残っている可能性が高く、それらのバグがシステムに障害を起し、サービスが停止する可能性がある。Webアプリケーションがバグ等によりダウンすると、サイトにとって莫大な損害が出ることから、バグが存在しても何とかサービスを継続させることのできる運用方法に注目が集まっている。
【００１７】
バグによって発生した障害の多くはアプリケーションを再起動することで一時的に解決することが知られていることから、Webアプリケーションを運営するサイトの中には、定期的にWebアプリケーションを再起動して障害を未然に防ぐ対策をしているところもある。
この再起動の考え方を粒度の小さなコンポーネントレベルで行うことでより効率的に障害から復旧する方法が特許文献１や非特許文献１に示されている。
【００１８】
特許文献１では、コンポーネントベース・アプリケーションにおいて、システム運用時に、システムの信頼性と性能を監視するために、ソフトウェア・コンポーネントに処理時間を測定するコードを埋め込み、これにより処理時間を測定し、測定された処理時間があらかじめ設定された閾値を超過した場合に、当該コンポーネントを異常状態と判定し、当該コンポーネントを閉塞したり、再起動するなどの対処方法について示している。
【００１９】
非特許文献１では、Webアプリケーションを構成するコンポーネントのうち、バグ等によって障害の発生したコンポーネントのみを再起動することによって、アプリケーション全体を再起動する場合に比べて高速に障害復旧するマイクロリブートという技術が示されている。障害の発生が予兆される場合にコンポーネントのマイクロリブートを行うことによって、低コストで未然に障害の発生を防ぐ方法についても示されている。
【００２０】
一方、再起動の場合、再起動している最中のコンポーネントに対する処理リクエストが来ると、それらはエラーとなってしまうこという問題があった。そこで、コンポーネントを終了して再び起動するのではなく、新しいコンポーネントを先に生成しておき新旧のコンポーネントを入替えることで、障害復旧とエラーを両立する方法が特許文献２と３に示されている。
【００２１】
特許文献２では、アプリケーションを構成するオブジェクト・インスタンス毎に監視プロセスを割り当て、これにより全てのオブジェクト・インスタンスの実行状況を監視し、異常と診断されたオブジェクト・インスタンスに対して、当該オブジェクト・インスタンスを代用オブジェクト・インスタンスと交換する方法を示している。
【００２２】
特許文献３では、マルチプロセス・マルチスレッドのアプリケーションにおいて、アプリケーションを停止することなく一部のコンポーネントを新コンポーネントと入替える方法が示されている。入替対象となっているコンポーネントに対する処理スレッドを一旦すべて停止し、全てのスレッドが停止状態となったらコンポーネントを置換するという方法を示している。
【００２３】
【特許文献１】特開２００２−８２９２６号公報
【００２４】
【特許文献２】特開平８−７７１２０号公報
【特許文献３】特開２００１−２９０６３７公報
【非特許文献１】Ｇｅｏｒｇｅ  Ｃａｎｄｅａ、  ｅｔ  ａｌ．、「Ａ  Ｍｉｃｒｏｒｅｂｏｏｔａｂｌｅ  Ｓｙｓｔｅｍ  −  Ａ  Ｔｅｃｈｎｉｑｕｅ  ｆｏｒ  Ｃｈｅａｐ  Ｒｅｃｏｖｅｒｙ」、６ｔｈ  Ｓｙｍｐｏｓｉｕｍ  Ｏｎ  Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍｓ  Ｄｅｓｉｇｎ  ＆  Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ  ２００４
【発明の開示】
【発明が解決しようとする課題】
【００２５】
しかし従来技術には次のような問題があった。第一に従来の技術ではコンポーネントを入替える際に、そのコンポーネントに対する処理をすべて停止するため、性能が低下するという問題があった。第二に、前述したようにEJBのメソッドを呼び出すためには、呼び出し側クライアントは呼び出し先EJBのホームインタフェースとコンポーネントインタフェースを順に取得し、最後に目的のメソッド呼び出しを行う。呼び出し先EJBの入替えを行った以後の当該EJBに対するメソッド呼び出しは、入替後の新EJBにて実行する必要がある。しかし、呼び出し側がホームインタフェース、または、ホームインタフェースとコンポーネントインタフェースの両方を取得した直後に、呼び出し先EJBの入替が行われ、その後メソッドが呼び出されても、当該インタフェースは旧EJBのインタフェースであるため、旧EJBに対してメソッド呼び出しを実行しようとする。もしEJBの入替直後に旧コンポーネントを終了すると、当該旧EJBに対するメソッド呼び出しはエラーとなる。また、EJBを入替た後も旧コンポーネントを残しておく方法も考えられるが、旧EJBに対するホームインタフェースやコンポーネントインタフェースは、クライアントのプログラムによって長時間生存し続ける可能性があることから、せっかくEJBを入替えて障害の発生を防止しようとしたのに、旧コンポーネントの終了ができずに、障害が発生してしまう可能性がある。
【００２６】
そこで、本発明の第一の課題は、障害の予兆や障害発生に適応してコンポーネントを入替えるコンポーネントアプリケーション運用方法であって、入替時にエラーを発生させずかつ性能を落とさないコンポーネント入替技術を提供することである。また、本発明の第二の課題は、コンポーネント入替時に問題となる上記インタフェースの問題を解決し、コンポーネントを旧コンポーネントから新コンポーネントに入替えた瞬間から、そのコンポーネントに対する全てのメソッド呼び出しは新コンポーネントで実行する技術を提供することである。
【課題を解決するための手段】
【００２７】
あらかじめコンポーネント毎に代替コンポーネントとそのコンポーネントに障害が発生することを予兆する条件を定義しておく。
アプリケーション運用基盤に、各コンポーネントの状態や運用基盤自身の状態を監視する監視部、監視部の情報に基づいて各コンポーネント毎に定義された条件が成立するかどうかを判定する判定部、判定部によって条件が成立したコンポーネントを指定された代替コンポーネントに入替える制御を行う制御部、既にアプリケーション運用基盤に配備されたコンポーネントを重複して配備する重複デプロイヤ、コンポーネント間の通信を制御する通信制御部、2つのエントリの名前とオブジェクトとをアトミックに入替える機能を持ったネームサーバを儲ける。
【００２８】
アプリケーション運用基盤は、監視部が各コンポーネントの状態や運用基盤自身の状態を監視して、判定部がその監視結果を元に各コンポーネントに定義された条件が成立するかどうか判定し、もしあるコンポーネントＡの条件が成立した場合は、制御部がそのコンポーネントＡを代替コンポーネントＢと入替える。
【００２９】
入替えは、まず、重複デプロイヤによって代替コンポーネントＢの実体をアプリケーション運用基盤上に生成し、その実体のインタフェースと、その実体を一意に識別する名前Ｂの組をネームサーバに登録する。そして、ネームサーバの入替え機能を用い、登録されている現在運用中のコンポーネントの名前Ａと新規に登録した代替コンポーネントの名前Ｂのインターフェース部分を入替え、以後、名前Ａで代替コンポーネントＢの実体のインタフェースが得られるようにする。次に、通信制御部によってコンポーネントＡに対する通信を、代替コンポーネントＢに送るように通信先を入替える。最後にコンポーネントＡの実体で実行されていた処理が全て完了するまで待って、完了するとコンポーネントＡの実体を終了すると共に、当該実体と名前Ｂからなるエントリをネームサーバから削除する。
【発明の効果】
【００３０】
本発明のコンポーネントソフトウェアの運用方法は、特定のコンポーネントに障害の発生が予兆される場合、当該コンポーネント（旧コンポーネント）の代替コンポーネント（新コンポーネント）を新たに配備して、配備が完了すると、当該コンポーネントに対する新規の処理要求は全て新コンポーネントで実行し、かつ、旧コンポーネントが既に実行中の処理は旧コンポーネントで処理を実行し続け、旧コンポーネントで実行中の処理が全て完了すると、旧コンポーネントを終了することによって、処理を停止することなく新旧コンポーネントを入替えるため、性能低下がなくかつコンポーネント入替えによって障害の発生が予防できる。また、クライアントから受けた処理をコンポーネントに送る通信処理を間接化し、クライアントが旧コンポーネントのインタフェースを持っていて、そのインタフェースを用いてメソッド呼び出しをした場合であっても、そのメソッド呼び出しは旧コンポーネントではなく新コンポーネントに送られて新コンポーネントで処理されるため、コンポーネントの入替えの短期化と、それによる確実な障害予防が実現される。
【発明を実施するための最良の形態】
【００３１】
性能を落とさずに高可用運転を実現するコンポーネントソフトウェアの運用基盤の実現を目的とし、既存のコンポーネントソフトウェア運用基盤であるＪ２ＥＥサーバをベースとし幾つかのモジュールの追加とＪ２ＥＥサーバの一部修正によって最小の工数で実現した。
【実施例１】
【００３２】
図１は、本発明のコンポーネントソフトウェア運用基盤の構成図である。２００、２１０、２１１、３００、３０１、３１１、３２０、３２１は前述の図２と同じである。１２０は図２のデプロイヤ１１０に同一ＥＪＢを重複して配備する機能を持たせたデプロイヤ、１３０はＥＪＢの入替えを制御する制御部、１４０は各ＥＪＢの状態、コンポーネントソフトウェア運用基盤の状態、コンポーネントソフトウェア運用基盤が動作するＯＳの状態などを監視する監視部、１５０は監視部１４０が監視して得られた各種の情報を元にしてＥＪＢ毎に定められた条件が成立するかどうか判定する判定部、３１２は図２のリモートＡ受信部３１０の機能を拡張したリモートＡ受信部、３３２は図２のリモートＢ受信部３３０の機能を拡張したリモートＢ受信部、４５０は図２のネームサーバ４００に機能を追加したネームサーバである。２２０はＥＪＢ  Ａの代替ＥＪＢや入替え条件を定義したＡ入替え定義ファイル、２２１はＥＪＢ  Ｂの代替ＥＪＢや入替え条件を定義したＢ入替え定義ファイルである。
【００３３】
（各部の説明）
（１）ネームサーバ
ネームサーバ４５０は図２のネームサーバ４００に機能を追加したものである。テーブル４０１は図２のテーブルそのものである。制御部４５２は図２の制御部４０２がサポートする全てのＡＰＩの他に図８に示すreplaceというＡＰＩとその処理機能を備える。制御部４５２がサポートする主要なＡＰＩを以下に示す。
(1)bind
(2)lookup
(3)rebind
(4)unbind
(5)replace
後述するように既存のbind等のAPIの処理も処理がアトミックとなるように機能を修正している。ｒｅｐｌａｃｅ  ＡＰＩは2つの名前ｎａｍｅ１、ｎａｍｅ２を引数として取り、テーブル４０１に登録されている名前がｎａｍｅ１のエントリのオブジェクトと、名前がｎａｍｅ２であるエントリのオブジェクトをアトミックに入替える。例えばテーブル４０１に名前NaとオブジェクトＯａの組(Na、Oa)と、名前NbとオブジェクトObの組（Ｎｂ、Ｏｂ）が登録されており、ｒｅｐｌａｃｅ（Ｎａ、Ｎｂ）が呼び出された場合、2つのエントリは（Ｎａ、Ｏｂ）、（Ｎｂ、Ｏａ）となる。このｒｅｐｌａｃｅの処理はｌｏｏｋｕｐとｒｅｂｉｎｄを組み合わせることで実現できる。まずＮａ、ＮｂをそれぞれｌｏｏｋｕｐしオブジェクトOa、 Obを取り出す。次に、名前Naに対してObをｒｅｂｉｎｄし、名前Nbに対してOaをrebindする。ただし、これらの処理の実行途中に、replace処理とは別にlookup、 rebind、 unbind処理が発生すると、テーブルが不整合になるなどの問題が発生する可能性がある。そこでまず制御部４５２にロック変数Ｌを設ける。また、従来のbind、 lookup、 rebind、 ｕｎｂｉｎｄをそれぞれibind、 ilookup、 irebind、 ｉｕｎｂｉｎｄと名称変更し、bindやlookupはロック変数とibindやilookupを組み合わせて実現する。図９にreplace（Ｎａ、Ｎｂ）の処理フローを示す。１００１でまずロック変数Ｌをロックする。既に他の処理がロック変数Ｌをロック中の場合はアンロックするまで待たされる。
【００３４】
次に１００２でilookup(Na)により名前Ｎａと組みになっているオブジェクトを取り出しtemp1に格納する。次に１００３でilookup(Nb)により名前Nbと組になっているオブジェクトを取り出してtemp2に格納する。１００４でirebind(Na、temp2)により、名前Ｎａのオブジェクトを入替え、１００５でirebind(Nb、temp1)により、名前Ｎｂのオブジェクトを入替える。最後に１００６でロック変数Ｌをアンロックする。図１０にbind(N、O)の処理フローを示す。まず１０１１でロック変数Ｌをロックし、１０１２でibind(N、O)を実行し、１０１３でロック変数Ｌをアンロックする。rebind(N、O)、unbind(N)も同様であり、１０１２のところをそれぞれirebind(N、O)、iunbind(N)と置き換えるだけで実現される。図1９にlookup(Na)の処理フローを示す。１０２１でロック変数Ｌをロックし、１０２２でilooup(Na)を実行し、１０２３でロック変数Ｌをアンロックし、１０２４で１０２２実行の結果得られたオブジェクトを返す。
【００３５】
（２）  入替え定義ファイル
入替え定義ファイル２２０、２２１は図４に示すように、XMLで記述され、ＥＪＢ名（2行目）、代替ＥＪＢ名（3行目）、入替え条件（4行目〜6行目）、優先度（7行目）などの項目から構成される。図４はＥＪＢ  Ａに関する入替えを定義しており、代替コンポーネントとしてＥＪＢ  Ａを（すなわち同一ＥＪＢの別の実体に入替える）、入替え条件として生存期間300秒（5行目）を指定しており、配備されてから300秒立つと入替えを行うことを意味する。優先度は、同時に複数のＥＪＢで入替え条件が成立したときに、入替えＥＪＢの順序を決定するのに使用する。入替え条件としては図４の生存期間の他、図５、図６、図７などが指定できる。図５はＥＪＢの呼び出し回数が１００００回になった場合、図６はＯＳのメモリ使用量が９０％を超えた場合、図７はＥＪＢ  Ａにて例外（種類は問わない）が5回発生した場合それぞれ入替えを行う。これらの条件をandやorで複数結合し、複合条件を指定することもできる。定義ファイル２２０、２２１はＸＭＬで記述されているが、他の形式や、独自形式であっても良い。また、図１ではＥＪＢ  Ａの入替え定義と、ＥＪＢ  Ｂの入替え定義を別々の入替え定義ファイルに記述しているが、幾つかのＥＪＢの入替え定義を一つのファイルにまとめて記述しても良い。ファイルの代わりに、これらの値を入力するユーザインタフェースを設けてユーザに入力させても良い。
【００３６】
（３）デプロイヤ
デプロイヤ１２０は図２のデプロイヤ１１０を機能拡張したものであり、クラスファイルと入替え定義ファイルを読み込みＥＪＢを配備する。以下ではＥＪＢ  Ａを配備する場合を例に説明する。ＥＪＢ  Ａがコンポーネントソフトウェア運用基盤１０１に配備されていない場合、前述の図２の１１０とほぼ同様に動作する。すなわちファイルシステム２００からEJB  Ａのクラスファイル２１０を読み込み、ＥＪＢ  Ａのコンテナ３００、リモートＡ受信部３１２、リモートＡ送信部３１１を生成する。そして、ＥＪＢ  Ａの名前Ａとコンテナ３００のリモートインタフェースＩｎｔＣｏｎＡの組（Ａ、ＩｎｔＣｏｎＡ）をネームサーバ４５０のｂｉｎｄ APIを呼び出して登録する。次にＡ入替え定義ファイル２２０を読み込んで、ＥＪＢ名、代替ＥＪＢ名、優先度を制御部１３０に設定し、ＥＪＢ名、入替え条件、現在時刻を判定部１５０に設定する。
【００３７】
ＥＪＢ  Ａが既にコンポーネントソフトウェア基盤１０１に配備されている場合を図１１を用いて説明する。図１１はＥＪＢ  ＡとＥＪＢ  Ｂが配備された図１のコンポーネントソフトウェア運用基盤１０１にＥＪＢ  Ａを重複して配備した場合を示しており、変更分は５００、５０１、５１２のもである。デプロイヤ１２０はファイルシステム２００からＥＪＢ  Ａのクラスファイルを読み込み、既に配備されているコンテナＡ３００、リモートＡ受信部３１０、リモートＡ送信部（図１中には記述なし）とは別に新たにＥＪＢ  ＡのコンテナＡｓ５００、リモートＡｓ受信部５１２、リモートＡｓ送信部（図中に記述無し）を生成する。そして、ＥＪＢ  Ａの名前Ａと重複しない名前Ａsをオリジナルの名前Ａに数字を付加して生成する。この数字はデプロイヤ１２０にＥＪＢ毎にカウンタを持たせ、ＥＪＢ  Ａの重複配備を実行する度にカウンタを１インクリメントすることで実現する。この数字はデプロイヤ１２０の内部のカウンタで管理するのではなく、外部のＤＢで管理しても良い。そのほか、数字の代わりに特定の文字列を用いても良いし、時刻を用いても良い。このようにして生成した名前ＡｓとコンテナＡｓ５００のリモートインタフェースＩｎｔＣｏｎＡｓの組（Ａｓ、ＩｎｔＣｏｎＡｓ）をネームサーバ４５０のbind ＡＰＩを呼び出して登録する。次にＡ入替え定義ファイル２２０を読み込んで、ＥＪＢ名、代替ＥＪＢ名、優先度を制御部１３０に設定し、ＥＪＢ名、入替え条件、現在時刻を判定部１５０に設定する。なお、入替えて意義ファイルが存在しない場合は、上記の制御部１３０と判定部１５０の設定は行わない。
【００３８】
デプロイヤ１２０によるリモート受信部（３１２、３３２）の生成については以下のリモート受信部（３１２、３３２）の記述の際に述べる。
デプロイヤ１２０はデプロイヤ１１０と同様に配備解除機能を持つ。配備解除は、配備解除対象ＥＪＢのインスタンスを破棄し、コンテナ、リモート受信部、リモート送信部を破棄する。この配備解除機能の他に、デプロイヤ１２０は部分配備解除機能を持つ。部分配備解除機能とは、対象ＥＪＢのインスタンスとコンテナの破棄のみ行い、リモート受信部、リモート送信部の破棄を行わない。
【００３９】
（４）監視部
監視部１４０は、各ＥＪＢ呼び出し回数、例外やエラーの発生、ＯＳのメモリ使用率等を例えば３０秒間隔ごとに定期的に計測する。ＥＪＢの呼び出し回数はコンテナ３００、３２０、５００内に整数カウンターを設け、呼び出しがあるたびにそれを１インクリメントすることで実現する。例外やエラーの発生は、コンテナ３３０、３２０、５００にvectorを設け、エラーや例外が発生すると、発生したエラーの種類、メソッドの名称、呼び出し時刻をそれに追記していく。これらカウンタやlistを返すメソッドをコンテナに用意し、監視部１４０は定期的にこれらのメソッドを呼び出して情報を取得する。ＯＳのメモリ使用率はコンポーネントソフトウェア運用基盤に用意されているＡＰＩがあればそれを使用し、そうでなければＯＳにシステムコールを発行してコンポーネントソフトウェア運用基盤が使用しているメモリサイズと、最大メモリサイズを取得して、これらから使用率を計算する。監視部１４０はこれらのＥＪＢ呼び出し回数、例外やエラーの発生、メモリ使用率のそれぞれを外部から取得するメソッドgetCount、 getEvent、 getMemを備えている。
【００４０】
（５）判定部
判定部１５０は一定の間隔、例えば１分毎に各ＥＪＢの入替え条件が成立するか判定する。判定部１５０は図１２に示す条件表６００を備えている。条件表６００は３つの欄ＥＪＢ名６１０、入替え条件６１１、配備時刻６１２から構成されている。図１２では２つのエントリ６２０と６２１が登録されている。これらのエントリはデプロイヤ１２０がＥＪＢを配備する際に条件表６００に登録される。エントリ６２０はＥＪＢ  Ａの入替え条件を示しており、配備時間が３００秒を超えたら入替えを行うことを示す。配備時間を判定するために、配備時刻の欄６１２が用いられる。エントリ６２１はＥＪＢ  Ｂの入替え条件を示しており、ＥＪＢ  Ｂの呼び出し回数が１００００回となったら入替えを実行することを意味している。
【００４１】
判定部１５０は条件表６００の各エントリに対して順次入替え条件が成立するかどうか判定する。入替え条件が配備時間である場合は、現在の時刻と条件表６００に登録されている配備時刻６１２の差分が指定時間より長ければ入替え条件が成立したと判定する。入替え条件がＥＪＢの呼び出し回数であるとき、監視部１４０のメソッドｇｅｔＣｏｕｎｔを呼び出して当該ＥＪＢの呼び出し回数を取得し、それが指定された値より大きければ入替え条件が成立したと判定する。入替え条件が例外やエラーの回数である場合は、監視部１４０のメソッドgetEventを呼び出して例外やエラー情報を取得し、指定されているエラーや例外の発生回数を調べ、それらが指定された回数を超えていれば条入替え条件が成立したと判定する。入替え条件がメモリ使用率である場合、監視部１４０のメソッドgetMemを呼び出してメモリ使用率を取得し、それが指定されたメモリ使用率より大きかった場合には、条件が成立したと判定する。以上の判定を条件表６００の各エントリに対して実行し、入替え条件が成立したＥＪＢ名リストを引数として制御部１３０を呼び出す。
【００４２】
（６）リモート受信部
リモートＡ受信部３１２、リモートＢ受信部３３２（以後リモート受信部）は図２のリモートＡ受信部３１０、リモートＢ受信部３３０に機能を追加したものである。これらはそれぞれリモートＡ送信部３１１、リモートＡ送信部（図中に記述無し）（以後リモート送信部）とペアになっており、ＥＪＢ  Ａ、ＥＪＢ  Ｂとのリモート通信を実現する。リモート受信部はＲＭＩのスケルトンとして実現され、リモート送信部はＲＭＩのスタブとして実現される。リモートＡ送信部３１１、リモートＢ送信部(図中に記述なし)はそれぞれ公知のＲＭＩスタブである。デプロイヤ１２０がこれらはＥＪＢ  ＡやＥＪＢ  Ｂを配備する際に、公知のＲＭＩコンパイラｒｍｉｃを使用して自動的に生成する。その手法は公知のデプロイヤ１１０と同様である。リモートＡ受信部３１２、リモートＢ受信部３３２は公知のＲＭＩスケルトンに機能追加している。
【００４３】
図１４にリモートＡ受信部３１２の構成を示す。リモートＡ受信部は図２のリモートＡ受信部３１０にコンテナ管理変数８００と制御部８０１とＥＪＢインスタンス管理テーブル８０２を追加し、通信機能を一部修正したものである。コンテナ管理変数８００の初期値はＮＵＬＬである。この変数はコンテナの切り替えをサポートするために用いられる。制御部８０１はsetContainerメソッドをサポートする。setContainerメソッドをコンテナを引数として呼び出すと、制御部８０１は、引数で指定されたコンテナをコンテナ管理変数８００に上書きする。ＥＪＢインスタンス管理テーブル８０２は、旧ＥＪＢインスタンスＩＤ８１０と新ＥＪＢインスタンスＩＤ８１１の欄から構成されるテーブルであり、コンテナを入替えた際に、旧インスタンスと新インスタンスとの対応関係を記録するために用いられる。ＥＪＢインスタンス管理テーブル８０２は、制御部８０１のsetContainerメソッドが呼び出されると、すべてのエントリがクリアされて初期化される。
【００４４】
リモートＡ受信部３１２とリモートＡ送信部３１１との間でやり取りされるメソッド呼び出しのメッセージは前述のリモートＡ受信部３１０とリモートＡ送信部３１１との間でやり取りされるメッセージ１１００（図１７）と同じである。リモートＡ受信部３１２がリモートＡ送信部３１１からメッセージ１１００を受け取ると、リモートＡ受信部３１２はまずコンテナ管理変数８００がＮＵＬＬであるかどうか調べ、ＮＵＬＬである場合、メッセージ１１００の対象識別子１１０１を調べ、対象識別子がコンテナＩＤである場合には、コンテナＩＤで示されるデフォルトのコンテナＡ３００のメソッド１１０１を引数１１０２とともに呼び出す。対象識別子がＥＪＢインスタンスＩＤである場合には、デフォルトのコンテナＡ３００上の対象識別子１１０１で識別されるＥＪＢ  Ａのインスタンス３０１のメソッド１１０２を引数１１０３と共に呼び出す。
【００４５】
コンテナ管理変数８００がＮＵＬＬで無い場合であって、メッセージ１１００の対象識別子がコンテナＩＤである場合には、コンテナ管理変数８００で識別されるコンテナのメソッド１１０２を引数１１０３と共に呼び出す。対象識別子がＥＪＢインスタンスＩＤである場合には、まずＥＪＢインスタンス管理テーブル８０２を参照し、旧ＥＪＢインスタンスＩＤ８１０の欄がメッセージ１１００の対象識別子１１０１と一致するエントリが無いか調べ、存在した場合は、そのエントリの新ＥＪＢインスタンスＩＤ８１１で識別される、コンテナ管理変数８００で識別されるコンテナ上のＥＪＢインスタンスのメソッド１１０２を引数１１０３と共に呼び出す。ＥＪＢインスタンス管理テーブル８０２にエントリに一致するエントリが存在しない場合は、コンテナ管理変数８００で識別されるコンテナにcreateメソッドを発行して当該コンテナ上に一つＥＪＢインスタンスを生成し、メッセージの対象識別子１１０１とcreateの結果生成されたＥＪＢインスタンスの識別子の組をＥＪＢインスタンス管理テーブル８０２に登録する。これによって、コンテナ管理変数にコンテナが登録されている場合には、アクセス対象をデフォルトのコンテナに代えて、指定されたコンテナとすることにより、リモートメソッド呼び出しの切り替えを実現している。
【００４６】
リモート受信部（３１２、３３２）は、デプロイヤ１２０がＥＪＢ  ＡやＥＪＢ  Ｂを配備する際に自動的に生成される。その方法は公知の図２のデプロイヤ１１０が従来のリモート受信部（３１０、３３０）を生成するのとほぼ同様である。相違点は、上記のコンテナ切り替え制御を実現するコードを通常のスケルトンコードに埋め組む拡張を施したＲＭＩコンパイラrmicを使用することである。あるいはスケルトンの生成には通常のＲＭＩコンパイラrmicを使用し、生成されたスケルトンコードに上記のコンテナ切り替えコードを埋め込むことによって生成しても良い。
【００４７】
（７）制御部
制御部１３０はＥＪＢの入替えを行う。制御部は図１３の入替表７００と図２０のユーザインタフェース１２００とを持つ。
入替表７００はＥＪＢ名７１０、代替ＥＪＢ名７１１、優先度７１２の欄を持つ。デプロイヤ１２０がＥＪＢを配備する際に入替定義ファイル２２０、２２１を読んで値を入替表７００に登録する。ＥＪＢ  Ａを配備した場合に登録されたエントリが７２０であり、ＥＪＢ  Ｂを配備した場合のエントリが７２１である。エントリ７２０は、ＥＪＢ  Ａの代替ＥＪＢはEJB Aであり、その優先度は３であることを意味する。エントリ７２１はＥＪＢ  Ｂの代替ＥＪＢがＥＪＢ  Ｂnewであり、その優先度は５であることを意味する。
【００４８】
ユーザインタフェース１２００はユーザがコンポーネントソフトウェア運用基盤１０１に対してコンポーネントの入替えに関する設定をするためのインタフェースである。ユーザインタフェース１２００は自動入替えに関する設定と、手動入替えに関する設定をサポートする。自動入替えに関する設定は、コンポーネントの入替えを自動的に行うかどうかを指示する。ボタン１２０１は自動的に入替えを実施することを示し、１２０２は自動的に入替えを実施しないことを示す。これらのボタンはどちらか一方のみ選択できる。図２０では入替えを実施するボタン１２０１が選択されており、この場合制御部１３０は以下に示すコンポーネント入替え処理を実行する。１２０２のボタンが選択されている場合には、コンポーネント入替え処理は行わない。また、手動入替えに関する設定は、入力欄１２０３に入替え対象コンポーネントを指定して、ボタン１２０４を押すと、以下コンポーネント入替え処理のフェーズ２で説明するように、入力したコンポーネントをその代替コンポーネントと入替える。なお、ユーザインタフェースは図２０の１２００のようなグラフィカルユーザインタフェース（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ：  ＧＵＩ）のほか、コマンドラインインタフェース（Ｃｏｍｍａｎｄ  Ｌｉｎｅ  Ｉｎｔｅｒｆａｃｅ：  ＣＵＩ）であっても良いし、ＧＵＩとＣＵＩを両方サポートしても良い。また、ユーザの代わりに、他のプログラムが上記ＧＵＩまたはＣＵＩを操作しても良い。
【００４９】
(コンポーネント入替え処理)
コンポーネント入替えは以下のフェーズ１とフェーズ２から構成される。
(フェーズ１)
制御部１３０は判定部１５０から呼び出される。判定部は入替え条件の成立したＥＪＢ名をリストとして制御部１３０に渡す。制御部１３０は、このリストを参照し、リストにある全てのＥＪＢに対して入替表７００から優先度を取り出し、優先度の高い順にＥＪＢの入替えを行う。優先度が同じ場合にはランダムに選ぶ。他の選択方法であっても良い。以後決定した順番でＥＪＢの入替えを行っていく。このとき、例えば１０秒間隔で一つずつ入替える。あるいは、間隔をあけずに順次入替えても良い。
【００５０】
(フェーズ２)
以下ＥＪＢ  Ａを入替える場合を例として処理方法を説明する。入替え処理は図１５のフローに従って実行される。まず９００で入替表７００を参照して入替え対象ＥＪＢの代替ＥＪＢを取り出す。ＥＪＢ  Ａの場合はＥＪＢ  Ａ自身が代替ＥＪＢである。次に９０１でデプロイヤ１２０に対し、ＥＪＢ  Ａの代替ＥＪＢであるＥＪＢ  Ａの配備を指示する。代替ＥＪＢ  ＡがＥＪＢ  Ａと同一であるため、デプロイヤ１２０はコンテナを重複して配備する。配備後のコンポーネントソフトウェア運用基盤は図１１の１０１となる。５００は重複して配備されたＥＪＢ  ＡのコンテナＡｓ、５１２はＥＪＢ  ＡのリモートＡｓ受信部である。（識別容易化のためＡの代わりにＡｓという記号を用いている）。図１１の５０１はコンテナＡｓ５００上のＥＪＢ  Ａのインスタンスであるが、この時点ではまだインスタンスは生成されない。そしてデプロイヤ１２０はネームサーバ４５０にエントリ４２３を追加する。次に制御部１３０は９０２で入替え対象ＥＪＢ  Ａの名前Ａと、新たに配備した代替ＥＪＢ  Ａの名前Ａｓを引数としてネームサーバ４５０のreplace  ＡＰＩを呼び出す。これによって、ネームサーバ４５０のテーブル４０１のエントリは図１６のようになる。４２４は名前Ａと新規に配備されたＥＪＢ  ＡのコンテナAsの組であり、４２５は名前Ａｓと旧コンテナＡの組である。次に制御部１３０は、９０３において、リモートＡ受信部３１２のsetContainerメソッドをコンテナＡｓ５００を引数として呼び出す。これによってリモートＡ受信部３１２のコンテナ管理変数８００はＮＵＬＬからコンテナＡｓ５００に書き換えられる。以後リモート受信部３１２を介するメソッド呼び出しはコンテナＡｓ５００で実行される。次に制御部１３０は、９０４にてコンテナＡ３００で実行中の全ての処理が終了するまで待ち、９０５でデプロイヤ１２０の部分配備解除機能を呼び出して、旧ＥＪＢ  Ａのインスタンス３０１と、コンテナ３００を終了(配備解除)する。最後に９０６でネームサーバ４５０のunbind  ＡＰＩを名前Ａｓを引数として呼び出し、エントリ（Ａｓ、ＩｎｔＣｏｎＡｓ）４２５をネームサーバ４５０から抹消する。以上でＥＪＢ  Ａの入替え処理は終了する。
【００５１】
（リモートメソッド呼び出し）
これまで主にＥＪＢ  Ａの入替え処理について説明してきた。ここでは、クライアントであるＥＪＢ  ＢがＥＪＢ  Ａのメソッドを呼び出す観点からその動作を説明する。まずＥＪＢ  ＢにおけるＥＪＢ  Ａのメソッド呼び出しコードの一部は図３のようになっているものとする。図１においてＥＪＢ  Ｂのインスタンス３２１はまず図３の1〜2行目を実行すると、ネームサーバ４５０が参照されて、名前の欄がＡであるエントリが検索される。結果としてエントリ４２１のオブジェクト欄に登録されているコンテナＡのホームインタフェースＩｎｔＣｏｎＡが得られる。インスタンス３２１は図３の3行目を実行し、lookupによって得られたホームインタフェースＩｎｔＣｏｎＡのcreateリモートメソッドを呼び出す。このリモートメソッド呼び出しは、コンテナＢ３２０経由でリモートＡ送信部３１１に送られ、ここでメッセージ１１００に変換されてリモート受信部３１２に到達する。メッセージ１１００の対象識別子１１０１はコンテナＡ３１２であり、メソッド１１０２はcreateである。リモートＡ受信部はこのメッセージを受け取ると、まずコンテナ管理変数８００を参照し、その値がＮＵＬＬであるので、メッセージ１１００の対象識別子１１０１で識別されるコンテナＡ３１２のcreateメソッドを呼び出す。
【００５２】
コンテナＡ３１２はＥＪＢ  Ａのインスタンス３０１を生成し、当該インスタンスのコンポーネントインタフェースをコンテナＡ３００、リモートＡ受信部３１２、リモートＡ送信部３１１、コンテナＢを経由してＥＪＢ  Ｂのインスタンス３２１に返される。インスタンス３２１は次に図３の４行目を実行し、ＥＪＢ  Ａのインスタンス３０１のmethodXリモートメソッドを呼び出す。このメソッド呼び出しはコンテナＢ３２０を経由してリモートＡ送信部３１１に送られ、メッセージ１１００に変換される。ここでメッセージ１１００の対象識別子はＥＪＢ  Ａのインスタンス３０１であり、メソッド１１０２はmethodXである。このメッセージ１１００がリモートＡ受信部３１２に到達すると、リモートＡ受信部３１２はまずコンテナ管理変数８００を参照し、その値がＮＵＬＬなので、メッセージ１１００の対象識別子１１０１で識別されるＥＪＢ  Ａのインスタンス３０１のmethodXメソッドを呼び出す。結果はコンテナＡ３００、リモートＡ受信部３１２、リモートＡ送信部３１１、コンテナＢを経由してＥＪＢ  Ｂのインスタンス３２１に返される。
【００５３】
次に、ＥＪＢ  Ａの入替え条件が成立し制御部１３０がＥＪＢ  Ａの入替えを実行し、それが完了した後のコンポーネントソフトウェア運用基盤を図１８に示す。コンテナＡ３００がコンテナＡ５００に入替えられる。ネームサーバ４５０の名前ＡはリモートインタフェースＩｎｔＣｏｎＡｓに入替えられる。また、リモートＡ受信部３１２のコンテナ管理変数８００にはコンテナＡｓが５００が格納される。ここで、前述のＥＪＢ  ＢがＥＪＢ  Ａに対し再び図３の4行目のmethodXリモートメソッドを呼び出したとする。すると、前述と同様にメッセージが作成され、リモートＡ受信部３１２に渡される（コンテナ入替え後もリモートＡ送信部３１１はリモートＡ受信部３１２とペアになっており、リモートＡｓ送信部５１２とは通信できない）。リモートＡ受信部３１２はまずコンテナ管理変数８００を参照し、値がＮＵＬＬではないので、メッセージ１１００の対象識別子１１０１に相当するエントリが、ＥＪＢインスタンス管理表８０２に存在するかどうか検索し、存在しないので、コンテナ管理変数８００で識別されるコンテナＡｓ５００のcreateメソッドを実行してコンテナＡｓ５００上にＥＪＢ  Ａのインスタンス５０１を生成する。メッセージ１１００の対象識別子１１０１に格納されているコンテナＡ上のインスタンス３０１の識別子と、今生成したインスタンス５０１の識別子をペアとしてＥＪＢインスタンス管理表８０２に登録し、インスタンス５０１のメソッドmethodXを実行し、得られた値をインスタンス３２１に返す。以上のようにしてコンテナを入替える前に取得したホームインタフェースやリモートインタフェースを用いたメソッド呼び出しは、すべて新規コンテナの新しいインスタンス上で実行されることになる。
【００５４】
最後に、ＥＪＢ  Ａの入替えを行った後の図１８の状態において、上述のＥＪＢ  Ｂのインスタンス３２１とは異なる新規のインスタンス３２１が図３のコードを実行してＥＪＢ  ＡのmethodXリモートメソッドを呼び出す場合について説明する。図１８においてＥＪＢ  Ｂの新規インスタンス３２１はまず図３の1〜2行目を実行すると、ネームサーバ４５０にlookupを発行し、名前の欄がＡであるエントリが検索される。結果としてエントリ４２４のオブジェクト欄に登録されているコンテナＡｓのホームインタフェースＩｎｔＣｏｎＡｓが得られる。新規インスタンス３２１は図３の3行目を実行し、ホームインタフェースＩｎｔＣｏｎＡｓのcreateリモートメソッドを呼び出す。このリモートメソッド呼び出しは、コンテナＢ３２０経由でリモートＡ送信部３１１に送られ、ここでメッセージ１１００に変換されてリモートＡｓ受信部５１２に到達する。メッセージ１１００の対象識別子１１０１はコンテナＡｓ５００であり、メソッド１１０２はcreateである。リモートＡｓ受信部５１２はこのメッセージを受け取ると、まずコンテナ管理変数８００を参照し、その値がＮＵＬＬであるので、メッセージ１１００の対象識別子１１０１で識別されるコンテナＡｓ５００のcreateメソッドを呼び出す。コンテナＡｓ５００はＥＪＢ  Ａのインスタンス５０１を生成し、当該インスタンスのコンポーネントインタフェースをコンテナＡｓ５００、リモートＡｓ受信部５１２、リモートＡ送信部３１１、コンテナＢ３２０を経由してＥＪＢ  Ｂの新規インスタンス３２１に返す。新規インスタンス３２１は次に図３の４行目を実行し、ＥＪＢ  Ａのインスタンス５０１のmethodXリモートメソッド呼び出しも同様にして処理される。以上のようにしてコンテナを入替えた後にネームサーバのlookupから始まるプログラムを実行したリモートメソッド呼び出しは、すべて新しいコンテナＡｓで実行される。
【産業上の利用可能性】
【００５５】
本発明で示したコンポーネントソフトウェアの高可用運用方法を備えた運用基盤は、
幅広いアプリケーションを運用するアプリケーションプラットフォームソフトウェアとして利用可能である。特に、高い可用性が要求されるミッションクリティカルアプリケーションを運用するアプリケーションプラットフォームソフトウェアとしても利用できる。
【図面の簡単な説明】
【００５６】
【図１】コンポーネントソフトウェアの高可用運用方法及び運用基盤の実施方法を示した説明図である。（実施例１）
【図２】従来技術のコンポーネントソフトウェアの運用基盤を示した説明図である。
【図３】ＥＪＢのリモートメソッドを呼び出すクライアントプログラムの一部を示した図である。
【図４】本発明で使用するＥＪＢの入替え定義ファイルの例を示した図である。
【図５】本発明で使用するＥＪＢの入替え定義ファイルの入替え条件の一例を示した図である。
【図６】本発明で使用するＥＪＢの入替え定義ファイルの入替え条件の一例を示した図である。
【図７】本発明で使用するＥＪＢの入替え定義ファイルの入替え条件の一例を示した図である。
【図８】本発明で使用するネームサーバに追加したreplace  ＡＰＩの仕様を示した図である。
【図９】本発明で使用するネームサーバに追加したreplace  ＡＰＩの機能を実現する処理フローを示した図である。
【図１０】本発明で使用するネームサーバのbind  ＡＰＩの機能を実現する処理フローを示した図である。
【図１１】本発明で機能修正したデプロイヤによって既にコンポーネントソフトウェア運用基盤上に配備されているＥＪＢ  Ａを重複して配備した場合のコンポーネントソフトウェア運用基盤の説明図である。
【図１２】本発明で新たに追加した判定部において、各ＥＪＢの判定条件を記録する判定表を示す図である。
【図１３】本発明で新たに追加した制御部において、各ＥＪＢの代替ＥＪＢと優先度を記録する入替表を示す図である。
【図１４】本発明で機能修正したリモート受信部の構成を示す図である。
【図１５】本発明で新たに追加した制御部が、ＥＪＢを代替ＥＪＢと入替える際の処理フローを示した図である。
【図１６】ネームサーバのテーブルであって本発明で新たに追加したreplace APIを実行した結果得られるエントリを示した図である。
【図１７】従来技術のリモート送信部とリモート受信部の間でやり取りされるメッセージを示した概略図である。
【図１８】本発明で追加した制御部によってＥＪＢ  Ａの入替え処理を実行し終えた後のコンポーネントソフトウェア運用基盤の状態を説明する図である。
【図１９】本発明で使用するネームサーバのlookup  ＡＰＩの機能を実現する処理フローを示した図である。
【図２０】本発明で使用する制御部のインタフェースの概要を示す説明図である。
【符号の説明】
【００５７】
１００、１０１  コンポーネントソフトウェア運用基盤
１１０、１２０  デプロイヤ
１３０  制御部
１４０  監視部
１５０  判定部
２００  ファイルシステム
２１０、２１１  ＥＪＢクラスファイル
２２０、２２１  入替定義ファイル
３００、３２０、５００  コンテナ
３０１、３２１、５０１  ＥＪＢインスタンス
３１０、３１２、３３０、５１２  リモート受信部
３１１  リモート送信部
４００、４５０  ネームサーバ
４０１  テーブル
４０２、４５２  ネームサーバの制御部
４１１  名前
４１２  オブジェクト
４２１、４２２、４２３、４２４、４２５  ネームサーバのエントリ
６００  条件表
６１０  ＥＪＢ名
６１１  入替条件
６１２  ＥＪＢ配備時刻
６２０、６２１  条件表のエントリ
７００  入替表
７１０  ＥＪＢ名
７１１  代替ＥＪＢ
７１２  優先度
８００  コンテナ管理変数
８０１  リモート受信部の制御部
８０２  ＥＪＢインスタンス管理テーブル
８１０  旧ＥＪＢインスタンスＩＤ欄
８１１  新ＥＪＢインスタンスＩＤ欄
１１００  リモートメソッド呼び出しメッセージ
１１０１  対象識別子
１１０２  メソッド
１１０３  メソッド引数リスト
１２００  ユーザインタフェース
１２０１  自動入替え制御Ｏｎボタン
１２０２  自動入替え制御Ｏｆｆボタン
１２０３  手動入替え対象ＥＪＢ入力欄
１２０４  手動入替え開始ボタン。
【図１】
2006338069.tif 000003
【図２】
2006338069.tif 000004
【図３】
2006338069.tif 000005
【図４】
2006338069.tif 000006
【図５】
2006338069.tif 000007
【図６】
2006338069.tif 000008
【図７】
2006338069.tif 000009
【図８】
2006338069.tif 000010
【図９】
2006338069.tif 000011
【図１０】
2006338069.tif 000012
【図１１】
2006338069.tif 000013
【図１２】
2006338069.tif 000014
【図１３】
2006338069.tif 000015
【図１４】
2006338069.tif 000016
【図１５】
2006338069.tif 000017
【図１６】
2006338069.tif 000018
【図１７】
2006338069.tif 000019
【図１８】
2006338069.tif 000020
【図１９】
2006338069.tif 000021
【図２０】
2006338069.tif 000022