JP4876438B2

JP4876438B2 - コンポーネントソフトウェアの運用方法および運用基盤

Info

Publication number: JP4876438B2
Application number: JP2005158299A
Authority: JP
Inventors: 真一川本
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2005-05-31
Filing date: 2005-05-31
Publication date: 2012-02-15
Anticipated expiration: 2025-05-31
Also published as: JP2006338069A; US20070006212A1; US8782666B2

Description

本発明は、複数のソフトウェア部品(以後コンポーネント)から構成されるコンポーネントソフトウェアを高可用運用する運用方法及びコンポーネントソフトウェア運用基盤に関するものである。

オンラインショッピングサイトや、あるいは社内情報処理システムにおいて、クライアントとして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 ＡＰＩの機能を実現する処理フローを示した図である。本発明で使用する制御部のインタフェースの概要を示す説明図である。

符号の説明

１００、１０１コンポーネントソフトウェア運用基盤
１１０、１２０デプロイヤ
１３０制御部
１４０監視部
１５０判定部
２００ファイルシステム
２１０、２１１ＥＪＢクラスファイル
２２０、２２１入替定義ファイル
３００、３２０、５００コンテナ
３０１、３２１、５０１ＥＪＢインスタンス
３１０、３１２、３３０、５１２リモート受信部
３１１リモート送信部
４００、４５０ネームサーバ
４０１テーブル
４０２、４５２ネームサーバの制御部
４１１名前
４１２オブジェクト
４２１、４２２、４２３、４２４、４２５ネームサーバのエントリ
６００条件表
６１０ＥＪＢ名
６１１入替条件
６１２ＥＪＢ配備時刻
６２０、６２１条件表のエントリ
７００入替表
７１０ＥＪＢ名
７１１代替ＥＪＢ
７１２優先度
８００コンテナ管理変数
８０１リモート受信部の制御部
８０２ＥＪＢインスタンス管理テーブル
８１０旧ＥＪＢインスタンスＩＤ欄
８１１新ＥＪＢインスタンスＩＤ欄
１１００リモートメソッド呼び出しメッセージ
１１０１対象識別子
１１０２メソッド
１１０３メソッド引数リスト
１２００ユーザインタフェース
１２０１自動入替え制御Ｏｎボタン
１２０２自動入替え制御Ｏｆｆボタン
１２０３手動入替え対象ＥＪＢ入力欄
１２０４手動入替え開始ボタン。

Claims

