Oracle® Fusion Middleware

WebLogic Deployment APIによるアプリケーションのデプロイ

12c (12.2.1.2.0)

E82899-02(原本部品番号:E77960-02)

2016年12月

このドキュメントでは、WebLogic Serverアプリケーションに対してプログラム的なデプロイメント操作の実施、WebLogicデプロイメントAPIについて説明します。

Oracle Fusion Middleware WebLogic Deployment APIによるアプリケーションのデプロイ, 12c (12.2.1.2.0)

E82899-02

Copyright © 2007, 2016, Oracle and/or its affiliates. All rights reserved.

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- ドキュメントのアクセシビリティについて

- 表記規則

1 概要とロードマップ

- ドキュメントのスコープと対象読者

- このドキュメントの手引き

- 関連ドキュメント

- このリリースでの新機能と変更点

2 WebLogicデプロイメントAPIの理解

- WebLogicデプロイメントAPI

- WebLogicデプロイメントAPIのデプロイメントのフェーズ

- デプロイメントのためにアプリケーションの構成

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

- WebLogicデプロイメントAPIのweblogic.Deployer実装

- WebLogicデプロイメントAPIを使用する場合

- Java EEデプロイメントAPIコンプライアンス

- WebLogic Serverのデプロイメントの付加価値機能

- Service Provider Interfaceパッケージ

- weblogic.deploy.api.spi

- weblogic.deploy.api.spi.factories

- モジュールのターゲット指定

- WebLogicターゲット・タイプの問合せサポート

- サーバーのステージング・モード

- デプロイメント・プランのステージング・モード

- DConfigBean検証

- Modelパッケージ

- weblogic.deploy.api.model

- デプロイメント記述子へのアクセス

- Sharedパッケージ

- weblogic.deploy.api.shared

- デプロイ用、更新用のコマンド・タイプ

- モジュールのタイプのサポート

- 全種類のWebLogic Serverターゲットのサポート

- Toolsパッケージ

- weblogic.deploy.api.tools

- SessionHelper

- デプロイメント・プランの作成

- デプロイメント操作用のJMX API

- サポート対象のデプロイメント・オプション

- デプロイメント操作用のJMX APIの使用

- WebLogic Serverでのデプロイメント検証プラグインの使用方法

- デプロイメント検証プラグインの構成

- デプロイメント検証プラグインの使用方法

3 デプロイメントのためのアプリケーションの構成

- 構成プロセスの概要

- 構成情報の種類

- Java EEの構成

- WebLogic Server構成

- Java EE構成情報、WebLogic Server構成情報の表現

- DDBean

- Java EE記述子とWebLogic Server記述子の関係

- DConfigBean

- アプリケーション評価

- デプロイメント・マネージャの取得

- デプロイメント・マネージャの種類

- 接続および切断されたデプロイメント・マネージャのURI

- SessionHelperを使用したデプロイメント・マネージャの取得

- デプロイ可能なオブジェクトの作成

- WebLogicDeployableObjectクラスの使用

- SessionHelperを使用してデプロイ可能なオブジェクトの取得

- フロントエンド構成の実行

- フロントエンド構成

- デプロイメント構成

- サンプル・コード

- SessionHelperで情報を読み取る

- 構成の検証

- デプロイメント構成のカスタマイズ

- 構成属性の変更

- Target

- アプリケーションの命名

- デプロイメント準備

- セッションのクリーン・アップ

4 デプロイメント操作の実行

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

- DeploymentManagerの割当

- DeploymentManagerオブジェクトの取得

- DeploymentManager URI実装の理解

- サーバー接続

- デプロイメントの手続き

- DeploymentOptions

- 配布

- アプリケーションの起動

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

- アプリケーションの停止

- アンデプロイメント

- 本番再デプロイメント

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

- モジュール・レベルのターゲット指定

- 廃止ポリシー

- バージョンのサポート

- 管理(テスト)モード

- 進捗状況のレポート

- Targetオブジェクト

- モジュールのタイプ

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

- Webサービス

- CMP

- JDBC

- JMS

- INTERCEPT

- ターゲット・タイプの認識

- TargetModuleIDオブジェクト

- WebLogic Server TargetModuleID拡張

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

はじめに

ここでは、このガイド『WebLogic Deployment APIによるアプリケーションのデプロイ』で使用されるアクセシビリティ機能および表記規則について説明します。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害があるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。

表記規則

このドキュメントでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

斜体

イタリックは、ユーザーが特定の値を指定するプレースホルダー変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 概要とロードマップ

この章では、『WebLogic Deployment APIによるアプリケーションのデプロイ』の内容と構成について説明します。

この章の内容は次のとおりです。

- ドキュメントのスコープと対象読者

- このドキュメントの手引き

- 関連ドキュメント

- このリリースでの新機能と変更点

ドキュメントのスコープと対象読者

このドキュメントは以下の読者を対象にしています。

