test

N1 Grid Service Provisioning System 5.0 XML スキーマリファレンスガイド

第 1 章 XML スキーマの概要

この章では、XML スキーマの概要を説明し、XML スキーマを使用して作業を行う前に必要な一般的な情報を詳細に解説します。

次にこの章の内容を示します。

注 –

このマニュアルでは、「派生コンポーネント」、「子コンポーネント」、および「親コンポーネント」という用語は、コンポーネントの複合関係ではなく、コンポーネントの継承関係を指します。

サービスプロビジョニング言語およびスキーマ

N1 Grid Service Provisioning Systemソフトウェアは、XML を介して、プラン、コンポーネント、およびプラグインの定義を実装します。プロビジョニングソフトウェア 環境の各部分には、固有の XML スキーマがあります。各 XML スキーマは、プロビジョニングソフトウェア 環境の適切な部分を定義するために使用される、一連の固有の要素を定義します。

N1 Grid Service Provisioning Systemソフトウェアには 5 つの XML スキーマが含まれています。これらのスキーマは、次の 2 つの言語グループに分かれます。

各スキーマについては、このマニュアルの参照先の章で詳細に説明されています。すべてのスキーマに関連する一般的な情報は、この章の後ろで説明します。

ロケールと文字セットに関する要件

プランとコンポーネントは複数バイトデータを含むことができます。プランまたはコンポーネントが XML で作成されている場合、入力ファイルは UTF-8 形式であるか、ファイルの先頭でバイトオーダーマーク (BOM) を使用してその Unicode 符号を指定する必要があります。プランとコンポーネントがダウンロードされる場合、それらは常に UTF-8 形式で書き込まれます。単純コンポーネントが構成可能なリソースを参照する場合、そのリソースは Master Server のネイティブ符号化で符号化されている必要があり、またバイトオーダーマークを使用してその符号化を指定する必要があります。

パターン一致

要素の属性の多くは、正規表現パターンを含むことができます。特に指定がないかぎり、これらのパターンは完全な総称正規表現ではなく glob スタイルのパターンです。つまり、0 個以上の文字と一致させる場合はアスタリスク (*) が使用され、厳密に 1 文字だけと一致させる場合は疑問符 (?) が使用されます。角括弧 ( []) 内の文字は、厳密に 1 文字だけと一致させる文字の範囲を指定します。ハイフン (-) で区切られた文字は、アルファベット順でその範囲内にある文字と、指定された文字を含む任意の文字に一致します。

たとえば、[ab] は a または b に一致します。[a-z] は、任意の小文字に一致します。この場合、厳密な ASCII 文字のみが一致し、アクセント記号が付いた文字など、文字の拡張バリアントには一致しません。

すべての Unicode 文字に一致させるには、パターンには、Perl 5 の regex [[:lower]] などの POSIX 文字クラスが含まれる必要があります。また、非 ASCII 文字を直接含めることもできます。たとえば、[eé] は e または é に一致します。

変数とパラメータの受け渡し

プランとコンポーネントはどちらも、ステップで使用する変数を宣言できます。

コンポーネント変数は、コンポーネントのインストール時に評価、設定されます。したがって、コンポーネント制御ブロック内の手順が、コンポーネントスコープ変数を参照している場合、使用される値はコンポーネントのインストール時の変数の値と同じです。

ただしプラン変数は、プランの実行ごとに評価、設定されます。したがって、プラン内のステップがプラン変数を参照している場合、使用される値はプラン実行時に定義された値となり、実行ごとに異なる可能性があります。

プランは、パラメータと変数の両方を宣言できます。 変数の値は、ほかの変数と定数の値をもとに宣言時に定義されます。パラメータは、呼び出し元が値を定義する特殊な変数です。上位プランの場合、呼び出し元はプランの実行を開始したユーザーです。プランによって宣言される各パラメータに対して、プランを実行する前に、ユーザーはそのパラメータの値を指定します。プランが <execSubplan> 呼び出しの結果として呼び出された場合、その呼び出しを含むプランは、呼び出されたプランによって宣言される各パラメータの値を明示的に渡す必要があります。