ソフトウェア部品であるコンポーネントから構成されるコンポーネントソフトウェアの運用方法であって、
前記コンポーネントを識別する識別子と、前記コンポーネントに対する処理要求を前記コンポーネントを用いて実行する実行環境であるコンテナと、の間の対応関係を管理し、
前記コンポーネントソフトウェアの運用基盤であるコンポーネントソフトウェア運用基盤の中に第１のコンテナを生成し、
前記第１のコンテナを前記コンポーネントの中の第１のコンポーネントの実行環境として、前記第１のコンポーネントを識別する第１の識別子と、前記第１のコンテナと、の前記対応関係である第１の対応関係を生成し、
前記第１のコンポーネントに対する第１の処理要求を受信すると、前記第１の識別子に基づいて前記第１の対応関係を参照して、前記第１の識別子に対応付けられた前記第１のコンテナにおいて、前記第１のコンポーネントを用いて前記第１の処理要求を実行し、
前記コンポーネントソフトウェア運用基盤の中に第２のコンテナを生成し、
前記第１のコンポーネントと同じ内容の前記コンポーネントを前記第１のコンポーネントの代替のコンポーネントである第２のコンポーネントとして設定し、
前記第２のコンテナを前記コンポーネントの中の第２のコンポーネントの実行環境として、前記第２のコンポーネントを識別する第２の識別子と、前記第２のコンテナと、の前記対応関係である第２の対応関係を生成し、
予め設定された前記第１のコンポーネントの入れ替えの環境が整った場合、または他のソフトウェアやユーザからの入れ替え指示を受信した場合に、前記第２のコンテナにおいて前記第２のコンポーネントの使用を開始し、
前記第２のコンポーネントの使用を開始した際に、前記第１の対応関係における前記第１の識別子を前記第２の識別子に、前記第２の対応関係における前記第２の識別子を前記第１の識別子に、それぞれ変更し、
前記第２のコンポーネントの使用開始より前に受信済みの前記第１のコンポーネントに対する処理要求を前記第１のコンポーネントを用いて実行し、
前記第２のコンポーネントの開始以降に前記第１の処理要求を受信した場合は、前記第１の識別子に基づいて前記変更後の前記第２の対応関係を参照して、前記第１の識別子に対応付けられた前記第２のコンテナにおいて、前記第２のコンテナを実行環境とする前記第２のコンポーネントを用いて前記第１の処理要求を実行し、
前記第２のコンポーネントの開始より前に受信した前記第１のコンポーネントに対する処理要求の実行が完了したことを契機に、前記第１のコンポーネントを終了し、前記第１のコンテナを前記コンポーネントソフトウェア運用基盤から削除し、前記第１の対応関係を削除する、こと、
を特徴とするコンポーネントソフトウェアの運用方法。
前記第２のコンポーネントの起動を、あらかじめ運用の開始前に行っておくこと、を特徴とする請求項１記載のコンポーネントソフトウェアの運用方法。
前記第２のコンポーネントを起動する際は、前記第１のコンポーネントの他に前記第１のコンポーネントと同一のコンポーネントを重複して、前記第２のコンポーネントとして起動すること、を特徴とする請求項１記載のコンポーネントソフトウェアの運用方法。
ソフトウェア部品であるコンポーネントから構成されるコンポーネントソフトウェアの運用を行うコンポーネントソフトウェア運用基盤であって、
前記コンポーネントと、前記コンポーネントに対する処理要求を前記コンポーネントを用いて実行する実行環境であるコンテナ、の生成及び削除を管理し、前記コンポーネントを識別する識別子と前記コンテナとの間の対応関係を管理する管理部と、
前記コンポーネントに対する処理要求を受信すると、前記処理要求の対象である前記コンポーネントの前記識別子に基づいて前記対応関係を参照して、前記処理要求の対象である前記コンポーネントの前記識別子に対応付けられた前記コンテナにおいて、前記コンテナを実行環境とする前記コンポーネントを用いて前記処理要求を実行する処理要求実行部と、を有し、
前記管理部は、
第１のコンテナを生成し、前記第１のコンテナを前記コンポーネントの中の第１のコンポーネントの実行環境として、前記第１のコンポーネントを識別する第１の識別子と、前記第１のコンテナと、の前記対応関係である第１の対応関係を生成し、
前記コンポーネントソフトウェア運用基盤の中に第２のコンテナを生成し、
前記第１のコンポーネントと同じ内容の前記コンポーネントを前記第１のコンポーネントの代替のコンポーネントである第２のコンポーネントとして設定し、
前記第２のコンテナを前記コンポーネントの中の第２のコンポーネントの実行環境として、前記第２のコンポーネントを識別する第２の識別子と、前記第２のコンテナと、の前記対応関係である第２の対応関係を生成し、
前記第２のコンポーネントの使用が開始された際に、前記第１の対応関係における前記第１の識別子を前記第２の識別子に、前記第２の対応関係における前記第２の識別子を前記第１の識別子に、それぞれ変更し、
前記第２のコンポーネントの開始より前に受信した前記第１のコンポーネントに対する処理要求の実行が完了したことを契機に、前記第１のコンポーネントを終了し、前記第１のコンテナを前記コンポーネントソフトウェア運用基盤から削除し、前記第１の対応関係を削除し、
前記処理要求実行部は、
前記第１のコンポーネントに対する第１の処理要求を受信すると、前記第１の識別子に基づいて前記第１の対応関係を参照して、前記第１の識別子に対応付けられた前記第１のコンテナにおいて、前記第１のコンポーネントを用いて前記第１の処理要求を実行し、
予め設定された前記第１のコンポーネントの入れ替えの環境が整った場合、または他のソフトウェアやユーザからの入れ替え指示を受信した場合に、前記第２のコンテナにおいて前記第２のコンポーネントの使用を開始し、
前記第２のコンポーネントの使用開始より前に受信済みの前記第１のコンポーネントに対する処理要求を前記第１のコンポーネントを用いて実行し、
前記第２のコンポーネントの開始以降に前記第１の処理要求を受信した場合は、前記第１の識別子に基づいて前記変更後の前記第２の対応関係を参照して、前記第１の識別子に対応付けられた前記第２のコンテナにおいて、前記第２のコンテナを実行環境とする前記第２のコンポーネントを用いて前記第１の処理要求を実行する、こと、
を特徴とするコンポーネントソフトウェア運用基盤。
前記管理部は、
前記第２のコンポーネントの起動を、あらかじめ運用の開始前に行っておくこと、を特徴とする請求項４記載のコンポーネントソフトウェア運用基盤。
前記管理部は、
前記第２のコンポーネントを起動する際は、前記第１のコンポーネントの他に前記第１のコンポーネントと同一のコンポーネントを重複して、前記第２のコンポーネントとして起動することを特徴とする請求項４記載のコンポーネントソフトウェア運用基盤。