- WebLogicデプロイメントAPIの理解を目的としたソフトウェア開発者。このAPIはJava EEデプロイメントAPI標準(JSR-88、http://jcp.org/en/jsr/detail?id=88を参照)に記述された仕様に準拠し、この標準で提供されるインタフェースを拡張するものです。

- WebLogic Serverアプリケーションに対してプログラム的なデプロイメント操作の実施を検討している開発者。

- WebLogic Serverを評価したり、WebLogicデプロイメントAPIの使用を検討しているシステム設計者。

- ソフトウェア・プロジェクトの設計、デプロイメント、テスト、および本番前のフェーズの担当者。本番フェーズでの管理、モニター、WebLogicデプロイメントAPIでのアプリケーション・パフォーマンスのチューニングについては直接的には取扱いません。このデプロイメントAPIには本番フェーズでソフトウェアを更新するユーティリティもありますが、これはすでに利用できるデプロイメント・ツールの機能を反映したものです。

このドキュメントでは、以下の内容に重点を置いています。

- WebLogicデプロイメントAPIの付加価値機能

- WebLogicデプロイメントAPIによるアプリケーション・デプロイメントの管理方法

このマニュアルは、Java EEの概念、http://www.jcp.org/en/jsr/detail?id=088のJava EEデプロイメントAPI標準(JSR-88)、Javaプログラミング言語、Enterprise Java Bean (EJB)、およびWeb技術に精通している読者を対象としています。

このドキュメントの手引き

- この章「概要とロードマップ」では、このマニュアルの構成を紹介します。

- 「WebLogicデプロイメントAPIについて」では、WebLogicデプロイメントAPIのパッケージ、インタフェース、およびクラスについて説明します。この項では、Java EEデプロイメントAPI標準(JSR-88、http://jcp.org/en/jsr/detail?id=88を参照)の拡張、ユーティリティ、ヘルパー・クラスおよびWebLogic Serverデプロイメントの新しい概念についても記載しています。

- 「デプロイメントのためのアプリケーションの構成」では、WebLogic Serverへのデプロイメントのためにアプリケーションまたはデプロイ可能なリソースを準備するプロセスについて説明します。

- 「デプロイメント操作の実行」では、デプロイメントのライフサイクルとデプロイされたアプリケーションの制御について説明します。

関連ドキュメント

アプリケーションおよびモジュールのWebLogic Serverへのデプロイの詳細は、次のドキュメントを参照してください。

- 『Oracle WebLogic Serverアプリケーションの開発』では、wldeploy Antタスクを使用して開発中にアプリケーションをデプロイする方法を説明し、エンタープライズ・アプリケーションのWebLogic Serverデプロイメント記述子に関する情報を提供します。

- WebLogic Server Java EEプログラミングに関するガイド群。各Java EEアプリケーションおよびモジュールで使用されるJava EEおよびWebLogic Serverデプロイメント記述子について説明します。

- 『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』

- 『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発』

- 『Oracle WebLogic Serverリソース・アダプタの開発』

- 『Oracle WebLogic Server JAX-WS Webサービスの開発』

- Oracle WebLogic Serverへのアプリケーションのデプロイ

- 『Oracle WebLogic Server JDBCアプリケーションの開発』では、JDBCアプリケーション・モジュールのXMLデプロイメント記述子について説明します。

- 『Oracle WebLogic Server JMSアプリケーションの開発』では、JMSアプリケーション・モジュールのXMLデプロイメント記述子について説明します。

このリリースでの新機能と変更点

このリリースで導入されたWebLogic Serverの総合的な新機能一覧は、『Oracle WebLogic Serverの新機能』 12.2.1.2.0を参照してください。

2 WebLogicデプロイメントAPIの理解

この章では、Java EEデプロイメントAPI仕様(JSR-88)を実装および拡張するWebLogicデプロイメントAPIの構造および機能について説明します。また、デプロイメント操作用のJMX APIについても説明します。これは、JSR-88の代替として使用できます。

この章の内容は以下のとおりです。

- WebLogicデプロイメントAPI

- Java EEデプロイメントAPIコンプライアンス

- WebLogic Serverのデプロイメントの付加価値機能

- Service Provider Interfaceパッケージ

- Modelパッケージ

- Sharedパッケージ

- Toolsパッケージ

- デプロイメント操作用のJMX API

- WebLogic Serverでのデプロイメント検証プラグインの使用方法

JSR-88の詳細は、http://jcp.org/en/jsr/detail?id=88を参照してください。

WebLogicデプロイメントAPI

注意:

WebLogic Server 9.0では、旧リリースで使われていたweblogic.management.deploy APIの使用は非推奨になっています。

次の項では、WebLogic ServerデプロイメントAPIの概要を説明します。

- WebLogicデプロイメントAPIのデプロイメントのフェーズ

- WebLogicデプロイメントAPIのweblogic.Deployer実装

- WebLogicデプロイメントAPIを使用する場合

WebLogicデプロイメントAPIのデプロイメントのフェーズ

Java EEデプロイメントAPI仕様(JSR-88、http://jcp.org/en/jsr/detail?id=88を参照)では、構成セッションとデプロイメントは違うものとされています。この2つは次のように区別されています。

- デプロイメント・プランの記述子を生成するアプリケーションの構成

- 配布、起動、停止、再デプロイ、アンデプロイなどのデプロイメント・タスク

お使いの環境でデプロイメント・プロセスを効率的に管理するには、WebLogicデプロイメントAPIを使用して、以下を実行する必要があります。

- デプロイメントのためにアプリケーションの構成

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

デプロイメントのためにアプリケーションの構成

このドキュメントでは、構成という用語は、WebLogic Serverインスタンスへのデプロイメントのためにアプリケーションまたはデプロイ可能なリソースを準備するプロセスのことを指します。アプリケーションの構成は、次のフェーズで構成されています。

- アプリケーション評価 - アプリケーション・ファイルを検査および評価して、アプリケーションの構造と埋込み記述子の内容を決定します。「アプリケーション評価」を参照してください。

- フロントエンド構成 - アプリケーションに埋め込まれている情報に基づいて構成情報を作成します。この情報には、WebLogic Server記述子、デフォルト、ユーザー定義によるデプロイメント・プランなどがあります。「フロントエンド構成の実行」を参照してください。

- デプロイメント構成 - ユーザー入力および選択されたWebLogic Serverターゲットに基づいて、個別のWebLogic Server構成の値を変更します。「デプロイメント構成のカスタマイズ」を参照してください。

- デプロイメントの準備 - 最終的なデプロイメント・プランを生成し、クライアント側でアプリケーションを事前に検証します。「デプロイメントの準備」を参照してください。

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

アプリケーションのデプロイメントは、サーバー側処理とアプリケーションの起動のために管理サーバーにアプリケーションとプランを配布するプロセスです。「デプロイメント操作の実行」を参照してください。

WebLogicデプロイメントAPIのweblogic.Deployer実装

WebLogic Serverでは、パッケージ化されたデプロイメント・ツールwebLogic.Deployerが提供されています。このツールを使用すると、WebLogic Serverでデプロイメント・サービスを利用できます。WebLogicデプロイメントAPIを使用して実装できるデプロイメント操作は、weblogic.Deployerによって部分的に、または完全に実装されています。

WebLogicデプロイメントAPIを使用する場合

注意:

weblogic.Deployerは、WebLogic Server環境にお薦めするデプロイメント・ツールです。weblogic.DeployerおよびWebLogic Server管理コンソールの使用方法は、「Oracle WebLogic Serverへのアプリケーションのデプロイ」を参照してください。

WebLogicデプロイメントAPIは以下の場合に必要になります。

- 独自の実装をモデル化し、WebLogicサービス・プロバイダ・インタフェース(SPI)とインタフェースさせる必要がある場合。この場合、WebLogicデプロイメントAPIデプロイメント・ファクトリを使用してWebLogicDeploymentManagerを取得します。これは、weblogic.deploy.api.spiと併用するためのjavax.enterprise.deploy.spi.DeploymentManagerの拡張です(http://docs.oracle.com/javaee/7/api/javax/enterprise/deploy/spi/DeploymentManager.htmlを参照)。「アプリケーション評価」およびJava EEデプロイメントAPI仕様(http://jcp.org/en/jsr/detail?id=88)を参照してください。

- WebLogic Server管理コンソールまたはweblogic.Deployerを使用するかわりに、独自のデプロイメント・インタフェースを作成する必要がある場合。この場合、WebLogicデプロイメントAPIのクラスおよびインタフェースを使用して、「WebLogicデプロイメントAPIのデプロイメントのフェーズ」の一部またはすべてを実装します。

Java EEデプロイメントAPIコンプライアンス

WebLogicデプロイメントAPIのクラスおよびインタフェースは、javax.enterprise.deployサブパッケージに記述されているJava EEデプロイメントAPI仕様(JSR-88)インタフェースを拡張および実装します(http://docs.oracle.com/javaee/7/api/overview-summary.htmlを参照)。WebLogicデプロイメントAPIには、以下のパッケージが提供されています。

- weblogic.deploy.api.spi

- weblogic.deploy.api.spi.factories

- weblogic.deploy.api.model

- weblogic.deploy.api.shared

- weblogic.deploy.api.tools

WebLogic Serverのデプロイメントの付加価値機能

WebLogicでは、http://jcp.org/en/jsr/detail?id=88のJava EEデプロイメントAPI仕様(JSR-88)に記述されている「製品プロバイダ」のロールをサポートし、任意のJava EEネットワーク・クライアント用の拡張可能なコンポーネントに加えて、WebLogic Server環境固有のユーティリティも用意されています。そうした拡張機能には、以下のようなものがあります。

- WebLogicの各種機能のサポート。adminモードでの起動や、バージョニング機能付きの再デプロイなどがあります。

- 以下のようなきめ細かなレベルでの制御。

- モジュール・レベルのターゲット指定

- 部分的な再デプロイメント(アプリケーションの一部の再デプロイメントまたは削除)

- 動的な構成変更

- JMS、JDBC、インターセプション、アプリケーション固有の構成(カスタムまたは構成)モジュールなど、WebLogicモジュール拡張のサポート。

- 付加的な操作。distributeとstartを組み合わせたDeployという動詞などがあります。

注意:

WebLogicデプロイメントAPIでは、アプリケーションの更新に失敗した際の自動フォールバック手続きはサポートされていません。この動作のポリシーと手続きは、各デプロイメント環境の開発者または管理者が定義し、構成する必要があります。

Service Provider Interfaceパッケージ

OracleはJava EE製品プロバイダとして、javax Service Provider Interface (SPI)パッケージを拡張して、WebLogic Server固有の構成とデプロイ制御を提供しています。このパッケージのコア・インタフェースはDeploymentManagerであり、ここから他のすべてのデプロイメント・アクティビティを開始、モニターおよび制御します。

WebLogicDeploymentManagerインタフェースは、javax.enterprise.deploy.spi.DeploymentManagerインタフェースに対してWebLogic Server拡張を提供します。WebLogicDeploymentManagerのオブジェクトではWeblogic Serverデプロイメント・フレームワークがステートレスでインタフェースされます。これにより、基本的なデプロイメント機能に加えて、本番再デプロイメント、エンタープライズ・アプリケーション内のモジュールの部分的なデプロイメントなどの幅広いWebLogic Serverデプロイメント機能が実現します。WebLogicDeploymentManagerオブジェクトは、通常ToolsパッケージのSessionHelperヘルパー・クラスからSessionHelper.getDeploymentManagerメソッドを使用して取得します。「アプリケーション評価」を参照してください。

次の項では、WebLogic Server SPIの機能の概要について説明します。

- weblogic.deploy.api.spi

- weblogic.deploy.api.spi.factories

- モジュールのターゲット指定

- WebLogicターゲット・タイプの問合せサポート

- サーバーのステージング・モード

- デプロイメント・プランのステージング・モード

- DConfigBean検証

weblogic.deploy.api.spi

weblogic.deploy.api.spiパッケージには、ターゲットにアプリケーションを構成およびデプロイするために必要なインタフェースが用意されています(有効なターゲット・タイプは、「WebLogicターゲット・タイプの問合せサポート」を参照してください)。このパッケージを使用すると、エンタープライズ・アプリケーションまたはスタンドアロン・モジュールのWebLogic Server固有のデプロイメント構成を実装できるデプロイメント・ツールを作成できます。

weblogic.deploy.api.spiには、WebLogicDeploymentManagerインタフェースが含まれています。このデプロイメント・マネージャを使用して、WebLogic Serverでのすべてのデプロイメント関係の操作(アプリケーションの配布、起動、停止など)を実行します。WebLogicDeploymentManagerでは、Java EE DeploymentManagerインタフェースの重要な拡張で、エンタプライズ・アプリケーション・モジュールのモジュール・レベルのターゲット指定、本番再デプロイメント、アプリケーションのバージョニング、アプリケーションのステージング・モード、デプロイされたアプリケーションへの管理アクセスの制約などの機能が提供されます。

weblogic.deploy.api.spiパッケージのWebLogicDeploymentConfigurationクラスおよびWebLogicDConfigBeanクラスで、アプリケーションのデプロイメントおよび構成の記述子(WebLogic Serverデプロイメント記述子)が表されます。

- WebLogicDeploymentConfigurationオブジェクトはデプロイメント・プランのラッパー。

- WebLogicDConfigBeanには、Weblogicデプロイメント記述子のプロパティがカプセル化されます。

weblogic.deploy.api.spi.factories

このパッケージに含まれるインタフェースはWebLogicDeploymentFactoryのみです。これは、javax.enterprise.deploy.spi.factories.DeploymentFactoryのWebLogic拡張です。このファクトリ・インタフェースを使用すると、様々な特性を持つDeploymentManagerオブジェクトを選択して割り当てられます。WebLogicDeploymentManagerの特性は、このWebLogicDeploymentFactoryのpublicフィールドで定義されます。

モジュールのターゲット指定

モジュールのターゲット指定とは、アプリケーション内の特定のモジュールを別のターゲットにデプロイすることです(JSR-88の仕様にある、すべてのモジュールを同じターゲットのセットにデプロイする処理とは異なります)。モジュールのターゲット指定は、WebLogicDeploymentManager.createTargetModuleIDメソッドによってサポートされています。

WebLogicTargetModuleIDクラスには、javax.enterprise.deploy.spi.TargetModuleIDインタフェースのWebLogic Server拡張が含まれています。このクラスは、構成されたTargetInfoMBeans(AppDeploymentMBeanおよびSubDeploymentMBean)と密接に関連しています。WebLogicTargetModuleIDクラスには、アプリケーション・モジュールについて、またアプリケーション・モジュールとそのターゲットとの関係について、TargetInfoMBeansにあるよりも詳細に記述されます。「モジュールのタイプ」を参照してください。

WebLogicターゲット・タイプの問合せサポート

WebLogic Serverでは、WebLogicTargetクラスにWebLogic Serverで使用できるターゲット・タイプを管理するための直接インタフェースが提供されています。表2-1で、ターゲット・アクセサ・メソッドについて説明します。

表2-1ターゲット・アクセサ・メソッド

メソッド

説明

boolean isCluster()

このターゲットがクラスタかどうかを示します。

boolean isJMSServer()

このターゲットがJMSサーバーかどうかを示します。

boolean isSAFAgent()

このターゲットがSAFエージェントかどうかを示します。

boolean isServer()

このターゲットがサーバーかどうかを示します。

boolean isVirtualHost()

このターゲットが仮想ホストかどうかを示します。

サーバーのステージング・モード

アプリケーションのステージング・モードは、デプロイメントの動作に影響します。アプリケーションのステージング動作は、DeploymentOptions.setStageMode (stage mode)を使用して設定されます。stage modeの値は以下のいずれかになります。

- STAGE - ターゲット・サーバーにファイルが強制的にコピーされます。

- NO_STAGE - ターゲット・サーバーにファイルがコピーされません。

- EXTERNAL_STAGE - ファイルを手動でステージングします。

デプロイメント・プランのステージング・モード

アプリケーションのデプロイメント・プランは、アプリケーション・アーカイブとは別個にステージングできます。これにより、アプリケーションがステージングされていない場合に、デプロイメント・プランをステージングできます。DeploymentOptions.setPlanStageMode (plan stage mode)を使用してデプロイメント・プランのステージング動作を構成できます。この場合、plan stage modeの値は次のいずれかになります。

- STAGE - デプロイメント・プランがターゲット・サーバーにコピーされます。

- NO_STAGE - デプロイメント・プランはターゲット・サーバーにコピーされません。

- EXTERNAL_STAGE - デプロイメント・プランがターゲット・サーバーに手動でコピーされます。

ステージング・モードを指定しない場合は、デプロイメント・プランでは、アプリケーションのステージングに指定された値がデフォルトで使用されます。たとえば、デプロイメント・プランのステージングが指定されておらず、アプリケーション・ステージングがSTAGEに設定されている場合は、デプロイメント・プランのステージング・モードはSTAGEに設定されます。

DConfigBean検証

DConfigBeanのプロパティ・セッターでは、無効な値の設定が拒否されます。これには、プロパティの型の検証(整数型プロパティに対する非数値の指定の検証など)が含まれます。一部のプロパティでは、セマンティックな検証(関連する最小値よりも最大値が小さく指定されていないことの確認など)が行われます。

Modelパッケージ

これらのクラスは、javax.enterprise.deploy.modelインタフェースのWebLogic Server拡張および実装です(http://docs.oracle.com/javaee/7/api/javax/enterprise/deploy/model/package-summary.htmlを参照)。modelインタフェースでは、Java EEアプリケーションの標準的な要素(デプロイメント記述子など)を表現します。

- weblogic.deploy.api.model

- デプロイメント記述子へのアクセス

weblogic.deploy.api.model

このパッケージには、デプロイ可能なオブジェクトのJava EE構成を表すために使用されるインタフェース群が含まれています。デプロイ可能なオブジェクトとは、エンタープライズ・アプリケーションまたはスタンドアロン・モジュールのデプロイメント・コンテナです。

javax.enterprise.deploy.modelインタフェースのWebLogic Server実装を使用すると、WebLogic Serverアプリケーション・インストール・ディレクトリに格納されているアプリケーションで作業できます。WebLogic Serverアプリケーション・インストール・ディレクトリとは、構成プロセスで生成される、アプリケーションのデプロイメント・ファイル、デプロイメントおよび外部WebLogicデプロイメント記述子の管理に使用する正式なディレクトリ構造です。アプリケーション・インストール・ディレクトリの配置の詳細は、アプリケーションおよびモジュールのデプロイメント準備を参照してください。任意のJava EEアプリケーションと、(拡張として)アプリケーション・インストール・ディレクトリにあるサポート・アプリケーションがサポートされています。

注意:

weblogic.deploy.api.modelでは、Java EEデプロイメント記述子要素に対する構成中の動的な変更がサポートされません。したがって、XPathリスナーの登録および削除はサポートされません。DDBean.addXPathListenerおよびremoveXPathListenerはサポートされていません。

weblogic.deploy.api.modelパッケージのWebLogicDeployableObjectクラスとWebLogicDDBeanインタフェースで、アプリケーションの標準的なデプロイメント記述子が表現されます。

デプロイメント記述子へのアクセス

Java EEデプロイメントAPIでは、Java EEデプロイメント記述子にはDeployableObjectを介してアクセスするように規定されています(http://docs.oracle.com/javaee/7/api/javax/enterprise/deploy/model/DeployableObject.htmlを参照)。DeployableObjectはアプリケーション内のモジュールを表します。記述子の要素はDDBeansで表されます。デプロイメント記述子の各要素に1つのDDBeanが対応します。記述子のルート要素はDDBeanRootオブジェクトで表されます。これらのインタフェースはすべて、対応するこのパッケージのインタフェースおよびクラス内に実装されます。

DeployableObjectのWebLogic Server実装であるWebLogicDeployableObjectクラスには、createDeployableObjectメソッドがあり、これらのメソッドでアプリケーションのデプロイメント記述子のWebLogicDeployableObjectおよびWebLogicDDBeanを作成します。基本的な構成タスクを実行するには、WebLogicDDBeanをWebLogicDConfigBeanに関連付けます。WebLogicDConfigBeanはWebLogic Serverへのアプリケーションのデプロイに必要なサーバー構成のプロパティを表しています。「アプリケーション評価」を参照してください。

サーバー環境(この場合はWebLogic Serverインスタンス)の具体的な構成情報を格納するDConfigBeanと異なり、DDBeanオブジェクトにはアプリケーションの一般的なデプロイメント記述子要素が格納されます。たとえば、Webアプリケーションをデプロイする場合、WebLogicDDBeansのデプロイメント記述子は、.warアーカイブのWEB-INF/web.xmlファイルから取得されます。WebLogicDConfigBeansの情報は、WebLogicDDBeansに基づいて.warアーカイブのWEB-INF/weblogic.xmlから取得されます。これらのBeanは構成情報を保持するという基本的な目的については同じですが、論理的には異なるものです。DDBeanではアプリケーションについて記述され、DConfigBeansでは特定の環境に対してアプリケーションが構成されます。

これらのオブジェクトは両方とも構成セッションを開始するときに生成されます。WebLogicDeployableObject、WebLogicDDBeans、およびWebLogicDConfigBeansはすべて構成セッションの中でインスタンス化され、操作されます。「構成プロセスの概要」を参照してください。

Sharedパッケージ

次の項では、WebLogic Server固有のデプロイメント・コマンド、モジュールのタイプ、および(クラスとしての)ターゲット・タイプを表現する一連のクラスについて説明します。

- weblogic.deploy.api.shared

- デプロイ用、更新用のコマンド・タイプ

- モジュールのタイプのサポート

- 全種類のWebLogic Serverターゲットのサポート

weblogic.deploy.api.shared

weblogic.deploy.api.sharedパッケージには、WebLogic Server固有のデプロイメント・コマンド、モジュールのタイプ、および(クラスとしての)ターゲット・タイプを表す一連のクラスが用意されています。これらのクラスのオブジェクトはweblogic.deploy.api.modelパッケージおよびweblogic.deploy.api.spiパッケージで共有できます。

標準のjavax.enterprise.deploy.sharedクラスにあるModuleTypeおよびCommandTypeの定義は、以下をサポートするように拡張されています。

- モジュールのタイプ。「モジュールのタイプのサポート」を参照してください。

- コマンド。「デプロイ用、更新用のコマンド・タイプ」を参照してください。

Java EEデプロイメントAPI仕様(JSR-88、http://jcp.org/en/jsr/detail?id=88を参照)で必須ではないWebLogicTargetTypeクラスでは、WebLogic Serverでサポートされる多様なデプロイメント・ターゲット・タイプが列挙されます。このクラスでjavaxのデプロイメント・クラスが拡張されません。「すべてのタイプのWebLogic Serverターゲットのサポート」を参照してください。

デプロイ用、更新用のコマンド・タイプ

javax.enterprise.spi.sharedパッケージに定義されている必須のコマンド・タイプに、deployとupdateのコマンド・タイプが追加され、WebLogicDeploymentManagerから利用できます。

モジュールのタイプのサポート

サポートされているモジュールのタイプには、JMS、JDBC、インターセプション、WSEE、構成、およびWLDFがあります。これらはweblogic.deploy.api.shared.WebLogicModuleTypeクラスにフィールドとして定義されています。

全種類のWebLogic Serverターゲットのサポート

Java EEデプロイメントAPI仕様では実装されていないターゲットはWebLogicデプロイメントAPIで実装されます。有効なターゲットの値は以下のとおりです。

- クラスタ

- JMSサーバー

- ストア・アンド・フォワード(SAF)エージェント

- サーバー

- 仮想ホスト

これらは、weblogic.deploy.api.shared.WebLogicTargetTypeクラスの列挙フィールドの値です。

Toolsパッケージ

次の項では、最小限の制御および明示的なオブジェクト操作で一般的なデプロイメント・ツールのタスクを実行できるAPIツールについて説明します。

- weblogic.deploy.api.tools

- SessionHelper

- デプロイメント・プランの作成

weblogic.deploy.api.tools

weblogic.deploy.api.toolsには、コンビニエンス・クラスが用意されています。

- WebLogicDeploymentManagerの取得

- アプリケーションの構成の入力

- デプロイメント・プランの新規作成または更新

ツール・パッケージのクラス群は、Java EEデプロイメントAPI仕様(JSR-88、http://jcp.org/en/jsr/detail?id=88を参照)インタフェースの拡張ではありません。これらのクラス群を使用すると、WebLogicデプロイメントAPIで提供されるデプロイメント操作に簡単にアクセスできます。

SessionHelper

構成セッションはWebLogicDeploymentManagerから直接制御することもできますが、制御を簡単に実行できるメソッドがSessionHelperに用意されています。使用しているツールで直接WebLogic Server Java EEデプロイメントAPI実装に対してコーディングする場合、必ずSessionHelperを使用する必要があります。

SessionHelperを使用すると、1回のメソッド呼出しでWebLogicDeploymentManagerを取得できます。この作業を効率的に行うには、アプリケーションを検索できる必要があります。SessionHelperでは「インストール・ルート」抽象を使用してアプリケーションとデプロイメント・プランのアーティファクトを表示します。これは理想的には実際のアプリケーションの構成です。インストール・ルートは次のように表示されます。

install-root (eg myapp)
-- app
----- archive (eg myapp.ear)
-- plan
----- deployment plan (eg plan.xml)
----- external descriptors (eg META-INF/weblogic-application.xml...)

アプリケーションは上記の構成でなくてもかまいません。ただし、アプリケーションと構成アーティファクトは共通のルートに保持するのが推奨されるアプローチです。そうすることでSessionHelperで解釈できる形式になります。

SessionHelper.getModuleInfo()では、アプリケーション構造の理解に役立つオブジェクトが返されます。この場合、DDBeansおよびDeployableObjectsを直接扱う必要がありません。次のような情報が提供されます:

- アプリケーション内のモジュールおよびサブモジュールの名前およびタイプ

- アプリケーションで提供されるWebサービスの名前

- Webアプリケーションのコンテキスト・ルート

- EJBのエンタープライズBean名

デプロイメント記述子は、内部的には記述子Beanのツリー(個々の記述子要素を表す型付きのJava Beanオブジェクトのツリー)として表現されます。こうしたBeanツリーを使用すると、より一般的なDDBeanおよびDConfigBeanオブジェクトを扱うよりも簡単に処理できます。各モジュールの記述子Beanツリーには、関連する各モジュールのWebLogicDDBeanRootオブジェクトおよびWebLogicDConfigBeanRootオブジェクトから、それらのオブジェクトにあるgetDescriptorBeanメソッドを使用して直接アクセスできます。WebLogicDConfigBeanから取得したBeanツリーを変更すると、関連付けられたDConfigBean (したがってアプリケーションのデプロイメント・プラン)を変更するのと同じ結果が得られます。

デプロイメント・プランの作成

weblogic.PlanGeneratorを使用すると、アプリケーション内にあるJava EEおよびWebLogic Server記述子に基づいてデプロイメント・プランのテンプレートを作成できます。結果として作成されるプランによりアプリケーションの構造が記述され、すべてのデプロイメント記述子が特定されて、アプリケーションの構成可能なプロパティのサブセットがエクスポートされます。プロパティがエクスポートされると、そのプロパティはWebLogic Serverコンソールのようなツールに対して公開されます。そうしたツールではプランを使用して、管理者がプロパティに適切な値を指定できるように支援します。weblogic.PlanGeneratorツールからは、デフォルトではアプリケーションの依存関係、つまり正常なデプロイメントに必要なプロパティのみがエクスポートされます。この動作は以下のオプションの1つを用いてオーバーライドできます。

- Dependencies: アプリケーションで参照するリソースをエクスポートします(デフォルト)

- Declarations: アプリケーションで定義されているリソースをエクスポートします

- Configurables: 非リソース指向の構成可能なプロパティをエクスポートします

- Dynamics: 実行中のアプリケーションで変更される可能性があるプロパティをエクスポートします

- All: すべての変更可能なプロパティをエクスポートします

- None: プロパティをエクスポートしません

デプロイメント操作用のJMX API

デプロイメント操作用のJava Management Extensions (JMX) APIでは、Java EEデプロイメントAPI仕様(JSR-88)で使用可能な一般的な機能すべてをサポートしています。JMX APIをJSR-88の代替として使用し、指定したターゲット・サーバーで、次のようなデプロイメント・タスクを実行できます。

- 起動

- 停止

- 配布

- デプロイ

- 再デプロイ

- アンデプロイ

- アプリケーションの再デプロイなしのデプロイメント・プランの更新

デプロイメント操作用のJMX APIでは、オープンMBeanデータ・タイプを使用するため、クライアント側ではWebLogic Serverクラスは必要ありません。デプロイメント用のこれらの新しいMBeansは、JSR-88と概念的に類似しており、ドメイン実行時MBeanサーバーに存在します。このモデルでは、管理サーバーでデプロイメント操作を開始する必要があります。

次の4つの実行時MBeansでは、デプロイメント操作用のJMX APIをサポートしています。

- DeploymentManagerMBean
DeploymentManagerMBeanでは、デプロイや配布などのデプロイメント操作を提供します。また、ドメインにデプロイされた各アプリケーションのAppDeploymentRuntime MBeanにもアクセスできます。さらに、デプロイメント進行状況オブジェクトを管理し、アプリケーションが作成または削除された場合やアプリケーションの状態が変更された場合に、通知を表示します。

- AppDeploymentRuntimeMBean
AppDeploymentRuntimeMBeanでは、起動、停止、アンデプロイ、再デプロイ、およびアプリケーションの再デプロイなしのデプロイメント・プランの更新などの、アプリケーションのデプロイメント操作を提供します。

- DeploymentProgressObjectMBean
DeploymentProgressObjectMBeanでは、AppDeploymentRuntime MBeanによって開始されたデプロイメント操作をモニターします。

- LibDeploymentRuntimeMBean
LibDeploymentRuntimeMBeanでは、アンデプロイや再デプロイなどの、ライブラリのデプロイメント操作を提供します。

詳細は、Oracle WebLogic Server MBeanリファレンスを参照してください。

サポート対象のデプロイメント・オプション

デプロイメント操作用のJMX APIでは、JSR-88で使用可能なすべてのデプロイメント・オプションをサポートしています。これらは、Propertyの名前/値ペアとして指定されます。デプロイメント・オプションを指定することにより、デフォルト値をオーバーライドできます。表 2-2に、サポート対象のデプロイメント・オプションの名前と値の概要を示します。

表2-2 JMX APIでサポートされているデプロイメント・オプション

デプロイメント・オプション

説明

adminMode

実行中のアプリケーションをADMINモードに切り替えて、構成済の管理チャネル経由での管理リクエストのみを受け付けることを指定するオプション。

altDD

管理サーバーにある、代替アプリケーション・デプロイメント記述子の場所。

altWlsDD

管理サーバーにある、代替WebLogicアプリケーション・デプロイメント記述子の場所。

appVersion

アプリケーションのバージョン識別子。

clusterDeploymentTimeout

このアプリケーションでクラスタのデプロイメント・タスクに付与されている時間(ミリ秒単位)。

createPlan

ユーザーがデフォルト・プランを作成することを示すブール値。このオプションのデフォルト値はfalseです。

defaultSubmoduleTargets

条件を満たすJMSサブモジュールのターゲット指定がシステムによって導出される必要があることを示すブール値。このオプションのデフォルト値はtrueです。

deploymentOrder

相互に関連するデプロイメントのロード順序を制御するオプション。

deploymentPrincipalName

サーバーの起動時にファイルまたはアーカイブをデプロイするときに使用されるプリンシパルを示す文字列値(静的デプロイメントであるため、現在のデプロイメント・タスクには影響を与えません)。

forceUndeployTimeout

アンデプロイメントのタイムアウト値を強制します。

gracefulIgnoreSessions

本番モードからADMINモードへの正常な移行の際に保留中のHTTPセッションを無視するかどうかを指定するブール値。このオプションのデフォルト値はfalseで、gracefulProductionToAdminがtrueに設定されている場合にのみ適用されます。

gracefulProductionToAdmin

本番モードからADMINモードへの移行を正常に行う必要があるかどうかを指定するブール値。このオプションのデフォルト値はfalseです。

library

共有Java EEライブラリまたはオプション・パッケージとしてのデプロイメント。

libImplVer

ライブラリの実装バージョン(マニフェストにない場合)。

libSpecVer

ライブラリの仕様バージョン(マニフェストにない場合)。

noVersion

バージョニング情報は無視されます。

planVersion

デプロイメント・プランのバージョン識別子。

retireGracefully

すべての処理中の作業が完了した後にのみ、アプリケーションを正常にリタイアするためのリタイア・ポリシー。このポリシーは停止および再デプロイ操作でのみ意味があり、リタイアされたタイムアウト・ポリシーと相互に排他的になります。

retireTimeout

新しいバージョンで置き換えられたアプリケーションをリタイアする前にWebLogic Serverが待機する時間(秒単位)。このオプションのデフォルト値は-1で、正常なタイムアウトを指定します。

rmiGracePeriod

正常停止または廃止の際にRMIの猶予期間内でRMIリクエストの受信がなくなるまで、ワーク・マネージャがRMI呼出しを受け付けてスケジューリングする時間(秒単位)。

securityModel

セキュリティ・モデル。有効な値はDDOnly、CustomRoles、CustomRolesAndPolicies、およびAdvancedです。

securityValidationEnabled

セキュリティ検証を有効にするかどうかを指定するブール値。

stageMode

デプロイするアプリケーションのステージング・モード。有効な値はstage、nostage、およびexternal_stageです。指定していない場合は、WebLogic Serverでは、デフォルトのステージ・モードが使用されます。デフォルトのステージ・モードは、管理サーバーの場合はnostage、管理対象サーバーの場合はstageです。

subModuleTargets

JMSモジュールのサブモジュール・レベル・ターゲット。例: submod@mod-jmx.xml@target | submoduleName@!target。

timeout

操作を取り消す前にWebLogic Serverがデプロイメント・プロセスの完了を待機する時間(ミリ秒単位)。値0は、操作のタイムアウトが発生しないことを示します。この引数のデフォルト値は300,000 ms(5分)です。

useNonExclusiveLock

同じユーザーがドメインですでに取得している既存のロックを、デプロイメント処理で使用することを指定します。複数のデプロイメント・ツールを同時に使用していて、いずれかのツールでドメイン構成のロックをすでに取得している場合に便利。

versionIdentifier

バージョン識別子。

デプロイメント操作用のJMX APIの使用

例2-1では、デプロイメント操作用のWebLogic Server JMX APIの使用について説明します。この例には、インライン・コメントと次の作業の実行方法が示されています。

- 同期および非同期でのアプリケーションのデプロイ

- デプロイメント操作の進行状況のモニター

- アプリケーションの停止

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

- 通知の処理

注意:

この例では、可読性のためにJMXプロキシを使用しています。WebLogic Server JMX APIでは、オープン・タイプを使用しているため、WebLogic ServerクラスなしでJMXクライアントで実行できます。さらに、例をできるかぎり小さくするため、エラー処理が省略されています。

JMXの理解と使用に関する詳細な情報は、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』および『Oracle WebLogic Server JMXによる管理可能アプリケーションの開発』を参照してください。

例2-1 デプロイメント操作用のJMX APIの使用

import weblogic.management.mbeanservers.domainruntime.DomainRuntimeServiceMBean;
import weblogic.management.runtime.AppDeploymentRuntimeMBean;
import weblogic.management.runtime.DeploymentManagerMBean;
import weblogic.management.runtime.DeploymentProgressObjectMBean;

import java.util.Hashtable;
import java.util.Properties;

import javax.management.MBeanServerConnection;
import javax.management.Notification;
import javax.management.NotificationListener;
import javax.management.ObjectName;
import javax.management.remote.JMXConnector;
import javax.management.remote.JMXConnectorFactory;
import javax.management.remote.JMXServiceURL;
import javax.naming.Context;

public class JMXDeploymentExample {

// Deployment Manager JMX proxy
DeploymentManagerMBean deploymentManager;

// Domain Runtime MBean Server connection
MBeanServerConnection connection;

private void setUp() throws Exception {
System.out.println("*** Setting up...");

// Get connection to the Domain Runtime MBean Server.
// For more information, see Make Remote Connections to an MBean Server.
// in Developing Custom Management Utilities Using JMX for Oracle WebLogic Server.
connection = getDomainRuntimeJMXConnection();

// Get DeploymentManager JMX proxy.
// For more information, see Oracle WebLogic Server MBean Reference.
DomainRuntimeServiceMBean svcBean = (DomainRuntimeServiceMBean)
weblogic.management.jmx.MBeanServerInvocationHandler.newProxyInstance(
connection, new ObjectName(DomainRuntimeServiceMBean.OBJECT_NAME));
deploymentManager = svcBean.getDomainRuntime().getDeploymentManager();

// Add a JMX notification listener that outputs the JMX notifications generated during deployment operations.
connection.addNotificationListener(new ObjectName("com.bea:Name=DeploymentManager,Type=DeploymentManager"),
new DeployListener(), null, null);
}

/*
* Demonstrates synchronously deploying an application.
*/

private void deploySynchronously() throws Exception {
System.out.println("*** Deploying SimpleApp...");

// This form of the deploy operation is synchronous.
// Errors are still returned through a progress object.
// By default, the SimpleApp is deployed to all servers.

DeploymentProgressObjectMBean progressObj = deploymentManager.deploy(
"SimpleApp", "/apps/simpleapp.war", /* no plan */ null);
printCompletionStatus(progressObj);
}

/*
* Demonstrates asynchronously deploying an application to a server instance.
*/

private void deployASynchronously() throws Exception {
System.out.println("*** Deploying VersionedApp...");

// This form of the deploy operation is asynchronous.
// The caller should utilize the returned progress object to monitor the progress of the deployment.

Properties deploymentOptions = new Properties();
deploymentOptions.put("appVersion", "V1");
deploymentOptions.put("planVersion", "P1");

DeploymentProgressObjectMBean progressObj = deploymentManager.deploy("VersionedApp", "/apps/app-v1.war",
new String[] { "myserver" },
"/apps/app-v1-plan.xml", deploymentOptions);

waitForCompletion(progressObj, 200);
}

/*
* Demonstrates using a deployment progress object to display the status of the deployment operation.
*/

private void printCompletionStatus(DeploymentProgressObjectMBean progressObj) throws Exception {

System.out.println(" State: " + progressObj.getState());
if ("STATE_FAILED".equals(progressObj.getState())) {
Exception[] exceptions = progressObj.getRootExceptions();
for (int i = 0; exceptions != null && i < exceptions.length; i++)
System.out.println(" Exception: " + exceptions[i]);
}
}

/*
* Demonstrates using a deployment progress object to wait for the completion of the deployment operation.
*/

private void waitForCompletion(DeploymentProgressObjectMBean progressObj, int timeoutSecs) throws Exception {

for (int i = 0; i < timeoutSecs; i++) {
String state = progressObj.getState();
if ("STATE_COMPLETED".equals(state) || "STATE_FAILED".equals(state))
break;
try {
Thread.currentThread().sleep(1000);
} catch (InterruptedException ex) {
//ignore
}
}

printCompletionStatus(progressObj);
}

/*
* Demonstrates stopping an application asynchronously.
*/

private void stopAsynchonously() throws Exception {
System.out.println("*** Stopping SimpleApp...");

// The DeploymentManagerMBean is used for the initial deployment of an application.
// After the initial deployment, the AppDeploymentRuntimeMBean is used for stop, start,
// redeploy, and undeploy of an application.

AppDeploymentRuntimeMBean appRuntime = deploymentManager.lookupAppDeploymentRuntime("SimpleApp");

Properties deploymentOptions = new Properties();
deploymentOptions.put("gracefulIgnoreSessions", "true");

DeploymentProgressObjectMBean progressObj = appRuntime.stop(new String[]{"myserver"}, deploymentOptions);
waitForCompletion(progressObj, 200);

}

/*
* Demonstrates using an AppDeploymentRuntimeMBean to undeploy an application.
*/

private void undeploySynchronously() throws Exception {
System.out.println("*** Undeploying SimpleApp...");

// The DeploymentManagerMBean is used for the initial deployment of an application.
// After the initial deployment, the AppDeploymentRuntimeMBean is used for stop, start,
// redeploy, and undeploy of an application.

AppDeploymentRuntimeMBean appRuntime = deploymentManager.lookupAppDeploymentRuntime("SimpleApp");

DeploymentProgressObjectMBean progressObj = appRuntime.undeploy();
printCompletionStatus(progressObj);

}

/*
* Demonstrates the notifications that are generated by WebLogic Server deployment operations.
*/

private class DeployListener implements NotificationListener {

public void handleNotification(Notification notification, Object handback) {
System.out.println(" Notification from DeploymentManagerMBean");
System.out.println("  notification type:  " + notification.getType());
String userData = (String)notification.getUserData();
System.out.println("  userData:  " + userData);
}

}

private MBeanServerConnection getDomainRuntimeJMXConnection() throws Exception {

JMXServiceURL serviceURL = new JMXServiceURL("t3", "localhost", 7001,
"/jndi/weblogic.management.mbeanservers.domainruntime");

Hashtable h = new Hashtable();
h.put(Context.SECURITY_PRINCIPAL, "weblogic");
h.put(Context.SECURITY_CREDENTIALS, "password");
h.put(JMXConnectorFactory.PROTOCOL_PROVIDER_PACKAGES, "weblogic.management.remote");

JMXConnector connector = JMXConnectorFactory.connect(serviceURL, h);
MBeanServerConnection connection = connector.getMBeanServerConnection();
return connection;
}

public static void main(String args[]) throws Exception {
JMXDeploymentExample example = new JMXDeploymentExample();

example.setUp();
example.deploySynchronously();
example.deployASynchronously();
example.stopAsynchonously();
example.undeploySynchronously();
}

}

WebLogic Serverでのデプロイメント検証プラグインの使用方法

デプロイメント検証プラグインを作成すると、WebLogic Serverドメインにアプリケーションをデプロイする前に、そのアプリケーションを検証できます。管理サーバーでは、デプロイメント・プロセスの開始時にプラグインを実行して、アプリケーションがドメインに対して有効であるかどうかを判断します。検証にパスすると、アプリケーションがデプロイされます。検証に失敗すると、アプリケーションはデプロイされないので、構成変更やデプロイメントのエビデンスは記録されません。

デプロイメント検証プラグインを使用する場合は、ドメイン固有の要件に基づいて、無効と判断すべき条件を定めておきます。たとえば、不正な形式やEJBを拒否するようにプラグインを構成できます。登録可能なデプロイメント検証プラグインはドメインごとに1つのみで、プラグインはドメインに対して一意であることが必要です。新しいデプロイメント検証プラグインを構成して、元のプラグインを置き換えることは可能ですが、同じドメインに2つ目のプラグインを追加することはできません。

WebLogic Serverでデプロイメント検証プラグインを使用すると、次のことができるようになります。

- 不正なアプリケーション・コードを拒否して悪意のあるアプリケーションからドメインを保護

- アプリケーションのデプロイメント・プランの変更

- 構成パラメータを使用して固有の要件に合せたプラグインの調整

- メッセージのログ記録

検証はオプションのステップなので、デプロイメント検証プラグインの有無にかかわらず、デプロイメント・プロセスは変わりません。検証プロセスはアプリケーションの初回デプロイ時に発生し、デプロイ済アプリケーションのサーバー起動時や自動デプロイメント中には発生しません。

次の各項では、WebLogic Serverでデプロイメント検証プラグインを使用して、アプリケーションを検証する方法について説明します。

- デプロイメント検証プラグインの構成

- デプロイメント検証プラグインの使用方法

デプロイメント検証プラグインの構成

デプロイメント検証プラグインをWebLogic Serverで実行できるようにするには、<deployment-validation-plugin>要素をconfig.xmlファイルに追加し、管理サーバーがプラグインのクラスにアクセスしてそのクラスを使用できるようにする必要があります。<deployment-validation-plugin>要素にプラグインの完全修飾クラス名を追加して、パラメータを宣言する必要があります。<deployment-validation-plugin>要素は、手動またはDomainMBeanに用意されているDeploymentConfigurationMBeanを使用して追加できます。

デプロイメント検証プラグインは、次の3つの構成MBeansでサポートされています。

- DeploymentConfigurationMBean
DeploymentConfigurationMBeanにはDeploymentValidationPlugIn属性が含まれています。この属性はDeploymentValidationPluginMBeanで、デプロイメント検証プラグインを有効または無効にする<deployment-validation-plugin>要素に対応します。

- DeploymentValidationPluginMBean
DeploymentValidationPluginMBeanでは、デプロイメント検証プラグインの構成情報を指定します。このMBeanには、プラグインの完全修飾クラス名であるFactoryClassname属性が含まれています。このクラスは、管理サーバーのCLASSPATHから使用できる必要があります。DeploymentValidationPluginMBeanには、プラグインに渡すことのできるパラメータも含まれています。これらのパラメータはParameterMBeanで宣言します。

- ParameterMBean
ParameterMBeanでは、デプロイメント検証プラグインの構成パラメータとユーザー・パラメータを指定します(Name、Value、Descriptionなど)。

デプロイメント検証プラグインの使用方法

WebLogic Serverは、デプロイメント検証プラグインのコード自体は提供しませんが、プラグインをデプロイメント・プロセスの一環として実行し、検証してドメインを悪意のあるアプリケーションから保護する方法を備えています。ドメイン管理者は、使用環境の要件や仕様に従って、ドメイン固有のプラグインで使用するコードのプログラミングとコンパイルを行います。プラグイン・クラスと、そこで使用されるその他のクラスは、管理サーバーのCLASSPATHから使用できる必要があります。

デプロイメント検証プラグインはプラグイン・ファクトリ・インタフェースweblogic.deployment.configuration.DeploymentValidationPluginを実装している必要があります。デプロイメント検証プラグインのインスタンスを作成するため、この実装には空のコンストラクタが含まれている必要があります。

weblogic.deployment.configurationインタフェースには、初期化メソッドと検証メソッドが含まれています。初期化メソッドは、デプロイメント検証プラグインのインスタンスに対して、config.xmlファイルの<deployment-validation-plugin>要素で宣言されているparametersを提供します。検証メソッドはアプリケーション・コンテキスト情報を提供し、アプリケーションに検証結果を返します。

検証結果はValidationResultインタフェースを実装するクラスです。デプロイメントが有効で作業を続行する必要があるかどうかを示すisDeploymentValidメソッドを実装します。デプロイメントが無効な場合に、その原因として設定する必要のある例外を提供するgetExceptionメソッドを実装します。検証メソッドに渡される引数はDeploymentValidationContextで、SessionHelperインスタンスを介して、指定されたアプリケーションへのアクセスを提供します。デプロイメント検証プラグインではDeploymentValidationContext引数のgetSessionHelper属性を使用して、SessionHelperで許可されているアプリケーション情報を確認します。

DeploymentValidationContext引数では、DeploymentValidationLoggerへのアクセスも提供します。DeploymentValidationLoggerでは、アプリケーションの検証で実行されるプラグイン・アクションやアプリケーションを無効とした理由に関するメッセージをログに記録します。

検証結果でアプリケーションが有効であることが示された場合、デプロイメントは検証にパスして、デプロイメント・プロセスを続行します。検証結果でアプリケーションが無効であることが示された場合、プラグインではアプリケーションが検証に失敗した理由を説明する例外メッセージを送信して、アプリケーションはデプロイされません。構成変更やデプロイメントのエビデンスは記録されません。検証プロセスは管理サーバー上で発生するため、デプロイメントが失敗しても管理対象サーバーではデプロイメントを意識することはなく、構成をアンデプロイしたり元に戻したりする必要はありません。

3 デプロイメントのためのアプリケーションの構成

この章では、デプロイメント記述子を使用してWebLogic Serverインスタンスへのデプロイメント用のアプリケーションまたはデプロイ可能なリソースを構成する方法について説明します。これらの記述子の一部の要素は外部オブジェクトを参照し、サーバー・ベンダーに応じて特別な処理が必要なものもあります。WebLogic Serverでは、記述子を拡張したWebLogic Server固有のデプロイメント記述子を使用します。標準の記述子とWebLogic Server記述子とのマッピングはDDBeansおよびDConfigBeansを介して管理されます。

この章の内容は以下のとおりです。

- 構成プロセスの概要

- 構成情報の種類

- アプリケーション評価

- フロントエンド構成の実行

- デプロイメント構成のカスタマイズ

- デプロイメント準備

- セッションのクリーン・アップ

構成プロセスの概要

この項では、デプロイするアプリケーションの構成を行うために、デプロイメント・ツールで行う必要がある基本的な手順について説明します。

1. アプリケーション評価 - アプリケーション・ファイルを検査および評価して、アプリケーションの構造と埋込み記述子の内容を決定します。

- WebLogicDeploymentManagerを取得することでデプロイメント・セッションを初期化します。「アプリケーション評価」を参照してください。

- WebLogicJ2eeApplicationObjectまたはWebLogicDeployableObjectを作成して、エンタープライズ・アプリケーション(Enterprise Application: EAR)またはスタンドアロン・モジュール(WAR、EAR、RARまたはCAR)のJava EE構成を表します。オブジェクトはEARの場合、子オブジェクトが生成されます。http://jcp.org/en/jsr/detail?id=88のJava EEデプロイメントAPI標準(JSR-88)および「デプロイ可能なオブジェクトの作成」を参照してください。

2. フロントエンド構成 - アプリケーションに埋め込まれている情報に基づいて構成情報を作成します。この情報には、WebLogic Server記述子、デフォルト、ユーザー定義によるデプロイメント・プランなどがあります。

- WebLogicDeploymentConfigurationオブジェクトを作成して、アプリケーションのWebLogic Server構成を表現します。これは、このオブジェクトのデプロイメント・プランを作成するための最初のステップです。「デプロイメント構成」を参照してください。

- 既存のデプロイメント・プランを利用できる場合は、そのデプロイメント・プランから既存のWebLogic Server構成の値を復元します。「フロントエンド構成の実行」を参照してください。

3. デプロイメント構成 - ユーザー入力および選択されたWebLogic Serverターゲットに基づいて、個別のWebLogic Server構成の値を変更します。
デプロイメント・ツールには、ユーザー入力および選択するWebLogic Serverターゲットに基づいて、個々のWebLogic Server構成の値を変更する機能が必要です。「デプロイメント構成のカスタマイズ」を参照してください。

4. デプロイメントの準備 - 最終的なデプロイメント・プランを生成し、クライアント側でアプリケーションを事前に検証します。
デプロイメント・ツールには、変更したWebLogic Server構成情報を、新しいデプロイメント・プランまたは既存のデプロイメント・プランの変数定義に保存する機能が必要です。

構成情報の種類

次の項では、構成情報の種類、表現方法、およびJava EE記述子とWebLogic Server記述子の関係に関する基本情報について説明します。

- Java EEの構成

- WebLogic Server構成

- Java EE構成情報、WebLogic Server構成情報の表現

- Java EE記述子とWebLogic Server記述子の関係

Java EEの構成

アプリケーションのJava EE構成では、アプリケーションの基本的なセマンティクスと実行時の動作、またアプリケーションの機能に必要な外部リソースを定義します。この構成情報は、アプリケーションに関連付けられた標準Java EEデプロイメント記述子ファイルに格納されます。表3-1は、この記述子ファイルの一覧です。

表3-1 標準Java EEデプロイメント記述子

アプリケーションまたはスタンドアロン・モジュール

Java EE記述子

エンタープライズ・アプリケーション

META-INF/application.xml

Webアプリケーション

WEB-INF/web.xml

Enterprise JavaBeans

META-INF/ejb.xml

リソース・アダプタ

META-INF/ra.xml

クライアント・アプリケーション・アーカイブ

META-INF/application-client.xml

あらゆるアプリケーション構成セッションには、完全で有効なJava EEデプロイメント記述子の入力が必須です。

Java EE構成でアプリケーションの基本的な動作が判断するため、Java EE記述子は通常アプリケーションのデプロイメント・フェーズ中にのみ定義され、アプリケーションが後に別の環境にデプロイされる際にも変更されません。たとえば、テスト用ドメインまたは本番用ドメインにアプリケーションをデプロイする場合、アプリケーションの動作は(したがってそのJava EE構成も)そのアプリケーションをデプロイメント・ドメインにデプロイしたときと同じ状態のままです。詳細は、「フロントエンド構成の実行」を参照してください。

WebLogic Server構成

WebLogic Server記述子では、拡張機能、外部リソースの解決、およびアプリケーション・セマンティクスに関連するチューニングが規定されます。この記述子はアプリケーションに埋め込まれていても埋め込まれていなくてもかまいません。アプリケーションのWebLogic Server構成では、以下のことができます。

- 外部リソース名をJava EEデプロイメント記述子のリソースの定義にバインドして、特定のWebLogic Serverドメインでアプリケーションが機能できるようにする

- アプリケーション・コンテナのチューニング・パラメータを定義する

- Java EEアプリケーションおよびスタンドアロン・モジュールに拡張機能を提供する

WebLogic Server構成の属性および値は、WebLogic Serverデプロイメント記述子ファイルに格納されます。これについて、表3-2に示します。

表3-2 WebLogic Serverデプロイメント記述子

アプリケーションまたはスタンドアロン・モジュール

WebLogic Server記述子

エンタープライズ・アプリケーション

META-INF/weblogic-application.xml

Webアプリケーション

WEB-INF/weblogic.xml

Enterprise JavaBeans

META-INF/weblogic-ejb-jar.xml

リソース・アダプタ

META-INF/weblogic-ra.xml

クライアントのアーカイブ

META-INF/weblogic-appclient.xml

様々なWebLogic Serverドメインでアプリケーションに対して色々な種類の外部リソースや多様なレベルのサービスが提供されるため、アプリケーションのWebLogic Server構成は、通常そのアプリケーションが新しい環境にデプロイされる際に変更されます。たとえば、本番ステージング・ドメインにはデプロイメント・ドメインとは異なるデータベース・ベンダーが採用されていたり、より使用に適したメモリーが用意されていたりする場合があります。そのため、アプリケーションをデプロイメントからステージング・ドメインに移動する際には、新しいデータベース接続や利用可能なメモリーを使用できるようにするために、アプリケーションのWebLogic Server記述子の値を更新する必要があります。

デプロイメント構成ツールの主な仕事は、アプリケーションのWebLogic Server構成を、選択したWebLogicターゲットに対して確実に有効なものにすることです。

Java EE構成情報、WebLogic Server構成情報の表現

Java EEデプロイメント記述子と利用可能なすべてのWebLogic Server記述子の両方が、アプリケーションの構成プロセスへの入力として使用されます。デプロイメントAPIを使用して、Java EE構成およびWebLogic Server構成の両方をJavaオブジェクトとして表現します。

アプリケーションのJava EE構成は、EARの場合WebLogicJ2eeApplicationObjectを、スタンドアロン・モジュールの場合WeblogicDeployableObjectを作成することにより取得されます。(WebLogicJ2eeApplicationObjectには、EARにある個々のモジュールを表現する複数のDeployableObjectインスタンスが含まれています)。

各WebLogicJ2eeApplicationObjectまたはWeblogicDeployableObjectにはDDBeanRootがあり、これが対応するJava EEデプロイメント記述子ファイルを表しています。EARおよびモジュールのJava EE記述子のプロパティは、DDBeanRootの下にある1つ以上のDDBeanオブジェクトで表されます。DDBeanコンポーネントには、デプロイメント記述子の個々のプロパティ、値、およびネストされた記述子要素のそれぞれにアクセスする標準のゲッター・メソッドが備わっています。

DDBean

DDBeansはjavax.enterprise.deploy.modelパッケージに記述されています。このオブジェクトでは標準デプロイメント記述子の要素に対する一般的なインタフェースが提供されますが、標準記述子の基本的な形式に従う任意のXMLファイルへのアクセス用にXPathベースのメカニズムとしても使用できます。そのようなファイルの例には、WebLogic Server記述子やWebサービス記述子があります。

記述子のDDBean表現はDDBeansのツリー構造で、専用のDDBeanが使用され、ツリーのルートには、DDBeanRootがあります。DDBeansには、それらが表現する記述子要素の要素名、ID属性、ルートおよびテキストに対するアクセサが用意されています。

アプリケーションのDDBeanはモデル・プラグインによって導入されます。モデル・プラグインはjavax.enterprise.deploy.modelのツール・プロバイダ実装です。アプリケーションは、DeployableObjectインタフェースで表現されます。このインタフェースのWebLogic Server実装はpublicクラスweblogic.deploy.api.model.WebLogicDeployableObjectです。WebLogic Serverベースのデプロイメント・ツールで、アプリケーションのWebLogicDeployableObjectオブジェクトのインスタンスをcreateDeployableObjectファクトリ・メソッドを介して取得します。その結果、アプリケーションのDDBeanツリーが作成されて、アプリケーションに埋め込まれたJava EE記述子の要素により内容が設定されます。アプリケーションがEARの場合、複数のWebLogicDeployableObjectオブジェクトが作成されます。ルートのWebLogicDeployableObjectはWebLogicJ2eeApplicationObjectとして拡張され、これがEARモジュールを表します。その子WebLogicDeployableObjectインスタンス群がアプリケーションに含まれるモジュール群(WAR、EJB、RAR、CARなど)を表します。

Java EE記述子とWebLogic Server記述子の関係

Java EE記述子とWebLogic Server記述子は外部リソースの構成において直接的に関連しています。Java EE記述子にはアプリケーションが機能するために必要なリソースの種類を定義しますが、実際に使用するリソース名は特定しません。WebLogic Server記述子の方で、そのJava EE記述子内のリソース定義名をターゲット・ドメインの実際のリソース名にバインドします。

外部リソースのバインドは、構成プロセスに必須のプロセスです。リソースをターゲット・ドメインにバインドすることで、確実にアプリケーションでリソースを見つけ、正しくデプロイできるようになります。

Java EE記述子とWebLogic Server記述子は、WebLogic Serverのチューニング・パラメータの構成においても間接的に関連しています。標準Java EE記述子の要素に対してWebLogic Serverでチューニング・パラメータを設定する必要はありませんが、個々の記述子ファイルの存在によって、どのチューニング・パラメータがアプリケーションの構成時に重要なのかが分かります。たとえば、ejb.xml記述子にWebLogic Server EJBコンテナのチューニングに関連する要素が含まれていなくても、ejb.xmlがJava EE構成にあることで、デプロイメントの前にチューニング・プロパティを構成できることが分かります。

DConfigBean

DConfigBean (構成Bean)は、サーバーの構成要件をデプロイメント・ツールに伝達するために使われるオブジェクトです。また、デプロイメント・プランの作成には主にここからの情報が使用されます。構成BeanはJava Beanであり、このBeanのプロパティは参照できます。また、それらには基本的なプロパティ編集機能もあります。

DConfigBeanは、埋め込まれたWebLogic Server記述子とデプロイメント・プランの情報、およびIDEデプロイメント・ツールからの入力によって作成されます。

DConfigBeanは、アプリケーションの依存関係に関連付けられるすべてのWebLogic記述子要素に対して作成できます。記述子はアプリケーションで利用可能なリソースが記述されるエンティティで、サーバーで指定されるJNDI名で表されます。

記述子は、構成セッションの設定時に型付きのBeanツリーとしてメモリーに解析されます。DConfigBean実装クラスはWebLogic Server記述子Beanに委任します。依存関係にあるプロパティ(リソース参照など)を持つBeanのみがDConfigBeanを持ちます。記述子のルートには常にDConfigBeanRootがあります。

Beanのプロパティへのアクセサでは、構成が必要な要素については子DConfigBeanが、構成不要の要素については記述子Beanが返されます。プロパティへのアクセサでは記述子Beanからのデータが返されます。

Beanのプロパティを変更すると、プランがオーバーライドされます。既存の記述子に対するプランのオーバーライドは、変数の割当によって処理されます。関連するWebLogic Server記述子がアプリケーションにない場合、記述子が自動的に作成されて外部プラン・ディレクトリに配置されます。外部デプロイメント記述子の場合、記述子が直接変更されます。埋込み記述子はディスク上では変更されません。

アプリケーション評価

アプリケーション評価では、アプリケーション用のデプロイメント・マネージャおよびデプロイ可能なオブジェクト・コンテナを取得します。次の手順に従います。

1. デプロイメント・ファクトリ・クラスを名前にweblogic.deployer.spi.factories.internal.DeploymentFactoryImplを指定して取得します。

2. ファクトリ・クラスをjavax.enterprise.deploy.spi.DeploymentFactoryManagerインスタンスに登録します。

次に例を示します。

Class WlsFactoryClass =   Class.forname("weblogic.deployer.spi.factories.internal.DeploymentFactoryImpl");
DeploymentFactory myDeploymentFactory =
(DeploymentFactory) WlsFactoryClass.newInstance();
DeploymentFactoryManager.getInstance().registerDeploymentFactory(myDeploymentFactory);

3. デプロイメント・マネージャの取得

4. デプロイ可能なオブジェクトの作成

デプロイメント・マネージャの取得

次の項では、デプロイメント・マネージャを取得する方法について説明します。

- デプロイメント・マネージャの種類

- 接続および切断されたデプロイメント・マネージャのURI

- SessionHelperを使用したデプロイメント・マネージャの取得

デプロイメント・マネージャの種類

WebLogic Serverにはjavax.enterprise.deploy.spi.DeploymentManagerの実装が1つ用意されていますが、この実装はファクトリから取得したクラスの初期化時に指定するURIによって動作が異なります。そのためWebLogic Serverには、基本的なデプロイメント・マネージャが2種類あります。

- 切断されたデプロイメント・マネージャには、WebLogic Serverインスタンスへの接続がありません。リモート・クライアント・マシン上のアプリケーションを構成するために、切断されたデプロイメント・マネージャを使用します。それをデプロイメント操作を実行するために使用することはできません。(たとえば、デプロイメント・ツールは切断されたデプロイメント・マネージャを使用してアプリケーションを配布することはできません。)

- 接続されたデプロイメント・マネージャには、WebLogic Serverドメイン用の管理サーバーへの接続があり、デプロイメント・ツールにより、アプリケーションの構成およびデプロイの両方に使用できます。

接続されたデプロイメント・マネージャは、管理サーバーのローカルに存在するか、あるいは管理サーバーに接続されたリモート・マシンで動作しているかによってさらに分類されます。ローカルまたはリモートの分類によって、ファイル参照が管理サーバーに対してローカルとして扱われるかリモートとして扱われるかが決まります。

表3-3に、デプロイメント・マネージャのタイプをまとめます。

表3-3 WebLogic Serverデプロイメント・マネージャの使い方

デプロイメント・マネージャの接続性

種類

用途

注意

切断された

なし

構成ツールのみ

デプロイメント操作を実行できない

接続された

ローカル

管理サーバーのローカルの構成ツールおよびデプロイメント・ツール

すべてのファイルが管理サーバー・マシンのローカルにある

接続された

リモート

リモート・マシン上(管理サーバー上以外)にある構成ツールおよびデプロイメント・ツール

配布およびデプロイメントの操作を行うと、ローカル・ファイルが管理サーバーにアップロードされる

接続および切断されたデプロイメント・マネージャのURI

WebLogicDeploymentFactoryから取得した各DeploymentManagerでは、WebLogic Server拡張がサポートされます。デプロイメント・ツールを作成する場合、デプロイメント・ファクトリのインスタンスにある適切なメソッドを呼び出し、必要な種類のデプロイメント・マネージャについて記述されているweblogic.deployer.spi.factories.WebLogicDeploymentFactoryに定義された文字列定数を指定して、特定の種類のデプロイメント・マネージャを取得します。接続されたデプロイメント・マネージャで管理サーバーへの接続を取得するためには、有効なサーバーのURIと資格証明をメソッドに渡す必要があります。

表3-4に、各種のデプロイメント・マネージャを取得する際に使用するメソッド・シグネチャと定数についてまとめます。

表3-4 WebLogic Serverデプロイメント・マネージャを取得するためのURI

デプロイメント・マネージャの種類

メソッド

引数

切断された

getDisconnectedDeploymentManager()

WebLogicDeploymentFactory.LOCAL_DM_URIの値(String型)

接続された、ローカル

getDeploymentManager()

以下の要素からなるURIを指定する

- WebLogicDeploymentFactory.LOCAL_DM_URI

- 管理サーバーのホスト名

- 管理サーバーのポート

- 管理者のユーザー名

- 管理者のパスワード

接続された、リモート

getDeploymentManager()

以下の要素からなるURIを指定する

- WebLogicDeploymentFactory.REMOTE_DM_URI

- 管理サーバーのホスト名

- 管理サーバーのポート

- 管理者のユーザー名

- 管理者のパスワード

例 3-1のサンプル・コードに、切断されたデプロイメント・マネージャを取得する方法について示します。

例 3-1 切断されたデプロイメント・マネージャの取得

Class WlsFactoryClass = Class.forname("weblogic.deployer.spi.factories.internal.DeploymentFactoryImpl");
DeploymentFactory myDeploymentFactory = (DeploymentFactory) WlsFactoryClass.newInstance();
DeploymentFactoryManager.getInstance().registerDeploymentFactory(myDeploymentFactory);
WebLogicDeploymentManager myDisconnectedManager =
(WebLogicDeploymentManager)myDeploymentFactory.getDisconnectedDeploymentManager(WebLogicDeploymentFactory.LOCAL_DM_URI);

デプロイメント・ファクトリには、接続されたデプロイメント・マネージャ作成のためのURI引数の形成に役立つcreateUri()というヘルパー・メソッドがあります。たとえば、切断されたリモート・デプロイメント・マネージャを作成するには、コードの最終行を次のように置き換えます。

(WebLogicDeploymentManager)myDeploymentFactory.getDeploymentManager(myDeploymentFactory.createUri(WebLogicDeploymentFactory.REMOTE_DM_URI, "localhost", "7001", "weblogic", "weblogic"));

SessionHelperを使用したデプロイメント・マネージャの取得

SessionHelperヘルパー・クラスでは、例 3-1にあるように手動でデプロイメント・ファクトリを作成および登録せずに、簡単にデプロイメント・マネージャを取得できるようにするための便利なメソッドが複数提供されています。切断されたデプロイメント・マネージャを取得するために必要なSessionHelperのコードは以下の1行のみです。

DeploymentManager myDisconnectedManager = SessionHelper.getDisconnectedDeploymentManager();

SessionHelperを使用して接続されたデプロイメント・マネージャを取得することもできます。以下に例を示します。

DeploymentManager myConnectedManager = SessionHelper.getDeploymentManager("adminhost", "7001", "weblogic", "weblogic"));

このメソッドでは、管理サーバー(adminhost)へのリモート接続を前提にしています。SessionHelperの詳細は、「Javadocs」を参照してください。

デプロイ可能なオブジェクトの作成

以下の節では、デプロイ可能なオブジェクトを作成する方法について説明します。このオブジェクトは、デプロイメント・ツールでアプリケーションをデプロイするのに使用されるコンテナになります。デプロイメント・マネージャの取得によって構成セッションを初期化したら、デプロイメント・ツールで使用するデプロイ可能なオブジェクトを次のいずれかの方法で作成します。

- WebLogicDeployableObjectクラスの使用

- SessionHelperを使用してデプロイ可能なオブジェクトの取得

WebLogicDeployableObjectクラスの使用

直接的なアプローチでは、modelパッケージのWebLogicDeployableObjectクラスを次のように使用します。

WebLogicDeployableObject myDeployableObject = WebLogicDeployableObject.createWebLogicDeployableObject("myAppFileName");

デプロイ可能なオブジェクトが作成されたら、アプリケーションのデプロイメント構成を作成できます。

SessionHelperを使用してデプロイ可能なオブジェクトの取得

SessionHelperヘルパー・クラスには、デプロイ可能なオブジェクトを取得するための便利なメソッドが用意されています。デプロイ可能なオブジェクトの取得に必要なSessionHelperコードを以下に示します。

SessionHelper.setApplicationRoot(root);
WebLogicDeployableObject myDeployableObject = SessionHelper.getDeployableObject();

getDeployableObject()呼出しには何もアプリケーションが指定されていません。SessionHelperでは、setApplicationRoot()で指定されたルート・ディレクトリのアプリケーションが使用されます。アプリケーションのルート・ディレクトリを指定すれば、SessionHelperで他の処理(明示的なディスパッチ・ファイルの場所やデプロイメント・プランの場所の指定など)を実行できます。

また、以下のようにsetApplicationメソッドを使用してアプリケーションのファイル名を指定することもできます。

SessionHelper.setApplication(AppFileName);

このメソッドを使用すると、ディレクトリ構造に関係なく引続きSessionHelperを使用できます。getDeployableObjectメソッドは、指定されたアプリケーションを返します。

フロントエンド構成の実行

フロントエンド構成では、WebLogicDeploymentPlanの作成と、WebLogicDeploymentPlanおよび関連するBeanツリーへの構成情報の指定を行います。

- フロントエンド構成

- デプロイメント構成

- 構成の検証

フロントエンド構成

フロントエンド構成フェーズは、次の2つの論理的処理から構成されます。

- デプロイメント・プランからデプロイメント構成に情報をロードします。デプロイメント構成がまだ存在しない場合は、WebLogicDeploymentConfigurationオブジェクトを作成して、アプリケーションのWebLogic Server構成を表現します。これは、このオブジェクトのデプロイメント・プランを作成するプロセスの最初のステップです。

- 既存のデプロイメント・プランから既存のWebLogic Server構成の値を復元します。

デプロイメント・ツールには、以下の機能が必要です。

- デプロイメント構成からの情報の展開。デプロイメント構成はデプロイメント・マネージャで構成情報を取得するために使用されるアクティブなJavaオブジェクトです。デプロイメント・プランは、アプリケーションを操作せずに変更できるように、アプリケーションの外部に置かれています。

デプロイメント・プランはアプリケーション環境の構成が格納されるXMLドキュメントで、アプリケーションのフロントエンド構成と呼ばれることもあります。デプロイメント・プランには、以下のような目的があります。

- アプリケーションのロジックからアプリケーションの環境固有の詳細情報を分離します。

- すべてのアプリケーションに必須なわけではありませんただし、デプロイメント・プランは一般的にアプリケーションのデプロイ先とする各環境に存在します。

- アプリケーションにどのようなモジュールがあるかなど、アプリケーションの構造を記述します。

- 開発者や管理者がアプリケーションのアーカイブを変更せずにアプリケーションの構成を更新できるようにします。

- 環境固有の記述子オーバーライド情報(チューニング可能)を格納します。デプロイメント・プランを変更して、アプリケーションのチューニング可能な変数に環境固有の値を指定できます。

デプロイメント構成

アプリケーション用のサーバー構成はjavax.enterprise.deploy.spi.DeploymentConfigurationインタフェースにカプセル化されます。DeploymentConfigurationはデプロイメント・プランのオブジェクト表現を提供します。DeploymentConfigurationはDeploymentManager.createConfigurationメソッドを介してDeployableObjectに関連付けられます。DeploymentConfigurationオブジェクトを作成すると、すべてのWebLogic Server記述子に記述された、構成可能な要素とチューニング可能な要素を表すDConfigBeanのツリーが利用できるようになります。アプリケーションにWebLogic Server記述子がない場合、DConfigBeanツリーは利用可能なデフォルト値を使用して作成されます。デフォルト値のないバインドのプロパティは指定されないままになります。

デプロイメント・ツールを作成する場合、アプリケーションが配布される前にDConfigBeanツリーを完全に設定する必要があります。

サンプル・コード

次のコードは、DConfigBeanの設定方法の例です。

例 3-2 DConfigBeanを設定するためのサンプル・コード

public class DeploymentSession {
DeploymentManager dm;
DeployableObject dObject = null;
DeploymentConfiguration dConfig = null;
Map beanMap = new HashMap();
.
.
.
// Assumes app is a Web app.
public void initializeConfig(File app) throws Throwable {
/**
* Init the wrapper for the DDBeans for this module. This example assumes
* it is using the WLS implementation of the model api.
*/
dObject= WebLogicDeployableObject.createDeployableObject(app);
//Get basic configuration for the module
dConfig = dm.createConfiguration(dObject);
/**
* At this point the DeployableObject is populated. Populate the
* DeploymentConfigurationbased on its content.
* We first ask the DeployableObject for its root.
*/
DDBeanRoot root = dObject.getDDBeanRoot();
/**
* The root DDBean is used to start the process of identifying the
* necessary DConfigBeans for configuring this module.
*/
System.out.println("Looking up DCB for "+root.getXpath());
DConfigBeanRoot rootConfig = dConfig.getDConfigBeanRoot(root);
collectConfigBeans(root, rootConfig);
/**
* The DeploymentConfiguration is now initialized, although not necessarily
* completely setup.
*/
FileOutputStream fos = new FileOutputStream("test.xml");
dConfig.save(fos);

}

// bean and dcb are a related DDBean and DConfigBean.
private void collectConfigBeans(DDBean bean, DConfigBean dcb) throws Throwable{
DConfigBean configBean;
DDBean[] beans;
if (dcb == null) return;
/**
* Maintain some sort of mapping between DDBeans and DConfigBeans
* for later processing.
*/
beanMap.put(bean,dcb);
/**
* The config bean advertises xpaths into the web.xml descriptor it
* needs to know about.
*/
String[] xpaths = dcb.getXpaths();
if (xpaths == null) return;
/**
* For each xpath get the associated DDBean and collect its associated
* DConfigBeans. Continue this recursively until we have all DDBeans and
* DConfigBeans collected.
*/
for (int i=0; i<xpaths.length; i++) {
beans = bean.getChildBean(xpaths[i]);
for (int j=0; j<beans.length; j++) {
/**
* Init the DConfigBean associated with each DDBean
*/
System.out.println("Looking up DCB for "+beans[j].getXpath());
configBean = dcb.getDConfigBean(beans[j]);
collectConfigBeans(beans[j], configBean);
}
}

このサンプルでは単にDDBeanツリーを反復処理して、インスタンス化される各DDBeanのDConfigBeanをリクエストしています。

DeploymentConfigurationオブジェクトはDeploymentConfiguration.save()を使用するとデプロイメント・プランとして永続化できます。デプロイメント・ツールを使用すると、デプロイメント・プランをゼロから作成する代わりに、保存されているデプロイメント・プランをDeploymentConfigurationオブジェクトにインポートすることもできます。DeploymentConfiguration.restore()を使用するとこの機能を実現できます。これにより、アプリケーションのデプロイメント・プランのリポジトリを保持して、そこに様々な環境に適用できる様々なデプロイメント・プランを格納するという手法がサポートされます。

同様に、以前の構成セッションからリポジトリに保存された部分的なプランをつなぎ合わせてDeploymentConfigurationを構成することもできます。部分的なプランは、DConfigBeanツリーのmodule-rootにマップされます。DeploymentConfiguration.saveDConfigBean()およびDeploymentConfiguration.restoreDConfigBean()を使用すると、この機能を実現できます。

アプリケーションのWebLogic Server記述子の解析は、DeploymentConfigurationが作成されるときに自動的に行われます。記述子は最新のスキーマに準拠しているのが理想的です。WebLogic Server 8.1以前のDTDに基づく記述子が含まれる古いアプリケーションの場合、変換が実行されます。古い記述子はサポートされてはいますが、デプロイメント・プランを使用して変更することはできません。そのため、あらゆるDOCTYPE宣言をネーム・スペースの参照に変換する必要があります。また、要素に固有の変換も必ず実施します。

SessionHelperで情報を読み取る

SessionHelper.initializeConfigurationでは、アプリケーション内のすべての標準記述子およびWebLogic Server記述子が処理されます。

initializeConfigurationを呼び出す前に、SessionHelper.setPlan()メソッドを使用して既存のデプロイメント・プランをアプリケーションに関連付けるように指定できます。プランが設定されている場合、DeploymentConfiguration.restore()メソッドでデプロイメント・プランを読み取ることもできます。さらに、プランを設定するとDeploymentConfiguration.initializeConfiguration()メソッドで自動的に構成情報を復元することも可能です。

SessionHelperクラスで構成セッションを開始する場合、以下に例示するようにデプロイメント・プランの情報をdeploymentConfigurationに入力して簡単に開始できます。

DeploymentManager dm = SessionHelper.getDisconnectedDeploymentManager();
SessionHelper helper = SessionHelper.getInstance(dm);
// specify location of archive
helper.setApplication(app);
// specify location of existing deployment plan
helper.setPlan(plan);
// initialize the configuration session
helper.initializeConfiguration();
DeploymentConfiguration dc = helper.getConfiguration();

上記のコードでは、デプロイメント構成およびそれに関連付けられるWebLogicDDBeanTreeが生成されます。

構成の検証

構成の検証は、ほとんどの場合、アプリケーションの記述子が処理される際に行われる記述子の解析中に発生します。検証では、記述子が有効なXMLドキュメントかどうか、また記述子が各自のスキーマに準拠しているかどうかが確認されます。

デプロイメント構成のカスタマイズ

デプロイメント構成のカスタマイズ・フェーズでは、ユーザー入力と選択したWebLogic Serverターゲットに基づいて、個々のWebLogic Server構成の値を変更します。

- 構成属性の変更

- Target

- アプリケーションの命名

構成属性の変更

この段階の構成は、記述子またはアプリケーションに関連付けられた既存のプランとほとんど同様です。DConfigBeanはJava Beanとして設計されていて内部を参照できるため、ツールでその内容を意味のある形式で提示できます。DConfigBeanのプロパティは、そのほとんどが構成可能です。また、主要なプロパティ(一意なもの)も公開されます。セッターについては、安全に変更できるプロパティに関するもののみが公開されます。一般的に、アプリケーションの動作が記述されるプロパティは変更できません。すべてのプロパティには記述子スキーマで定義されている型が指定されています。

プロパティのゲッターからは下位要素のDConfigBean、DConfigBeanの配列、記述子Bean、記述子Beanの配列、単純な値(プリミティブおよびjava.langオブジェクト)、または単純な値の配列が返されます。記述子Beanでは、変更可能だがDConfigBeanの機能を必要としない記述子要素が表現されます。たとえば、記述子Beanに直接関連している標準記述子要素はありません。構成の編集は、プロパティのセッターを呼び出すことにより行われます。

Java JSR-88のDConfigBeanクラスを使用すると、ツールからgetDConfigBean(DDBean)メソッドまたは内部参照を利用してBeanにアクセスできます。アプリケーションのDeployableObject内のDDBeanに基づいて標準記述子を提示し、各DDBeanの構成(そのDConfigBean)に直接アクセスするツールでは、前者のアプローチが便利です。このアプローチでは、アプリケーションに指定されている可能性のある必須リソース要件の構成が提供されます。内部参照でのアプローチでは、ツールでアプリケーション全体の構成を提示できますが、必須のリソース要件が強調されるとは限りません。

内部参照は両方のアプローチにおいて記述子のプロパティを提示または変更するために必要になります。異なるのはツールでの情報の提示方法です。

- 標準記述子の内容

- WebLogic Server記述子の内容

構成情報を変更するシステムには、変更を要求するためのユーザー・インタフェースを含める必要があります。例 3-3を参照してください。

例 3-3 構成情報を変更するためのサンプル・コード

.
.
.
// Introspect the DConfigBean tree and ask for input on properties with setters
private  void processBean(DConfigBean dcb) throws Exception {
if (dcb instanceof DConfigBeanRoot) {
System.out.println("Processing configuration for descriptor: "+dcb.getDDBean().getRoot().getFilename());
}
// get property descriptor for the bean
BeanInfo info =
Introspector.getBeanInfo(dcb.getClass(),Introspector.USE_ALL_BEANINFO);
PropertyDescriptor[] props = info.getPropertyDescriptors();
String bean = info.getBeanDescriptor().getDisplayName();
PropertyDescriptor prop;
for (int i=0;i<props.length;i++) {
prop = props[i];
// only allow primitives to be updated
Method getter = prop.getReadMethod();
if (isPrimitive(getter.getReturnType())) // see isPrimitive method below
{
writeProperty(dcb,prop,bean); //see writeProperty method below
}
// recurse on child properties
Object child = getter.invoke(dcb,new Object[]{});
if (child == null) continue;
// traversable if child is a DConfigBean.
Class cc = child.getClass();
if (!isPrimitive(cc)) {
if (cc.isArray()) {
Object[] cl = (Object[])child;
for (int j=0;j<cl.length;j++) {
if (cl[j] instanceof DConfigBean) processBean((DConfigBean) cl[j]);
}
} else {
if (child instanceof DConfigBean) processBean((DConfigBean) child);
}
}
}
}

// if the property has a setter then invoke it with user input
private void writeProperty(DConfigBean dcb, PropertyDescriptor prop, String bean)
throws Exception {
Method getter = prop.getReadMethod();
Method setter = prop.getWriteMethod();
if (setter != null) {
PropertyEditor pe =
PropertyEditorManager.findEditor(prop.getPropertyType());
if (pe == null &&
String[].class.isAssignableFrom(getter.getReturnType())) pe =
new StringArrayEditor();  // see StringArrayEditor class below
if (pe != null) {
Object oldValue = getter.invoke(dcb,new Object[0]);
pe.setValue(oldValue);
String val =
getUserInput(bean,prop.getDisplayName(),pe.getAsText());
// see getUserInput method below
if (val == null || val.length() == 0) return;
pe.setAsText(val);
Object newValue = pe.getValue();
prop.getWriteMethod().invoke(dcb,new Object[]{newValue});
}
}
}

private String getUserInput(String element, String property, String curr) {
try {
System.out.println("Enter value for "+element+"."+property+". Current value is: "+curr);
return br.readLine();
} catch (IOException ioe) {
return null;
}
}
// Primitive means a java primitive or String object here
private  boolean isPrimitive(Class cc) {
boolean prim = false;
if (cc.isPrimitive() || String.class.isAssignableFrom(cc)) prim = true;
if (!prim) {
// array of primitives?
if (cc.isArray()) {
Class ccc = cc.getComponentType();
if (ccc.isPrimitive() || String.class.isAssignableFrom(ccc)) prim = true;
}
}
return prim;
}

/**
* Custom editor for string arrays. Input text is converted into tokens using
* commas as delimiters
*/
private class StringArrayEditor extends PropertyEditorSupport {
String[] curr = null;

public StringArrayEditor() {super();}

// comma separated string
public String getAsText() {
if (curr == null) return null;
StringBuffer sb = new StringBuffer();
for (int i=0;i<curr.length;i++) {
sb.append(curr[i]);
sb.append(',');
}
if (curr.length > 0) sb.deleteCharAt(sb.length()-1);
return sb.toString();
}

public Object getValue() { return curr; }

public boolean isPaintable() { return false; }

public void setAsText(String text) {
if (text == null) curr = null;
StringTokenizer st = new StringTokenizer(text,",");
curr = new String[st.countTokens()];
for (int i=0;i<curr.length;i++) curr[i] = new String(st.nextToken());
}

public void setValue(Object value) {
if (value == null) {
curr = null;
} else {
String[] v = (String[])value; // let caller handle class cast issues
curr = new String[v.length];
for (int i=0;i<v.length;i++) curr[i] = new String(v[i]);
}
}
}
.
.
.

管理者またはユーザーが構成を変更できるあらゆるインタフェースでは、基礎的なユーザー・インタフェースの仕組みを超えてプロパティのセッターが使用されます。例 3-3を参照してください。

Target

TargetはWebLogic Server、クラスタ、Webサーバー、仮想ホスト、およびJMSサーバーに関連付けられています。詳細は、「weblogic.deploy.api.spi.WebLogicTarget」および「WebLogicターゲット・タイプの問合せサポート」を参照してください。

アプリケーションの命名

WebLogic Serverでは、アプリケーションの名前をデプロイメント・ツールで指定します。アプリケーションに格納されているモジュールの名前は、関連付けられているアーカイブ名またはモジュールのルート・ディレクトリ名に基づきます。これらの名前は、アプリケーション用に構築された構成MBeansに保持されます。

Java EEデプロイメントでは、アプリケーションやその構成要素のモジュールに構成される名前について、TargetModuleIDオブジェクト以外には特に規定されていません。しかし、TargetModuleIDは、WebLogic Serverドメインに配布済みのアプリケーションにのみ存在するものです。そのため、配布する前にデプロイメント・ツールでアプリケーションおよびモジュールの名前を表現する必要があります。この表現は、最終的にアプリケーションが配布されるときにサーバーによって割り当てられる名前と一致している必要があります。

デプロイメント・ツール・プラグインでは、DeployableObjectクラスおよびJ2eeApplicationObjectクラスを通じて、アプリケーションの一覧を構築する必要があります。これらのクラスはそれぞれスタンドアロン・モジュールとEARを表します。各々のクラスがDDBeanRootオブジェクトと直接関係しています。名前が構成されていない配布を提示する場合、デプロイメント・ツールで配布の名前を作成する必要があります。配布されるのがFileオブジェクトである場合、その配布のファイル名を使用します。アーカイブが入力ストリームとして提供された場合、ルート・モジュールにはランダムな名前が使用されます。

デプロイメント準備

デプロイメント準備フェーズでは、構成セッションから生成されたプランを保存します。これは、DeploymentConfiguration.save()メソッド(標準Java EEデプロイメントAPIのメソッド)によって行われます。この作業にSessionHelper.savePlan()メソッドを使用できます。この場合デプロイメント・プランの新しいコピーが、プラン・ディレクトリにあるすべての外部ドキュメントと共に保存されます。

DeploymentConfiguration.saveメソッドでは、デプロイメント・プランのスキーマに基づいてXMLファイルが作成されます。このファイルは、現在のDConfigBeanの集合のシリアライゼーション、およびすべての変数割当てと定義で構成されます。DConfigBeanツリーは常に外部の記述子として保存されます。この記述子は、アプリケーションのアーカイブまたは外部構成領域にまだ存在していない場合にのみ保存されます。すなわち、保存操作では既存の記述子は上書きされません。一方、DeploymentConfiguration.saveDConfigBeanメソッドではファイルが上書きされます。これは、構成に行ったすべての変更が失われるということではありません。変更は変数割当てを使用して処理されます。

前述したように、DeploymentConfiguration.restoreメソッドは前もって保存されたデプロイメント・プランに基づく構成Beanを作成するために使用されます(「フロントエンド構成の実行」を参照)。構成Beanはその全集合を復元することも、一部のみを復元することもできます。また、アプリケーション内の特定モジュールの構成Beanを保存したり復元したりすることも可能です。

セッションのクリーン・アップ

構成セッション中には一時ファイルが作成されます。アーカイブは一時領域に展開され、セッション構成の完了後にのみ削除できます。セッションをクローズするために定義された標準のAPIはありません。WebLogicDeployableObjectとWebLogicDeploymentConfigurationに対してはclose()を使用します。SessionHelper.close()を使用するとセッションの完了後にクリーン・アップできます。セッションのクローズ後にクリーン・アップしないと、時間が経過すると一時ディレクトリのディスクがいっぱいになる可能性があります。

4 デプロイメント操作の実行

この章では、WebLogic Serverのアプリケーション・デプロイメントについて説明します。アプリケーションのデプロイメントでは、サーバー側処理とアプリケーションの起動のために管理サーバーに「デプロイメントのためのアプリケーションの構成」で作成した情報を配布します。デプロイメント・ツールを使用して、この章に記載されているデプロイメント工程を正常に完了する必要があります。

この章の内容は以下のとおりです。

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

- 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には、デプロイメントのためのアプリケーションの構成に加えて、Java EEサーバーへの接続を確立する役割もあります。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 Server管理サーバーのリモートで動作しています。デプロイメント・セッション中に参照されるファイルはすべて管理サーバーのリモートにあると想定され、アップロードが必要になる場合があります。たとえば、配布操作ではアプリケーション・ファイルの管理サーバーへのアップロードが行われます。

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

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

サーバー接続

DeploymentManagerは接続されているか、あるいは切断されています。接続されたDeploymentManagerとは、WebLogic Server管理サーバーに接続されていることを意味します。この接続は、接続が明示的に切断されるか失われるまで維持されます。接続が失われた場合、このDeploymentManagerは切断された状態になります。

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

注意:

新しいDeploymentManagerを割り当てても、ツール内でDeploymentConfigurationオブジェクトを通じて管理している構成情報には影響しません。

デプロイメントの手続き

DeploymentManagerのほとんどの機能的なコンポーネントは、Java EEデプロイメント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つのポリシーがあります。

1. (デフォルト)新しいバージョンがアクティブな場合、古いバージョンは無効になり、古いバージョンで実行中の処理が完了されます。

2. 新しいバージョンがアクティブになるまでの指定された時間制限の後で、新しいバージョンがアクティブなときに古いバージョンが廃止されます。

注意:

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

バージョンのサポート

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

管理(テスト)モード

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

進捗状況のレポート

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

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

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

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

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

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

package weblogic.deployer.tools;

import javax.enterprise.deploy.shared.*;
import javax.enterprise.deploy.spi.*;
import javax.enterprise.deploy.spi.status.*;

/**
* Example of class that waits for the completion of a deployment
* using ProgressEvent's.
*/
public class ProgressExample implements ProgressListener {

private boolean failed = false;
private DeploymentManager dm;
private TargetModuleID[] tmids;

public void main(String[] args) {
// set up DeploymentManager, TargetModuleIDs, etc
try {
wait(dm.start(tmids));
} catch (IllegalStateException ise) {
//... dm not connected
}
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の一部としてデプロイメント・プランに組み込まれ、別個のモジュールとしては組み込まれません。

ターゲット・タイプの認識

Java EEデプロイメント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() is not part of this 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が定義されています。この記述子は特定の環境向けに完全に構成されているのでデプロイメント・プランは必要ありませんが、ここで紹介するシナリオはデプロイメント・プランがある場合も同じです。

このモジュールをデプロイするツールでは次の手順が実行されます。

// init the jsr88 session. This uses a WLS specific helper class,
// which does not employ any WLS extensions
DeploymentManager dm = SessionHelper.getDeploymentManager(host,port,user,pword);

// get list of all configured targets
// The filter method is a location where you could ask the user
// to select from the list of all configured targets

Target[] targets = filter(dm.getTargets());

// the module is distributed to the selected targets
ProgressObject po = dm.distribute(targets,new File("jms.xml"),plan);

// when the wait comes back the task is done
waitForCompletion(po);

// It is assumed here that it worked (there is no exception handling)
// the TargetModuleIDs (tmids) returned from the PO correspond to all the
// configured app/module mbeans for each target the app was distributed to.
// This should include 3 tmids per target: the root module tmid and the
// submodules' tmids.
TargetModuleID[] tmids = po.getResultTargetModuleIDs();

// then to deploy the whole thing everywhere you would do this
po = dm.start(tmids);
// the result is that all sub-modules would be deployed on all the selected
// targets, since they are implicitly targeted wherever the their parent is
// targeted

// To get sub-module level deployment you need to use WebLogic Server
// extensions to create TargetModuleIDs that support module level targeting.
// The following deploys the topic "xyz" on a JMS server
WebLogicTargetModuleID root =
dm.createTargetModuleID(tmids[i].getModuleID(),tmids[i],jmsServer);
WebLogicTargetModuleID topic =
dm.createTargetModuleID(root,"xyz",WebLogicModuleType.JMS);

// now we can take the original list of tmids and let the user select
// specific tmids to deploy
po = dm.start(topic);

Oracleの法律上の注意点

コピーライト

Copyright © 1994-2017, Oracle and/or its affiliates. All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

Pre-General Availability (一般提供前)版のドキュメントについて

このドキュメントがPre-General Availability (一般提供前)版の場合:

このドキュメントはPre-General Availability (一般提供前)版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のPre-General Availability (一般提供前)版のドキュメントについて

このドキュメントが非公開のPre-General Availability (一般提供前)版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のPre-General Availability Trial Agreement (Pre-GAトライアル契約)のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle Partner Network Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティ

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info)か、聴覚に障害のあるお客様は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。