5. アプリケーション

5.1. 概要

5.1.1. アプリケーションの種類

WebOTX ASは以下に示す8種類のアプリケーションをサポートします。 アプリケーションは種類ごとにアーカイブの形式や拡張子が仕様で定められています。

表5.1.1-1
アプリケーションの種類 拡張子 アーカイブ形式の仕様
Webアプリケーション .war Java EE
EJBアプリケーション .jar Java EE
エンタープライズアプリケーション .ear Java EE
アプリケーションクライアント .jar Java EE
リソースアダプタ .rar Java EE
CORBAアプリケーション .cpk WebOTX AS固有
共有コンポーネント .spk WebOTX AS固有
OSGiバンドル .jar OSGi
Webアプリケーション(Web Application)

WebアプリケーションはWebアプリケーションのためのコンテンツを格納します。静的なHTMLを提供するだけでなく、サーブレットやJSPを利用して動的にコンテンツを生成することもできます。

EJBアプリケーション(EJB Application)

EJBアプリケーションにはEJB(Enterprise JavaBeans)を格納します。またEJBが利用するユーティリティクラスを含めることもできます。

エンタープライズアプリケーション(Enterprise Application)

エンタープライズアプリケーションは、Webアプリケーション,EJBアプリケーション,アプリケーションクライアント,リソースアダプタなどを1つ以上格納した統合アプリケーションです。JavaEEのアプリケーションを提供する場合、1つのEARでアプリケーションを組み立てることもできますし、また個別にWebアプリケーションやEJBアプリケーションなどを配備してアプリケーションを組み立てても構いません。さらには各アプリケーションを異なるサーバ上に配備することでアプリケーションを分散することができます。

アプリケーションクライアント(Application Client)

Java EEアプリケーションクライアントはクライアントコンテナ上で動作するアプリケーションです。アプリケーションクライアントはRMI-IIOP経由でEJB等のサーバサイドアプリケーションにアクセスします。

リソースアダプタ(Resource Adapter)

リソースアダプタアーカイブにはリソースアダプタを格納します。リソースアダプタとは、EJBやWebアプリケーションが外部のエンタープライズシステムにアクセスできるようにするためのコンポーネントです。

CORBAアプリケーション(CORBA Application)

OMGが標準化を行っているCORBAという仕様に準拠したアプリケーションです。Javaだけではなく、C/C++やCOBOLで実装することもできます。CORBAアプリケーションの形式にはR5形式とR4形式が存在します(「アプリケーション開発ガイド」参照)。

共有コンポーネント(Shared Component)

プロセスグループ間で共有するライブラリです。

OSGiバンドル(OSGi Bundle)

OSGiの仕様に準拠したモジュールです。

5.1.2. エディションごとにサポートするアプリケーション

サポートするアプリケーションの種類はWebOTX ASのエディションにより異なります。

表5.1.2-1
アプリケーションの種類 Express Standard Enterprise
Webアプリケーション
EJBアプリケーション
エンタープライズアプリケーション
アプリケーションクライアント
リソースアダプタ
CORBAアプリケーション × ×
共有コンポーネント ×
OSGiバンドル

5.1.3. アプリケーションに対する運用操作

作成したアプリケーションをWebOTX AS上で実行する場合、アプリケーションに対して次に示す運用操作を行います。

パッケージング

開発したアプリケーションを、各アプリケーションが準拠している仕様に基づきアーカイブします。

配備

作成したアプリケーションをWebOTX ASの管理下におく作業です。アプリケーションを配備するためには、ドメインが起動している必要があります。配備するアプリケーションは、あらかじめearやwar等の形式でパッケージ化しておきます。

開始と停止

デフォルトでは配備後のアプリケーションは開始した状態にあります。開始した状態とは、配備されたアプリケーションが動作しており、クライアントからの要求を受け付けることができる状態です。また、停止した状態とは、アプリケーションが動作していない状態のことで、クライアントからの要求は受け付けることができません。停止した状態のアプリケーションは依然としてWebOTX ASの管理下にあります。簡単な運用操作によって、アプリケーションの開始状態と停止状態を切り替えることができます。

再配備

配備済みのアプリケーションを置換する作業を再配備と呼びます。再配備はアプリケーションの開発時に頻繁に行われる作業です。

置換

インタフェースやオペレーション単位に設定した情報を引き継いだまま、配備済みのアプリケーションを置換する作業を置換と呼びます。 置換はすでに運用されている環境において、アプリケーションの小さな修正を適用したいときに有効です。 インタフェースやオペレーションが再配備前後ですべて一致している必要があり、異なっている場合置換することができません。

配備解除

アプリケーションをWebOTX ASの管理下から除外する作業です。

5.1.4. アプリケーションのバージョニング機能

アプリケーションのバージョニング機能を使用すると、同じ名前の複数のバージョンのアプリケーションを配備することができます。これによって、アプリケーションのアップグレードとロールバックが簡単になります。

バージョニング機能は、複数のバージョンのアプリケーションが同時に有効にならないことを保証します。そのため、アプリケーションのバージョンが異なるのであれば、同じコンテキストルートやJNDI名を持たせることができます。

また、アプリケーションの配備解除、停止、状態取得時に、アプリケーション名を指定する箇所でバージョンIDの部分にアスタリスク(*)をワイルドカードとして使用することができます。

5.1.4.1. バージョンIDの付与

アプリケーションにバージョンIDを付与するには、配備時のアプリケーション名の指定で、アプリケーション名の後にコロン(:)で区切ってバージョンIDを指定します。

otxadmin> deploy --name アプリケーション名:バージョンID アーカイブ名

具体例を挙げると、アーカイブ名が「hello.war」であるWebアプリケーションを、アプリケーション名を「hello」、バージョンIDを「1.0」として配備するには、次のようにします。

otxadmin> deploy --name hello:1.0 hello.war

バージョンIDは英数字で始まる必要があります。また、バージョンIDには英数字およびアンダースコア(_)、ハイフン(-)、ピリオド(.)を含めることができます。有効なバージョンIDの例は、以下のとおりです。

アプリケーションに対して設定や運用操作を行う際は、バージョンIDも含めた名前をアプリケーション名として指定する必要があります。例えば、アプリケーション名が「hello」、バージョンIDが「1.0」であるアプリケーションを開始するには、次のようにします。

otxadmin> enable hello:1.0

5.1.4.2. 有効なバージョンの切り替え

有効化したいバージョンのアプリケーションを開始することで、有効なバージョンを切り替えることができます。

具体例として、以下のアプリケーションが配備されているとします。括弧の中はアプリケーションの状態を表しています。

この状態で、「hello:3.0-BETA」を有効にするには、次のようにします。

otxadmin> enable hello:3.0-BETA

コマンド実行後の状態は以下のようになります。

新たに配備するバージョンを有効化したい場合は、アプリケーションを開始状態で配備します。

具体例として、以下のアプリケーションが配備されているとします。括弧の中はアプリケーションの状態を表しています。

この状態で、「hello:3.0-BETA」という名前で新たに配備したアプリケーションを有効にするには、次のようにします。

otxadmin> deploy --name hello:3.0-BETA --enabled=true hello.war

コマンド実行後の状態は以下のようになります。

なお、deployコマンドの--enabledオプションのデフォルト値はtrueです。

5.1.4.3. バージョンIDのワイルドカード指定

アプリケーションの配備解除、停止、状態取得においては、バージョンIDにワイルドカードとしてアスタリスク(*)を指定することができます。有効なワイルドカードを含むバージョンIDの例は、以下のとおりです。

アプリケーションの配備解除でバージョンIDにワイルドカードを指定すると、マッチする全てのバージョンが配備解除されます。
具体例として、以下のアプリケーションが配備されているとします。括弧の中はアプリケーションの状態を表しています。

この状態で、以下のコマンドを実行します。

otxadmin> undeploy hello:1.*

上記のコマンドにより、「hello:1.0」と「hello:1.1」が配備解除されます。
以下のコマンドを実行すると、全てのバージョンが配備解除されます。

otxadmin> undeploy hello:*

アプリケーションの停止でバージョンIDにワイルドカードを指定すると、マッチするバージョンが停止されます。
具体例として、以下のアプリケーションが配備されているとします。括弧の中はアプリケーションの状態を表しています。

この状態で、以下のコマンドを実行すると、いずれのバージョンが有効状態であっても停止することができます。

otxadmin> disable hello:*

アプリケーションの状態取得でバージョンIDにワイルドカードを指定すると、マッチする全てのバージョンの状態が取得できます。
具体例として、以下のアプリケーションが配備されているとします。括弧の中はアプリケーションの状態を表しています。

この状態で、以下のコマンドを実行します。

otxadmin> show-component-status hello:1.*

上記のコマンドにより、以下のメッセージが表示されます。

otxadmin> show-component-status hello:1.*
hello:1.0 の状態は 無効(disabled) です。
hello:1.1 の状態は 有効(enabled) です。

5.1.4.4. 注意事項

CORBAアプリケーション、共有コンポーネント、およびOSGiバンドルの配備では、バージョニング機能を使用することはできません。CORBAアプリケーション、共有コンポーネント、およびOSGiバンドル配備時にバージョンIDを付与すると、バージョンIDは無視されます。

バージョンIDを付与して配備を行うと、deployコマンドの--bindtypeオプション(名前サーバの登録方式)の既定値がtransient(一時的に扱う)になります(バージョンIDを付与しない場合の既定値はpersistent(永続的に扱う)です)。これは、バージョンIDを付与することで異なるバージョン間で同じJNDI名を使用することが可能になり、その場合、名前サーバへの登録・登録解除をアプリケーションの配備・配備解除時ではなく、アプリケーションの起動・停止時に行う必要があるためです。バージョンIDを付与した上で「名前サーバの登録方式」を「永続的に扱う」に設定する場合は、--bindtypeオプションでpersistentを明示的に指定してください。なお、CORBAアプリケーションはバージョンIDを付与してもバージョンIDが無視されるため、--bindtypeオプションの既定値はpersistentのままで変更はありません。また、統合運用管理ツールおよびWeb版統合運用管理コンソールで配備を行う場合は、バージョンIDを付与した場合でも「名前サーバの登録方式」の既定値に変更はありません。必要があれば、配備の際に「名前サーバの登録方式」で「一時的に扱う」を選択してください。

5.1.5. 旧バージョンからの変更点

WebOTX AS V7およびWebOTX V6にバンドルしていた配備ツール、およびWebOTX V5にバンドルしていた展開ツールはV8で廃止になりました。WebOTX AS V8以降でGUIを用いた配備/配備解除を行う場合は、以下のツールを利用してください。

5.2. アプリケーションの動作プロセス

WebOTX ASに配備するアプリケーションは、エディションにより動作するプロセスが異なります。この章では、配備の観点からアプリケーションが動作するプロセスについての解説を行います。

5.2.1. 配備先の種類

アプリケーションが動作するプロセスは大きく分けて「エージェントプロセス」と「プロセスグループ」の二種類存在します。この節では、これらの違いについて解説します。

5.2.1.1. エージェントプロセス

エージェントプロセスとは、WebOTX ASが動作している、コアとなるプロセスのことです。WebOTX AS Expressでは、配備したアプリケーションは全てエージェントプロセス上で動作します。このエディションでは、配備時には配備先の指定は必要ありません。

5.2.1.2. プロセスグループ

WebOTX AS Standard/Enterpriseでは、配備したアプリケーションはWebOTX ASのエージェントプロセスから分離された個別のプロセス上で動作します。このプロセスは多重化することができ、多重化したプロセス群のことを「プロセスグループ」と呼んでいます。

プロセスグループは、更に業務単位にまとめることができます。業務単位でまとめたプロセスグループ群を「アプリケーショングループ」と呼びます。

WebOTX AS Standard/Enterpriseで以下のアプリケーションを配備する際には、どのアプリケーショングループおよびプロセスグループに対しての配備なのかを指定する必要があります。

5.2.2. アプリケーショングループとプロセスグループの作成方法

この節では、各ツールを使ってアプリケーショングループとプロセスグループを作成する方法を説明します。

5.2.2.1. コマンドを利用した作成方法

運用管理コマンドを利用してアプリケーショングループとプロセスグループを作成する手順を説明します。なお運用管理コマンドの詳細については運用管理コマンドリファレンスの「create-apg」、「create-pg」を参照してください。

プロセスグループを作成する前に、それが属するアプリケーショングループを作成する必要があります。アプリケーショングループを作成するには、次に示すオペレーションcreate-apgを実行します。

otxadmin> create-apg アプリケーショングループ名

具体例を挙げると、「myapg」という名前のアプリケーショングループを作成するには、次のようにします。

otxadmin> create-apg myapg

次にプロセスグループを作成します。プロセスグループを作成するには、次に示すオペレーションcreate-pgを実行します。

otxadmin> create-pg --apgroup 所属アプリケーショングループ名 --kind 種別 --version バージョン プロセスグループ名

具体例を挙げると、「javaeepg」という名前の、「myapg」というアプリケーショングループに属するJava EE用のプロセスグループを作成するには、次のようにします。

otxadmin> create-pg --apgroup myapg --kind javaee --version 9 javaeepg

別の例を挙げると、「corba」という名前の、「yourapg」というアプリケーショングループに属する、Visual C++ 2005で実装したCORBAアプリケーションのためのプロセスグループを作成するには、次のようにします。

otxadmin> create-pg --apgroup yourapg --kind vc2005 --version 9 corba

5.2.2.2. 統合運用管理ツールを利用した作成方法

統合運用管理ツールを利用して、アプリケーショングループとプロセスグループを作成する手順を説明します。

  1. 統合運用管理ツールでWebOTX ASに接続します。画面左側のツリーの「アプリケーショングループ」を選択し、表示されたメニューから「アプリケーショングループの新規作成」を選択します。


    図5.2.2.2-1

  2. アプリケーショングループを作成するためのダイアログに必要な情報を入力します。「アプリケーショングループ」に作成するアプリケーショングループの名前を入力し、「実行」ボタンを押下します。


    図5.2.2.2-2

  3. アプリケーショングループの作成に成功すると、以下のように「アプリケーショングループ」の下に作成したアプリケーショングループが現れます。


    図5.2.2.2-3

  4. 次にプロセスグループを作成します。作成したアプリケーショングループの下の「プロセスグループ」を選択し、右クリックします。表示されたメニューから「プロセスグループの新規作成」を選択します。


    図5.2.2.2-4

  5. プロセスグループを作成するためのダイアログに必要な情報を入力します。「プロセスグループ」に作成するプロセスグループ名を入力します。また「WebOTX ASバージョン」と「モジュールの種類」を適切に設定してください。必要な情報の入力の後、「実行」ボタンを押下します。


    図5.2.2.2-5

  6. プロセスグループの作成に成功すると、以下のように「プロセスグループ」の下に作成したプロセスグループが現れます。


    図5.2.2.2-6

5.2.2.3. Web版統合運用管理コンソールを利用した作成方法

Web版統合運用管理コンソールを利用して、アプリケーショングループとプロセスグループを作成する手順を説明します。

  1. Web版統合運用管理コンソールでWebOTX ASに接続します。画面左側のツリーの「アプリケーショングループ」を選択し、「操作」タグ下に表示されたリストから「アプリケーショングループの新規作成」を選択します。


    図5.2.2.3-1

  2. 右側の「アプリケーショングループ」に作成するアプリケーショングループの名前を入力し、「実行」ボタンを押下します。


    図5.2.2.3-2

  3. アプリケーショングループの作成に成功すると、以下のように「アプリケーショングループ」の下に作成したアプリケーショングループが現れます。「操作結果」と「ログ詳細」に作成情報表示されます。


    図5.2.2.3-3

  4. 次にプロセスグループを作成します。作成したアプリケーショングループの下の「プロセスグループ」を選択し、「操作」タグ下に表示されたリストから「プロセスグループの新規作成」を選択します。


    図5.2.2.3-4

  5. プロセスグループを作成するためのダイアログに必要な情報を入力します。「プロセスグループ」に作成するプロセスグループ名を入力します。また「WebOTX ASバージョン」と「モジュールの種類」を適切に設定してください。必要な情報の入力の後、「実行」ボタンを押下します。


    図5.2.2.3-5

  6. プロセスグループの作成に成功すると、以下のように「プロセスグループ」の下に作成したプロセスグループが現れます。


    図5.2.2.3-6

5.2.3. 配備先の調整

配備時あるいは再配備時にプロセスグループを指定しても、別の配備先に自動調整される場合があります。 これは以下の場合です。

以下の表は、配備/再配備時のプロセスグループの指定と、実際の配備先についてまとめたものです。 太字で表示されている部分が調整された配備先になります。

※以下の表では、プロセスグループをPGと表記します。

