第 1 章 N1 Service Provisioning System プラグインの概要

この章では、Sun N1 Service Provisioning System (N1 SPS) 環境の概要を示し、プラグインがこの環境にどのように適合するかについて説明します。この章では、次の内容について説明します。

• 「Sun N1 Service Provisioning System の概要」

• 「ソリューション開発環境の概要」

• 「プラグインの概論」

• 「プラグインの内容」

• 「プラグインのパッケージ化」

Sun N1 Service Provisioning System の概要

N1 SPS 製品は、エンタープライズシステム構成、サービスプロビジョニング、およびアプリケーション配備のニーズを解決するための、XML ベースのオブジェクト指向型分散環境です。プロビジョニングシステムは、拡張可能なフレームワークと環境を提供し、次の基本機能があります。

• サービスプロビジョニングの自動化を実現する共通のフレームワーク – プロビジョニングシステムには、アプリケーションとサービスをモデル化し、これらのオブジェクトの配備を自動化できる XML スキーマと Java API があります。

• 変更の監査ログの維持 – プロビジョニングシステムの Run History プランと Where Installed プランを使用すると、ネットワーク内での配備とその配備のターゲットホストの状態を追跡できます。

• ターゲットホストの現在の状態とあるべき状態の比較 – プロビジョニングシステムでは、ネットワーク上のターゲットホストのスナップショットを取得し、ブラウザインタフェースまたは cmp コマンドを使用してさまざまな比較を実行できます。

• 変更のシミュレーションによる構成上の問題の特定 – プリフライト実行オプションを使用すると、配備プランのシミュレーションを行うことができます。配備上の問題が生じた場合は、ターゲットホストに悪影響を及ぼさずに障害追跡を行い、問題を解決できます。

• 自動実行を制御する一連の規則の実装 – プロビジョニングのプランでは、component 要素の platform 属性と limitToHostSet 属性とのプロビジョニングに、個々のホストまたはホストセットを指定できます。

• システム管理者に対する問題およびアクションの通知 – <sendCustomEvent> ステップを使用すると、コンポーネントの配備またはプランの実行が行われるたびに特定のメッセージが生成されます。このステップを通知規則モジュールと併用することで、特定のホストでこのステップが検出されるたびに電子メールを送信できます。

• バージョンの自動管理 – コンポーネントやプランを変更またはチェックインすると、プロビジョニングシステムソフトウェアによって、新しいコンポーネントまたはプランのバージョンが更新され、一方、古いバージョンが維持されます。

N1 SPS ソフトウェアでは、オブジェクト指向型のコンポーネントが XML スクリプトで記述され、また、分散、プロビジョニング、およびインストールのニーズの実行プランに従うように調整される分散環境が実装されます。N1 SPS の基本的な概念と用語については、『Sun N1 Service Provisioning System 5.2 インストールガイド』の第 1 章「Sun N1 Service Provisioning System 5.2 の概要」を参照してください。

ソリューション開発環境の概要

プロビジョニングシステムを使用して、システム構成、サービスプロビジョニング、およびアプリケーション配備のソリューションを構築できます。大まかな手順は次のとおりです。

1. 一連のコンポーネントを構築します。この手順には次の作業が含まれます。

   1. アプリケーションに固有のコンポーネントタイプを定義する

   2. 各コンポーネントに名前を付ける

   3. 各コンポーネントにコンポーネントタイプを割り当てる

   4. コンポーネントに必要なリソースを特定する (ソースファイルやディレクトリなど)

   5. コンポーネントに固有のタスク (制御) を定義する

2. コンポーネントの配備を指示するプランを作成します。各プランには次の情報が含まれます。

   1. コンポーネントの一覧

   2. コンポーネントの実行順序

   3. コンポーネントに必要な変数の一覧

   4. コンポーネントを配備する一連のターゲットホスト (<hostSet> 要素で定義)

