| Oracle® Fusion Middleware Oracle Virtual Assembly Builderアプリケーションおよびイントロスペクション・プラグインの開発 12c (12.1.2) E47992-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Virtual Assembly Builderアプリケーションおよびイントロスペクション・プラグインの開発 12c (12.1.2) E47992-01 |
|
前 |
次 |
この章ではOracle Virtual Assembly Builderイントロスぺクション・フレームワークのモジュールについて説明します。この章の構成は、次のとおりです。
7.5項「アプライアンス[oracle.as.assemblybuilder.introspector.metadata.appliance.Appliance]」
7.6項「アセンブリ[oracle.as.assemblybuilder.introspector.metadata.assembly.Assembly]」
7.8項「イントロスペクタ・プラグイン・ユーティリティ[oracle.as.assemblybuilder.introspector.plugin.util]」
Oracle Virtual Assembly Builderフレームワークは多数のモジュールで構成されています。現時点では、モジュールという用語はJARファイルと同義語ですが、このドキュメントではモジュールという用語を使用します。単一のモジュールにすべての機能を配置するのではなく、機能の論議グループごとに専用のモジュールに格納します。これによって各モジュール間の依存関係を表示し、様々なユース・ケースでの機能のデプロイメントの柔軟性を高めます。
この項の目標は、Oracle Virtual Assembly Builderディストリビューションで提供されているモジュールを簡単に説明することです。これはすべてのモジュールの包括的なリストではなく、プラグインに関連するモジュールのみを取り上げています。
外部共通モジュールにはすべてのプラグインによって使用される機能が含まれます。このモジュールにはログ出力、リソース・バンドル(国際化のためにログ出力によって使用される)、基本例外およびその他のいくつかのクラスが含まれます。
プラグイン内でのロギングの場合、LoggerFactoryを使用してログ出力インスタンスを作成します。このログ出力インスタンスは、すべてのログ・メッセージが共通のログ・ファイルに一貫した書式で格納されるように保証します。また、このログ出力インスタンスは診断情報とすべてのOracle製品で必要とされる国際化を適切に処理するためにOJDLをサポートしています。汎用のLoggerFactoryとロギングの使用の詳細は「イントロスペクタ・プラグインの開発」の項に記載されています。
プラグインで新しい例外タイプを作成する場合は、AbExceptionまたはAbCheckedExceptionを拡張する必要があります。AbExceptionはRuntimeExceptionで、AbCheckedExceptionはExceptionです。これらの例外タイプは、すべてのOracle製品の要件であるOJDLをサポートしています。
ロギングと例外のどちらのクラスも国際化にリソース・バンドルを使用します。デフォルトでは、ログ出力がリソースにアクセスするためにこのモジュール内のResourceBundleクラスを拡張する必要があります。ただし、別の方法でメッセージを格納することを決定した場合は、ログ出力と例外を使用する他の方法があります。これについては、第6章「インスペクション・プラグインの開発」で詳しく説明されています。
進捗モジュールには、プラグインがユーザー・インタフェースに進捗を報告できるようにする機能が含まれています。現在配置されている進捗メカニズムは事前定義済進捗と非定型進捗の両方をサポートしています。事前定義済進捗を使用すると、プラグインはデハイドレーション(および最終的にはリハイドレーション)で発生するステップ・リスト、つまりユーザーに現在のステップや残りのステップ数を提示できるリストを定義できます。非定型進捗では、プラグインは実行時まで決定できない動的に生成されたテキストをユーザーに提供します。これについては、第6章「インスペクション・プラグインの開発」で詳しく説明されています。
イントロスペクタ・モジュールにはイントロスペクタ・フレームワークとメタデータAPIが含まれます。イントロスペクタ・モジュールは、クライアントがイントロスぺクションを実行するために使用するIntrospectorManagerサービスを登録します。また、すべての使用可能なプラグインを動的に検出するためにすべてのプラグイン・サービスの登録を追跡します。
このモジュールにはプラグインを作成するために必要なすべてのインタフェースが含まれます。したがって、プラグインはこのモジュールに必ず依存します。
このドキュメントの他の部分で述べたとおり、カタログはメタデータが格納される場所で、デハイドレーション・プロセスの主要な結果を示します。イントロスペクタ・モジュールは専用のメタデータAPIを通じてカタログAPIのサブセットを公開します。メタデータAPIは、'oracle.as.assemblybuilder.introspector.metadata'パッケージ内のこのモジュールに配置されています。
アプライアンスは所定の製品のサーバーの特定にインストールに関するメタデータを取得するために使用されます。アプライアンスには子はありません。
次にアプライアンスの各部分を示します。
CaptureId
CaptureIdは、新しいアプライアンスが作成されると自動的に生成される一意のキーです。それは、他のカタログ・アーティファクトをメタデータに関連付けるために使用されます。
ScalabilityInfo
スケーラビリティ情報には、アプライアンスをデプロイするための最小、最大、ターゲットおよび絶対最大が記述されます。最小は、デプロイ可能なこのアプライアンスのインスタンスの最小数です。最大は、デプロイ可能なこのアプライアンスのインスタンスの最大数です。ターゲットは、デプロイ時に作成されるこのアプライアンスのインスタンスの実際の数です。ターゲットは最小を下回ることも最大を上回ることもありません。絶対最大は、最大を設定できる上限で、デハイドレーション時にのみ設定され、ユーザーは編集時にこの値を変更できません。他のすべての値は編集時にユーザーによって設定できます。
最小が1、最大が10、ターゲットが5に設定されている例を取り上げます。初期デプロイメントでは、5つのアプライアンスのインスタンスが作成されます。ただし、ユーザーはアプライアンスを拡張すると決定した場合に、後からさらに5つのアプライアンスを追加できます。
リソース要件
リソース要件は、アプライアンスに必要なシステム・リソースを定義します。現在のリソース要件タイプ: CPU_MHZ、MEMORY_MBおよびNUMBER_CPUS。デプロイメント時に、これらの値を使用して、このアプライアンスがデプロイされている仮想マシンが定義済の値を満たすか超えているように保証できます。
含まれるコンポーネント
このアプライアンスに含まれているコンポーネントのリストです。一般に、これはプラグイン名と同じで、単一の項目のみになります。
タイプ
アプライアンスのタイプ。これはプラグインによって設定されることがあります。プラグインによって設定されていない場合は、デフォルトでプラグイン名になります。
入力
入力は、定義では、あるプロトコル・セットを使用してあるポートをリッスンするソケットです。入力の作成時にはポートとプロトコルの値を提供する必要があります。
出力
出力は製品が確立する他の入力への接続です。接続に使用するプロトコルを指定する必要があります。また、リハイドレーション時に出力に関する追加情報が必要な場合は、プロパティとシステム・プロパティを出力に追加できます。これらのプロパティはOVABによって直接使用されることはなく、単に他のメタデータと一緒に渡されます。プロパティとシステム・プロパティの相違は、プロパティはユーザーによって編集可能であるのに対し、システム・プロパティは編集不可である点です。
ユーザー・プロパティ
プロパティによって、プラグインは任意の名前/値ペアをリハイドレーションに使用するアプライアンスにアタッチできます。ユーザー・プロパティはユーザーによって編集可能です。
システム・プロパティ
システム・プロパティによって、プラグインは任意の名前/値ペアをリハイドレーションで使用するアプライアンスにアタッチできます。ユーザーはシステム・プロパティを編集できません。
コンテンツ・リソース
コンテンツ・リソースはファイルと考えることができます。これによって、デプロイ済システムへ転送するためにファイルをアプライアンスにアタッチできます。発想は、必要なすべてのファイルをグラブするのではなく、ゴールデン・システムからデプロイ済システムまでの途中でなんらか方法で変更する必要のあるファイルのみをグラブするというものです。たとえば、構成ファイルを元の形式からVelocityテンプレートに変換する場合があります。その後、リハイドレーション時にこれらのテンプレートを使用して、新しい入力/出力、プロパティおよびシステム・プロパティ情報を追加しなおします。これらの変換されたファイルは、その後元の構成ファイルの場所に戻されます。また、デハイドレーション時にスクリプトを生成し、その後コンテンツ・リソースとして追加して、後からリハイドレーション時に実行できるようにする場合があります。
|
注意: コンテンツ・リソースは、ファイルを参照システムからデプロイ済システムへ転送する方法を示してるわけではありません。パッケージ定義は、パッケージ化し、後からデプロイ済システムへ移動するファイル・セットを識別するために使用されます。 |
バージョン
これは、メタデータにそのバージョンを示す番号をマークするために使用されます。これは製品バージョンではなく、マーカーです。たとえば、初期リリースはバージョン1で始まります。後から追加のメタデータが必要だと判断した場合は、このバージョンを2に変更します。このように、プラグインがメタデータを参照する場合、最初にバージョン番号をチェックして存在すると予測される要素を把握し、その処理を適切に変更します。発想は、同じプラグインの以前のリリースで生成されたデータを処理するためにより最新のバージョンのプラグインを使用するというものです。
アセンブリは、アプライアンスとサブアセンブリのコンテナです。アセンブリには、アプライアンスと同様に、入力、出力、プロパティ、システム・プロパティ、コンテンツ・リソースおよびバージョンがあります。アプライアンスとアセンブリの主な相違は、アセンブリが他のアプライアンスとアセンブリのコンテナである点です。
カタログ・モジュールは、OVABに関連するすべてのデータを含むデータ・モデルです。カタログは、OVABのすべてのデーズからのデータが格納される階層構造とみなします。このデータはメタデータ、コンテンツ・リソース、パッケージ、テンプレートおよびデプロイメント・プランから構成されています。
メタデータはアセンブリとアプライアンスが保持される場所です。メタデータはイントロスぺクション・プロセスから生成されるプラグインの出力です。このデータは後からデプロイメント時に編集できますが、それはプラグインから生成されます。
パッケージはバンドリング中の収集されたバイナリ・データが格納されり場所です。パッケージ化は、デハイドレーションの直後に発生するプロセスで、テンプレートの生成の前兆です。パッケージ化は後述のテンプレートの生成に関する項で詳しく説明されています。
テンプレートはデプロイ可能なVMイメージが格納される場所です。テンプレートは、テンプレートの生成プロセスの結果として生成され、デプロイメント・プロセスへの入力として使用されます。これらはどちらも、後述のテンプレートの生成とデプロイヤに関する項で詳しく説明されています。
イントロスペクタ・プラグイン・ユーティリティ・モジュールはプラグイン開発用の一連のユーティリティを提供します。このモジュールは、ユーティリティ・インスタンスを作成するためのSPIFサービス'oracle.as.assemblybuilder.introspector.plugin.util.UtilFactory'を定義します。このファクトリ・クラスによって提供される各ユーティリティの詳細はJavadocドキュメントを参照してください。特に注目すべきなのは、リハイドレーション時のファイルのコピー、それらの権限の変更、特定ユーザーとしてのコマンドの実行またはテンプレートでのVelocityの実行に使用できるRehydrateUtilユーティリティ・クラスです。