表5.2.3-1
配備 再配備
PG指定あり PG指定なし PG指定あり PG指定なし
Express Webアプリケーション × エージェントプロセス × エージェントプロセス
EJB × エージェントプロセス × エージェントプロセス
リソースアダプタ × エージェントプロセス × エージェントプロセス
アプリケーションクライアント × エージェントプロセス × エージェントプロセス
エンタープライズアプリケーション × エージェントプロセス × エージェントプロセス
CORBAアプリケーション
(Expressでは未サポート)
× × × ×
共有コンポーネント
(Expressでは未サポート)
× × × ×
OSGiバンドル × エージェントプロセス × エージェントプロセス
Standard アドバンスト Webアプリケーション 指定したPG × 以前のPG 以前のPG
EJB 指定したPG × 以前のPG 以前のPG
リソースアダプタ エージェントプロセス エージェントプロセス エージェントプロセス エージェントプロセス
アプリケーションクライアント エージェントプロセス エージェントプロセス エージェントプロセス エージェントプロセス
エンタープライズアプリケーション
(EJBまたはWARを含む)
指定したPG × 以前のPG 以前のPG
エンタープライズアプリケーション
(EJBもWARも含まない)
エージェントプロセス エージェントプロセス エージェントプロセス エージェントプロセス
CORBAアプリケーション
(Standardでは未サポート)
× × × ×
共有コンポーネント エージェントプロセス エージェントプロセス エージェントプロセス エージェントプロセス
OSGiバンドル エージェントプロセス エージェントプロセス エージェントプロセス エージェントプロセス
スタンダード Webアプリケーション (EJBを含むが、WebサービスのEJBは含まない) 指定したPG × 以前のPG 以前のPG
Webアプリケーション (EJBを含まないか、WebサービスのEJBを含む) エージェントプロセス エージェントプロセス エージェントプロセス エージェントプロセス
EJB 指定したPG × 以前のPG 以前のPG
EJB(Webサービス) エージェントプロセス エージェントプロセス エージェントプロセス エージェントプロセス
リソースアダプタ エージェントプロセス エージェントプロセス エージェントプロセス エージェントプロセス
アプリケーションクライアント エージェントプロセス エージェントプロセス エージェントプロセス エージェントプロセス
エンタープライズアプリケーション
(EJBを含むが、WebサービスのEJBは含まない)
指定したPG × 以前のPG 以前のPG
エンタープライズアプリケーション
(EJBを含まないか、WebサービスのEJBを含む)
エージェントプロセス エージェントプロセス エージェントプロセス エージェントプロセス
CORBAアプリケーション
(Standardでは未サポート)
× × × ×
共有コンポーネント エージェントプロセス エージェントプロセス エージェントプロセス エージェントプロセス
OSGiバンドル エージェントプロセス エージェントプロセス エージェントプロセス エージェントプロセス
Enterprise アドバンスト Webアプリケーション 指定したPG × 以前のPG 以前のPG
EJB 指定したPG × 以前のPG 以前のPG
リソースアダプタ エージェントプロセス エージェントプロセス エージェントプロセス エージェントプロセス
アプリケーションクライアント エージェントプロセス エージェントプロセス エージェントプロセス エージェントプロセス
エンタープライズアプリケーション
(EJBまたはWARを含む)
指定したPG × 以前のPG 以前のPG
エンタープライズアプリケーション
(EJBもWARも含まない)
エージェントプロセス エージェントプロセス エージェントプロセス エージェントプロセス
CORBAアプリケーション 指定したPG × 以前のPG 以前のPG
共有コンポーネント エージェントプロセス エージェントプロセス エージェントプロセス エージェントプロセス
OSGiバンドル エージェントプロセス エージェントプロセス エージェントプロセス エージェントプロセス
スタンダード Webアプリケーション (EJBを含むが、WebサービスのEJBは含まない) 指定したPG × 以前のPG 以前のPG
Webアプリケーション (EJBを含まないか、WebサービスのEJBを含む) エージェントプロセス エージェントプロセス エージェントプロセス エージェントプロセス
EJB 指定したPG × 以前のPG 以前のPG
EJB(Webサービス) エージェントプロセス エージェントプロセス エージェントプロセス エージェントプロセス
リソースアダプタ エージェントプロセス エージェントプロセス エージェントプロセス エージェントプロセス
アプリケーションクライアント エージェントプロセス エージェントプロセス エージェントプロセス エージェントプロセス
エンタープライズアプリケーション
(EJBを含むが、WebサービスのEJBは含まない)
指定したPG × 以前のPG 以前のPG
エンタープライズアプリケーション
(EJBを含まないか、WebサービスのEJBを含む)
エージェントプロセス エージェントプロセス エージェントプロセス エージェントプロセス
CORBAアプリケーション 指定したPG × 以前のPG 以前のPG
共有コンポーネント エージェントプロセス エージェントプロセス エージェントプロセス エージェントプロセス
OSGiバンドル エージェントプロセス エージェントプロセス エージェントプロセス エージェントプロセス

5.3. パッケージング

作成したアプリケーションを配備する前に、アプリケーションを配備可能な形式にパッケージングします。アーカイブ内のディレクトリ構造やファイルの配置方法は、アプリケーションの種類ごとに定められています。この章では、アプリケーションのアーカイブの方法について解説します。

5.3.1. Java EEのアプリケーションのパッケージング

WebアプリケーションやEJBアプリケーションなどのJava EEのアプリケーションを配備する際には、標準仕様(JSR)に準拠した形式でパッケージングを行う必要があります。パッケージングの形式が標準化されているため、ポータビリティの高いアプリケーションの作成が可能になっています。WebOTX Developerでプロジェクトを作成することにより、パッケージングを自動化することができます。

ここではJava EEアプリケーションのパッケージングの解説は省略します。詳細はJava EEの仕様を参考にしてください。

5.3.2. CORBAアプリケーションのパッケージング

Java EEの場合とは異なり、CORBAアプリケーションにはパッケージングに関する標準仕様はありません。ここで示すCORBAのパッケージングはWebOTX ASに固有の形式です。

CORBAアプリケーションをパッケージングするためには、最低限次の2つのファイルが必要です。

また、必要であれば次のファイルを準備してください。

表5.3.2-1
プロパティ 説明
component.initfunc コンポーネント初期化ファイル名を指定します。
component.id コンポーネントIDを指定します。
component.useshareif 共有コンポーネントのifファイルを利用する場合trueを利用しない場合falseを指定します(既定値:false)。
component.shareif 共有コンポーネントのifファイルを利用する場合そのifファイル名を指定します。
component.sharedComponentList 利用する共有コンポーネントのアプリケーション名を記述します。複数ある場合はカンマ「,」で区切ります。
sharedcomponent.allModuleUse 共有コンポーネントを全てのアプリケーションから利用できるようにします。

なお、統合運用管理ツールおよびWeb版統合運用管理コンソールにはパッケージングされていないCORBAアプリケーションを配備する機能がありますので、CORBAアプリケーションのパッケージングは必須ではありません。

5.3.2.1. CORBAアプリケーションの形式

CORBAアプリケーションの形式にはR4形式とR5形式があります。CORBAアプリケーションの形式についての詳細は、「システム設計ガイド」を参照してください。

5.3.2.2. コマンドを利用したパッケージング

コマンドラインからCORBAアプリケーションをパッケージングするにはmakecpkコマンドを利用します。makecpkの詳細なリファレンスについては[ リファレンス集 運用管理・設定編 > 4. 運用管理コマンドリファレンス > 4.5. パッケージ生成 > 4.5.1. makecpk ]を参照してください。

例1: 既定値でCORBAアプリケーションをパッケージング
> makecpk corbaap.cpk module=corbaap.jar if=corbaap.if
例2: プロパティファイルを指定してのCORBAアプリケーションをパッケージング
> makecpk corbaap.cpk module=corbaap.jar if=corbaap.if prop=corbaap.properties
例3: オプションを指定してのCORBAアプリケーションのパッケージング
> makecpk corbaap.cpk module=corbaap.jar if=shareap.if id=AA initfunc=corbaap.create useshareif=true

5.3.3. 共有コンポーネントのパッケージング

共有コンポーネントはWebOTX AS固有のコンポーネントです。共有コンポーネントをパッケージングするためには、最低限次のファイルが必要です。

また共有コンポーネントがCORBAインタフェースを持つ場合、次のファイルも準備してください。

なお、統合運用管理ツールおよびWeb版統合運用管理コンソールにはパッケージングされていない共有コンポーネントを配備する機能がありますので、共有コンポーネントのパッケージングは必須ではありません。

5.3.3.1. コマンドを利用したパッケージング

コマンドラインから共有コンポーネントをパッケージングするにはmakecpkコマンドを利用します。makecpkの詳細なリファレンスについては[ リファレンス集 運用管理・設定編 > 4. 運用管理コマンドリファレンス > 4.5. パッケージ生成 > 4.5.1. makecpk ]を参照してください。

例1: 共有コンポーネントのパッケージング
> makecpk shareap.spk module=shareap.jar
例2: CORBAインタフェースを持つ共有コンポーネントのパッケージング
> makecpk shareap.spk module=shareap.jar if=shareap.if

5.3.4. OSGiバンドルのパッケージング

OSGiバンドルを配備する際には、OSGiの仕様に準拠した形式でパッケージングを行う必要があります。

ここではOSGiバンドルのパッケージングの解説は省略します。詳細はOSGiの仕様を参考にしてください。

5.4. 配備、再配備と置換

配備とは、作成したアプリケーションをWebOTX ASの管理下におく作業です。 また再配備とは、WebOTX ASの管理下にあるアプリケーションを、新しいアプリケーションで置換することです。 置換に関しては、設定情報を保持したまま、再配備を行う作業です。 この章では、これらについて解説します。

5.4.1. アプリケーション名の規約

WebOTX ASがアプリケーションを管理するために、配備の際にはアプリケーションに名前をつける必要があります。アプリケーションの名前は、WebOTX ASのドメイン内で一意でなければなりません。

アプリケーション名で使用可能な文字は、ASCII英数字、ハイフン(-)、アンダースコア(_)、ピリオド(.)のみです。 アプリケーション名の先頭には、ASCII英数字、アンダースコア(_)のみが使用可能です。 また、ファイル名として使用できない文字列はアプリケーション名として使用することはできません。 使用可能な文字の例外として、[ 5.1.4. アプリケーションのバージョニング機能 ] で使用するコロン(:)を1つだけ含めることができます。

アプリケーション名は、デフォルトではアーカイブのファイル名から拡張子を取り除いたものになります。例えば、アーカイブのファイル名が「sample.war」の場合、「sample」というアプリケーション名でWebOTX ASに配備されます。また、配備をサポートする各ツールは、アプリケーション名を明示的に指定する方法を提供しています。

EAR に含まれるモジュール名にコロン(:)、アスタリスク(*)、疑問符(?)、二重引用符(")、不等号(< および >)、バーティカルバー(|)、および連続するアンダースコア(_)を使用することはできません。

5.4.2. アプリケーショングループとプロセスグループ

[ 製品構成と提供機能 > 3. 提供機能 > 3.4. TPモニタ > 3.4.1. アプリケーションの構成 > 3.4.1.3. プロセスグループ ]で示したとおり、WebOTX AS Standard/Enterpriseでは、配備の際にアプリケーショングループとプロセスグループの指定が必要な場合があります。

再配備時には、アプリケーショングループとプロセスグループを指定する必要がありません。自動的に、新しいアプリケーションを古いアプリケーションが配備されていたアプリケーショングループおよびプロセスグループに再配備されます。

5.4.3. Java EEのアプリケーションの配備/再配備

この節では、Java EEのアプリケーションの配備/再配備について説明します。特に断りがない限り、説明はJava EEのアプリケーションの種類すべてに共通しているものとします。

5.4.3.1. コマンドを利用した配備 (deploy)

運用管理コマンドのdeployオペレーションを利用してJava EEのアプリケーションを配備/再配備する方法について説明します。なお、運用管理コマンドの詳細については運用管理コマンドリファレンスの「deploy」を参照してください。

配備するには、Java EEのアプリケーションのアーカイブを指定してオペレーションdeployを実行します。WebOTX AS Standard/Enterpriseの場合は、配備先のアプリケーショングループ名とプロセスグループ名を指定する必要があります。

otxadmin> deploy [--apgroup アプリケーショングループ名] [--pgroup プロセスグループ名] アーカイブ名

再配備するには、--forceオプションを付加します。

otxadmin> deploy --force アーカイブ名

具体例を挙げると、WebOTX AS Expressにおいてアーカイブ名が「hello.war」であるWebアプリケーションを配備し、その後再配備するには、次のようにします。

otxadmin> deploy hello.war
otxadmin> deploy --force hello.war

別の例を挙げると、WebOTX AS Enterpriseにおいてアーカイブ名が「sample.jar」であるEJBアプリケーションを配備し、その後再配備するには、次のようにします。配備先のアプリケーショングループ名をapgで、プロセスグループ名をpgとしています。

otxadmin> deploy --apgroup apg --pgroup pg sample.jar
otxadmin> deploy --force sample.jar

5.4.3.2. コマンドを利用した配備 (deploydir)

運用管理コマンドのオペレーションdeploydirを利用してJava EEのアプリケーションを配備/再配備する方法について説明します。なお、運用管理コマンドの詳細については運用管理コマンドリファレンスの「deploydir」を参照してください。

通常の配備では、アプリケーションをパッケージングし、そのアーカイブを配備します。オペレーションdeploydirを利用すると、パッケージング前のディレクトリ構造そのものを配備することができます。

配備するには、Java EEのアプリケーションが格納されているディレクトリのフルパスを指定してオペレーションdeploydirを実行します。配備対象のディレクトリのフルパスは、WebOTX ASが動作しているホストにおけるフルパスです。アプリケーションをクライアントマシンからサーバマシンへ転送する機能はありません。WebOTX AS Standard/Enterpriseでは、配備の際にアプリケーショングループとプロセスグループの指定が必要な場合があります。

otxadmin> deploydir [--apgroup アプリケーショングループ名] [--pgroup プロセスグループ名] ディレクトリのフルパス

再配備するには、--forceオプションを付加します。

otxadmin> deploydir [--apgroup アプリケーショングループ名] [--pgroup プロセスグループ名] --force ディレクトリのフルパス

具体例を挙げると、WebOTX AS Expressにおいてアプリケーションのディレクトリのフルパスが「C:\hello」であるWebアプリケーションを配備し、その後再配備するには、次のようにします。

otxadmin> deploydir C:\\hello
otxadmin> deploydir --force C:\\hello

※運用管理コマンドでは、ファイルパスのセパレータ '\' は "\\" として入力する必要があります。

別の例を挙げると、WebOTX AS Enterpriseにおいて、サーバ上でのディレクトリのフルパスが「C:\sample」であるWebアプリケーションを配備し、その後再配備するには次のようにします。配備先のアプリケーショングループ名をapgで、プロセスグループ名をpgとしています。

otxadmin> deploydir --apgroup apg --pgroup pg C:\\sample
otxadmin> deploydir --force C:\\sample

オペレーションdeploydirは、システムの開発効率を上げるために提供しています。そのため本番環境ではdeploydirは利用せずに、deployを利用してください。オペレーションdeploydirは配備するディレクトリの内容を直接に書き換えてしまうため、配備するディレクトリのバックアップを取ってから実行してください。

deploydirでは、アーカイブファイルが解体された状態のディレクトリ配下の中にある配備記述子XMLファイルを直接変更できます。「オートデプロイ」の項で説明した構成情報ファイル「domain.xml」の同じ「das-config」要素内の中にある下記のダイナミックリロードに関する属性が有効になっていると、サーバは自動的に変更を検知し、アプリケーションを再ロードします。

表5.4.3.2-1
属性 既定値 説明
dynamic-reload-enabled true trueの場合、「.reload」ファイルのタイムスタンプをチェックし、更新されていればアプリケーションを読み込みなおします。
dynamic-reload-poll-interval-in-seconds 2 ダイナミックリロードのポーリング間隔を指定します。単位は秒です。

「dynamic-reload-enabled」の設定を「true」に変更します。WebOTX ASに更新を知らせるために次の操作を行います。

5.4.3.3. 統合運用管理ツールを利用した配備

統合運用管理ツールを利用して、Java EEのアプリケーションを配備する手順を説明します。

  1. 統合運用管理ツールを起動し、ドメインに接続します。そして画面左側のツリーの「アプリケーション」を選択し、右クリックします。表示されたメニューから「コンポーネントの配備」を選択します。


    図5.4.3.3-1

  2. コンポーネントタイプを適切に選択してください。この例では「EJBコンポーネント」を選択しています。また配備するアーカイブのパスを「ファイル」に記述します。「参照」ボタンを押下することでダイアログからパスを選択できます。入力が完了したら「次へ(N)」ボタンを押下します。


    図5.4.3.3-2

  3. WebOTX AS Standard/Enterpriseの場合は、配備先のアプリケーショングループとプロセスグループ指定します。そして「配備(D)」ボタンを押下します。


    図5.4.3.3-3

  4. 配備実行の確認のダイアログが表示されますので「はい(Y)」ボタンを押下してください。


    図5.4.3.3-4

  5. 配備の進行状況が表示された後、終了を示すダイアログが表示されます。


    図5.4.3.3-5

  6. 正常終了した場合、画面左側のツリーにアプリケーション名が表示されます。以下の画面の例では、「EJBコンポーネント」の子要素として「sample」というアプリケーションが追加されています。アプリケーションがどの要素の子要素になるのかは、アプリケーションの種類によって異なります。さらに、WebOTX AS Standard/Enterpriseでは、「WebOTX Java EEアプリケーション」の子要素としても追加されます。


    図5.4.3.3-6

5.4.3.4. Web版統合運用管理コンソールを利用した配備

Web版統合運用管理コンソールを利用して、Java EEのアプリケーションを配備する手順を説明します。

  1. Web版統合運用管理コンソールを起動し、ドメインに接続します。そして画面左側のツリーの「アプリケーション」を選択し、配備画面を表示されます。


    図5.4.3.4-1

  2. コンポーネントタイプを適切に選択してください。この例では「EJBコンポーネント」を選択しています。


    図5.4.3.4-2

  3. 配備するアーカイブのパスを「ファイル」に記述します。「参照」ボタンを押下することでダイアログからパスを選択できます。WebOTX AS Standard/Enterpriseの場合は、配備先のアプリケーショングループとプロセスグループ指定します。そして「配備(P)」ボタンを押下します。


    図5.4.3.4-3

  4. 正常終了した場合、画面左側のツリーにアプリケーション名が表示されます。以下の画面の例では、「EJBコンポーネント」の子要素として「sample」というアプリケーションが追加されています。アプリケーションがどの要素の子要素になるのかは、アプリケーションの種類によって異なります。さらに、WebOTX AS Standard/Enterpriseでは、「WebOTX Java EEアプリケーション」の子要素としても追加されます。


    図5.4.3.4-4

5.4.3.5. オートデプロイ機能を利用した配備

オートデプロイ機能とは、アプリケーションのアーカイブファイルを次のディレクトリにコピーすることで自動的に配備を行う機能です。

${INSTANCE_ROOT}/autodeploy

配備が成功した場合には、ディレクトリautodeployに、[アーカイブファイル名]_deployedというファイルが作成されます。また配備が失敗した場合は、[アーカイブファイル名]_deployFailedというファイルが作成されます。これらのファイルの存在を確認することで、配備が正常に終了したかどうかを調べることができます。

再配備を行う場合は、再配備するアーカイブをディレクトリautodeployに上書きでコピーしてください。上書きするアーカイブのタイムスタンプは、上書きされるアーカイブのタイムスタンプよりも新しいものである必要があります。古いタイムスタンプのアーカイブで上書きした場合、配備処理は実行されません。

WebOTX AS Standard/Enterpriseでは、配備時にアプリケーショングループとプロセスグループを指定する必要があります。オートデプロイ機能で配備先のアプリケーショングループとプロセスグループを指定するには、ディレクトリautodeployに、プロパティファイルautodeploy.propertiesを作成し、内容を適切に設定してください。プロパティファイルautodeploy.propertiesは、java.util.Propertiesが読み込める形式でなければいけません。プロパティファイルautodeploy.propertiesはドメイン起動時に読み込まれ、その後変更するたびに再読み込みされます。プロパティファイルautodeploy.propertiesに記述するプロパティの詳細を以下に示します。

表5.4.3.5-1
キー 値の説明
apg 登録先アプリケーショングループ名。
pg 登録先プロセスグループ名。
methodid メソッド識別情報の割り当てのモードの指定。[ 5.8. 配備チューニング > 5.8.1. EJBのメソッド識別情報の割り当て抑止(Standard/Enterprise) ]参照。

オートデプロイ機能の各種設定は、${INSTANCE_ROOT}/config/domain.xmlに記述してあります。このdomain.xmlファイルの要素<das-config>の属性の値を編集することで、設定を変更することができます。domain.xmlの編集はドメインを停止してから行ってください。属性の詳細は以下の通りです。

表5.4.3.5-2
属性 既定値 説明
autodeploy-enabled true trueの場合、オートデプロイ機能が有効になります。falseの場合は、オートデプロイ機能は無効になり、動作しません。
autodeploy-polling-interval-in-seconds 2 オートデプロイのためのディレクトリを監視する間隔(ポーリング間隔)です。単位は秒です。
autodeploy-retry-timeout 4 オートデプロイのリトライを中止するまでのタイムアウト時間です。オートデプロイに失敗したアーカイブファイルは、次のポーリング時にリトライされます。これは、アーカイブのコピー中にオートデプロイが実行された場合に、はじめのオートデプロイで失敗しても、コピー完了後に再度オートデプロイを実行するためです。リトライタイムアウト時間が経過すると、以降のオートデプロイのリトライは実行されません。単位は秒です。
autodeploy-dir ${INSTANCE_ROOT}/autodeploy オートデプロイのためのディレクトリを設定します。このディレクトリは、絶対パスを指定します。
autodeploy-jsp-precompilation-enabled false trueの場合、配備中にJSPをコンパイルします。falseの場合、JSPのコンパイルは行いません。この場合はJSPの初回アクセス時に動的にコンパイルを実行します。

5.4.3.6. コンテキストパス"/" への配備

Java EEのアプリケーションへのアクセスパス(コンテキストパス)は通常パッケージング名(xxxx.war)の拡張子を除いた部分(xxxx)と等価となります。つまり Webブラウザからは

http://<host>/xxxx/

でアクセスすることになります。しかし、http://<host>/ としただけで特定のアプリケーションにアクセスしたい場合があります。このような場合は次のようにします(1 と 2 を実施)。

1) "/" への配備

