4 デプロイメント工程の実行

アプリケーションのデプロイメントでは、サーバサイド処理とアプリケーションの起動のために管理サーバに「デプロイメントのためのアプリケーションのコンフィグレーション」で作成した情報を配布します。デプロイメントツールを使用して、以下に示すデプロイメント工程を正常に完了する必要があります。

デプロイメントファクトリオブジェクトの登録
DeploymentManager の割り当て
デプロイメントの手続き
プロダクションの再デプロイメント
進捗状況のレポート
Target オブジェクト

デプロイメントファクトリオブジェクトの登録

デプロイメントツールには、使用する DeploymentFactory オブジェクトをインスタンス化して登録する役目があります。DeploymentFactory オブジェクトを管理するメカニズムは独自に実装することができます。WebLogic Server DeploymentFactory オブジェクトは、wldeploy.jar ファイルに格納されているマニフェストファイルによって公開されます。このマニフェストには、ファクトリの完全修飾クラス名をホワイトスペース区切りで定義するエントリが記述されています。たとえば、DeploymentFactory オブジェクトが一定の場所にあり、デプロイメントツールのクラスパスに指定されている場合、デプロイメントツールの起動時に認識された DeploymentFactory オブジェクトが登録されます。コードリスト 4-1 を参照してください。

コードリスト 4-1 マニフェストファイルに登録されたデプロイメントファクトリ

   MANIFEST.MF:
      Manifest-version: 1.0
      Implementation-Vendor: BEA Systems
      Implementation-Title: WebLogic Server 9.0 Mon May 29 08:16:47 PST 2006 221755
      Implementation-Version: 9.0.0.0
      J2EE-DeploymentFactory-Implementation-Class:
      weblogic.deploy.spi.factories.DeploymentFactoryImpl
   .
   .
   .

標準の DeploymentFactory インタフェースが、weblogic.deploy.api.WebLogicDeploymentFactory で拡張されています。この拡張には以下のような追加メソッドがあります。

String[] getUris() : getDeploymentManager で認識される URI の配列を返す。配列の最初の URI は、必ずデフォルトの DeploymentManager の URI、deployer:WebLogic です。公開されている URI のみがこの配列で返されます。
String createUri(String protocol, String host, String port) : 引数に基づいて使用に適した URI を返す。

DeploymentManager の割り当て

デプロイメントツールではデプロイメント工程を実行するために、DeploymentFactoryManager クラスに登録されている DeploymentFactory から取得した DeploymentManager を割り当てる必要があります。DeploymentManager には、デプロイメントのためのアプリケーションのコンフィグレーションに加えて、J2EE サーバへの接続を確立する役割もあります。DeploymentManager の実装には、DeploymentFactory を介してアクセスします。

以下の節では、DeploymentManager がサーバインスタンスに接続する方法について説明します。

DeploymentManager オブジェクトの取得
DeploymentManager URI 実装について
サーバ接続

DeploymentManager オブジェクトの取得

DeploymentManager を取得するには、DeploymentFactory.getDeploymentManager メソッドを使用します。このメソッドは、引数として URI、ユーザ ID、およびパスワードを取ります。URI のパターンを以下に示します。

deployer:WebLogic<:host:port>
deployer:WebLogic.remote<:host:port>
deployer:WebLogic.authenticated<:host:port>

管理サーバに接続する際、URI にはホストとポートを含める必要があります。たとえば、deployer:WebLogic:localhost:7001 のようにします。詳細については、「DeploymentManager URI 実装について」を参照してください。

DeploymentManager の引数に関する情報を以下に示します。

非接続 DeploymentManager を取得する場合は管理サーバに接続されないため、host:port を含める必要はない。たとえば、URI は deployer:WebLogic になります。
認証済みの DeploymentManager をデプロイメントツールで使用する場合、ユーザ ID およびパスワードの引数は無視される。
あらゆる DeploymentManager 実装の URI には DeploymentFactory.getUris() メソッドを使用してアクセスできる。getUris は DeploymenFactory の拡張です。

DeploymentManager URI 実装について

DeploymentManager オブジェクトは割り当て時に指定した URI によって以下のような特性を持ちます。