<install>、<uninstall>、<snapshot> 、および <control> ブロックは、パラメータとローカル変数を宣言できます。プランの場合と同様に、ローカル変数の値はローカルで定義され、パラメータの値はブロックの呼び出し元が渡した値をもとに定義されます。どちらもプランの実行ごとに異なることがあります。

変数またはパラメータの値を再割り当てすることはできません。

コンポーネントの互換性

すでに配備されているコンポーネントの新しいバージョンを作成する際には、互換性が問題になります。コンポーネントの新しいバージョンを作成する際には、そのコンポーネントを使用または参照するそのほかのオブジェクトが、変更の結果として破損しないようにする必要があります。依存性、コンポーネント包含、継承、およびコンポーネントターゲッターを使用することで、コンポーネントの使用および参照を行うことができます。

プロビジョニングソフトウェア は、次の種類のコンポーネントの互換性をサポートしています。

さまざまな時点で、データセンターのさまざまな部分に対して異なるバージョンのコンポーネントが配備できるため、開発者は互換性の要件に注意し、あるコンポーネントに対する変更がほかの既存コンポーネントに対してどのように影響するかを理解する必要があります。特定のケースでは、システムにより互換性の要件が強制される場合もあり、また開発者が新しいコンポーネントの互換性を確保しなければならない場合もあります。

あるコンポーネントに対して実施可能な変更の種類のリストは、付録 A 「コンポーネント変更の互換性」を参照してください。

呼び出しの互換性

あるコンポーネントが別のコンポーネントと呼び出し互換であるのは、以下の場合のように、最初のコンポーネントの使用を、別のコンポーネントの使用に安全に置き換えることができる場合です。

呼び出しの互換性は、API の互換性やインタフェースの互換性と同じです。

注 –

通常、2 つの呼び出し互換コンポーネントは、同じバージョンツリー内のバージョンが異なるコンポーネントです。ただし、2 つ目のコンポーネントは、最初のコンポーネントのインスタンスである場合、別のバージョンツリー内に存在することも可能です。

プロビジョニングソフトウェアでは、システムサービスを提供するコンポーネントに対して、呼び出しの互換性が強制されます。システムサービスが新しいコンポーネントを参照するよう更新される場合、新しいコンポーネントが元のコンポーネントに対して呼び出し互換性を持つようにします。これにより、システムサービスのアップグレード時にも、システムサービスのクライアントが正常に機能し続けることを保証できます。

プロビジョニングソフトウェアは、一部のインストール済みコンポーネントターゲッターに参照されているコンポーネントを解釈処理するときにも、オプションで呼び出し互換性を検証します。詳細は、「インストール済みコンポーネントターゲッター」を参照してください。

コンポーネントがその旧バージョンに対して呼び出し互換である必要はありませんが、呼び出し互換性を持たせることをお勧めします。

インストールの互換性

コンポーネントは、別のコンポーネントとインストール互換になることが可能です。最初のコンポーネントは、もう一方のコンポーネントと呼び出し互換である必要があります。以下の場合、もう一方のコンポーネントの使用は、最初のコンポーネントの使用と安全に置き換えられる必要があります。

インストールの互換性とは、構造上の互換性と同じです。

インストールの互換性の制約により、既存のインストール済みコンポーネントは、別のインストール互換コンポーネントに安全に置き換えることができる必要があります。オリジナルがどのようにインストールされたかを記述するデータ構造を変更する必要はありません。呼び出し互換のコンポーネントは、データ構造を適切に更新するために再インストールしなければならない場合があるので、呼び出し互換性はかなり弱いステートメントになります。

注 –

インストールの互換性を保つためには、両方のコンポーネントは同じバージョンツリーに属している必要があります。2 つの別々のバージョンツリーからのコンポーネントであってはなりません。

プロビジョニングソフトウェア は、コンポーネント型と呼ばれる、型として機能するコンポーネントだけにインストールの互換性を要求します。コンポーネント型が新しいバージョンのコンポーネントを参照するために更新されるときには、新しいバージョンは元のバージョンに対してインストール互換性を持ちます。 したがって、その型から派生するすべての既存コンポーネントを再構築や再インストールせずに、コンポーネント型に対してインストール互換の更新を実行できます。 インストール互換ではないコンポーネント型への変更は、独自の型名を持つ新しい別のコンポーネントバージョンツリーとして符号化する必要があります。このような場合、新しいコンポーネント型は、元のコンポーネント型から拡張することによって、呼び出し互換性を維持できます。 型間の関係を簡単に特定するには、コンポーネント型名を符号化するバージョン管理システムを使用します。 たとえば、コンポーネント名 EJB-1.0 と EJB-1.1 がある場合、EJB-1.1 は EJB-1.0 コンポーネント型の新しいバージョンであることを簡単に特定できます。