まず、対象となるアプリケーションを "/" への配備するための設定をします。

※application.xmlとnec-web.xmlの両方に設定がある場合は、nec-web.xmlが優先されます。

2) "/" にアクセスするための設定

下記2つのコマンドを入力し、ドメイン再起動します。

a) otxadmin> create-jvm-options -Dwebotx.webcontainer.serverconfig.NoRoot=false

b) otxadmin> add-pg-javasystem-property --apgroup [apgroup_name] --javasystemprop webotx.webcontainer.serverconfig.NoRoot --value false [pgroup_name]

【注意点】
・内蔵Webサーバを利用している場合、(2) は実施する必要はありません。
・スタンダードモードの場合は (a) のみを設定します。アドバンスドモードでは、(a) と (b) の2箇所に設定する必要があります。
・その他、[ 注意制限事項 > 3. Webコンテナ > 3.1. 注意事項 > Webアプリケーションのルートコンテキスト("/")への割り当てについて ]も参照してください。


5.4.3.7. ホットスワップ機能を利用したアプリケーションの更新

ホットスワップ機能とは、アプリケーションのクラスファイルを更新を検知し、配備を行うことなくアプリケーションの更新を反映する機能です。

ホットスワップ機能を有効にすると、アプリケーションのディレクトリ内のクラスファイルが監視されます。クラスファイルのタイムスタンプが変更されると、そのクラスファイルからロードされたクラスが再定義されます。
再定義に成功した場合も失敗した場合もログにメッセージが出力されます。再定義する前に実行中のメソッドは次回実行時に更新が反映されます。再定義に失敗した場合、再定義前のクラスがそのまま使用されます。

ホットスワップ機能を有効にするには、ドメインに対してホットスワップ機能を有効化した上で、個々のアプリケーションに対してホットスワップ機能を有効化する必要があります。そのため、ドメイン単位およびアプリケーション単位で、ホットスワップ機能の有効・無効を切り替えることができます。

ホットスワップ機能の各種設定は、${INSTANCE_ROOT}/config/domain.xmlに記述してあります。このdomain.xmlファイルの要素<das-config>の属性の値を編集することで、設定を変更することができます。設定の変更は運用管理ツールや運用管理コマンドを使用して行うことができます。domain.xmlを直接編集する場合はドメインを停止してから行ってください。属性の詳細は以下の通りです。

表5.4.3.7-1
属性 既定値 説明
hotswap-enabled false trueの場合、ドメインに対してホットスワップ機能が有効になります。falseの場合は、ホットスワップ機能が無効になり動作しません。
hotswap-polling-interval-in-seconds 2 ホットスワップのためのディレクトリを監視する間隔(ポーリング間隔)です。単位は秒です。

また、domain.xmlファイルの要素<application>の属性の値を編集することで、アプリケーションに対する設定を変更することができます。設定の変更は運用管理ツールや運用管理コマンドを使用して行うことができます。domain.xmlを直接編集する場合はドメインを停止してから行ってください。属性の詳細は以下の通りです。

表5.4.3.7-2
属性 既定値 説明
hotswap-enabled false trueの場合、アプリケーションのディレクトリをホットスワップ機能の監視対象に追加します。falseの場合は、アプリケーションのディレクトリは監視対象にならず、クラスファイルの更新は検知されません。この設定の変更は、アプリケーションの再起動で反映されます。

アプリケーションに対するホットスワップ機能の設定は、配備時の--hotswapenabledオプションでも行うことができます。

ホットスワップ機能の使用例

アプリケーションがディレクトリ「C:/apps/hello」にwarを展開した形式で存在する場合について説明します。

ディレクトリ構成例は以下の通りです。

C:/apps/hello/
WEB-INF/
classes/
com/
example/
HelloServlet.class
Person.class
web.xml

ホットスワップ機能を有効化する手順は以下の通りです。

[配備時に有効化する場合]

  1. ドメインに対して、ホットスワップ機能を有効化します。
    (すでに有効化されている場合、この手順は不要です)
    otxadmin> set server.admin-service.das-config.hotswap-enabled=true
  2. ホットスワップ機能を有効にしてアプリケーションを配備します。
    otxadmin> deploydir --hotswapenabled C:/apps/hello

[配備後に有効化する場合]

  1. ホットスワップ機能を無効にしてアプリケーションを配備します。
    (--hotswapenabledオプションの既定値はfalseです)
    otxadmin> deploydir C:/apps/hello
  2. ドメインに対して、ホットスワップ機能を有効化します。
    (すでに有効化されている場合、この手順は不要です)
    otxadmin> set server.admin-service.das-config.hotswap-enabled=true
  3. アプリケーションに対して、ホットスワップ機能を有効化します。
    otxadmin> set server.applications.application.hello.hotswap-enabled=true
  4. アプリケーションを再起動することで、アプリケーションがホットスワップの対象になります。
    otxadmin> disable hello
    otxadmin> enable hello

上記の設定を行って、ホットスワップ機能が有効になっている状態で、アプリケーション内のクラスファイル(例: HelloServlet.class)を更新すると、ロード済みのクラスが再定義されます。再定義に失敗した場合は、失敗原因とともにメッセージがログに出力されます。なお、更新されたクラスファイルのクラスがまだロードされていない場合は、再定義されません。その場合は、クラスがロードされるときに更新後のクラスファイルを読み込みます。

上記の例ではディレクトリ展開形式で配備したアプリケーションに対してホットスワップ機能を使用していますが、アーカイブ形式で配備したアプリケーションに対してもホットスワップ機能を使用することができます。

制限事項

5.4.4. Java EEのアプリケーションの置換

この節では、Java EEのアプリケーションの置換について説明します。特に断りがない限り、説明はJava EEのアプリケーションの種類すべてに共通しているものとします。

プロセスグループに配備したアプリケーションは、TPモニタの機能を最大限に引き出すために、メソッド単位で細粒度の設定を行う事が可能です。 しかしながら、細粒度であるが故にアプリケーションの構成変更の影響を受けやすく、再配備時にはTPモニタ関連の設定は初期値に戻ってしまいます。

アプリケーションの置換とは、「インタフェースに変更がない」という制約の下、TPモニタ関連の設定を保持したまま再配備を行う操作です。 アプリケーションの置換は、本番環境で動作しているアプリケーションに対して、そのアプリケーションの不具合の修正を目的としたリビジョンアップを行う場合に利用します。 アプリケーションの置換は、開発時のようにインタフェースが安定していない状況には向いていません。

「インタフェースに変更がない」とは、以下の条件を満たす事を指します。

上記の条件を満たさなかった場合、アプリケーションの置換は失敗し、エラーが返されます。

5.4.4.1. コマンドを利用した置換 (replace)

運用管理コマンドのreplaceオペレーションを利用してJava EEのアプリケーションを置換する方法について説明します。なお、運用管理コマンドの詳細については運用管理コマンドリファレンスの「replace」を参照してください。

置換するには、Java EEのアプリケーションのアーカイブを指定してオペレーションreplaceを実行します。

otxadmin> replace アーカイブ名

replaceは、旧アプリケーションが配備されていたプロセスグループを自働的に配備先として選択します。

具体例を挙げると、WebOTX AS Enterpriseにおいてアーカイブ名が「hello.war」であるWebアプリケーションを配備し、その後置換するには、次のようにします。

otxadmin> deploy --apgroup myapg --pgroup mypg hello.war
otxadmin> replace hello.war

5.4.4.2. 統合運用管理ツールを利用した置換

統合運用管理ツールを利用して、Java EEのアプリケーションを置換する手順を説明します。

  1. 統合運用管理ツールを起動し、ドメインに接続します。そして画面左側のツリーの「アプリケーション」を選択し、右クリックします。表示されたメニューから「コンポーネントの置換」を選択します。


    図5.4.4.2-1

  2. コンポーネントタイプを適切に選択してください。この例では「EJBコンポーネント」を選択しています。また配備するアーカイブのパスを「ファイル」に記述します。「参照」ボタンを押下することでダイアログからパスを選択できます。入力が完了したら「次へ(N)」ボタンを押下します。


    図5.4.4.2-2

  3. WebOTX AS Standard/Enterpriseの場合は、配備先のアプリケーショングループとプロセスグループ指定します。そして「置換(D)」ボタンを押下します。


    図5.4.4.2-3

  4. 配備実行の確認のダイアログが表示されますので「はい(Y)」ボタンを押下してください。


    図5.4.4.2-4

  5. 配備の進行状況が表示された後、終了を示すダイアログが表示されます。


    図5.4.4.2-5

  6. 正常終了した場合、画面左側のツリーにアプリケーション名が表示されます。以下の画面の例では、「EJBコンポーネント」の子要素として「sample」というアプリケーションが追加されています。アプリケーションがどの要素の子要素になるのかは、アプリケーションの種類によって異なります。さらに、WebOTX AS Standard/Enterpriseでは、「WebOTX Java EEアプリケーション」の子要素としても追加されます。


    図5.4.4.2-6

5.4.4.3. Web版統合運用管理コンソールを利用した置換

Web版統合運用管理コンソールを利用して、Java EEのアプリケーションを置換する手順を説明します。

  1. Web版統合運用管理コンソールを起動し、ドメインに接続します。そして画面左側のツリーの「アプリケーション」を選択し、配備画面を表示されます。


    図5.4.4.3-1

  2. コンポーネントタイプを適切に選択してください。この例では「EJBコンポーネント」を選択しています。


    図5.4.4.3-2

  3. 配備するアーカイブのパスを「ファイル」に記述します。「参照」ボタンを押下することでダイアログからパスを選択できます。WebOTX AS Standard/Enterpriseの場合は、配備先のアプリケーショングループとプロセスグループ指定します。そして「置換(P)」ボタンを押下します。


    図5.4.4.3-3

  4. 正常終了した場合、画面左側のツリーにアプリケーション名が表示されます。以下の画面の例では、「EJBコンポーネント」の子要素として「sample」というアプリケーションが追加されています。アプリケーションがどの要素の子要素になるのかは、アプリケーションの種類によって異なります。さらに、WebOTX AS Standard/Enterpriseでは、「WebOTX Java EEアプリケーション」の子要素としても追加されます。


    図5.4.4.3-4

5.4.5. CORBAアプリケーションの配備

ここではCORBAアプリケーションの配備について説明します。WebOTX AS EnterpriseのみがCORBAアプリケーションをサポートしています。

5.4.5.1. 動的配備と静的配備

CORBAアプリケーションの形式がR4形式なのかR5形式なのかによって、配備を行うための条件が異なります。アプリケーショングループが起動状態で配備を行うことを、動的配備と呼びます。アプリケーショングループが停止状態で配備を行うことを、静的配備と呼びます。

R4形式のCORBAアプリケーションの場合、静的配備のみをサポートします。配備を行うにはそのCORBAアプリケーションが属しているアプリケーショングループを停止してください。アプリケーショングループが起動している場合は配備できません。

R5形式のCORBAアプリケーションの場合は、動的配備も静的配備もサポートしています。ただし、動的配備を行う場合は以下の条件を満たす必要があります。

バージョン5のプロセスグループは動的配備をサポートしていませんので、アプリケーショングループを停止して静的配備を行ってください。

5.4.5.2. 動的再配備と静的再配備

CORBAアプリケーションの形式がR4形式なのかR5形式なのかによって、再配備を行うための条件が異なります。アプリケーショングループが起動状態で再配備を行うことを、動的再配備と呼びます。アプリケーショングループが停止状態で再配備を行うことを、静的再配備と呼びます。

R4形式のCORBAアプリケーションの場合、静的再配備のみをサポートします。再配備を行うにはそのCORBAアプリケーションが属しているアプリケーショングループを停止してください。アプリケーショングループが起動している場合は再配備できません。

R5形式のCORBAアプリケーションの場合は、動的再配備も静的再配備もサポートしています。ただし、動的再配備を行う場合は以下の条件を満たす必要があります。

バージョン5のプロセスグループは動的再配備をサポートしていませんので、アプリケーショングループを停止して静的再配備を行ってください。またCORBAアプリケーションが停止状態でない場合は、再配備ができません。CORBAアプリケーションを停止状態にすることで、再配備を行うことができます。CORBAアプリケーションを停止する際、実行中のオペレーションがエラーとなる可能性があります。

5.4.5.3. 業務の停止を伴わないアプリケーションの置換

動的配備と動的配備解除を利用することにより、業務を停止せずにアプリケーションを置換することができます。手順を以下に示します。

  1. 新しいアプリケーションを作成する際に、モジュール名を古いアプリケーションと異なるものにします。これにより新旧アプリケーションを同時に配備することができるようになります。
  2. 新しいアプリケーションを古いアプリケーションとは異なるアプリケーション名で動的配備します。これにより新旧アプリケーションが同時に起動している状態になります。
  3. 名前サーバの登録情報を、新しいアプリケーションの情報で上書きします。これにより新規に接続するクライアントは新しいアプリケーションを参照するようになります。
  4. 古いアプリケーションを動的配備解除します。詳細は[ 5.5. 配備解除 > 5.5.2. CORBAアプリケーションの配備解除 > 5.5.2.1. 動的配備解除と静的配備解除 ]を参照してください。

5.4.5.4. ファクトリインタフェースのオペレーション

WebOTX V6.5より、オペレーション数削減のために、業務実行において不要なCORBAオペレーションを表示しないようにしています。具体的には、R4形式で作成されたCORBAアプリケーションにおける、自動生成されたファクトリインタフェースのオペレーションのうち、CreateServerObject2とReleaseServerObject2の登録を行わないようにしています。これらは開発環境のIDLコンパイラ(woigenxx, woigenj)で作成したときに自動付加されます。WebOTX V6.4以前と同じように表示させたい場合は、以下の方法でドメインのJava VMオプションにシステムプロパティを設定してから配備しなおす必要があります。

設定するシステムプロパティは以下の通りです。

表5.4.5.4-1
プロパティ
com.nec.webotx.analyzeFactory true/false (既定値:false CreateServerObject2, ReleaseServerObject2を表示しない)

システムプロパティをJava VMオプションに追加します。設定手順は以下の通りです。

5.4.5.5. コマンドを利用した配備