deployer:WebLogic : DeploymentManager は管理サーバのローカルで動作する。そのため、デプロイメントセッション中に参照されるファイルはすべて管理サーバのローカルにあると想定されます。
deployer:WebLogic.remote : DeploymentManager は WebLogic 管理サーバのリモートで動作する。デプロイメントセッション中に参照されるファイルはすべて管理サーバのリモートにあると想定され、アップロードが必要になる場合があります。たとえば、配布工程ではアプリケーションファイルの管理サーバへのアップロードが行われます。
deployer:WebLogic.authenticated : これは内部の公開されていない URI で、すでに認証されていてドメインの管理情報にアクセスできるコンソールサーブレットなどのアプリケーションで使用できる。DeploymentManager は WebLogic 管理サーバのローカルで動作します。そのため、デプロイメントセッション中に参照されるファイルはすべて管理サーバのローカルにあると想定されます。

アプリケーションファイルのアップロードは、WebLogicDeploymentManager method enableFileUploads() メソッドを使用することによって明示的に行うことができます。

サーバ接続

DeploymentManager は接続機能を持つものと持たないもののどちらかです。接続 DeploymentManager には、WebLogic 管理サーバへの暗黙的な接続機能があります。この接続は、接続が明示的に切断されるか失われるまで維持されます。接続が失われた場合、この DeploymentManager は接続されていない状態になります。

DeploymentManager の接続の明示的な切断は、DeploymentManager.release メソッドを介して行います。DeploymentManager を再接続するためのメソッドはありません。代わりにデプロイメントツールで新しい DeploymentManager を割り当てる必要があります。

注意 :

新しい DeploymentManager を割り当てても、ツール内で DeploymentConfiguration オブジェクトを通じて管理しているコンフィグレーション情報には影響しません。

デプロイメントの手続き

DeploymentManager の機能要素のほとんどは J2EE Deployment API 仕様に定義されていますが、Oracle では DeploymentManager インタフェースを拡張し、既存の WebLogic Server ベースのデプロイメントツールに必要な機能を追加しています。Oracle の WebLogic Server デプロイメント拡張については、「weblogic.deploy.api.spi.WebLogicDeploymentManager」を参照してください。

JSR-88 のプログラミングモデルは、TargetModuleID のオブジェクト (TargetModuleID) と ProgressObject のオブジェクトの使用を中心に展開されています。一般に、対象モジュールは TargetModuleID のリストで定義されます。おおまかにいって、このリストはデプロイ可能なルートモジュールおよび下位モジュールレベルの MBean に相当します。DeploymentManager では TargetModuleID をそのデプロイメントオペレーションや進捗状況の追跡に利用します。デプロイメントツールでは各オペレーションで返される ProgressObject を介して進捗状況を問い合わせる必要があります。ProgressObject でオペレーションの完了または失敗が示された場合、そのオペレーションが実行されたことになります。

以下の節では、WebLogic DeploymentManager 機能の概要を説明します。

DeploymentOptions
配布
アプリケーションの起動
アプリケーションのデプロイ
アプリケーションの停止
アンデプロイメント

DeploymentOptions

WebLogic Server では DeploymentOptions 引数 (weblogic.deploy.api.spi.DeploymentOptions) を使用できます。この引数では、特定のデプロイメント動作のオーバーライドがサポートされています。この引数には null も指定でき、その場合は標準的な動作になります。このリリースでサポートされているオプションの一部を以下に示します。

管理 (テスト) モード
廃止ポリシー
ステージング

詳細については、DeploymentOptions の Javadoc を参照してください。

配布

新しいアプリケーションを配布すると、以下の処理が実行されます。

アプリケーションのアーカイブおよびプランがすべての対象にステージングされる
アプリケーションがドメインにコンフィグレーショングレーションされる

注意 :
再配布は、すでにアプリケーション用にコンフィグレーションされたステージングモードで有効になります。

標準の distribute オペレーションではバージョンに名前を付けることができません。WebLogicDeploymentManager では標準が拡張され、アプリケーションに関連するバージョン名を指定できます。

distribute から返される ProgressObject では、対象サーバにアプリケーションが存在している状態を表す TargetModuleID のリストが提供されます。distribute で使用される Target オブジェクトは、サポートされている任意の対象です。TargetModuleID では、各対象でアプリケーションのモジュールを利用できるかどうかが表されます。

新しいアプリケーションについては、TargetModuleID が最上位の AppDeploymentMBean オブジェクトを表します。TargetModuleID には、アプリケーション内のモジュールおよびサブモジュールに基づく子 TargetModuleID はありません。これは、基底の MBean がルートのモジュールのみを表しているためです。既存のアプリケーションについては、TargetModuleID は DeployableMBean と、コンフィグレーションにあるすべての AppDeploymentMBean および SubAppDeploymentMBean に基づいています。