3. 特定のプラットフォームまたはアプリケーション用に開発したコンポーネントやプランをほかのユーザーが使用できるようにするプラグインを作成します。この作業には主に次の作業が含まれます。

   1. 開発システムに sps-compSDK.jar ファイルをインストールする

   2. プラグインのモデルを開発して、プラグインで配備するアプリケーションのさまざまな構成オブジェクトをどのように特定するかを確認する

   3. アプリケーションオブジェクトをコンポーネントおよびリソースとして指定し、アプリケーションに必要な変数を定義する XML スキーマを開発する

   4. アプリケーションのインストール、アンインストール、起動、停止など、特定の配備作業を実行する XML プランを作成する

   5. プラグインで OS のネイティブコマンドを実行する execNative ステップをコンポーネントやプランに追加する

   6. プラグインの配備時に Java コードを実行する execJava ステップをコンポーネントやプランに追加する

      ---

      注 –

      Java を使用してプラグインを開発する必要がある場合は、NetBeans 製品を使用してください。詳細は、http://www.netbeans.org/ を参照してください。

      ---

   7. BrowserNode と ComponentExporter の各 Java クラスを使用して、プラグインユーザーがリモートシステムからコンポーネントを表示および作成できるようにする

   8. プラグイン用のカスタムユーザーインタフェースを開発して、ほかの SPS ユーザーが SPS のブラウザユーザーインタフェースを使用してプラグインにアクセスできるようにする

   9. コンポーネント、プラン、リソース、およびプラグイン定義ファイルを JAR ファイルとしてパッケージ化し、ほかの N1 SPS ユーザーに提供できるようにする

プラグインの概論

一般に、プラグインとは、 Web ブラウザに機能を追加するロード可能なアプリケーションを指します。N1 SPS 環境のプラグインは、一般的なプラグインとは概念的に少し異なります。N1 SPS 製品のプラグインは、特定のプラットフォーム、アプリケーション、または環境用の製品のプロビジョニング機能を拡張する、パッケージ化されたソリューションです。たとえば、BEA WebLogic 8.0 などの特定のアプリケーションや、Solaris ゾーンなどのオペレーティングシステムの特定の機能用にプラグインソリューションを作成できます。

プラグインには、新しいカスタムアプリケーションのサポートに必要な関連データがすべて含まれます。このデータは、プラグインの次の部分に含まれます。

• プラグイン記述子ファイル - このファイルには、プラグインの内容が記述されます。プラグイン記述子には、名前、説明、ベンダー、バージョン番号、旧バージョン、依存関係など、プラグインに関するメタデータが含まれます。また、readme.txt ファイルへのポインタを含めることもできます。記述子には、コンポーネント、プラン、フォルダ、ホストタイプ、ホストセット、ホスト検索、リソース、コンポーネントタイプ、およびシステムサービスを作成するための命令も含まれます。記述子では、サーバー側のプラグインコードのライブラリおよびプラグイン用の一連の GUI 拡張機能も定義できます。

• Java クラスファイル - Java ベースのコンポーネントクラスと execJava クラスがプラグインに含まれます。これらのファイルによって、エクスポート機能と一覧機能をプラグインに追加したり、Java コードを実行するステップを追加したりできます。

• コンポーネント定義 - プラグインに作成するコンポーネントとコンポーネントタイプは、プラグインの一部として XML ファイルに保存されます。これらのファイルで、プラグインで配備するオブジェクトとリソースを定義します。

XML スキーマ

N1 SPS 環境では、ソリューションのプラン、コンポーネント、およびその他の内容を XML で定義します。複数の XML スキーマを使用してプラグインソリューションを定義できます。製品メディアの docs/xml ディレクトリには、次のスキーマが含まれています。

• plugin.xsd – プラグイン記述子ファイルを使用してプラグインの内容を記述するプラグインスキーマ

• pluginUI.xsd – N1 SPS のブラウザインタフェース内でのプラグインのインタフェースを定義するプラグインユーザーインタフェーススキーマ

• component.xsd – コンポーネントとコンポーネントタイプを定義するコンポーネントスキーマ

• plan.xsd – 実行プランを定義するプランスキーマ

• planCompShared.xsd – プランとコンポーネントに共通する要素を含むスキーマ

このマニュアルには、XML スキーマの使用方法を示す例があります。XML スキーマで使用されている要素と属性のリファレンスについては、『Sun N1 Service Provisioning System 5.2 XML スキーマリファレンスガイド』を参照してください。