運用管理コマンドを利用してCORBAアプリケーションを配備/再配備する方法について説明します。なお、運用管理コマンドの詳細については運用管理コマンドリファレンスの「deploy」を参照してください。

配備するには、CORBAアプリケーションのアーカイブを指定してdeployオペレーションを実行します。deployオペレーションを実行する際には、配備先のアプリケーショングループ名とプロセスグループ名も指定する必要があります。

otxadmin> deploy --apgroup アプリケーショングループ名 --pgroup プロセスグループ名 アーカイブ名

再配備するには、--forceオプションを付加します。

otxadmin> deploy --force アーカイブ名

例えば、アーカイブ名が「corba.cpk」であるCORBAアプリケーションを配備し、その後再配備するには、次のようにします。配備先のアプリケーショングループ名をapgで、プロセスグループ名をpgとしています。

otxadmin> deploy --apgroup apg --pgroup pg corba.cpk
otxadmin> deploy --force corba.cpk

5.4.5.6. 統合運用管理ツールを利用した配備

統合運用管理ツールを利用して、CORBAアプリケーションを配備する手順を説明します。

  1. 統合運用管理ツールの画面左側のツリーの「アプリケーション」を選択し、右クリックします。表示されたメニューから「コンポーネントの配備」を選択します。


    図5.4.5.6-1

  2. 「コンポーネントタイプ」を「CORBAアプリケーション」に設定します。また「ファイル」に配備するCORBAアプリケーションのアーカイブ(.cpk)を設定します。入力が完了したら、「次へ(N)」ボタンを押下します。


    図5.4.5.6-2

  3. 「アプリケーショングループ」と「プロセスグループ」を適切に設定してください。また再配備を行う場合は、「強制(再)配備」にチェックを入れてください。入力が完了したら「配備(D)」ボタンを押下してください。


    図5.4.5.6-3

  4. 配備実行の確認画面が出てきますので、「はい(Y)」ボタンを押下してください。


    図5.4.5.6-4

  5. 配備が正常に完了すると、以下の画面のように、画面左側のツリーの「CORBAアプリケーション」の下に配備したアプリケーション名が表示されます。


    図5.4.5.6-5

5.4.5.7. Web版統合運用管理コンソールを利用した配備

Web版統合運用管理コンソールを利用して、CORBAアプリケーションを配備する手順を説明します。

  1. Web版統合運用管理コンソールの画面左側のツリーの「アプリケーション」を選択し、表示された配備画面から「コンポーネントタイプ」を「CORBAアプリケーション」に設定します。


    図5.4.5.7-1

  2. 「ファイル」に配備するCORBAアプリケーションのアーカイブ(.cpk)を設定してから、「アプリケーショングループ」と「プロセスグループ」を適切に設定してください。入力が完了したら「配備(P)」ボタンを押下してください。


    図5.4.5.7-2

  3. 配備が正常に完了すると、以下の画面のように、画面左側のツリーの「CORBAアプリケーション」の下に配備したアプリケーション名が表示されます。


    図5.4.5.7-3

5.4.6. 共有コンポーネントの配備

ここでは、共有コンポーネントの配備について説明します。WebOTX AS Standard/Enterpriseが共有コンポーネントをサポートしています。

5.4.6.1. コマンドを利用した配備

運用管理コマンドを利用して共有コンポーネントを配備/再配備する方法について説明します。なお、運用管理コマンドの詳細については運用管理コマンドリファレンスの「deploy」を参照してください。

配備する場合は、共有コンポーネントのアーカイブを指定してdeployオペレーションを実行します。

otxadmin> deploy アーカイブ名

再配備するには、--forceオプションを付加します。

otxadmin> deploy --force アーカイブ名

具体例を挙げると、アーカイブ名が「shared.spk」である共有コンポーネントを配備し、その後再配備するには、次のようにします。

otxadmin> deploy shared.spk
otxadmin> deploy --force shared.spk

5.4.6.2. 統合運用管理ツールを利用した配備

統合運用管理ツールを利用して、共有コンポーネントを配備する手順を説明します。

  1. 統合運用管理ツールの画面左側のツリーの「アプリケーション」を選択し、右クリックします。表示されたメニューから「コンポーネントの配備」を選択します。


    図5.4.6.2-1

  2. 「コンポーネントタイプ」を「共有コンポーネント」に設定します。また「ファイル」に配備する共有コンポーネントのアーカイブ(.spk)を設定します。入力が完了したら、「次へ(N)」ボタンを押下します。


    図5.4.6.2-2

  3. 再配備を行う場合は、「強制(再)配備」にチェックを入れてください。入力が完了したら「配備(D)」ボタンを押下してください。


    図5.4.6.2-3

  4. 配備実行の確認画面が出てきますので、「はい(Y)」ボタンを押下してください。


    図5.4.6.2-4

  5. 配備が正常に完了すると、以下の画面のように、画面左側のツリーの「共有コンポーネント」の下に配備したアプリケーション名が表示されます。


    図5.4.6.2-5

5.4.6.3. Web版統合運用管理コンソールを利用した配備

Web版統合運用管理コンソールを利用して、共有コンポーネントを配備する手順を説明します。

  1. 統合運用管理コンソールの画面左側のツリーの「アプリケーション」を選択し、表示された配備画面から「コンポーネントタイプ」を「共有コンポーネント」に設定します。


    図5.4.6.3-1

  2. 「ファイル」に配備する共有コンポーネントのアーカイブ(.spk)を設定します。入力が完了したら、「配備(P)」ボタンを押下してください。


    図5.4.6.3-2

  3. 配備が正常に完了すると、以下の画面のように、画面左側のツリーの「共有コンポーネント」の下に配備したアプリケーション名が表示されます。


    図5.4.6.3-3

5.4.7. OSGiバンドルの配備

ここでは、OSGiバンドルの配備について説明します。

5.4.7.1. コマンドを利用した配備

運用管理コマンドを利用してOSGiバンドルを配備/再配備する方法について説明します。なお、運用管理コマンドの詳細については運用管理コマンドリファレンスの「deploy」を参照してください。

配備する場合は、--typeオプションにosgiと指定し、OSGiバンドルのアーカイブを指定してdeployオペレーションを実行します。

otxadmin> deploy --type osgi アーカイブ名

再配備するには、--forceオプションを付加します。再配備時も--typeオプションにosgiと指定する必要があります。

otxadmin> deploy --force --type osgi アーカイブ名

具体例を挙げると、アーカイブ名が「sample.jar」であるOSGiバンドルを配備し、その後再配備するには、次のようにします。

otxadmin> deploy --type osgi sample.jar
otxadmin> deploy --force --type osgi sample.jar

5.4.7.2. 統合運用管理ツールを利用した配備

統合運用管理ツールを利用して、OSGiバンドルを配備する手順を説明します。

  1. 統合運用管理ツールの画面左側のツリーの「アプリケーション」を選択し、右クリックします。表示されたメニューから「コンポーネントの配備」を選択します。


    図5.4.7.2-1

  2. 「コンポーネントタイプ」を「OSGiモジュール」に設定します。また「ファイル」に配備するOSGiバンドルのアーカイブ(.jar)を設定します。入力が完了したら、「次へ(N)」ボタンを押下します。


    図5.4.7.2-2

  3. 再配備を行う場合は、「強制(再)配備」にチェックを入れてください。入力が完了したら「配備(D)」ボタンを押下してください。


    図5.4.7.2-3

  4. 配備実行の確認画面が出てきますので、「はい(Y)」ボタンを押下してください。


    図5.4.7.2-4

  5. 配備が正常に完了すると、以下の画面のように、画面左側のツリーの「OSGiバンドル」の下に配備したアプリケーション名が表示されます。


    図5.4.7.2-5

5.4.7.3. Web版統合運用管理コンソールを利用した配備

Web版統合運用管理コンソールを利用して、OSGiバンドルを配備する手順を説明します。

  1. 統合運用管理コンソールの画面左側のツリーの「アプリケーション」を選択し、表示された配備画面から「コンポーネントタイプ」を「OSGiモジュール」に設定します。


    図5.4.7.3-1

  2. 「ファイル」に配備するOSGiバンドルのアーカイブ(.jar)を設定します。入力が完了したら、「配備(P)」ボタンを押下してください。


    図5.4.7.3-2

  3. 配備が正常に完了すると、以下の画面のように、画面左側のツリーの「OSGiバンドル」の下に配備したアプリケーション名が表示されます。


    図5.4.7.3-3

5.4.7.4. オートデプロイ機能を利用した配備

オートデプロイ機能とは、OSGiバンドルのアーカイブファイルを次のディレクトリにコピーすることで自動的に配備を行う機能です。

${INSTANCE_ROOT}/autodeploy/bundles

Java EEのアプリケーションのオートデプロイとは異なり、OSGiバンドルのオートデプロイは、WebOTXが使用するOSGiフレームワークの機能を利用しています。そのため、オートデプロイされたOSGiバンドルはWebOTXの運用管理ツールから管理することはできません。

また、Java EEのアプリケーションのオートデプロイの設定は、OSGiバンドルのオートデプロイには適用されません。

5.4.8. 注意事項

5.5. 配備解除

配備解除とは、WebOTX ASの管理下からアプリケーションを除外することです。この章では配備解除について解説します。

5.5.1. Java EEのアプリケーションの配備解除

この節では、Java EEのアプリケーションの配備解除について説明します。特に断りがない限り、説明はJava EEのアプリケーションの種類すべてに共通しているものとします。

5.5.1.1. コマンドを利用した配備解除

運用管理コマンドを利用してJava EEのアプリケーションを配備解除する方法について説明します。なお、運用管理コマンドの詳細については運用管理コマンドリファレンスの「undeploy」を参照ください。

配備解除するには、アプリケーション名を指定してundeployオペレーションを実行します。

otxadmin> undeploy アプリケーション名

具体例を挙げると、アプリケーション名が「hello」であるアプリケーションを配備解除するには、次のようにします。

otxadmin> undeploy hello

5.5.1.2. 統合運用管理ツールを利用した配備解除

統合運用管理ツールを利用して、Java EEのアプリケーションを配備解除する手順を説明します。

  1. 統合運用管理ツールを起動し、ドメインに接続します。そして画面左側のツリーから配備解除するアプリケーションを選択し、右クリックします。表示されたメニューから「配備解除」を選択します。


    図5.5.1.2-1

  2. 配備解除のオプションを選択するダイアログが表示されますので、必要な情報を設定して、「OK」ボタンを押下します。


    図5.5.1.2-2

  3. 配備解除に成功すると、以下のような画面が表示されます。


    図5.5.1.2-3

5.5.1.3. Web版統合運用管理コンソールを利用した配備解除

Web版統合運用管理コンソールを利用して、Java EEのアプリケーションを配備解除する手順を説明します。

  1. Web版統合運用管理コンソールの画面左側のツリーから、配備解除するアプリケーションの名前を選択し、右側に表示された「操作」タグを選択します。


    図5.5.1.3-1

  2. 「操作」タグ下のリストから、「コンポーネントの配備解除」を選択したら、「実行(E)」ボタンを押して、配備解除を行います。


    図5.5.1.3-2

5.5.1.4. オートデプロイ機能による配備解除

オートデプロイ機能での配備で利用した以下のディレクトリから、該当アーカイブを削除することで、自動的に配備解除が開始します。

${INSTANCE_ROOT}/autodeploy

5.5.2. CORBAアプリケーションの配備解除

ここではCORBAアプリケーションの配備解除について説明します。

5.5.2.1. 動的配備解除と静的配備解除

CORBAアプリケーションの形式がR4形式なのかR5形式なのかによって、配備解除を行うための条件が異なります。アプリケーショングループが起動状態で配備解除を行うことを、動的配備解除と呼びます。アプリケーショングループが停止状態で配備解除を行うことを、静的配備解除と呼びます。

R4形式のCORBAアプリケーションの場合、静的配備解除のみをサポートします。配備解除を行うにはそのCORBAアプリケーションが属しているアプリケーショングループを停止してください。アプリケーショングループが起動している場合は配備解除できません。

R5形式のCORBAアプリケーションの場合は、動的配備解除も静的配備解除もサポートしています。ただし、動的配備解除を行う場合は以下の条件を満たす必要があります。

バージョン5のプロセスグループは動的配備解除をサポートしていませんので、アプリケーショングループを停止して静的配備解除を行ってください。またCORBAアプリケーションが停止状態でない場合は、配備解除ができません。CORBAアプリケーションを停止状態にすることで、配備解除を行うことができます。ただし停止状態にする際、現在実行中のオペレーションがエラーになる可能性があります。安全な停止方法については[ 5.6. 開始と停止 > 5.6.1. Java EEのアプリケーションの開始と停止 > 5.6.1.1. コマンドを利用した開始と停止 ]を参照してください。

5.5.2.2. コマンドを利用した配備解除

運用管理コマンドを利用してCORBAアプリケーションを配備解除する方法について説明します。CORBAアプリケーションを配備解除するための条件については[ 5.5.2.1. 動的配備解除と静的配備解除 ]を参照してください。なお、運用管理コマンドの詳細については運用管理コマンドリファレンスの「undeploy」を参照ください。

配備解除するには、アプリケーション名を指定してundeployオペレーションを実行します。

otxadmin> undeploy アプリケーション名

例えば、アプリケーション名が「corba」であるCORBAアプリケーションを配備解除するには、次のようにします。

otxadmin> undeploy corba

5.5.2.3. 統合運用管理ツールを利用した配備解除

ここでは統合運用管理ツールを利用してCORBAアプリケーションを配備解除する手順を説明します。CORBAアプリケーションを配備解除するための条件については[ 5.5.2.1. 動的配備解除と静的配備解除 ]を参照してください。

  1. 統合運用管理ツールの画面左側のツリーから、配備解除するCORBAアプリケーションの名前を選択し、右クリックします。表示されたメニューの中から「配備解除」を選択します。


    図5.5.2.3-1

  2. 配備解除の各種設定を行った後、「OK」ボタンを押下します。


    図5.5.2.3-2

  3. 配備解除に成功すると、以下のような画面が表示されます。


    図5.5.2.3-3

5.5.2.4. Web版統合運用管理コンソールを利用した配備解除

ここではWeb版統合運用管理コンソールを利用してCORBAアプリケーションを配備解除する手順を説明します。CORBAアプリケーションを配備解除するための条件については[ 5.5.2.1. 動的配備解除と静的配備解除 ]を参照してください。

  1. Web版統合運用管理コンソールの画面左側のツリーから、配備解除するCORBAアプリケーションの名前を選択し、右側に表示された「操作」タグを選択します。


    図5.5.2.4-1

  2. 「操作」タグ下のリストから、「コンポーネントの配備解除」を選択したら、「実行(E)」ボタンを押して、配備解除を行います。


    図5.5.2.4-2

5.5.3. 共有コンポーネントの配備解除

ここでは、共有コンポーネントの配備解除について説明します。

5.5.3.1. コマンドを利用した配備解除

運用管理コマンドを利用して共有コンポーネントを配備解除する方法について説明します。なお、運用管理コマンドの詳細については運用管理コマンドリファレンスの「undeploy」を参照ください。

配備解除するには、アプリケーション名を指定してundeployオペレーションを実行します。

otxadmin> undeploy アプリケーション名

例えば、アプリケーション名が「shared」である共有コンポーネントを配備解除するには、次のようにします。

otxadmin> undeploy shared

5.5.3.2. 統合運用管理ツールを利用した配備解除

ここでは、統合運用管理ツールを利用して共有コンポーネントを配備解除する手順について説明します。

  1. 統合運用管理ツールの画面左側のツリーから、配備解除する共有コンポーネントの名前を選択し、右クリックします。表示されたメニューの中から「配備解除」を選択します。


    図5.5.3.2-1

  2. 配備解除の各種設定を行った後、「OK」ボタンを押下します。


    図5.5.3.2-2

  3. 配備解除に成功すると、以下のような画面が表示されます。


    図5.5.3.2-3

5.5.3.3. Web版統合運用管理コンソールを利用した配備解除

ここでは、Web版統合運用管理コンソールを利用して共有コンポーネントを配備解除する手順について説明します。

  1. Web版統合運用管理コンソールの画面左側のツリーから、配備解除する共有コンポーネントの名前を選択し、右側に表示された「操作」タグを選択します。


    図5.5.3.3-1

  2. 「操作」タグ下のリストから、「コンポーネントの配備解除」を選択したら、「実行(E)」ボタンを押して、配備解除を行います。


    図5.5.3.3-2

5.5.4. OSGiバンドルの配備解除

ここでは、OSGiバンドルの配備解除について説明します。

5.5.4.1. コマンドを利用した配備解除

運用管理コマンドを利用してOSGiバンドルを配備解除する方法について説明します。なお、運用管理コマンドの詳細については運用管理コマンドリファレンスの「undeploy」を参照ください。

配備解除するには、アプリケーション名を指定してundeployオペレーションを実行します。

otxadmin> undeploy アプリケーション名

例えば、アプリケーション名が「sample」であるOSGiバンドルを配備解除するには、次のようにします。

otxadmin> undeploy sample

5.5.4.2. 統合運用管理ツールを利用した配備解除

ここでは、統合運用管理ツールを利用してOSGiバンドルを配備解除する手順について説明します。

  1. 統合運用管理ツールの画面左側のツリーから、配備解除するOSGiバンドルの名前を選択し、右クリックします。表示されたメニューの中から「配備解除」を選択します。


    図5.5.4.2-1

  2. 配備解除の各種設定を行った後、「OK」ボタンを押下します。


    図5.5.4.2-2

  3. 配備解除に成功すると、以下のような画面が表示されます。


    図5.5.4.2-3

5.5.4.3. Web版統合運用管理コンソールを利用した配備解除