アプリケーションの配布に distribute(Target[],InputStream,InputStream) メソッドを使用する場合、パフォーマンスに影響を及ぼすデプロイメントの前に、入力ストリームで表されているアーカイブおよびプランがストリームから一時領域にコピーされます。

アプリケーションの起動

標準の 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 に組み込まれていて、それによって特定のバージョンのアプリケーションを起動できます。アプリケーションは通常モードまたは管理 (テスト) モードで起動できます。

アプリケーションのデプロイ

deploy オペレーションは、distribute オペレーションと start オペレーションの機能を合わせ持っています。Web アプリケーションは通常モードまたは管理 (テスト) モードでデプロイできます。DeploymentOptions 引数を介してアプリケーションのステージングも設定できます。deploy オペレーションでは Targets オブジェクトではなく TargetModuleIDs を使用して対象指定するため、モジュールレベルでコンフィグレーションできます。

deploy オペレーションでは、提供された TargetModuleID に基づいてアプリケーションのコンフィグレーションを変更できます。

アプリケーションの停止

標準の stop オペレーションではルートモジュールのみがサポートされています。つまり、アプリケーションの全体的な停止のみができます。詳細については、「アプリケーションの起動」を参照してください。

Oracle ではバージョンのサポートを提供しており、それによって特定のバージョンのアプリケーションを停止できます。stop オペレーションではアプリケーションのコンフィグレーションは変更されません。詳細については、「バージョンのサポート」を参照してください。

アンデプロイメント

標準の undeploy オペレーションでは、TargetModuleID で指定してアプリケーションをコンフィグレーションから削除します。したがって、個々のモジュールをアンデプロイできます。結果としてアプリケーションは対象に残りますが、特定のモジュールが対象で実際に実行されないようにコンフィグレーションされます。モジュールレベルの制御の詳細については、「アプリケーションの起動」を参照してください。

WebLogicDeploymentManager は undeploy を拡張して、配布されたアプリケーションからファイルを削除できるようにしたものです。これはインプレース再デプロイメントの 1 つの形態で、Web アプリケーションでのみサポートされ、静的なページの削除を可能にすることを目的としています。詳細については、「バージョンのサポート」を参照してください。

プロダクションの再デプロイメント

標準の再デプロイメントのサポートはアプリケーション全体にのみ適用され、side-by-side バージョニングを採用することで中断のないセッション管理を実現しています。WebLogicDeploymentManager では、redeploy() メソッドが拡張され、以下のようなサポートが新たに提供されています。

インプレース再デプロイメント
モジュールレベルの対象指定
廃止ポリシー
バージョンのサポート
管理 (テスト) モード

インプレース再デプロイメント

インプレース再デプロイメント方式のしくみは、実行中のアプリケーションのデプロイメントファイルを、更新されたデプロイメントファイルで直ちに置き換えることです。その方法は以下のとおりです。

既存のデプロイメントに対する特定のファイルの追加や置換などの部分的な再デプロイメント
デプロイメントプランの再デプロイメントによるコンフィグレーションの更新

モジュールレベルの対象指定

DeploymentManager では、JSR-88 仕様に基づいてルートモジュールへの操作が制限されます。モジュールレベルで制御するには、WebLogicDeploymentManager.createTargetModuleID を介してモジュール固有の TargetModuleID 階層を手動で構築します。

廃止ポリシー

アプリケーションの新しいバージョンが再デプロイされる場合、古いバージョンは最終的には廃止されてアンデプロイされます。アプリケーションの古いバージョンの廃止には次の 2 つのポリシーがあります。

(デフォルト) 新しいバージョンがアクティブなときに古いバージョンが廃止され、古いバージョンで実行中の処理が完了する。
新しいバージョンがアクティブになるまでの指定された時間制限の後で、新しいバージョンがアクティブなときに古いバージョンが廃止される。

注意 :
新しいバージョンが管理 (テスト) モードの場合、古いバージョンは廃止されません。

バージョンのサポート

side-by-side バージョニングは、JSR-88 の再デプロイメント仕様に示されているように、廃止された拡張を提供するために使用されます。side-by-side バージョニングを使用すると、サービスを中断せずにアプリケーションを最新のクライアントに再デプロイできます。side-by-side バージョンのデプロイの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションのデプロイメント』の「プロダクション環境でのアプリケーションの再デプロイメント」を参照してください。

管理 (テスト) モード

