第 1 章 XML スキーマの概要

この章では、 Sun N1 Service Provisioning System (N1 SPS) により使用される XML スキーマの概要を説明します。

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

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

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

• 「パターン一致」

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

• 「コンポーネントの互換性」

• 「ターゲット可能コンポーネント」

• 「共通の属性型」

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

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

N1 SPSソフトウェアは、XML を使用して、プラン、コンポーネント、リソース記述子、およびプラグインの定義を実装します。これらの各N1 SPSコンストラクトは、特定の種類の XML スキーマを使用します。

N1 SPS製品には次の XML スキーマが含まれます。

• component.xsd – コンポーネントとコンポーネント型の定義に使用されるスキーマ。第 3 章「コンポーネントのスキーマ」を参照してください。

• plan.xsd – 実行プランの定義に使用されるスキーマ。第 4 章「プランのスキーマ」を参照してください。

• planCompShared.xsd – プランとコンポーネントに共通する要素が含まれるスキーマ。第 2 章「コンポーネントと単純プランにより使用される共有スキーマ」を参照してください。

• resourceDescriptor.xsd – リソース記述子の定義に使用されるスキーマ。第 5 章「リソース記述子スキーマ」を参照してください。

• plugin.xsd – プラグイン記述子ファイルでのプラグインの定義に使用されるスキーマ。第 6 章「プラグイン記述子スキーマ」を参照してください。

• pluginUI.xsd – N1 SPSブラウザインタフェース内でプラグインに対するユーザーインタフェースの定義に使用されるスキーマ。第 7 章「プラグインユーザーインタフェーススキーマ」を参照してください。

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

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

プランとコンポーネントは複数バイトデータを含むことができます。プランまたはコンポーネントが 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> ブロックは、パラメタとローカル変数を宣言できます。プランの場合と同様に、ローカル変数の値はローカルで定義され、パラメータの値はブロックの呼び出し元が渡した値をもとに定義されます。どちらもプランの実行ごとに異なることがあります。

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

コンポーネントの互換性

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

N1 SPS製品は、次の種類のコンポーネントの互換性をサポートしています。

• 呼び出しの互換性は、コンポーネントに対してユーザーが行える一連の変更を規定します。また呼び出しの互換性により、依存性とコンポーネントターゲッターを通じて存在する関係が保証されます。

• インストールの互換性は、コンポーネントに対してユーザーが行える一連の変更を規定します。またコンポーネントの互換性により、継承とコンポーネント包含関係を通じて存在する関係が保証されます。

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

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

呼び出しの互換性

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

• 最初のコンポーネントの <control>、<uninstall>、または <snapshot> ブロックへの呼び出しを行う場合

• <checkDependency> または <createDependency> を使用して、最初のコンポーネントの依存性を確認する場合

• 構成生成 :[component:AB:var] を使用することで、最初のコンポーネントの変数を参照する場合

呼び出しの互換性は、API 互換性やインタフェース互換性とも呼ばれます。

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

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

またN1 SPS製品は、一部のインストール済みコンポーネントターゲッターに参照されているコンポーネントを解釈処理するときにも、オプションで呼び出し互換性を検証します。詳細は、「インストール済みコンポーネントターゲッター」を参照してください。

必須ではありませんが、コンポーネントがその旧バージョンに対して呼び出し互換であるようにしてください。

インストールの互換性

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

• もう一方のコンポーネントのインストールブロックへの呼び出しを行う場合

• コンポーネントがもう一方のコンポーネントから拡張される場合

• コンポーネントがもう一方のコンポーネントへの参照を含む場合

インストールの互換性は、構造上の互換性とも呼ばれます。

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

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

N1 SPS製品は、「コンポーネント型」と呼ばれる、型として機能するコンポーネントだけにインストールの互換性を要求します。コンポーネント型が新しいバージョンのコンポーネントを参照するために更新されるときには、新しいバージョンは元のバージョンに対してインストール互換性を持ちます。 したがって、その型から派生するすべての既存コンポーネントを再構築や再インストールせずに、コンポーネント型に対してインストール互換の更新を実行できます。

インストール互換ではないコンポーネント型への変更を行う場合、新しい名前を持つ新しいバージョンツリーに新しいコンポーネント型を作成する必要があります。このような場合、新しいコンポーネント型は、元のコンポーネント型から拡張することによって、呼び出し互換性を維持できます。 型間の関係を簡単に特定するには、コンポーネント型名を符号化するバージョン管理システムを使用します。 たとえば、コンポーネント名 EJB-1.0 と EJB-1.1 で、EJB-1.1 が EJB-1.0 コンポーネント型の新しいバージョンであることを簡単に示すことができます。

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

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

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

ターゲット可能コンポーネントを使用して、関連付けられているホストをターゲットにすることで、プランはインストール済みコンポーネントを論理上ターゲットにすることができます。 通常、ターゲット可能コンポーネントは仮想ホストを作成します。ただし、ターゲット可能コンポーネントに物理ホストを作成させることもできます。物理ホストは、関連付けられたホストが独自の Remote Agent を持つモデルで便利です。Solaris ^TM 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 型の属性は、最大文字長は 512 文字で、次のパターンに一致します。

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

pathName 属性型

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

/
/pathPart

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

/ 区切り文字を使用すると、/pathPart /pathPart/pathPart のように、複数の pathPart をつなぎ合わせることができます。

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

pathReference 属性型

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

pathReference:
    absolutePath
    relativePath

absolutePath:
    /
    /relativePath

relativePath:
    relativePathStart
    relativePathStart/relativePath

relativePathStart:
    .
    ..
    pathPart

modifierEnum 属性型

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

accessEnum 属性型

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

• PUBLIC – 関連付けられたエンティティーが任意のオブジェクトによりアクセスできることを示します。

• PROTECTED – 関連付けられたエンティティーが、同じパス内にある派生コンポーネントおよびほかのエンティティーによりアクセスできることを示します。

• PATH – 関連付けられたエンティティーが、同じパス内にあるほかのエンティティーによりアクセスできることを示します。

• PRIVATE – 関連付けられたエンティティーが、宣言元コンポーネントによりアクセスできることを示します。

version 属性型

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

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

schemaVersion 属性型

schemaVersion 型の属性は、値 5.0 または 5.1 のみを取ります。

HostEntityName 属性型

HostEntityName 属性型の最大長は 64 で、Unicode 文字および数字の任意の組み合わせを含むことができます。

pluginName 属性型

pluginName 属性型の最大長は 64 で、Unicode 文字および数字の任意の組み合わせを含むことができます。

pluginHostEntityName 属性型

pluginHostEntityName 属性型の最大長は 64 で、Unicode 文字および数字の任意の組み合わせを含むことができます。