ここでは、Web版統合運用管理コンソールを利用してOSGiバンドルを配備解除する手順について説明します。

  1. Web版統合運用管理コンソールの画面左側のツリーから、配備解除するOSGiバンドルの名前を選択し、右側に表示された「操作」タグを選択します。


    図5.5.4.3-1

  2. 「操作」タグ下のリストから、「コンポーネントの配備解除」を選択したら、「実行(E)」ボタンを押して、配備解除を行います。


    図5.5.4.3-2

5.5.4.4. オートデプロイ機能による配備解除

オートデプロイ機能での配備で利用した以下のディレクトリから、該当アーカイブを削除することで、自動的に配備解除が開始します。オートデプロイ機能で配備したOSGiバンドルは、オートデプロイ機能による配備解除でしか配備解除できません。

${INSTANCE_ROOT}/autodeploy/bundles

5.5.5. 注意事項

5.6. 開始と停止

アプリケーションが開始した状態とは、配備されたアプリケーションが動作しており、クライアントからの要求を受け付けることができる状態です。また、アプリケーションが停止した状態とは、アプリケーションが動作していない状態のことで、クライアントからの要求は受け付けることができませんが、アプリケーションは依然としてWebOTX ASの管理下にあります。この章ではアプリケーションの開始と停止について解説します。

5.6.1. Java EEのアプリケーションの開始と停止

この節では、Java EEのアプリケーションの開始と停止について説明します。特に断りがない限り、説明はJava EEアプリケーションの種類すべてに共通しているものとします。

5.6.1.1. コマンドを利用した開始と停止

運用管理コマンドを利用してJava EEのアプリケーションを開始/停止する方法について説明します。なお、運用管理コマンドの詳細については運用管理コマンドリファレンスの「enable」、「disable」を参照してください。

アプリケーションを開始するにはオペレーションenableを、停止するにはオペレーションdisableを実行します。

otxadmin> enable アプリケーション名
otxadmin> disable アプリケーション名

具体例を挙げると、アプリケーション名が「myapp」であるアプリケーションを開始し、その後停止するには、次のようにします。

otxadmin> enable myapp
otxadmin> disable myapp

5.6.1.2. 統合運用管理ツールを利用した開始と停止

ここでは統合運用管理ツールを利用して、Java EEアプリケーションを開始/停止する手順を説明します。

まず、アプリケーションの開始から説明します。

  1. 統合運用管理ツールの画面左側のツリーから「アプリケーション」を選択し、右クリックします。表示されたメニューから「コンポーネントの開始」をクリックします。


    図5.6.1.2-1

  2. 表示されたダイアログに、開始するアプリケーションの名前を入力します。入力が完了したら「実行」ボタンを押下します。


    図5.6.1.2-2

  3. 開始に成功すると、以下の画面のように成功を示すメッセージが表示されます。


    図5.6.1.2-3

次に、アプリケーションの停止の手順について説明します。

  1. 統合運用管理ツールの画面左側のツリーから「アプリケーション」を選択し、右クリックします。表示されたメニューから「コンポーネントの停止」をクリックします。


    図5.6.1.2-4

  2. 表示されたダイアログに、停止するアプリケーションの名前を入力します。入力が完了したら「実行」ボタンを押下します。


    図5.6.1.2-5

  3. 停止に成功すると、以下の画面のように成功を示すメッセージが表示されます。


    図5.6.1.2-6

5.6.1.3. Web版統合運用管理コンソールを利用した開始と停止

ここではWeb版統合運用管理コンソールを利用して、Java EEアプリケーションを開始/停止する手順を説明します。

まず、アプリケーションの開始から説明します。

  1. Web版統合運用管理コンソールの画面左側のツリーから「アプリケーション」を選択し、右側に表示された「操作」タグを選択します。


    図5.6.1.3-1

  2. 「操作」タグ下のリストから、「コンポーネントの開始」を選択し、「コンポーネント名」に開始するアプリケーションの名前を入力します。入力が完了したら「実行(E)」ボタンを押下します。


    図5.6.1.3-2

  3. 開始に成功すると、以下の画面のように「操作結果」と「ログ詳細」に開始成功を示すメッセージが表示されます。


    図5.6.1.3-3

次に、アプリケーションの停止の手順について説明します。

  1. Web版統合運用管理コンソールの画面左側のツリーから「アプリケーション」を選択し、右側に表示された「操作」タグを選択します。


    図5.6.1.3-4

  2. 「操作」タグ下のリストから、「コンポーネントの停止」を選択し、「コンポーネント名」に停止するアプリケーションの名前を入力します。入力が完了したら「実行(E)」ボタンを押下します。


    図5.6.1.3-5

  3. 停止に成功すると、以下の画面のように「操作結果」と「ログ詳細」に停止成功を示すメッセージが表示されます。


    図5.6.1.3-6

5.6.2. CORBAアプリケーションの開始と停止

ここでは、CORBAアプリケーションの開始と停止について説明します。

5.6.2.1. CORBAアプリケーションの形式

CORBAアプリケーションの形式がR4形式なのかR5形式なのかによって、開始/停止の方法が異なります。

R4形式のCORBAアプリケーションの場合、アプリケーション単位の開始/停止はできません。プロセスグループの開始/停止、あるいはアプリケーショングループの開始/停止により、該当CORBAアプリケーションを開始/停止してください。

R5形式のCORBAアプリケーションの場合は、アプリケーション単位の開始/停止をサポートしています。ただし、アプリケーション単位の開始/停止を行う場合は以下の条件を満たす必要があります。

ただし、アプリケーション単位の開始が成功するためには、そのアプリケーションが属しているプロセスグループが開始している必要があります。

バージョン5のプロセスグループはアプリケーション単位の開始/停止をサポートしていませんので、プロセスグループの開始/停止、あるいはアプリケーショングループの開始/停止により、該当CORBAアプリケーションを開始/停止してください。

5.6.2.2. 安全な停止

使用中のCORBAアプリケーションを停止してしまうと、以後はそのCORBAアプリケーションに対する呼び出しは失敗します。安全にCORBAアプリケーションの停止を行うためには、そのCORBAアプリケーションがクライアントから利用されていないか確認する必要があります。CORBAアプリケーションの利用状況ついては、以下の情報が参考になります。

モジュールアイドル時間が十分に長い場合、そのアプリケーションは利用されていないと判断できます。モジュールアイドル時間が-1の時は、オペレーションが実行中であることを示しています。

統合運用管理ツールを利用する場合、モジュールアイドル時間とモジュールアクティブオブジェクト数は以下の場所で確認できます。


図5.6.2.2-1

Web版統合運用管理コンソールを利用する場合、モジュールアイドル時間とモジュールアクティブオブジェクト数は以下の場所で確認できます。


図5.6.2.2-2

また、運用管理コマンドを利用する場合は、以下のようにします。

otxadmin> get applications.corba-applications.[アプリケーション名].[モジュール名].idleTime
otxadmin> get -m applications.[アプリケーション名].[モジュール名].[インタフェース名].activeObject-Current

具体例を挙げると、アプリケーション名が「myapp」、モジュール名が「corba.jar」、インタフェース名が「loopback」の場合、次のようになります。モジュール名に含まれるピリオド「.」は円マーク「\」でエスケープする必要がある点に注意してください。

otxadmin> get applications.corba-applications.myapp.corba\.jar.idleTime
otxadmin> get -m applications.myapp.corba\.jar.loopback.activeObject-Current

5.6.2.3. コマンドを利用した開始と停止

運用管理コマンドを利用してCORBAアプリケーションを開始/停止する方法について説明します。なお、運用管理コマンドの詳細については運用管理コマンドリファレンスの「enable」、「disable」を参照してください。

アプリケーション単位の開始/停止が可能な場合には、開始するにはオペレーションenableを、停止するにはオペレーションdisableを実行します。

otxadmin> enable アプリケーション名
otxadmin> disable アプリケーション名

具体例を挙げると、アプリケーション名が「myapp」であるCORBAアプリケーションを開始し、その後停止するには、次のようにします。

otxadmin> enable myapp
otxadmin> disable myapp

アプリケーション単位の開始/停止がサポートされていない場合には、プロセスグループあるいはアプリケーショングループの開始/停止を行うことにより、該当CORBAアプリケーションを開始/停止します。プロセスグループの開始/停止にはオペレーションstart-pg/stop-pgを、アプリケーショングループの開始/停止にはオペレーションstart-apg/stop-apgを利用します。

otxadmin> start-pg プロセスグループ名
otxadmin> stop-pg プロセスグループ名
otxadmin> start-apg アプリケーショングループ名
otxadmin> stop-apg アプリケーショングループ名

具体例を挙げます。アプリケーショングループ「apg」、プロセスグループ「pg」に配備されているCORBAアプリケーション「myapp」があるとします。アプリケーショングループを開始することによりアプリケーションを開始し、プロセスグループを停止することによりアプリケーションを停止するには、以下のようにします。

otxadmin> start-apg apg
otxadmin> stop-pg pg

5.6.2.4. 統合運用管理ツールを利用した開始と停止

アプリケーション単位の開始/停止が可能な場合について開始と停止の方法を解説します。アプリケーショングループとプロセスグループの開始/停止の手順については[ 7. WebOTXの内部サービス > 7.1. TPシステム ]を参照してください。

まずCORBAアプリケーションを開始する手順を示します。

  1. 統合運用管理ツールの画面左側のツリーから「アプリケーション」を選択し、右クリックします。表示されたメニューから「コンポーネントの開始」をクリックします。


    図5.6.2.4-1

  2. 表示されたダイアログに、開始するアプリケーションの名前を入力します。入力が完了したら「実行」ボタンを押下します。


    図5.6.2.4-2

  3. 開始に成功すると、以下の画面のように成功を示すメッセージが表示されます。


    図5.6.2.4-3

次に、CORBAアプリケーションを停止する手順について解説します。

  1. 統合運用管理ツールの画面左側のツリーから「アプリケーション」を選択し、右クリックします。表示されたメニューから「コンポーネントの停止」をクリックします。


    図5.6.2.4-4

  2. 表示されたダイアログに、停止するアプリケーションの名前を入力します。入力が完了したら「実行」ボタンを押下します。


    図5.6.2.4-5

  3. 停止に成功すると、以下の画面のように成功を示すメッセージが表示されます。


    図5.6.2.4-6

5.6.2.5. Web版統合運用管理コンソールを利用した開始と停止

アプリケーション単位の開始/停止が可能な場合について解説します。アプリケーショングループとプロセスグループの開始/停止の手順については[ 7. WebOTXの内部サービス > 7.1. TPシステム ]を参照してください。

まずCORBAアプリケーションを開始する手順を示します。

  1. Web版統合運用管理コンソールの画面左側のツリーから「アプリケーション」を選択し、右側に表示された「操作」タグを選択します。


    図5.6.2.5-1

  2. 「操作」タグ下のリストから、「コンポーネントの開始」を選択し、「コンポーネント名」に開始するアプリケーションの名前を入力します。入力が完了したら「実行(E)」ボタンを押下します。


    図5.6.2.5-2

  3. 開始に成功すると、以下の画面のように「操作結果」と「ログ詳細」に開始成功を示すメッセージが表示されます。


    図5.6.2.5-3

次に、CORBAアプリケーションを停止する手順について解説します。

  1. Web版統合運用管理コンソールの画面左側のツリーから「アプリケーション」を選択し、右側に表示された「操作」タグを選択します。


    図5.6.2.5-4

  2. 「操作」タグ下のリストから、「コンポーネントの停止」を選択し、「コンポーネント名」に停止するアプリケーションの名前を入力します。入力が完了したら「実行(E)」ボタンを押下します。


    図5.6.2.5-5

  3. 停止に成功すると、以下の画面のように「操作結果」と「ログ詳細」に停止成功を示すメッセージが表示されます。


    図5.6.2.5-6

5.6.3. OSGiバンドルの開始と停止

この節では、OSGiバンドルの開始と停止について説明します。

5.6.3.1. コマンドを利用した開始と停止

運用管理コマンドを利用してOSGiバンドルを開始/停止する方法について説明します。なお、運用管理コマンドの詳細については運用管理コマンドリファレンスの「enable」、「disable」を参照してください。

OSGiバンドルを開始するにはオペレーションenableを、停止するにはオペレーションdisableを実行します。

otxadmin> enable アプリケーション名
otxadmin> disable アプリケーション名

具体例を挙げると、アプリケーション名が「sample」であるOSGiバンドルを開始し、その後停止するには、次のようにします。

otxadmin> enable sample
otxadmin> disable sample

5.6.3.2. 統合運用管理ツールを利用した開始と停止

ここでは統合運用管理ツールを利用して、OSGiバンドルを開始/停止する手順を説明します。

まず、OSGiバンドルの開始から説明します。

  1. 統合運用管理ツールの画面左側のツリーから「アプリケーション」を選択し、右クリックします。表示されたメニューから「コンポーネントの開始」をクリックします。


    図5.6.3.2-1

  2. 表示されたダイアログに、開始するOSGiバンドルの名前を入力します。入力が完了したら「実行」ボタンを押下します。


    図5.6.3.2-2

  3. 開始に成功すると、以下の画面のように成功を示すメッセージが表示されます。


    図5.6.3.2-3

次に、OSGiバンドルの停止の手順について説明します。

  1. 統合運用管理ツールの画面左側のツリーから「アプリケーション」を選択し、右クリックします。表示されたメニューから「コンポーネントの停止」をクリックします。


    図5.6.3.2-4

  2. 表示されたダイアログに、停止するOSGiバンドルの名前を入力します。入力が完了したら「実行」ボタンを押下します。


    図5.6.3.2-5

  3. 停止に成功すると、以下の画面のように成功を示すメッセージが表示されます。


    図5.6.3.2-6

5.6.3.3. Web版統合運用管理コンソールを利用した開始と停止

ここではWeb版統合運用管理コンソールを利用して、OSGiバンドルを開始/停止する手順を説明します。

まず、OSGiバンドルの開始から説明します。

  1. Web版統合運用管理コンソールの画面左側のツリーから「アプリケーション」を選択し、右側に表示された「操作」タグを選択します。


    図5.6.3.3-1

  2. 「操作」タグ下のリストから、「コンポーネントの開始」を選択し、「コンポーネント名」に開始するOSGiバンドルの名前を入力します。入力が完了したら「実行(E)」ボタンを押下します。


    図5.6.3.3-2

  3. 開始に成功すると、以下の画面のように「操作結果」と「ログ詳細」に開始成功を示すメッセージが表示されます。


    図5.6.3.3-3

次に、OSGiバンドルの停止の手順について説明します。

  1. Web版統合運用管理コンソールの画面左側のツリーから「アプリケーション」を選択し、右側に表示された「操作」タグを選択します。


    図5.6.3.3-4

  2. 「操作」タグ下のリストから、「コンポーネントの停止」を選択し、「コンポーネント名」に停止するOSGiバンドルの名前を入力します。入力が完了したら「実行(E)」ボタンを押下します。


    図5.6.3.3-5

  3. 停止に成功すると、以下の画面のように「操作結果」と「ログ詳細」に停止成功を示すメッセージが表示されます。


    図5.6.3.3-6

5.6.4. 注意事項

5.7. ライフサイクルモジュール

ライフサイクルモジュールについて説明します。

5.7.1. ライフサイクルモジュールとは

ライフサイクルモジュールとは、WebOTX ASの起動・停止のライフサイクルの状態に合わせ実行されるJavaクラスまたはモジュールであり、ユーザが作成した任意のクラスまたはモジュールをライフサイクルモジュールとすることが可能です。

WebOTX ASではライフサイクルの状態管理のために以下の状態を定義しています。ライフサイクルモジュールはこの状態により管理され、WebOTX ASのライフサイクルに同期した処理を実行します。

表5.7.1-1
状態 説明
INIT 初期化処理中であることを表します
STARTUP 起動処理中であることを表します
READY サービス開始処理中であることを表します
SHUTDOWN 停止処理中であることを表します
TERMINATION リソース開放処理中であることを表します

ライフサイクルモジュールが複数登録されている場合は、各ライフサイクルモジュールは並列に処理されます。たとえば、WebOTX ASが初期化の状態であるとき、全てのライフサイクルモジュールの状態はINITであり、全てのライクサイクルモジュールのINITイベントによる処理が終了するまで、次の状態には移行しません。


図5.7.1-1

5.7.2. ライフサイクルモジュール登録の流れ

ライフサイクルモジュールを登録する場合の流れについて説明します。

  1. ライフサイクルモジュールの作成

    登録するコンポーネントとLifecycleListener実装クラスを作成します。登録に必要なファイルは以下のとおりです。


  2. ライフサイクルモジュールの登録

    ライフサイクルモジュールをWebOTX ASに登録します。登録は統合運用管理ツールおよび運用管理コマンドで行なうことができます。

  3. ライフサイクルモジュールの設定

    ライフサイクルモジュールの設定を変更します。この設定はライフサイクルモジュールの登録時にも行うことができます。登録後に設定の変更が必要な場合に行ってください。変更は統合運用管理ツールおよび運用管理コマンドで行なうことができます。

5.7.3. ライフサイクルモジュールの作成

WebOTX ASへのライフサイクルモジュールの登録にはWebOTX ASとライフサイクルモジュールのインタフェースとして、LifecycleListenerインタフェースを実装したクラスを作成する必要があります。

LifecycleListenerインタフェースはPublicメソッドとしてhandleEventを持ちます。WebOTX ASはこのメソッドを呼び出し、LifecycleListener実装クラスに状態情報を保持したLifecycleEventクラスのオブジェクトを渡します。

LifecycleEventクラスは状態情報として以下のpublicかつstaticなフィールドを持ちます。

表5.7.3-1
フィールド名 説明
INIT_EVENT ライフサイクルモジュールの初期化処理中であることを表します
STARTUP_EVENT ライフサイクルモジュールの起動処理中であることを表します
READY_EVENT ライフサイクルモジュールのサービス開始処理中であることを表します
SHUTDOWN_EVENT ライフサイクルモジュールの停止処理中であることを表します
TERMINATION_EVENT ライフサイクルモジュールのリソース開放処理中であることを表します