インストール互換である場合は呼び出し互換でもありますが、呼び出し互換であってもインストール互換であるとは限りません。また、コンポーネントが呼び出し互換でない場合は、インストール互換ではありません。

ターゲット可能コンポーネント

<targetRef> 要素が存在していれば、インストールされたコンポーネントは、ほかのコンポーネントの配備ターゲットとして使用できることを示します。このようにターゲット可能にするには、コンポーネントの各インストール済みインスタンスを、一意の仮想ホストまたは物理ホストに関連付けます。

ターゲット可能コンポーネントを使用して、関連付けられているホストをターゲットにすることで、プランはインストール済みコンポーネントを論理上ターゲットにすることができます。通常、ターゲット可能コンポーネントは仮想ホストを作成します。 ただし、ターゲット可能コンポーネントに物理ホストを作成させることもできます。物理ホストは、関連付けられたホストが独自の Remote Agent を持つモデルで便利です。SolarisTM Zone をモデル化するコンポーネントがこれに該当します。

<targetRef> 要素を定義するコンポーネントは、ターゲット可能コンポーネントです。ターゲット可能コンポーネントは、インストール時に、そのほかのコンポーネントの配備ターゲットとして機能するホストを作成します。ターゲット可能コンポーネントをアンインストールすると、そのコンポーネントによって作成されたホストが自動的に削除されます。このようなホストは「Hosts」ページに一覧表示されますが、一覧表示から削除することはできません。またそれらに対して可能な編集の種類も制限されています。

共通の属性型

属性型は、プランまたはコンポーネントの属性の値に対する制約として機能します。ある属性に特定の型が記載されていない場合、その値には制約がありません。

以降の節では、スキーマによって使用される属性型の形式について説明します。\p{N} はすべての Unicode 数字を表し、\p{L} はすべての Unicode 文字を表します。

entityName 属性型

entityName 型の属性は、最大文字長は 512 文字で、次のパターンに一致します。


[\p{N}\p{L}-_. ]+

特別なケースとして、ドット (.) および 2 つのドット (..) はエンティティ名になることはできません。

systemName 属性型

systemName 型の属性は、次のように、最大文字長が 64 文字である simpleSystemName、およびオプションで同じく最大文字長が 64 文字である pluginName から構成されています。


simpleSystemName
pluginName#
simpleSystemName

simpleSystemName は次のパターンに一致します。


[\p{L}_][\p{N}\p{L}-_. +]*

identifier 属性型

identifier 型の属性は、最大文字長は 32 文字で、次のパターンに一致します。


[\p{L}_][\p{N}\p{L}_]*

pathName 属性型

pathName 型の属性は、最大文字長は 512 文字で、次のいずれかのパターンに一致します。


"/"
( "/" pathPart )+

ここで pathPart は [\p{N}\p{L}-_. ]+ です。

特別なケースとして、ドット (.) および 2 つのドット (..) を、pathPart に含めることはできません。

pathReference 属性型

pathReference 型の属性の構文は次のようになります。


pathReference:
    absolutePath
    relativePath

absolutePath:
    "/"
    "/" relativePath

relativePath:
    relativePathStart
    relativePathStart "/" relativePath

relativePathStart:
    "."
    ".."
    identifier

modifierEnum 属性型

modifierEnum 型の属性は、値として ABSTRACT または FINAL を取ります。一般的に、値 ABSTRACT は、関連付けられるエンティティが派生コンポーネントによってオーバーライドされることを示します。値 FINAL は、関連付けられるエンティティがオーバーライドされないことを示します。

accessEnum 属性型

accessEnum 型の属性は、次のいずれかの値を取ります。

version 属性型

version 型の属性は、次のパターンに一致します。


[0-9]+\.[0-9]+

schemaVersion 属性型

schemaVersion 型の属性は、唯一の値 5.0 のみを取ることができます。