WebLogic デプロイメント プログラマーズ ガイド
|
 |
 |
|
以下の節では、WebLogic デプロイメント API で構築したデプロイメント ツールにデプロイメント工程を実装する方法について説明します。
これまでの章では綿密なコンフィグレーションの作成方法について説明してきましたが、そうしたコンフィグレーションを実用に役立てるために実際に配置する作業についてはまだ触れていませんでした。デプロイメントの 5 番目のフェーズであるアプリケーションのデプロイメント フェーズでは、コンフィグレーション工程で設定した任意の情報を使用して、サーバサイド処理とアプリケーションの起動のために管理サーバにアプリケーションおよびプランを配布します。この章では、アプリケーションを WebLogic Server 環境にデプロイし制御するために必要なすべてのコンポーネントについて説明します。
Deployer ツールではデプロイメント工程を実行するために、DeploymentFactoryManager に登録されている DeploymentFactory から取得した DeploymentManager を割り当てる必要があります。DeploymentManager には、コンフィグレーションに加えて (「コンフィグレーション プロセスの概要」を参照)、J2EE サーバへの接続を確立する役割もあります。DeploymentManager の実装には、DeploymentFactory を介してアクセスします。
Deployer ツールには、使用する DeploymentFactory オブジェクトをすべてインスタンス化して登録する役目があります。WebLogic のファクトリは、wldeploy.jar アーカイブのマニフェスト ファイルによって公開されます。このマニフェストには、ファクトリの完全修飾クラス名をホワイトスペース区切りで定義するエントリが記述されています。たとえば次のように記述されています。
MANIFEST.MF:
Manifest-version: 1.0
Implementation-Vendor: BEA Systems
Implementation-Title: WebLogic Server 9.0 Mon Nov 11 08:16:47 PST 2002 221755
Implementation-Version: 9.0.0.0
J2EE-DeploymentFactory-Implementation-Class:
weblogic.deploy.spi.factories.DeploymentFactoryImpl
Deployer ツールでは、認識する SPI プラグインを管理するための任意のメカニズムを定義できます。簡単に処理するには、すべての SPI プラグインが一定の場所にあること、それらがクラスパスにも指定されていることを、ツールでの要件とします。起動時に、サンプルで示されているようにツールでプラグインを登録します。
標準の DeploymentFactory インタフェースが、weblogic.deploy.api.WebLogicDeploymentFactory で拡張されています。この拡張には以下のような追加メソッドがあります。
getDeploymentManager で認識される URI の配列を返す。配列の最初の URI は、必ずデフォルトの DeploymentManager の URI、deployer:WebLogic です。公開されている URI のみがこの配列で返されます。
提供されている DeploymentManager の実装は 1 つだけですが、DeploymentManager は割り当てるときに指定した URI によって以下のような複数の特性を持ちます。
DeploymentManager は管理サーバのローカルで動作すると見なされる。そのため、デプロイメント セッション中に参照されるファイルはすべて管理サーバのローカルにあると想定されます。DeploymentManager は WebLogic 管理サーバのリモートで動作すると見なされる。そのため、デプロイメント セッション中に参照されるファイルはすべて管理サーバのローカルにはないと想定されます。したがって、たとえば配布工程ではアプリケーション ファイルの管理サーバへのアップロードが行われます。DeploymentManager は WebLogic 管理サーバのローカルで動作すると見なされます。そのため、デプロイメント セッション中に参照されるファイルはすべて管理サーバのローカルにあると想定されます。
デプロイメント ツールでは、登録された DeplomentFactory から DeploymentManager を割り当てます (上記を参照)。DeploymentManager は接続機能を持つものと持たないもののどちらかにできます。接続 DeploymentManagers には、WebLogic 管理サーバへの暗黙的な接続機能があります。この接続は、接続が明示的に切断されるか失われるまで維持されます。接続が失われた場合、この DeploymentManager は接続されていない状態になります。
DeploymentManager の接続の明示的な切断は、DeploymentManager.release メソッドを介して行います。DeploymentManager を再接続するためのメソッドはありません。代わりに Deployer ツールで新しい DeploymentManager を割り当てる必要があります。この処理を行っても、ツール内で DeploymentConfiguration オブジェクトを通じて管理しているコンフィグレーション情報には影響しません。
DeploymentManagers はある種の非透過的な URI によって識別されます。WebLogic Server のすべての DeploymentManager には、deployer:WebLogic<.type> という URI スキーマがあります。DeploymentFactory.getDeploymentManager メソッドでは、引数として URI、ユーザ ID、およびパスワードを取ります。この場合 URI には、管理サーバのホストとポートを含める必要があります。たとえば、deployer:WebLogic:localhost:7001 のようにします。非接続 DeploymentManager を取得する場合はサーバに実際に接続されないため、URI のみが必須になります。この場合、URI は単純に deployer:WebLogic となりますが、ここにホストとポートが指定されていても構いません。
認証済みの DeploymentManager を Deployer ツールで使用する場合、ユーザ ID およびパスワードの引数は無視されます。ファクトリではそのユーザがすでに認証されていると見なします。
あらゆる DeploymentManager 実装の URI には必ず DeploymentFactory.getUris() メソッドを使用してアクセスします。getUris は DeploymenFactory の拡張です。
DeploymentManager の一連のオペレーションの動作は、ファクトリから割り当てられた際に指定された URI の指示によって変わります。DeploymentManager でサポートされる当該オペレーションに動作が適用されます。以下のようなものがあります。
DeploymentManagers では自動的に有効になっています。これらの動作は、WebLogicDeploymentManager の enableFileUploads() メソッドを使用して明示的に有効にすることもできます。
DeploymentManager の機能要素のほとんどは J2EE Deployment API 仕様に定義されていますが、この仕様には WebLogic Server ユーザのニーズに十分に対応する形の DeploymentManager が記述されていません。そのため、数多くの拡張が導入されています。そうした拡張については weblogic.deploy.api.spi.WebLogicDeploymentManager の Javadoc で説明されています。ここでは、SPI のオペレーションと WebLogic Server との関係について説明します。
これは、J2EE Deployment API 仕様で定義されているプログラミング モデルの変更を意図するものではありません。DeploymentManager インタフェース (DeploymentManager) を拡張して、既存の WebLogic Server ベースのデプロイメント ツールに必要とされ期待されていた機能を追加することを目的としています。
JSR-88 のプログラミング モデルは、TargetModuleID のオブジェクト (TargetModuleID) と ProgressObject のオブジェクトの使用を中心に展開されています。一般に、対象モジュールは TargetModuleID のリストで定義されます。おおまかにいって、このリストはデプロイ可能なモジュール (ルート モジュール) および (下位) モジュール レベルの MBean に相当します。DeploymentManager では TargetModuleID をそのデプロイメント オペレーション (start、stop など) や進捗状況の追跡に利用します。Deployer ツールでは各オペレーションで返される ProgressObject を介して進捗状況を問い合わせます。ProgressObject でオペレーションの完了または失敗が示された場合、そのオペレーションが実行されたことになります。
次の節では、さまざまな DeploymentManager のオペレーションとその拡張について説明します。詳細な説明については、「Javadoc」を参照してください。ここでは、全般的な概要を示します。拡張により次のような機能が実現しています。
WebLogic Server では DeploymentOptions 引数 (weblogic.deploy.api.spi.DeploymentOptions) を使用できます。この引数では、特定のデプロイメント動作のオーバーライドがサポートされています。この引数には null も指定でき、その場合は標準的な動作になります。このリリースでサポートされているオプションの一部を以下に示します。
全オプションの一覧については DeploymentOptions の Javadoc を参照してください。
新しいアプリケーションを配布すると、アプリケーションのアーカイブおよびプランがすべての対象にステージングされ、アプリケーションがドメインにコンフィグレーショングレーションされます。再配布は、すでにアプリケーション用にコンフィグレーションされたステージング モードで有効になります。
標準の distribute オペレーションではバージョンに名前を付けられず、システムで生成される名前がそのまま使用されます。WebLogicDeploymentManager では標準が拡張され、ユーザ側で新しいアプリケーションに関連するバージョン名を指定できます。
distribute から返される ProgressObject では、対象サーバにアプリケーションが存在している状態を表す TargetModuleID のリストが提供されます。distribute で使用される Target オブジェクトは、サポートされている任意の対象です。TargetModuleID では、各対象でアプリケーションのモジュールを利用できるかどうかが表されます。
新しいアプリケーションについては、結果として提供された TargetModuleID が最上位の AppDeploymentMBean オブジェクトを表します。TargetModuleIDs には、アプリケーション内のモジュールおよびサブモジュールに基づく子 TargetModuleIDs はありません。これは、基底の MBean がルートのモジュールのみを表しているためです。既存のアプリケーションについては、TargetModuleID は DeployableMBean と、コンフィグレーションにあるすべての AppDeploymentMBean および SubAppDeploymentMBean に基づいています。
配布に distribute(Target[],InputStream,InputStream) メソッドを使用する場合、デプロイされる前に、入力ストリームで表されているアーカイブおよびプランがストリームから一時領域にコピーされます。パフォーマンス上の理由から、この distribute メソッドは使用しないことをお勧めします。
標準の start オペレーションではルート モジュールのみがサポートされています。つまり、アプリケーションの全体的な起動のみができます。以下のコンフィグレーションについて考察します。
<AppDeployment Name="myapp">
<SubDeployment Name="webapp1", Targets="serverx"/>
<SubDeployment Name="webapp2", Targets="serverx"/>
</AppDeployment>
getAvailableModules(ModuleType.EAR) から返される TargetModuleID は次のようになります。
myapp on serverx (implied)
webapp1 on serverx
webapp2 on serverx
したがって、start(tmid) では serverx 上の webapp1 および webapp2 が起動されます。
webapp1 のみを起動するには、モジュール レベルでの制御が必要です。そのように制御するには、TargetModuleID の階層を次のように手動で作成します。
WebLogicTargetModuleID root = dm.createTargetModuleID("myapp",ModuleType.EAR,getTarget(serverx));
WebLogicTargetModuleID web = dm.createTargetModuleID(root,"webapp1",ModuleType.WAR);
dm.start(new TargetModuleID[]{web});
この方法では、TargetModuleID 作成の拡張を使用して、手動で明示的に TargetModuleID の階層を作成しています。この場合、作成される TargetModuleID は次のようになります。
myapp on serverx (implied)
webapp1 on serverx
start オペレーションではアプリケーションのコンフィグレーションは変更されません。バージョンのサポートが TargetModuleID に組み込まれていて、それによって特定のバージョンのアプリケーションを起動できます。アプリケーションは通常モードまたは管理 (テスト) モードで起動できます。
distribute オペレーションと start オペレーションの機能を合わせ持つ便利なオペレーションとして deploy オペレーションが用意されています。Web アプリケーションは通常モードまたは管理 (テスト) モードでデプロイできます。deploy では、DeploymentOptions 引数を介してアプリケーションのステージングも設定できます。deploy オペレーションでは Target オブジェクトではなく TargetModuleID を使用して対象指定するため、モジュール レベルでコンフィグレーションできます。
deploy オペレーションでは、提供された TargetModuleID に基づいてアプリケーションのコンフィグレーションを変更できます。
標準の stop オペレーションではルート モジュールのみがサポートされています。つまり、アプリケーションの全体的な停止のみができます。モジュール レベルの制御の詳細については、「アプリケーションの起動」の説明を参照してください。
stop オペレーションではアプリケーションのコンフィグレーションは変更されません。
バージョンのサポートが TargetModuleID に組み込まれていて、それによって特定のバージョンのアプリケーションを停止できます。
標準の undeploy オペレーションでは、TargetModuleID で指定してアプリケーションをコンフィグレーションから削除します。したがって、個々のモジュールをアンデプロイできます。結果としてアプリケーションは対象に残りますが、特定のモジュールが対象で実際に実行されないようにコンフィグレーションされます。モジュール レベルの制御の詳細については、「アプリケーションの起動」を参照してください。
WebLogicDeploymentManager は undeploy を拡張して、配布されたアプリケーションからファイルを削除できるようにしたものです。これはインプレース再デプロイメントの 1 つの形態で、Web アプリケーションでのみサポートされ、静的なページの削除などを可能にすることを目的としています。
バージョンのサポートが TargetModuleID に組み込まれていて、それによって特定のバージョンのアプリケーションをアンデプロイできます。
標準の再デプロイメントのサポートはアプリケーション全体にのみ適用され、side-by-side バージョニングを採用することで中断のないセッション管理を実現しています。WebLogicDeploymentManager では、redeploy() メソッドが次のように拡張されています。
バージョンのサポートは上記のオペレーションの引数を介して実現します。該当するバージョンがあると、TargetModuleID に指定されます。
アプリケーションの新しいバージョンが再デプロイされる場合、古いバージョンは最終的には廃止されてアンデプロイされます。アプリケーションの古いバージョンの廃止には次の 2 つのポリシーがあります。
1. (デフォルト) 新しいバージョンがアクティブなときに古いバージョンが廃止され、古いバージョンで実行中の処理が完了する。
2. 新しいバージョンがアクティブになるまでの指定された時間制限の後で、新しいバージョンがアクティブなときに古いバージョンが廃止される。
新しいバージョンが管理 (テスト) モードの場合、古いバージョンは廃止されません。
DeploymentManager の実装では JSR-88 仕様が尊重されて、ルート モジュールへの操作が制限されます。モジュール レベルで制御するには、WebLogicDeploymentManager.createTargetModuleID を介してモジュール固有の TargetModuleID 階層を手動で構築します。
サイド バイ サイド バージョニングは、JSR-88 の再デプロイメント仕様に示されているように、廃止された拡張を提供するために使用されます。side-by-side バージョニングを使用すると、サービスを中断せずにアプリケーションを最新のクライアントに再デプロイできます。side-by-side バージョンのデプロイの詳細については、「再デプロイメント方式の概要」で説明しています。簡潔にいうと、アーカイブのマニフェストで WebLogic Server アプリケーションのバージョンを指定できます。また、デプロイメント プランでもバージョンの識別子がサポートされます。これらの 2 つのバージョン識別子の組み合わせが内部的に使用されて、アプリケーションのバージョンが区別されます。また、開発者や管理者がこれらを使用してバージョンの制御に役立てることもできます。
この機能は WebLogic Server デプロイメント サービス用に実装された場合にプロダクションの再デプロイメントの基礎になります。詳細については、「再デプロイメント方式の概要」を参照してください。
Web アプリケーションは通常モードまたは管理 (テスト) モードで起動できます。通常モードは、その Web アプリケーションがクライアントから完全にアクセス可能であることを示します。管理 (テスト) モードは、そのアプリケーションが管理チャネルを通してのみ要求をリスンすることを示します。管理 (テスト) モードは start、deploy、および redeploy の WebLogic Server 拡張の DeploymentOptions 引数を介して指定されます。詳細については、DeploymentOptions の Javadoc を参照してください。
ProgressObject はデプロイメントの状態に関する SPI のインタフェースです。そのオブジェクトは DeploymentTaskRuntimeMBean に関連付けられています。ProgressObject では cancel オペレーションはサポートされますが、stop オペレーションはサポートされません。
ProgessObject の実装は 1 つまたは複数の TargetModuleID に関連付けられます。各 TargetModuleID が、アプリケーションおよびそのアプリケーションと特定の対象との関連付けを表します。任意の ProgressObject の実装にとって、関連付けられた TargetModuleID が、モニタの対象とするアプリケーションを表します。
ProgressObject ではデプロイメント フレームワークとのライブ接続が維持されるため、ツールに最新のデプロイメントの状態を提供できます。状態が完了、失敗、または解放に至ると、それ以降の変更をツールで期待することはできません。デプロイメントの状態が実行中から完了または失敗に変化するのは、関係するすべての TargetModuleIDs で個々のデプロイメントが完了したすぐ後です。結果として状態が「完了」になるのは、TargetModuleIDs が正しくデプロイされた場合のみです。
「解放」状態は、デプロイ中に DeploymentManager の接続が切断されたことを意味します。この状態の原因には、手動による解放、ネットワークの停止、または類似する通信障害の場合があります。
以下のコード サンプルでは、ProgressObject を使用してデプロイメントの完了を待機する方法について示します。
package weblogic.deployer.tools;
import javax.enterprise.deploy.shared.*;
import javax.enterprise.deploy.spi.*;
import javax.enterprise.deploy.spi.status.*;
/**
* ProgressEvent の実装を使用して
* デプロイメントの完了を待機するクラスのサンプル
*/
public class ProgressExample implements ProgressListener {
private boolean failed = false;
private DeploymentManager dm;
private TargetModuleID[] tmids;
public void main(String[] args) {
// DeploymentManager、TargetModuleID などを設定する
try {
wait(dm.start(tmids));
} catch (IllegalStateException ise) {
//... dm は接続されていない
}
if (failed) System.out.println("oh no!");
}
void wait(ProgressObject po) {
ProgressHandler ph = new ProgressHandler();
if (!po.getDeploymentStatus().isRunning()) {
failed = po.getDeploymentStatus().isFailed();
return;
}
po.addProgressListener(ph);
ph.start();
while (ph.getCompletionState() == null) {
try {
ph.join();
} catch (InterruptedException ie) {
if (!ph.isAlive()) break;
}
}
StateType s = ph.getCompletionState();
failed = (s == null ||
s.getValue() == StateType.FAILED.getValue());
po.removeProgressListener(ph);
}
class ProgressHandler extends Thread implements ProgressListener {
boolean progressDone = false;
StateType finalState = null;
public void run(){
while(!progressDone){
Thread.currentThread().yield();
}
}
public void handleProgressEvent(ProgressEvent event){
DeploymentStatus ds = event.getDeploymentStatus();
if (ds.getState().getValue() != StateType.RUNNING.getValue()) {
progressDone = true;
finalState = ds.getState();
}
}
public StateType getCompletionState(){
return finalState;
}
}
}
標準のモジュールのタイプは javax.enterprise.deploy.shared.ModuleType に定義されています。これが、WebLogic Server 固有のモジュールのタイプ JMS、JDBC、INTERCEPT、および CONFIG をサポートするように拡張されています。
J2EE Deployment API 仕様での対象の定義では、対象の種類について特に述べられていません。WebLogic Server では種類を認識します。サーバ、クラスタ、JMS サーバ、および仮想ホストがデプロイメントの有効な対象です。こうした概念が weblogic.deploy.api.spi.WebLogicTarget クラスおよび weblogic.deploy.api.spi.WebLogicTargetType クラスによって API に導入されています。WebLogicTargetType は、javax.enterprise.deploy.shared のクラスの形式に従います。このクラスでは既知の対象の型が列挙されます。
WebLogicTarget および WebLogicTargetType については、「Javadoc」でさらに詳細に定義されています。WebLogicTarget は javax.enterprise.deploy.spi.Target の拡張です。
TargetModuleID のオブジェクトではモジュールとそれに関連付けられた対象をユニークに識別します。TargetModuleID は、起動および停止されるモジュールの場所を指定するオブジェクトです。TargetModuleID を識別するために使用されるオブジェクト名は、次の形式で表されます。
Application=parent-name,Name=configured-name,Target=target-name,TWebLogicTargetType=target-type
TargetModuleID.toString() はこのオブジェクトの名前を返します。
TargetModuleID が weblogic.deploy.api.spi.WebLogicTargetModuleID によって拡張されています。このクラスでは以下の付加機能が提供されます。
getServers - TargetModuleID の対象に関連付けられているサーバisOnCluster - 対象がクラスタかどうかisOnServer - 対象がサーバかどうかisOnHost - 対象が仮想ホストかどうかisOnJMSServer - 対象が JMS サーバかどうかgetVersion - バージョン名createTargetModuleID - モジュール固有の対象を作成するファクトリWebLogicTargetModuleID については、「Javadoc」でさらに詳細に定義されています。
また、WebLogicDeploymentManager も便利なメソッド群で拡張されています。それらのメソッド群を使用すると TargetModuleID との連携が容易になります。メソッドは次のとおりです。
filter - アプリケーション、モジュール、バージョンに一致する TargetModuleID のリストを返すgetModules - AppDeploymentMBean に基づいて TargetModuleID を作成するTargetModuleID 群にはベースとするアプリケーションに基づく階層関係があります。アプリケーションのルート TargetModuleID は、EAR モジュールまたはスタンドアロン モジュールを表します。子 TargetModuleID 群は、ルート モジュールの記述子で定義されているモジュール群です。EAR の場合、その EAR の application.xml 記述子で定義されているモジュールになります。JMS モジュールにはサブモジュールの概念があるため、JMS モジュールには JMS デプロイメント記述子に定義されている子 TargetModuleID があることもあります。それらは組み込みモジュールの子またはルート モジュールの子の場合があります。したがって、アプリケーションの TargetModuleID には 3 つのレベルがあり得ることになります。
TargetModuleID は一般的には何らかのデプロイメント関連のオペレーション、または DeploymentManager.get*Modules() メソッド群のうちの 1 つを介して取得されます。これらの手段では、既存のコンフィグレーションに基づく TargetModuleID 群のみが提供されます。現在コンフィグレーションに定義されているよりも限定された対象を指定する必要がある場合のために、createTargetModuleID メソッドが用意されています。このメソッドでは、アプリケーション内のモジュールまたはサブモジュールに相当するルート TargetModuleID が作成されます。作成された TargetModuleID は、任意のデプロイメント関連のオペレーションで使用できます。アプリケーションのアーカイブ処理が含まれるオペレーション (たとえば deploy()) で、こうした TargetModuleID の 1 つを使用すると、アプリケーションが再コンフィグレーションされることがあります。たとえば、次のようなコンフィグレーションがあるとします。
<AppDeployment Name="myapp", Targets="s1,s2"/>
このアプリケーションでは、現在すべてのモジュールが s1 および s2 で動作するようにコンフィグレーションされています。さらに限定された対象を指定するには、デプロイメント ツールで次のようにします。
Target s1 = find("s1",dm.getTargets());
// find() はこの API の一部ではない
WebLogicTargetModuleID root = dm.createTargetModuleID("myapp",ModuleType.EAR,s1);
WebLogicTargetModuleID web = dm.createTargetModuleID(root,"webapp1",ModuleType.WAR);
dm.deploy(new TargetModuleID[]{web},myapp,myplan,null);
myapp が再コンフィグレーションされ、webapp が s1 でのみ動作するように限定的に対象指定されます。新しいコンフィグレーションは次のようになります。
<AppDeployment Name="myapp", Targets="s1,s2">
<SubDeployment Name="webapp", Targets="s1"/>
</AppDeployment>
JSR-88 では、モジュールで参照したり利用したりできる補足的な記述子として二次的な記述子が定義されています。このような記述子はモジュールのルート DConfigBean と関連付けられることで、Java Bean ベースのツールから参照できるようになっています。これらは DConfigBeanRoot オブジェクトの子プロパティです。二次的記述子はモジュールのコンフィグレーション プロセスで自動的に含められます。
EJB または Web アプリケーションには、webservers.xml 記述子を含められます。これが存在する場合、モジュールは WebLogic Server の Web サービス コンフィグレーション用の相当する記述子に自動的にコンフィグレーションされます。こうした記述子は、JSR-88 の用語では二次的記述子として扱われます。デプロイメント プランにはこうした記述子が、別個のモジュールではなくモジュールの一部として含められます。
EJB での CMP のサポートは RDBMS 記述子によってコンフィグレーションされます。RDBMS 記述子は weblogic-ejb-jar.xml 記述子内で CMP Bean 用に定義されます。RDBMS 記述子では、現在 CMP11 および CMP20 がサポートされています。RDBMS 記述子は EJB モジュールにいくつでも含められます。この種の記述子は、アプリケーションのアーカイブまたはコンフィグレーション領域 (approot/plan) に置く必要があります。この種の記述子はコンフィグレーション プロセスでは作成されませんが、別の記述子と同様、変更されることはあります。RDBMS 記述子はデプロイメント プランでは二次的記述子として扱われます。
JDBC モジュールは単一のデプロイメント記述子で記述されます。アーカイブは含まれません。モジュールが EAR の一部の場合、一連の JDBC 記述子は weblogic-application.xml に記述されます。これらはコンフィグレーション可能なプロパティです。JDBC モジュールは WebLogic Server およびクラスタにデプロイできます。JDBC 記述子に対するコンフィグレーションの変更は、記述子のオーバーライドとして処理されます。
JDBC モジュールが EAR の一部の場合、そのコンフィグレーションのオーバーライドは二次的記述子として扱われます。デプロイメント プランには EAR の一部として組み込まれ、別個のモジュールとしては組み込まれません。
JMS モジュールは単一のデプロイメント記述子で記述されます。アーカイブは含まれません。EAR の一部の場合、一連の JMS 記述子は weblogic-application.xml に記述されます。これらはコンフィグレーション可能なプロパティです。JMS モジュールは JMS サーバにデプロイできます。JMS 記述子に対するコンフィグレーションの変更は、記述子のオーバーライドとして処理されます。JMS 記述子では「対象指定できるグループ」を識別できます。そうしたグループはデプロイメント処理中にはサブモジュールとして扱われます。
JMS モジュールが EAR の一部の場合、そのコンフィグレーションのオーバーライドは二次的記述子として扱われます。デプロイメント プランには EAR の一部として組み込まれ、別個のモジュールとしては組み込まれません。
Intercept モジュールは単一のデプロイメント記述子で記述されます。アーカイブは含まれません。EAR の一部の場合、一連の Intercept 記述子は weblogic-application.xml に記述されます。これらはコンフィグレーション可能なプロパティです。Intercept モジュールは WebLogic Server およびクラスタにデプロイできます。Intercept 記述子に対するコンフィグレーションの変更は、記述子のオーバーライドとして処理されます。
Intercept モジュールが EAR の一部の場合、そのコンフィグレーションのオーバーライドは二次的記述子として扱われます。デプロイメント プランには EAR の一部として組み込まれ、別個のモジュールとしては組み込まれません。
サブモジュールを持つスタンドアロン JMS モジュールのデプロイメントについて考察します。このモジュールは jms.xml ファイルで定義され、このファイルにサブモジュール sub1 と sub2 が定義されています。この記述子は特定の環境向けに完全にコンフィグレーションされているのでデプロイメント プランは必要ありませんが、ここで紹介するシナリオはデプロイメント プランがある場合も同じです。
このモジュールをデプロイするツールでは次の手順が実行されます。
// jsr88 セッションを初期化する。これには WLS 固有のヘルパー クラスを使用する。
// このヘルパー クラスには WLS 拡張は使用されていない
DeploymentManager dm = SessionHelper.getDeploymentManager(host,port, user,pword);
// コンフィグレーション済みのすべての対象のリストを取得する。
// この filter メソッドで、コンフィグレーション済みのすべての対象のリストから選択するように
// ツールからユーザに尋ねられる
Target[] targets = filter(dm.getTargets());
// 選択した対象にモジュールが配布される
ProgressObject po = dm.distribute(targets,new File("jms.xml"),plan);
// ここで待機用メソッドがタスクの完了を戻す
waitForCompletion(po);
// ここでは正常に動作したと見なす (例外処理なし)。
// アプリケーションを配布する各対象において、PO から返される TargetModuleID (tmid) 群が
// すべてのコンフィグレーション済みのアプリケーションおよびモジュールの MBean に相当する。
// これには対象ごとに 3 レベルの tmid が含まれる。
// すなわちルート モジュールの tmid とサブモジュール群の tmid である
TargetModuleID[] tmids = po.getResultTargetModuleIDs();
// 続いて、すべての必要な場所にすべてをデプロイする
po = dm.start(tmids);
// 結果として、すべてのサブモジュールもすべての選択した対象にデプロイされる。
// これは、サブモジュールは親が対象指定される場所には
// すべて暗黙的に対象指定されるためである。
// サブモジュール レベルのデプロイメントを取得するには、WebLogic Server 拡張を使用して
// モジュール レベルの対象指定をサポートする TargetModuleID 群を作成する。
// 以下では topic "xyz" を JMS サーバにデプロイする
WebLogicTargetModuleID root = dm.createTargetModuleID(tmids[i].getModuleID(),tmids[i],jmsServer);
WebLogicTargetModuleID topic = dm.createTargetModuleID(root,"xyz",WebLogicModuleType.JMS);
// これで、元の tmid のリストを取得して
// ユーザにデプロイする特定の timid を選択させたことになる
po = dm.start(topic);
|
|
|