LifecycleListener実装クラスでは、この状態情報に応じた処理を実装する必要があります。

LifecycleListener実装クラスの実装方法については[ アプリケーション開発ガイド(共通) > 2. ライフサイクルモジュールの開発 ] を参照してください。

5.7.4. 統合運用管理ツールによる登録・登録削除および一覧の取得

統合運用管理ツールよりライフサイクルモジュールの登録・登録削除および一覧を取得する方法について説明します。なお、ここでは以下の条件でライフサイクルモジュールの登録を行っています。

表5.7.4-1
LifecycleListener実装クラス名 sample.SampleLifecycleModule
モジュールとLifecycleListener実装クラスを含むjarファイル名 sample.jar
jarファイル配置位置 Cドライブ直下
ライフサイクルモジュールの登録名 Sample
アプリケーショングループ名 apg
プロセスグループ名 pg

5.7.4.1. 登録

以下の手順で登録します。なお、ここではライフサイクルモジュール名に加え、クラスパスと必須入力項目であるクラス名のみ指定しています。必要に応じて他の設定項目を入力して実行してください。

  1. 統合運用管理ツールよりドメインと接続します。
  2. ツリービューより[アプリケーション]を選択します。
  3. [操作]-[ライフサイクルモジュールの作成]を実行します。
  4. ライフサイクルモジュール名、クラスパス、クラス名を入力し、「OK」ボタンを押します。


    図5.7.4.1-1

    WebOTX AS Standard/Enterpriseにおいて、ライフサイクルモジュールをプロセスグループ上で動作させる場合は、追加で以下の作業も必要になります。

  5. ツリービューより[アプリケーション]を選択します。
  6. [操作]-[プロセスグループへのライフサイクルモジュールを追加]を実行します。
  7. 登録するライフサイクルモジュール名、アプリケーショングループ名、プロセスグループ名を入力し、「OK」ボタンを押します。

5.7.4.2. 登録削除

ドメインからライフサイクルモジュールを登録削除する手順を示します。WebOTX AS Standard/Enterpriseで、登録削除対象のライフサイクルモジュールをプロセスグループへも登録している場合は、先にプロセスグループからライフサイクルモジュールを登録削除する必要がある点に注意してください。

  1. ツリービューより[アプリケーション]を選択します。
  2. [操作]-[ライフサイクルモジュールの削除]を実行します。
  3. 登録削除するライフサイクルモジュール名を入力し、「OK」ボタンを押します。


    図5.7.4.2-1

次に、プロセスグループからライフサイクルモジュールを登録削除する手順を示します。

  1. ツリービューより[アプリケーション]を選択します。
  2. [操作]-[プロセスグループからのライフサイクルモジュールの削除]を実行します。
  3. 登録削除するライフサイクルモジュール名、アプリケーショングループ名、プロセスグループ名を入力し、「OK」ボタンを押します。

5.7.4.3. 一覧の取得

まず、ドメインに登録されたライフサイクルモジュールの一覧を取得する手順を以下に示します。

  1. ツリービューより[アプリケーション]を選択します。
  2. [操作]-[ライフサイクルモジュールの一覧]を実行します。
  3. 「OK」ボタンを押します。WebOTX AS Standard/Enterpriseの場合はアプリケーショングループ名とプロセスグループ名の入力欄が表示されますが、WebOTX AS Expressの場合は、何も入力せずに「OK」ボタンを押してください。

次に、プロセスグループに登録されたライフサイクルモジュールの一覧を取得する手順を以下に示します。こちらはWebOTX AS Standard/Enterpriseでサポートしています。

  1. ツリービューより[アプリケーション]を選択します。
  2. [操作]-[ライフサイクルモジュールの一覧]を実行します。
  3. 一覧を取得したいプロセスグループのアプリケーショングループ名、プロセスグループ名を入力し、「実行」ボタンを押します。


    図5.7.4.3-1

5.7.5. Web版統合運用管理コンソールによる登録・登録削除および一覧の取得

Web版統合運用管理コンソールよりライフサイクルモジュールの登録・登録削除および一覧を取得する方法について説明します。なお、ここでは以下の条件でライフサイクルモジュールの登録を行っています。

表5.7.5-1
LifecycleListener実装クラス名 sample.SampleLifecycleModule
モジュールとLifecycleListener実装クラスを含むjarファイル名 sample.jar
jarファイル配置位置 Cドライブ直下
ライフサイクルモジュールの登録名 Sample
アプリケーショングループ名 apg
プロセスグループ名 pg

5.7.5.1. 登録

以下の手順で登録します。なお、ここではライフサイクルモジュール名に加え、クラスパスと必須入力項目であるクラス名のみ指定しています。必要に応じて他の設定項目を入力して実行してください。

  1. Web版統合運用管理コンソールよりドメインと接続します。
  2. ツリービューより[アプリケーション]を選択します。
  3. [操作]-[ライフサイクルモジュール作成]を選択します。
  4. ライフサイクルモジュール名、クラスパス、クラス名を入力し、「実行(E)」ボタンを押します。


    図5.7.5.1-1

    WebOTX AS Standard/Enterpriseにおいて、ライフサイクルモジュールをプロセスグループ上で動作させる場合は、追加で以下の作業も必要になります。

  5. ツリービューより[アプリケーション]を選択します。
  6. [操作]-[プロセスグループへのライフサイクルモジュールを追加]を選択します。
  7. 登録するライフサイクルモジュール名、アプリケーショングループ名、プロセスグループ名を入力し、「実行(E)」ボタンを押します。

5.7.5.2. 登録削除

ドメインからライフサイクルモジュールを登録削除する手順を示します。WebOTX AS Standard/Enterpriseで、登録削除対象のライフサイクルモジュールをプロセスグループへも登録している場合は、先にプロセスグループからライフサイクルモジュールを登録削除する必要がある点に注意してください。

  1. ツリービューより[アプリケーション]を選択します。
  2. [操作]-[ライフサイクルモジュール削除]を選択します。
  3. 登録削除するライフサイクルモジュール名を入力し、「実行(E)」ボタンを押します。


    図5.7.5.2-1

次に、プロセスグループからライフサイクルモジュールを登録削除する手順を示します。

  1. ツリービューより[アプリケーション]を選択します。
  2. [操作]-[プロセスグループからのライフサイクルモジュールの削除]を選択します。
  3. 登録削除するライフサイクルモジュール名、アプリケーショングループ名、プロセスグループ名を入力し、「実行(E)」ボタンを押します。

5.7.5.3. 一覧の取得

まず、ドメインに登録されたライフサイクルモジュールの一覧を取得する手順を以下に示します。

  1. ツリービューより[アプリケーション]を選択します。
  2. [操作]-[ライフサイクルモジュールの一覧]を選択します。
  3. 「実行(E)」ボタンを押します。WebOTX AS Standard/Enterpriseの場合はアプリケーショングループ名とプロセスグループ名の入力欄が表示されますが、WebOTX AS Expressの場合は、何も入力せずに「実行(E)」ボタンを押してください。

次に、プロセスグループに登録されたライフサイクルモジュールの一覧を取得する手順を以下に示します。こちらはWebOTX AS Standard/Enterpriseでサポートしています。

  1. ツリービューより[アプリケーション]を選択します。
  2. [操作]-[ライフサイクルモジュールの一覧]を選択します。
  3. 一覧を取得したいプロセスグループのアプリケーショングループ名、プロセスグループ名を入力し、「実行(E)」ボタンを押します。


    図5.7.5.3-1

5.7.6. コマンドによる登録・登録削除および一覧の取得

運用管理コマンドよりライフサイクルモジュールコンポーネントの登録および登録削除する方法について説明します。なお、ここでは以下の条件でライフサイクルモジュールの登録を行っています。

表5.7.6-1
LifecycleListener実装クラス名 sample.SampleLifecycleModule
モジュールとLifecycleListener実装クラスを含むjarファイル名 sample.jar
jarファイル配置位置 Cドライブ直下
ライフサイクルモジュールの登録名 Sample
アプリケーショングループ名 apg
プロセスグループ名 pg

5.7.6.1. 登録

ライフサイクルモジュールをドメインに登録するには、登録するコンポーネントとライフサイクルモジュールの初期設定情報を指定して、create-lifecycle-moduleコマンドを実行します。なお、ここではコマンドのオプションとしてclasspathと必須オプションであるclassnameのみ指定しています。必要に応じて他のオプションを指定して実行してください。

otxadmin> create-lifecycle-module -classname sample.SampleLifecycleModule -classpath C:/Sample.jar Sample

WebOTX AS Standard/Enterpriseにおいて、ライフサイクルモジュールをプロセスグループに登録するには、登録するライフサイクルモジュール名、アプリケーショングループ名、プロセスグループ名を指定して、add-pg-lifecycle-moduleコマンドを実行します。

otxadmin> add-pg-lifecycle-module -apgroup apg pgroup pg Sample

5.7.6.2. 登録削除

ライフサイクルモジュールをドメインから登録削除するには、登録削除するライフサイクルモジュール名を指定して、delete-lifecycle-moduleコマンドを実行します。ただし、WebOTX AS Standard/Enterpriseをお使いで、登録削除対象のライフサイクルモジュールをプロセスグループへも登録している場合は、先にプロセスグループからの登録削除を行う必要があります。

otxadmin> delete-lifecycle-module Sample

WebOTX AS Standard/Enterpriseにおいて、ライフサイクルモジュールをプロセスグループから登録削除するには、登録削除するライフサイクルモジュール名、アプリケーショングループ名、プロセスグループ名を指定して、remove-pg-lifecycle-moduleを実行します。

otxadmin> remove-pg-lifecycle-module -apgroup apg -pgroup pg Sample

5.7.6.3. 一覧の取得

ドメインに登録されたライフサイクルモジュールの一覧を取得するには、list-lifecycle-modulesコマンドをオプション指定なしで実行します。

otxadmin> list-lifecycle-modules

WebOTX AS Standard/Enterpriseにおいて、プロセスグループに登録されたライフサイクルモジュールの一覧を取得するには、オプションで一覧を取得したいプロセスグループのアプリケーショングループ名、プロセスグループ名を指定し、list-lifecycle-modulesコマンドを実行します。

otxadmin> list-lifecycle-modules -apgroup apg -pgroup pg

5.7.7. ライフサイクルモジュールの設定

ライフサイクルモジュールはJMX仕様に基づき、WebOTX AS内で管理対象オブジェクト(Managed Object: MO)として登録され、管理されます。

登録されたライフサイクルモジュールは統合運用管理ツールまたは運用管理コマンドからその設定を変更することが可能です。ただし設定の変更を反映させるには、そのライフサイクルモジュールの登録先(ドメイン又はプロセスグループ)を再起動する必要があります。

5.7.7.1. ライフサイクルモジュールMOの設定項目

ライフサイクルモジュールの設定項目についての一覧を以下に示します。なお、MOの詳細については [ リファレンス集 運用管理・設定編 > 2. MO定義リファレンス ] を参照してください。また、設定方法については [ リファレンス集 運用管理・設定編 > 4. 運用管理コマンドリファレンス ] を参照してください。

表5.7.7.1-1
属性名 統合運用管理ツールでの表記 Dotted Name 説明
name 文字列 ライフサイクルモジュール名 server.applications.lifecycle-module.ライフサイクルモジュール名.name ライフサイクルモジュール名です。ここで指定した名前でライフサイクルモジュールをドメインに登録します。ただし、文字列にスペースを混入させることはできません。
class-name 文字列 ライフサイクルモジュールクラス名 server.applications.lifecycle-module.ライフサイクルモジュール名.class-name LifecycleListener実装クラスのクラス名を、パッケージ名を含めて指定します。
classpath 文字列 クラスパス server.applications.lifecycle-module.ライフサイクルモジュール名.classpath ライフサイクルモジュールとして登録するコンポーネントのクラスパスです。クラスパスを複数指定する場合は各パスをWindows OSでは「;」、UNIX系OSでは「:」で区切ってください。また、クラスパスの通っているフォルダ/ディレクトリに格納する場合はクラスパスの指定は不要になります。(例. <INSTANCE_ROOT>/libなど)
load-order 数値 サービス実行順番 server.applications.lifecycle-module.ライフサイクルモジュール名.load-order サーバ起動時に、この起動順序番号に従って各モジュールが順次起動されます。既定ではドメインに登録された順序に従って起動されます。ライフサイクルモジュールの起動順序に依存関係がある場合はこの値を指定する必要があります。
is-failure-fatal true/false サービス起動失敗時動作 server.applications.lifecycle-module.ライフサイクルモジュール名.is-failure-fatal 既定値falseを選択するとドメイン起動時にライフサイクルモジュールの起動処理に失敗した場合でもその起動処理を継続します。trueを選択すると、ライフサイクルモジュールの起動処理に失敗した場合にドメイン(またはプロセスグループ)を停止することができます。詳細は後述の「is-failure-fatalの設定効果について」をご覧ください。
enabled true/false サービス起動設定 server.applications.lifecycle-module.ライフサイクルモジュール名.enabled ライフサイクルモジュールの有効の可否を決定します。
description 文字列 説明 server.applications.lifecycle-module.ライフサイクルモジュール名.description 登録したライフサイクルモジュールに関する説明書き欄です。
property 文字列 (以下で解説) server.applications.lifecycle-module.ライフサイクルモジュール名.property.プロパティ名 ユーザにより定義可能なライフサイクルモジュールの任意のプロパティです。「プロパティ名=値」の形式で指定してください。運用管理コマンドから複数指定する場合はプロパティの組を「:」で繋げてください。

属性propertyはライフサイクルモジュールの「一般」タグ内には表示されません。統合運用管理ツールからpropertyを取得・設定するにはツール上のライフサイクルモジュールの右クリックから「プロパティ一覧の取得」または「プロパティの設定」を実行してください。


図5.7.7.1-1

Web版統合運用管理コンソールの場合、左側のツリービューより作成したライフサイクルモジュールを選択し、「操作」リストの下の「プロパティ一覧の取得」または「プロパティの設定」を選択してください。


図5.7.7.1-2

なお、コマンドからpropertyを取得・設定するにはその他の設定項目同様にget・setコマンドを使用してください。

※is-failure-fatalの設定効果について

ライフサイクルモジュールの設定項目is-failure-fatalをtrueに設定する場合は、同時に次の設定を行ってください。

・ドメインを停止する場合(ドメインに登録されたライフサイクルモジュールに設定が適用されます)

otxadmin> set server.internal-lifecycle-module.LifecycleModuleService.is-failure-fatal=true

・プロセスグループを停止する場合(プロセスグループに登録されたライフサイクルモジュールに設定が適用されます)

otxadmin> set サーバ名.internal-lifecycle-module.LifecycleModuleService.is-failure-fatal=true
Memo
サーバ名は、アプリケーショングループ名とプロセスグループ名を-(ハイフン)でつないだものです。

また、登録されているライフサイクルモジュールが複数ある場合は、そのライフサイクルモジュールのいずれかの起動が失敗すると、その起動順序によっては他のライフサイクルモジュールの起動処理がスキップされることがあります。 この時、各ライフサイクルモジュールの初期化が正常に行われなくなることがあります。例えば、ライフサイクルモジュール間に依存関係があり、登録した全てのライフサイクルモジュールが正常に起動することが前提条件にある場合は、上記の設定を行うことを推奨します。

5.7.7.2. 各プロセス上での有効・無効設定

WebOTX ASでは複数プロセスグループ上でライフサイクルモジュールの機能を提供するため、各プロセスグループ上からはドメインに登録されたライフサイクルモジュールの情報を参照し、設定情報を取得しています。したがって、ドメインに登録された情報への参照の有効・無効を設定することで、プロセスグループごとにライフサイクルモジュールの有効・無効を設定することができます。

以下の図はドメイン上のライフサイクルモジュールの情報を各プロセスグループから参照する場合のイメージです。ただし、ここでは各プロセスグループを表すのにアプリケーショングループ名とプロセスグループ名を-(ハイフン)でつないだサーバ名で表しています。


図5.7.7.2-1

参照の有効・無効設定を行うには、運用管理コマンドから以下の手順で変更します。

otxadmin> set サーバ名.application-ref.ライフサイクルモジュール名.enabled=true

または

otxadmin> set サーバ名.application-ref.ライフサイクルモジュール名.enabled=false

5.8. 配備チューニング

この章では主に配備処理を高速化する方法について解説します。アプリケーションの開発時には、配備/配備解除が頻繁に繰り返されるため、配備処理の高速化を意識することで開発効率が向上します。

5.8.1. EJBのメソッド識別情報の割り当て抑止(Standard/Enterprise)

TPモニタでは、オペレーション毎にトランザクション等の実行時情報を管理する機能を備えています。あるモジュールが配備されると、TPモニタでは個々のオペレーションを識別するために番号を付与して、内部管理テーブルと状態情報との関連付けを行います。EJBモジュールの場合には、オペレーションがリモートインタフェースのメソッドに該当します。

メソッド識別情報の割り当て範囲を限定することにより、配備処理中に行われる識別情報の生成数を削減し、配備処理にかかる時間の短縮およびメモリ消費量の削減が可能です。

5.8.1.1. オプション

割り当て方法は以下の中から選択できます。

表5.8.1.1-1
メソッド名 ステートレスSession Bean ステートフルSession Bean Entity Bean メッセージドリブンBean
リモートインタフェース
getEJBHome() × × × -
getPrimaryKey() × × × -
getHandle() × × × -
isIdentical(javax.ejb.EJBObject) × × × -
remove() × -
ホームインタフェース
getEJBMetaData() × × × -
getHomeHandle() × × × -
remove(java.lang.Object) × × -
remove(javax.ejb.Handle) × -
[EJB生成メソッド](例:create()メソッド) × -
[ファインダメソッド](例:findByPrimaryKey(String)メソッド) - - -
凡例
割り当てます
× 割り当てません
- 存在しません