Web アプリケーションは通常モードまたは管理 (テスト) モードで起動できます。通常モードは、その Web アプリケーションがクライアントから完全にアクセス可能であることを示します。管理 (テスト) モードは、そのアプリケーションが admin チャネルを通してのみ要求をリスンすることを示します。管理 (テスト) モードは start、deploy、および redeploy の WebLogic Server 拡張の DeploymentOptions 引数によって指定されます。詳細については、DeploymentOptions の Javadoc を参照してください。

進捗状況のレポート

アプリケーションのデプロイメント状態を判断するには、ProgressObject を使用します。そのオブジェクトは DeploymentTaskRuntimeMBeans. ProgressObject に関連付けられていて、cancel オペレーションはサポートされますが、stop オペレーションはサポートされません。

ProgessObject の実装は 1 つまたは複数の TargetModuleID に関連付けられます。各 TargetModuleID が、アプリケーションおよびそのアプリケーションと特定の対象との関連付けを表します。任意の ProgressObject の実装にとって、関連付けられた TargetModuleID が、モニタの対象とするアプリケーションを表します。

ProgressObject ではデプロイメントフレームワークとの接続が維持されるため、デプロイメントツールに最新のデプロイメントの状態を提供できます。デプロイメントの状態が実行中から完了または失敗に変化するのは、関係するすべての TargetModuleID で個々のデプロイメントが完了したすぐ後です。結果として状態が completed になるのは、TargetModuleID が正しくデプロイされた場合のみです。

released 状態は、デプロイ中に DeploymentManager の接続が切断されたことを意味します。この状態の原因には、手動による解放、ネットワークの停止、または類似する通信障害の場合があります。

以下のコードサンプルでは、ProgressObject を使用してデプロイメントの完了を待機する方法について示します。

コードリスト 4-2 デプロイメントの完了を待機するサンプルコード

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;
}
}
}

Target オブジェクト

この節では、オブジェクトを対象指定する方法について説明します。

モジュールのタイプ
拡張モジュールのサポート
対象の種類の認識
TargetModuleID オブジェクト
WebLogic Server TargetModuleID 拡張
サンプルモジュールのデプロイメント

モジュールのタイプ

標準のモジュールのタイプは javax.enterprise.deploy.shared.ModuleType に定義されています。これが、WebLogic Server 固有のモジュールのタイプ JMS、JDBC、INTERCEPT、および CONFIG をサポートするように拡張されています。

拡張モジュールのサポート

JSR-88 では、モジュールで参照したり利用したりできる補足的な記述子として二次的な記述子が定義されています。このような記述子はモジュールのルート DConfigBean と関連付けられることで、Java Bean ベースのツールから参照できるようになっています。これらは DConfigBeanRoot オブジェクトの子プロパティです。二次的記述子はモジュールのコンフィグレーションプロセスで自動的に含められます。

Web サービス

EJB または Web アプリケーションには、webservers.xml 記述子を含められます。これが存在する場合、モジュールは二次的記述子として WebLogic Server の Web サービスコンフィグレーション用の相当する記述子に自動的にコンフィグレーションされます。デプロイメントプランにはこうした記述子が、別個のモジュールではなくモジュールの一部として含められます。

CMP

EJB での CMP のサポートは RDBMS 記述子によってコンフィグレーションされます。RDBMS 記述子は weblogic-ejb-jar.xml 記述子内で CMP Bean 用に定義されます。RDBMS 記述子では、CMP11 および CMP20 がサポートされています。RDBMS 記述子は EJB モジュールにいくつでも含められます。この種の記述子は、アプリケーションのアーカイブまたはコンフィグレーション領域 (approot/plan) に配置します。この種の記述子はコンフィグレーションプロセスでは作成されませんが、別の記述子と同様、変更されることはあります。RDBMS 記述子はデプロイメントプランでは二次的記述子として扱われます。

JDBC

JDBC モジュールはアーカイブなしの単一のデプロイメント記述子で記述されます。モジュールが EAR の一部の場合、一連の JDBC 記述子はコンフィグレーション可能なプロパティとして weblogic-application.xml に記述されます。JDBC モジュールは WebLogic Server およびクラスタにデプロイできます。JDBC 記述子に対するコンフィグレーションの変更は、記述子のオーバーライドとして処理されます。

JDBC モジュールが EAR の一部の場合、そのコンフィグレーションのオーバーライドは EAR の一部としてデプロイメントプランに組み込まれ、別個のモジュールとしては組み込まれません。

JMS