プラグインの内容

プラグインソリューションには、新しいカスタムアプリケーションのサポートに必要な関連データがすべて含まれます。このデータには、次のようなファーストクラスのプロビジョニングシステムオブジェクトが含まれます。

• コンポーネント

• コンポーネントタイプ

• フォルダ

• ホスト検索

• ホストセット

• ホストタイプ

• プラン

• システムサービス

また、プラグインには、システムで使用する補助オブジェクトを含めることができます。次にオブジェクトの例を示します。

• リソース

• プラグインの一覧機能とエクスポート機能を有効にする Java コード

• プラグインソリューション内で実行する execJava ステップ

プラグインのパッケージ化

プラグインは Java アーカイブ (JAR) ファイルとしてパッケージ化します。JAR ファイルの内容および内容を解釈するための命令は、JAR ファイルの最上位ディレクトリにある plugin-descriptor.xml ファイルに記述します。このファイルは署名することもできます。プラグイン記述子の構文は、2001 年 5 月 2 日付けの W3C 勧告 (http://www.w3.org/TR/2001/xmlschema-0-20010502/) に従った XML スキーマを使用して指定されています。このスキーマを Sun Studio^TM や NetBeans などの開発 IDE とともに使用して、プラグイン記述子ファイルの構文の妥当性を判断できます。

推奨される命名方法

重複を避けるため、プラグインは Java パッケージの命名規則に従い、com.companyname. productname の形式にする必要があります (たとえば com.sun.solaris )。フォルダ内のオブジェクトはすべて、プラグイン名を反映したフォルダディレクトリ構造に配置する必要があります (たとえば /com/sun/solaris)。プラグインの JAR ファイルの名前は、 pluginname_ version.jar の形式である必要があります (たとえば com.sun.solaris_1.1.jar )。

インストールに関する考慮事項

プラグインをインストールするには、サービスプロビジョニングの管理者がプラグインの JAR ファイルをロードします。プラグインは、ブラウザインタフェースまたはコマンド行インタフェースを使用して N1 SPS 環境にインポートできます。プラグインのインポート時には、プラグイン記述子ファイルおよびプラグインの内容の妥当性検査が行われます。ブラウザインタフェースでは、インポート処理中のエラーが強調表示されます。

プラグインのインポート方法については、『Sun N1 Service Provisioning System 5.2 システム管理者ガイド』を参照してください。

プラグインのアップグレードに関する考慮事項

プラグインを既存のバージョンから新しいバージョンにアップグレードするには、パッチに必要な内容のみを含むパッチ JAR ファイルを用意します。たとえば、version 1.2 と 1.3 の間で 2 つのコンポーネントタイプを変更しただけの場合、アップグレードパッチには新しいコンポーネントタイプの XML ファイルのみを含めます。パッチは、順番に適用して複数のバージョンにアップグレードできるように定義します。たとえば、version 1.0 から 1.2 にアップグレードする場合、ユーザーは最初に 1.0 から 1.1 へのアップグレードを適用し、次に 1.1 から 1.2 へのアップグレードを適用します。アップグレードパッチは、以前にロードされているプラグインのバージョンに付加する形で提供する必要があります。特定の既存のバージョン (1.0 など) から特定の新しいバージョン (1.3) にアップグレードするパッチを作成することもできます。ただし、任意のバージョンから新しいバージョンにアップグレードするパッチを作成することはできません。

プラグインのアンインストール

プラグインをアンインストールするには、次の作業を行う必要があります。

• プラグインのすべてのコンポーネントをアンインストールする

• プラグイン配備の一環としてターゲットホストにインストールされているすべてのシステムサービスをアンインストールする

• マスターサーバーのコンポーネントリポジトリから、非表示のインスタンスを含む、プラグインのコンポーネントタイプから作成されたすべてのコンポーネントインスタンスを削除する

プラグインのアンインストール方法については、『Sun N1 Service Provisioning System 5.2 システム管理者ガイド』を参照してください。

プラグインバージョンのアンインストール

プラグインの個々のパッチをアンインストールすることはできません。また、旧バージョンのプラグインによって作成されたオブジェクトを削除することはできません。この内容を削除するには、現バージョンのプラグインをアンインストールし、旧バージョンを再インストールする必要があります。別の方法として、旧バージョンのプラグインのコードをインストールすると同時に、プラグインで定義されているオブジェクトの新バージョンを作成するアンチパッチを作成することもできます。

コンポーネントのバージョンと依存関係

プラグインで定義されているオブジェクトは、プラグイン記述子ファイルで定義されている順序でインストール時にロードされます。これらのオブジェクトは、プラグインで以前に定義されているオブジェクト、またはオブジェクトを定義しているプラグインが直接依存するプラグイン内のオブジェクトだけを参照できます。依存関係はプラグイン記述子ファイルで宣言する必要があります。

バージョン管理に関する考慮事項

N1 SPS ソフトウェアでは、プランとコンポーネントのバージョンを取得できます。プラグイン内のプランやコンポーネントを変更し、これらのオブジェクトを N1 SPS 環境にチェックインすると、オブジェクトに新しいバージョン番号が割り当てられます。プラグイン配備の一環として、プラグインのプランとコンポーネントの最新バージョンを使用するか、旧バージョンを使用するかを選択できます。

プラグインで、タイプと名前がシステム内の既存のオブジェクトと同じであるバージョン管理対象オブジェクトを作成しようとすると、オブジェクトの新バージョンが作成されます。プラグイン定義で、このオブジェクトのメジャーバージョンを増分すると明示的に定義していない場合は、オブジェクトのマイナーバージョンが増分されます。

名前の重複を避けるため、プラグインではコンポーネントやプランなどのバージョン管理対象オブジェクトを、ほかのプラグインによって作成されたディレクトリに配置できません。

次のオブジェクトはバージョン管理されません。

• コンポーネントタイプ

• システムサービス

• ホストタイプ

• ホスト検索

• ホストセット

プラグインで、タイプと名前が既存のオブジェクトと同じであるバージョン管理対象外のオブジェクトを作成しようとすると、名前の重複を避けるため、オブジェクト名の前にプラグイン名が付加されます。

証明書

1 つのバージョンのプラグイン記述子ファイルを署名した場合、そのプラグインのそのあとのバージョンでもファイルを署名する必要があります。プラグイン記述子ファイルに署名するには、標準の jarsigner ツールを使用します。ファイルが署名されている場合、その署名はプラグインのインストール時に公開証明書に対して確認されます。プラグインをアップグレードするときは、新バージョンの署名に使用されている証明書が、システム内の既存バージョンの署名に使用されている証明書に対して照合されます。プラグインのバージョン間で証明書の有効期限が切れていた場合は、アップグレードが失敗します。

プラグイン記述子ファイルだけでなく、プラグインの JAR に含まれるすべてのエントリに同じ証明書を使用して署名する必要があります。各エントリに添付できる証明書は 1 つだけです。

セキュリティーに関する考慮事項

プラグインには、グループまたはアクセス権を定義する機能はありません。これは、アクセス権の管理はプラグインのロード先の環境に大きく依存し、すべての環境について効果的にモデル化できないためです。

プラグインを追加する管理者が、適切なアクセス権を決定する必要があります。一般に、プラグインはすべてのユーザーが使用できるように設計されているとみなされます。ただし、顧客によっては、プラグインの使用を特定のグループに制限する場合があります。プラグインには、異なる実行権が必要な特定のフォルダが含まれる場合もあります。

ブラウザインタフェースでのプラグインの表示

ブラウザインタフェースでのプラグインの表示順序は、N1 SPS プロビジョニングソフトウェアによって制御されます。プラグイン定義では表示順序を制御できません。

プラグインの readme.txt ファイル

プラグインには readme.txt ファイルを用意する必要があります。プラグインの readme.txt ファイルには、プラグインを使用できるようにシステムを構成する手順とプラグインに適用される著作権を記述します。一般に、readme.txt ファイルには、プラグインが機能するために必要なアクセス権、セッション変数、およびその他のインスタンス固有の設定を記述する必要があります。具体的には、プラグインによって作成されるフォルダに対するアクセス権を設定する手順や、必要なセッション変数、その説明、および暗号化の方法を列挙する手順を記述します。