(注:メッセージドリブンBeanのonMessage()メソッド、タイマーBeanのejbTimeout()メソッドについてはリモートメソッドではありませんが、どのオプションでも割り当てられます。)

識別情報を割り当てなかったメソッドに対しては以下の機能が使用できなくなります。

しかしながら、割り当てるメソッド数を減らすことにより、モジュールの配備時間が向上し、消費メモリ量が削減されます。

注意:「割り当てない」オプションを使用すると障害発生時の原因解析が困難になる場合があります。頻繁に配備/配備解除を繰り返す開発時には有用ですが、本番環境では「ビジネスメソッドのみ割り当てる」もしくは「全てのリモートメソッドに対して割り当てる」を使用することを強く推奨します。

5.8.1.2. 指定方法

これらのオプションの指定は、EJBモジュールを配備操作する時に行います。以下では、配備操作を支援する機能毎に説明します。

統合運用管理ツール

コンポーネント配備ダイアログの「EJBメソッド識別情報の割り当て方法」で設定します。

運用管理コマンド

deploy サブコマンドに「--methodid」オプションを指定します。

表5.8.1.2-1
--methodid all 全てのリモートメソッドに対して割り当てる
--methodid limit ビジネスメソッドのみ割り当てる (既定値)
--methodid none 割り当てない
オートデプロイ (自動配備)

ドメインのautodeployディレクトリ下のautodeploy.propertiesファイルで以下の指定をします。

表5.8.1.2-2
methodid=all 全てのリモートメソッドに対して割り当てる
methodid=limit ビジネスメソッドのみ割り当てる (既定値)
methodid=none 割り当てない

5.9. クラスローダ

この章では、WebOTX AS が利用するクラスローダについて解説します。クラスローダについての知識は、アプリケーションが共通に利用するクラスファイルやJar ライブラリの配置場所を決定する際に役立ちます。

5.9.1. クラスローダの階層

クラスローダは階層構造になっており、この階層構造に従ってクラスをロードします。Java VM 等からクラスのロードの要求があった場合、クラスローダはまず親のクラスローダにクラスのロード処理を委譲します。親のクラスローダでクラスがロードできなかった場合、そのクラスローダ自身でクラスをロードしようとします。それでもクラスが見つからない場合、NoClassDefFoundError またはClassNotFoundException がスローされます。WebOTX ASのクラスローダについて理解しておくことは、開発者や運用者がアプリケーション共通で使うJARアーカイブやアプリケーション・モジュールのためのリソース・ファイルを、どの位置に配置すべきかを決める際に重要な助けとなります。

WebOTX AS で利用しているクラスローダの階層を以下の図に示します。


図5.9.1-1

ブートストラップクラスローダからApplibsクラスローダまでは、同一Java VM 内で共通に利用するクラスローダです。破線で囲まれたクラスローダは、アプリケーションをロードするクラスローダです。WAR、EJB、EAR、ライフサイクルモジュールはクラスローダによって分離されているため、お互い干渉することなく動作することができます。RAR は他のアプリケーションから利用されるという性質上、コネクタクラスローダはドメイン内で共通に利用されます。Applibsクラスローダはドメイン内で共通ですが、アプリケーションからは配備時に指定したライブラリのみ参照可能です。また、共有コンポーネントクラスローダは、WebOTX AS Standard/Enterpriseで利用されます。

一般に、下位のクラスローダでロードしたクラスは上位のクラスローダでロードしたクラスを参照できますが、その逆はできません。つまり、上位のクラスローダでロードしたクラスは、下位のクラスローダでロードしたクラスを参照できず、NoClassDefFoundErrorまたはClassNotFoundExceptionの原因となります。アプリケーションを構築する上で、この原則に従うようにライブラリを配置する必要があります。

5.9.2. 同一 Java VM 内で共通に利用するクラスローダ

ここでは、ブートストラップクラスローダから共有コンポーネントクラスローダまでを解説します。同一Java VM 内で動作するすべてのアプリケーションは、これらのクラスローダを共有します。これらのクラスローダがロードする対象についての概要図を、以下の図に示します。


図5.9.2-1

図中の鍵括弧で囲まれた部分は、以下のパスを示しています。

[JAVA_HOME]

JDK のインストール先を示しています。

[WEBOTX]

WebOTX AS のインストール先を示しています。デフォルトのインストール先は、以下の通りです。

表5.9.2-1
OS パス
Windows C:\WebOTX
UNIX系 /opt/WebOTX
[DOMAIN]

WebOTX AS で利用するドメインのパスを示しています。デフォルトのドメインを利用する場合は、以下のパスになります。

表5.9.2-2
OS パス
Windows C:\WebOTX\domains\domain1
UNIX系 /opt/WebOTX/domains/domain1

以降では、これらのクラスローダの詳細を解説します。

5.9.2.1. ブートストラップクラスローダ

このクラスローダは、Java の標準のクラスライブラリをロードするクラスローダです。ブートストラップクラスローダに親のクラスローダはありません。ブートストラップクラスローダは、以下のJar ファイルから標準のクラスライブラリを読み込みます。