JMS モジュールはアーカイブなしの単一のデプロイメント記述子で記述されます。モジュールが EAR の一部の場合、一連の JMS 記述子はコンフィグレーション可能なプロパティとして weblogic-application.xml に記述されます。JMS モジュールは JMS サーバにデプロイされます。JMS 記述子に対するコンフィグレーションの変更は、記述子のオーバーライドとして処理されます。JMS 記述子では「対象指定できるグループ」を識別できます。そうしたグループはデプロイメント処理中にはサブモジュールとして扱われます。

JMS モジュールが EAR の一部の場合、そのコンフィグレーションのオーバーライドは EAR の一部としてデプロイメントプランに組み込まれ、別個のモジュールとしては組み込まれません。

INTERCEPT

Intercept モジュールはアーカイブなしの単一のデプロイメント記述子で記述されます。モジュールが EAR の一部の場合、一連の Intercept 記述子はコンフィグレーション可能なプロパティとして weblogic-application.xml に記述されます。Intercept モジュールは WebLogic Server およびクラスタにデプロイされます。Intercept 記述子に対するコンフィグレーションの変更は、記述子のオーバーライドとして処理されます。

Intercept モジュールが EAR の一部の場合、そのコンフィグレーションのオーバーライドは EAR の一部としてデプロイメントプランに組み込まれ、別個のモジュールとしては組み込まれません。

対象の種類の認識

J2EE Deployment API 仕様での対象の定義では、対象の種類について特に述べられていません。WebLogic Server では、標準モジュールと Oracle 固有のモジュールのタイプが有効なデプロイメント対象としてサポートされています。対象のサポートは、weblogic.deploy.api.spi.WebLogicTarget クラスおよび weblogic.deploy.api.spi.WebLogicTargetType クラスによって提供されます。詳細については、「モジュールのタイプ」を参照してください。

TargetModuleID オブジェクト

TargetModuleID のオブジェクトではモジュールとそれに関連付けられた対象をユニークに識別します。TargetModuleID は、起動および停止されるモジュールの場所を指定するオブジェクトです。TargetModuleID を識別するために使用されるオブジェクト名は、次の形式で表されます。

Application=parent-name,Name=configured-name,Target=target-name,TWebLogicTargetType=target-type

各要素の説明は次のとおりです。

parent-name は、このモジュールが含まれる EAR の名前。
configured-name は、このアプリケーションまたはモジュールに対して WebLogic Server コンフィグレーションで使用される名前。
target-name は、モジュールが対象指定されているサーバ、クラスタ、または仮想ホスト。
target-type は、Target.getDescription から得られた対象についての説明。

TargetModuleID.toString() はこのオブジェクトの名前を返します。

WebLogic Server TargetModuleID 拡張

TargetModuleID が weblogic.deploy.api.spi.WebLogicTargetModuleID によって拡張されています。このクラスでは以下の付加機能が提供されます。

getServers - TargetModuleID の対象に関連付けられているサーバ
isOnCluster - 対象がクラスタかどうか
isOnServer - 対象がサーバかどうか
isOnHost - 対象が仮想ホストかどうか
isOnJMSServer - 対象が JMS サーバかどうか
getVersion - バージョン名
createTargetModuleID - モジュール固有の対象を作成するファクトリ

WebLogicTargetModuleID の定義の詳細については、Javadocs を参照してください。

また、WebLogicDeploymentManager も便利なメソッド群で拡張されています。それらのメソッド群を使用すると TargetModuleID との連携が容易になります。このようなユーティリティには以下の 2 つがあります。

filter - アプリケーション、モジュール、バージョンに一致する TargetModuleIDs のリストを返す
getModules - AppDeploymentMBean に基づいて TargetModuleIDs を作成する

TargetModuleID 群にはベースとするアプリケーションに基づく階層関係があります。アプリケーションのルート TargetModuleID は、EAR モジュールまたはスタンドアロンモジュールを表します。子 TargetModuleID 群は、ルートモジュールの記述子で定義されているモジュール群です。EAR の場合、その EAR の application.xml 記述子で定義されているモジュールになります。JMS モジュールには、JMS デプロイメント記述子に定義されている子 TargetModuleID (サブモジュール) が存在することもあります。それらは組み込みモジュールの子またはルートモジュールの子の場合があります。したがって、JMS モジュールではアプリケーションの 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>

サンプルモジュールのデプロイメント

サブモジュールを持つスタンドアロン JMS モジュールのデプロイメントについて考察します。このモジュールは simple-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);