[JAVA_HOME]/jre/lib/*.jar

このパスはJDK 依存のパスであり、JDK のバージョンやJDK のベンダによって異なる可能性があります。

5.9.2.2. 拡張クラスローダ

このクラスローダは、Java の拡張機能を読み込むクラスローダです。拡張クラスローダの親クラスローダはブートストラップクラスローダです。拡張クラスローダは、以下のJar ファイルから拡張機能を実装しているクラスライブラリを読み込みます。

[JAVA_HOME]/jre/lib/ext/*.jar
[DOMAIN]/lib/ext/*.jar

[JAVA_HOME]/jre/lib/extには、JDK が標準で提供する拡張機能のJar ライブラリが配置されています。このパスはJDK 依存のパスであり、JDK のバージョンやJDK のベンダによって異なる可能性があります。

[DOMAIN]/lib/ext にJarライブラリを配置すると、WebOTX AS に対して拡張機能を提供することができます。アプリケーションでJDBC ドライバを利用する場合、このディレクトリにJDBC ドライバを格納したJar ライブラリを配置する必要があります。

拡張クラスローダの詳細については、以下のJDK のマニュアルを参照してください。

The Java Extension Mechanism (英語)

http://docs.oracle.com/javase/6/docs/technotes/guides/extensions/

Java 拡張機能機構 (日本語)

http://docs.oracle.com/javase/jp/6/technotes/guides/extensions/

5.9.2.3. システムクラスローダ

システムクラスローダは、WebOTX AS本体の起動に必要なライブラリのみをロードします。システムクラスローダの親クラスローダは拡張クラスローダです。

エージェントプロセスでは、domain.xmlの設定を変更することで、ユーザ定義のクラスをシステムクラスローダで読み込ませることができます。 ただし、この設定を正しく行うためにはWebOTX ASへの深い知識が必要になりますので、通常は共通クラスローダもしくは拡張クラスローダを利用してユーザ定義のクラスライブラリをロードします。

また、アプリケーション用のクラスローダは、システムクラスローダを親に持たないため、システムクラスローダのクラスパスに含まれるクラスやリソースをアプリケーション用のクラスローダから参照することはできません。WebOTX V8までの環境でclasspath-suffixや環境変数CLASSPATHを使用してユーザ定義のライブラリをロードしていた場合は、jarファイルを[DOMAIN]/lib/に置くか、server-classpathを使用することで、[5.9.2.5. 共通クラスローダ] でロードするように設定してください。

system-classpath

domain.xml 中の要素<java-config>の属性system-classpathで指定したクラスパスは、WebOTX AS本体の起動に必要なライブラリの後に読み込まれます。デフォルトではこの属性には何も指定されていません。

環境変数CLASSPATH

domain.xml 中の要素<java-config>で属性env-classpath-ignored="false"の指定があった場合、環境変数CLASSPATH で指定されたクラスパスを読み込みます。環境変数CLASSPATHは、要素<java-config>の属性system-classpathで指定したクラスパスの後に読み込まれます。デフォルトでは属性env-classpath-ignored="true"が設定されており、環境変数CLASSPATHは読み込まれません。

WebOTX V8まで存在した属性classpath-prefixおよびclasspath-suffixは、WebOTX V9で廃止されました。また、WebOTX V8までシステムクラスローダのクラスパスを指定するために使用されていた属性server-classpathは、WebOTX V9では、後述の共通クラスローダのクラスパスを指定するために使用されます。

まとめると、エージェントプロセスのシステムクラスローダでは以下の順でクラスパスを検索します。

  1. WebOTX AS本体の起動に必要なライブラリ
  2. domain.xml 中で属性system-classpathに指定したクラスパス
  3. 環境変数CLASSPATH (env-classpath-ignored="false"の場合)

一方プロセスグループにおいては、domain.xml 中のsystem-classpath等の設定は反映されません。これらのクラスパスに関する設定は、エージェントプロセスに対するものだからです。プロセスグループでは、そのプロセスグループに対して環境変数CLASSPATH を設定することで、システムクラスローダにクラスパスを追加することができます。設定の反映には、アプリケーショングループの再起動が必要になります。統合運用管理ツールでの設定場所を、以下の図に示します。


図5.9.2.3-1

まとめると、プロセスグループのシステムクラスローダは、以下の順でクラスパスを検索します。

  1. WebOTX AS本体の起動に必要なライブラリ
  2. 環境変数CLASSPATH (もし設定されていれば)

5.9.2.4. パブリックAPIクラスローダ

パブリックAPIクラスローダは、配備されたアプリケーション用にWebOTXが明示的にエクスポートしているクラスを使用可能にします。この中には、Java EE APIなどが含まれます。パブリックAPIクラスローダの親クラスローダは拡張クラスローダです。パブリックAPIクラスローダは、以下の場所からクラスライブラリを読み込みます。

  1. [WEBOTX]/modules/*.jar
  2. 配備されたOSGiバンドル

[WEBOTX]/modules/にはWebOTXの動作に必要なJarファイルが配置されています。ここに配置されたファイルの構成を変更する事はサポート対象外であり、このディレクトリにユーザ定義のJarを配置してはいけません。

5.9.2.5. 共通クラスローダ

共通クラスローダは、ドメイン内で動作するアプリケーションで共通に利用するクラスをロードします。共通クラスローダの親クラスローダはパブリックAPIクラスローダです。

共通クラスローダは、以下の場所からクラスライブラリを読み込みます。

  1. [WEBOTX]/lib/*.jar
  2. [DOMAIN]/lib/classes
  3. [DOMAIN]/lib/*.jar

[WEBOTX]/lib/にユーザ定義のJarを配置することは、サポート対象外です。 [DOMAIN]/lib/classesには、ドメイン内で共通に利用するクラスのクラスファイルを配置します。[DOMAIN]/libには、ドメイン内で共通に利用するクラスが格納されているJarファイルを配置します。

上記の位置に複数のアプリケーションで共通に利用するライブラリを配置すると、WAR ファイルやEARファイルの中にライブラリを含める必要がなくなります。ただし、共通するライブラリをバージョンアップ等の理由で置換すると、そのライブラリを利用する全てのアプリケーションが影響を受けます。また、ライブラリを追加・削除・置換する際には、ドメインを再起動する必要があります。

domain.xmlのserver-classpathの設定を変更することで、ユーザ定義のクラスを共通クラスローダで読み込ませることができます。この設定は、エージェントプロセスとプロセスグループの両方で有効です。

server-classpath

domain.xml中の要素<java-config>の属性server-classpathで指定したクラスパスは、[DOMAIN]/lib/*.jarの後に読み込まれます。デフォルトではこの属性には何も指定されていません。

5.9.2.6. 共有コンポーネントクラスローダ

このクラスローダは、WebOTX AS Standard/Enterpriseで利用可能であり、配備した共有コンポーネントをロードするクラスローダです。共有コンポーネントクラスローダの親クラスローダは共通クラスローダです。

共有コンポーネントの更新を行なう場合は、その共有コンポーネントを利用している全てのアプリケーションを停止すればよく、プロセスグループの再起動は必要ありません。そのため、その他の動作中のアプリケーションに影響を及ぼすことなく、ライブラリの更新が可能です。

5.9.3. コネクタクラスローダ

コネクタクラスローダはJCAに準拠したリソースアダプタを読み込むためのクラスローダです。 コネクタクラスローダの親クラスは共有コンポーネントクラスローダです。 EARに含まれていないスタンドアローンのリソースアダプタはコネクタクラスローダでロードされます。EARに含まれているリソースアダプタは、後述のEAR内部コネクタクラスローダでロードされます。 リソースアダプタは他のアプリケーションから利用されるという性質上、コネクタクラスローダはドメイン内で共有されます。

以下の図では、例として二つのリソースアダプタlegacy-ra.rarmain-frame-ra.rarを配備した状態のコネクタクラスローダの概要図を示します。


図5.9.3-1

最上位のブートストラップクラスローダから最下位のコネクタクラスローダまで、6つのクラスローダが関係しています。 クラスをロードする優先順位は1位のブートストラップクラスローダから始まり、コネクタクラスローダは最後の6位になります。 コネクタクラスローダはlegacy-ra.rarmain-frame-ra.rarを読み込みますが、これらのファイルに含まれるJarライブラリもロードの対象になります。

スタンドアローンのリソースアダプタは、Java EE 5では、全てのアプリケーションから参照可能でしたが、Java EE 6(JCA1.6)では、アプリケーションの配備記述子やアノテーションなどで指定したリソースアダプタのみが参照可能に変更されました。domain.xmlの以下の設定を変更することで、Java EE 5とJava EE 6のいずれに準拠した動作となるか設定できます。

class-loading-policy

domain.xml中の要素<connector-service>の属性class-loading-policyに、"derived"を指定するとJava EE 6に準拠した動作となり、アプリケーションからは指定したリソースアダプタのみが参照可能になります。"global"を指定するとJava EE 5に準拠した動作になり、全てのリソースアダプタがアプリケーションから参照可能になります。デフォルトは、"derived"で、Java EE 6に準拠した動作になります。

class-loading-policyの値をotxadminコマンドで変更するには、以下のコマンドを実行します。(コマンド例は"global"に設定する場合)

otxadmin> set server.connector-service.class-loading-policy=global

設定値を確認するには、以下のコマンドを実行します。

otxadmin> get server.connector-service.class-loading-policy

5.9.4. Applibsクラスローダ

EJB/WAR/EAR/RARで利用されるクラスローダです。 配備時に指定されたアプリケーション固有のライブラリを読み込みます。 ライブラリは[DOMAIN]/lib/applibsに配置し、配備時には[DOMAIN]/lib/applibsからの相対パスでライブラリを指定します。 アプリケーション固有のライブラリは、他のアプリケーションと共有されますが、配備時に指定したライブラリしか参照できません。

なお、Applibsクラスローダでロードされる jar ファイルのクラスは、Applibsクラスローダでロードされる他の jar ファイルのクラスやリソースを参照することはできません。

otxadminコマンドでは、以下のように指定します。

otxadmin> deploy --libraries [ライブラリのパス] [アーカイブ]

以降のWAR、EJB、EARのクラスローダの解説では、説明の便宜上mylib.jarをアプリケーション固有のライブラリに指定して配備したとします。 例えば、otxadminコマンドを利用した配備では、以下のようにして配備したとします。

otxadmin> deploy --libraries mylib.jar [アーカイブ]

5.9.5. スタンドアロンの WAR

スタンドアロンのWAR(すなわちEAR に含まれていないWAR)のクラスローダの構成を、下の図に示します。


図5.9.5-1

WAR のクラスローダは、Servlet 用のWebApp クラスローダとJSP 用のJSPクラスローダに分かれています。 JSP は実行時に動的にServletに変換されるために、このような構造になっています。 最上位のブートストラップクラスローダから最下位のJSP クラスローダまで、9つのクラスローダが関係しています。

Servlet を読み込むWebAppクラスローダは、/WEB-INF/classesに配置したクラスファイルと/WEB-INF/libに配置したJarライブラリを読み込みます。 一方JSP を読み込むJSPクラスローダは、/WEB-INFおよび/META-INF以外のディレクトリに配置されているJSPを読み込みます。

5.9.5.1. クラスのロード処理の優先順位の制御

WebApp クラスローダは、クラスのロード処理を親クラスローダに委譲するタイミングを、以下の2 つから選択できます。

(1) 親クラスローダ優先。まず親クラスローダにクラスのロードを委譲し、見つからなかった場合にWebApp クラスローダでロード。
(2) WebApp クラスローダ優先。まずWebApp クラスローダでクラスのロードを試みて、見つからなかった場合に親クラスローダにクラスのロードを委譲。

「(1)親クラスローダ優先」は他のクラスローダでも採用されている一般的なクラスの探索方法であり、親のクラスローダでロードするクラスを優先的に利用します。(2)はWebApp クラスローダ特有の探索方法であり、WebApp クラスローダがロードするクラスを優先的に利用します。すなわち(2)を採用した場合、Servlet は上位のクラスローダがロードするクラスをWEB-INF/classesまたはWEB-INF/libにあるクラスで置換することができます。

ロード処理の優先順位の制御は、WEB-INF/nec-web.xml中の要素<class-loader>の属性delegateで指定します。

<?xml version="1.0" encoding="UTF-8"?>
<nec-web-app>
    <context-root>myapp</context-root>
    <class-loader delegate="true"/>
</nec-web-app>

属性delegate="true"の場合は、「(1) 親クラスローダ優先」となり、属性delegate="false"の場合は、「(2) WebApp クラスローダ優先」となります。要素<class-loader>を省略した場合や、WEB-INF/nec-web.xmlそのものを省略した場合の属性delegateのデフォルト値は、Servlet のバージョンによって異なります。Servlet 2.4 では属性delegate のデフォルト値は"true"であり、Servlet 2.3 以前では"false"です。

以降では、属性delegateの値別に、クラスのロードの具体的な動作を解説します。

5.9.5.2. 属性delegate="true"の場合のクラスローダの動作

ここでは、属性delegate="true"の場合のクラスローダの動作について説明します。

まずServlet の視点から解説します。クラスローダのロード処理順の概要図を以下に示します。 Servlet の視点では、JSPクラスローダはクラスのロード処理に関与しない点に注意してください。


図5.9.5.2-1

WebApp クラスローダがServlet等のクラスをロードする際、まず親クラスローダであるApplibsクラスローダにクラスのロード処理を委譲します。 Applibsクラスローダを含む上位のクラスローダも、通常どおり先に親クラスローダに処理を委譲します。 そのため優先順位の最も高いクラスローダはブートストラップクラスローダであり、最も優先順位の低いクラスローダはWebAppクラスローダで、優先順位8位になります。

次にJSP の視点から解説します。クラスローダのロード処理順の概要図を以下に示します。


図5.9.5.2-2

JSPクラスローダはJSP のみをロードする特別なクラスローダです。JSPクラスローダに対してロード要求があった場合、まずJSPクラスローダ自身でJSPのロードを試みます。 従って、JSPクラスローダが優先順位1位になります。 ロード対象がJSP ではない場合、親クラスローダであるWebAppクラスローダにクラスのロード処理を委譲します。 WebAppクラスローダを含む上位のクラスローダも、通常どおり先に親クラスローダにロード処理を委譲します。 そのためブートストラップクラスローダが優先順位2位です。最も優先順位の低いクラスローダは優先順位9位のWebAppクラスローダです。

5.9.5.3. 属性delegate="false"の場合のクラスローダの動作

ここでは、属性delegate="false"の場合のクラスローダの動作について説明します。

まずServlet の視点から解説します。クラスローダのロード処理順の概要図を以下に示します。 Servlet の視点では、JSPクラスローダは無関係である点に注意してください。


図5.9.5.3-1

WebApp クラスローダがServlet 等のクラスをロードする際、まずWebAppクラスローダ自身でクラスのロードを試みます。 従って、WebApp クラスローダは優先順位1位になります。 WebAppクラスローダでクラスをロードできなかった場合は、親クラスローダであるApplibsクラスローダにクラスのロード処理を委譲します。 Applibsクラスローダを含む上位のクラスローダは、通常どおり先に親クラスローダに処理を委譲します。 そのためブートストラップクラスローダが優先順位2位となり、Applibsクラスローダは優先順位8位になります。

次にJSP の視点から解説します。クラスローダのロード処理順の概要図を以下に示します。


図5.9.5.3-2

JSP クラスローダはJSP のみをロードする特別なクラスローダです。 JSPクラスローダに対してロード要求があった場合、まずJSP クラスローダ自身でJSP のロードを試みます。 従って、JSPクラスローダが優先順位1位になります。 ロード対象がJSP ではない場合、親クラスローダであるWebAppクラスローダにクラスのロード処理を委譲します。 WebAppクラスローダは親クラスローダにロード処理を委譲する前に、自身でクラスのロードを試みます。 従って、WebApp クラスローダは優先順位2位になります。 WebAppクラスローダでクラスをロードできなかった場合は、親クラスローダであるApplibsクラスローダにクラスのロード処理を委譲します。 Applibsクラスローダを含む上位のクラスローダは、通常どおり先に親クラスローダに処理を委譲します。 そのためブートストラップクラスローダが優先順位3位となり、Applibsクラスローダは優先順位9位になります。

5.9.6. スタンドアロンの EJB

スタンドアロンのEJB(すなわちEARに含まれていないEJB)のクラスローダの構成を、以下の図に示します。 以下の図は、例としてbackend-ejb.jarを配備したときのEJB クラスローダの概要図です。


図5.9.6-1

最上位のブートストラップクラスローダから最下位のEJB クラスローダまで、8つのクラスローダが関係しています。 EJBクラスローダを利用してクラスをロードする場合、まず親クラスローダであるApplibsクラスローダにロード処理を委譲します。 Applibsクラスローダを含む上位のクラスローダも、通常どおり先に親クラスローダに処理を委譲します。 そのため優先順位の最も高いクラスローダはブートストラップクラスローダであり、最も優先順位の低いクラスローダはEJBクラスローダで、優先順位8位になります。

5.9.7. EAR のクラスローダ

EAR はWAR、EJB、RARを含むことのできる、「アプリケーションのとりまとめ」のような役割を担っています。 そのため、クラスローダの構成も、他のアプリケーションと比べると複雑になっています。 ここでは以下のようなEAR(app.ear)を例に挙げ、解説を行います。

まとめると、app.earは以下のような構成になります。

app.ear
    META-INF/application.xml
    web-app.war (delegate="true"、Class-Path: lib/common.jar)
    other-web-app.war (delegate="false")
    backend-ejb.jar (Class-Path: lib/utilities.jar)
    legacy-ra.rar
    lib/common.jar
    lib/utilities.jar

5.9.7.1. クラスローダの構成

app.earを配備した際のクラスローダの構成を以下の図に示します。


図5.9.7.1-1

EAR のクラスローダは、以下のクラスローダから構成されます。

Applibsクラスローダ

[DOMAIN]/lib/applibs配下の指定したJarをロードするクラスローダです。 Applibsクラスローダの親クラスローダはコネクタクラスローダです。

EAR Libクラスローダ

EAR内のlibディレクトリにあるライブラリをロードするクラスローダです。このライブラリは、EAR内の全てのモジュールから参照可能です。ディレクトリは配備記述子(application.xml)の要素<library-directory>で指定できます(デフォルト値はlib)。EAR Libクラスローダの親クラスローダはApplibsクラスローダです。

EAR内部コネクタクラスローダ

EAR内のRARをロードするクラスローダです。EAR内部コネクタクラスローダの親クラスローダはEAR Libクラスローダです。

WebOTX V8では、EAR内のRARもドメイン内で共通のコネクタクラスローダでロードされており、他のアプリケーションからも利用可能でしたが、WebOTX V9ではJava EE 6の仕様に準拠するために、EAR内のRARは他のアプリケーションからは利用できないように変更されました。

EJB クラスローダ

EJB をロードするクラスローダです。 EJB クラスローダの親クラスローダはEAR内部コネクタクラスローダです。 EAR内に含まれるEJB の数とは関係なく、必ず1 つだけ存在します。EJB クラスローダは、EJBだけではなく、マニフェストファイルの属性Class-Pathで指定したライブラリもロードの対象とします。

WebApp クラスローダ/JSP クラスローダ

WAR をロードするクラスローダです。EAR 内に含まれるWAR の数だけ存在します。WebApp クラスローダの親クラスローダはEJB クラスローダです。WebApp クラスローダとJSP クラスローダは対になっており、JSP クラスローダの親クラスローダは、それと対のWebApp クラスローダです。

5.9.7.2. EAR 内で共通に利用するJar ライブラリの配置

EAR の中には、WAR やEJB で共通に利用するライブラリを含めることができます。 Java EE 5以降に準拠したEARでは、EAR内のlibというディレクトリにJarを配置してください。


図5.9.7.2-1

J2EE 1.4以前に準拠したEARでは、単にEARに含めるだけではロードの対象にはなりません。 そのライブラリを利用するWAR やEJBのマニフェストファイルの属性Class-Pathにライブラリのパスを記述する必要があります。 ライブラリのパスは、EARファイルのトップディレクトリからの相対パスでなければいけません。 例えば、web-app.warlib/common.jarを利用するために、web-app.warに次のようなマニフェストファイルを含めます。

Manifest-Version: 1.0
Created-By: 1.5.0_18-b02 (Sun Microsystems Inc.)
Class-Path: lib/common.jar

EAR内で共通に利用するライブラリに着目したapp.earのクラスローダの構成図を以下に示します。 J2EE 1.4以前のEARでは、図にある通りマニフェストファイルにライブラリのパスを記述する必要があります。


図5.9.7.2-2

EJBでのマニフェストファイルの属性Class-Pathの利用には副作用がある点に注意してください。 EJBのマニフェストファイルの属性Class-Pathに記述したライブラリはEJBクラスローダでロードされるため、その属性を持たないアプリケーションでも利用可能になります。 例えば、other-web-app.warはマニフェストファイル中に属性Class-Pathを持ちませんが、親クラスローダであるEJBクラスローダがlib/utilities.jarをロードしているため、これらのライブラリを利用することができます。

5.9.7.3. WAR からの視点(delegate="true")

ここではWEB-INF/nec-web.xml<class-loaderdelegate="true"/>を含んでいるweb-app.warについてのクラスローダの動作を説明します。 すなわち、WebAppクラスローダはクラスのロード処理を親クラスローダに優先的に委譲します。 また、もう一つのWARであるother-web-app.warのクラスローダは、クラスのロード処理に関与しない点に注意してください。

まずServlet の視点から解説します。クラスローダのロード処理順の概要図を以下に示します。 Servletの視点では、JSPクラスローダはクラスのロードに関与しません。


図5.9.7.3-1

WebAppクラスローダがServlet等のクラスをロードする際、まず親クラスローダであるEJBクラスローダにクラスのロード処理を委譲します。 EJBクラスローダを含む上位のクラスローダも、通常どおり先に親クラスローダに処理を委譲します。 そのため優先順位の最も高いクラスローダはブートストラップクラスローダであり、最も優先順位の低いクラスローダはWebAppクラスローダで、優先順位11位になります。

次にJSP の視点から解説します。クラスローダのロード処理順の概要図を以下に示します。


図5.9.7.3-2

JSP クラスローダはJSP のみをロードする特別なクラスローダです。 JSPクラスローダに対してロード要求があった場合、まずJSP クラスローダ自身でJSP のロードを試みます。 従って、JSPクラスローダが優先順位1位になります。 ロード対象がJSP ではない場合、親クラスローダであるWebAppクラスローダにクラスのロード処理を委譲します。 WebAppクラスローダを含む上位のクラスローダも、通常どおり先に親クラスローダにロード処理を委譲します。 そのためブートストラップクラスローダが優先順位2位となり、WebApp クラスローダは優先順位12位になります。

5.9.7.4. WARからの視点(delegate="false")

ここではWEB-INF/nec-web.xml<class-loaderdelegate="false"/>を含んでいるother-web-app.warについてのクラスローダの動作を説明します。 すなわち、WebAppクラスローダはクラスのロード処理を優先的に自身で行い、クラスが見つからなかった場合に親クラスローダに処理を委譲します。 また、もう一つのWARであるweb-app.warのクラスローダは、クラスのロード処理に関与しない点に注意してください。

まずServletの視点から解説します。 クラスローダのロード処理順の概要図を以下に示します。 Servlet の視点では、JSPクラスローダはクラスのロードに関与しません。


図5.9.7.4-1

WebApp クラスローダがServlet 等のクラスをロードする際、まずWebAppクラスローダ自身でクラスのロードを試みます。 従って、WebApp クラスローダは優先順位1位になります。 WebAppクラスローダでクラスをロードできなかった場合は、親クラスローダであるEJB クラスローダにクラスのロード処理を委譲します。 EJBクラスローダを含む上位のクラスローダは、通常どおり先に親クラスローダに処理を委譲します。 そのためブートストラップクラスローダが優先順位2位となり、EJB クラスローダは優先順位11位になります。 EJB クラスローダでもクラスをロードできなかった場合はWebAppクラスローダに処理が戻りますが、WebAppクラスローダは既にロード処理を試みているために何もせず、従ってクラスがロードできなかったという結果になります。

次にJSP の視点から解説します。クラスローダのロード処理順の概要図を以下に示します。


図5.9.7.4-2

JSP クラスローダはJSP のみをロードする特別なクラスローダです。 JSPクラスローダに対してロード要求があった場合、まずJSP クラスローダ自身でJSP のロードを試みます。 従って、JSPクラスローダが優先順位1位になります。 ロード対象がJSP ではない場合、親クラスローダであるWebAppクラスローダにクラスのロード処理を委譲します。 WebAppクラスローダは親クラスローダにロード処理を委譲する前に、自身でクラスのロードを試みます。 従って、WebAppクラスローダは優先順位2位になります。 WebApp クラスローダでクラスをロードできなかった場合は、親クラスローダであるEJBクラスローダにクラスのロード処理を委譲します。 EJBクラスローダを含む上位のクラスローダは、通常どおり先に親クラスローダに処理を委譲します。 そのためブートストラップクラスローダが優先順位3位となり、EJBクラスローダは優先順位12位になります。

5.9.7.5. EJB からの視点

ここではEJB の視点からEJB クラスローダの動作を説明します。 EJBクラスローダの動作の概要図を以下に示します。


図5.9.7.5-1

EJBの視点では、WebAppクラスローダとJSPクラスローダはクラスのロード処理に関与しない点に注意してください。 EJBクラスローダを利用してクラスをロードする場合、まず親クラスローダであるEAR内部コネクタクラスローダにロード処理を委譲します。 EAR内部コネクタクラスローダを含む上位のクラスローダも、通常どおり先に親クラスローダに処理を委譲します。 そのため優先順位の最も高いクラスローダはブートストラップクラスローダであり、最も優先順位の低いクラスローダはEJBクラスローダで、優先順位10位になります。

5.9.7.6. RAR からの視点

ここではRAR の視点からEAR内部コネクタクラスローダの動作を説明します。EAR内部コネクタクラスローダの動作の概要図を以下に示します。


図5.9.7.6-1

RAR の視点では、EJBクラスローダ、WebApp クラスローダ、JSPクラスローダはクラスのロード処理に関与しない点に注意してください。 EAR内部コネクタクラスローダを利用してクラスをロードする場合、まず親クラスローダであるEAR Libクラスローダにロード処理を委譲します。 EAR Libクラスローダを含む上位のクラスローダも、通常どおり先に親クラスローダに処理を委譲します。 そのため優先順位の最も高いクラスローダはブートストラップクラスローダであり、最も優先順位の低いクラスローダはEAR内部コネクタクラスローダで、優先順位9位になります。

5.9.8. ライブラリの配置計画

共通クラスローダでロード

最も一般的な、ライブラリの共有方法です。 配置したライブラリは、WebOTX ASに配備した全てのアプリケーションで利用できます。 ただしライブラリを更新する場合、そのライブラリを利用している全てのアプリケーションが影響を受けるという点に注意する必要があります。 ライブラリの置換を行う場合は、WebOTX AS の再起動が必要になります。

アプリケーションのアーカイブに含める

ライブラリを共有せずに、個別にアプリケーションのアーカイブに含めます。 他のアプリケーションに影響を与えることなく利用するライブラリを更新できるメリットがあります。 ただしライブラリを更新するためには、アプリケーションの再配備が必要になります。 さらにアプリケーションの形式がEARの場合は、利用するライブラリをEAR 内で共通とするか、WAR 等で個別に持つかを決定する必要があります。 EJBの呼び出しで引数や戻り値として利用するクラスは、必ずEAR 内で共通のライブラリとして配置する必要があります。

アプリケーション固有のライブラリとして配備時に指定する

アーカイブに含めずに、配備時に利用するライブラリを指定します。 Applibsクラスローダでロードされます。 使用するライブラリは、[DOMAIN]/lib/applibsに配置してください。 アーカイブを変更する必要がなく、なおかつアプリケーション間で特定のライブラリの別バージョンを使い分ける事ができる点が特徴です。

共有コンポーネントとして配備

WebOTX AS Standard/Enterpriseで、プロセスグループ上で動作するアプリケーションで利用可能な方法です。 共有コンポーネントは、プロセスグループ上で動作している全てのアプリケーションで利用可能です。 共有コンポーネントの更新を行なう場合は、その共有コンポーネントを利用している全てのアプリケーションを停止すればよく、プロセスグループの再起動は必要ありません。

OSGiバンドルとして配備

ユーザによって配備されたOSGiバンドルがエクスポートするクラスは、パブリックAPIクラスローダから利用することができます。 OSGiバンドルがエクスポートしているクラスは全てのアプリケーションで利用可能です。 OSGiバンドルの更新を行なう場合は、そのOSGiバンドルを利用している全てのアプリケーションを停止すればよく、ドメインの再起動は必要ありません。

拡張クラスローダでロード

配置したライブラリは、WebOTX ASに配備した全てのアプリケーションで利用できます。 拡張クラスローダでライブラリをロードした場合、WebOTX AS自体のライブラリよりも優先してロードされるため、注意が必要です。 拡張クラスローダでロードするJarライブラリを更新するためには、ドメインの再起動が必要になります。

プロセスグループのシステムクラスローダでロード

プロセスグループ毎に環境変数CLASSPATHでクラスパスを設定可能であるため、プロセスグループ毎に共有するライブラリを分ける場合に利用できます。 設定変更後は、アプリケーショングループの再起動が必要になります。

5.9.8.1. JDBC ドライバの配置

JDBC ドライバはWebOTX 本体からアクセスできる必要があります。そのため、JDBC ドライバは拡張クラスローダか共通クラスローダで読み込むように配置する必要があります。通常は[DOMAIN]/lib/extに配置します。

5.9.9. EJB リモートインタフェース呼び出しがローカル呼び出しになる条件

EJB のリモートメソッドのパフォーマンスを向上させるために、リモートインタフェースを介しての呼び出しがローカル呼び出しとなる場合があります。 その条件は、リモートインタフェースが共通のクラスローダでロードされることです。

この条件を満たすには、主に以下の 2 つの方法があります。

モジュールを同一の EAR に含めることで、リモートインタフェースが共通のクラスローダである EAR の EJB クラスローダでロードされます。
また、モジュールを別々に配備する場合、リモートインタフェースを含むライブラリを [DOMAIN]/lib に配置することで、リモートインタフェースが共通のクラスローダである共通クラスローダでロードされます。 クラスローダの階層については、 [5.9.1. クラスローダの階層 ] を参照してください。

なお、プロセスグループが異なる場合は、必ずリモート呼び出しになります。