test

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

第 1 章 XML スキーマの概要

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

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

注 –

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

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

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

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

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

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

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

パターン一致

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

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

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

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

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

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

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

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

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

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

<assign> ステップと <assign*> 要素では、ローカル変数に新しい値を割り当てる手段が提供されます。包含ブロックで新しい変数の宣言が許可されない場合は、包含するローカルスコープ内に変数があれば、その変数だけを変更できます。

コンポーネントの互換性

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

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

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

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

呼び出しの互換性

次の場合に、A の使用を安全に B の使用に置き換えることができれば、コンポーネント B はコンポーネント A と「呼び出し互換」であると見なされます。

呼び出しの互換性は、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 を持つモデルで便利です。SolarisTM 10 Zone をモデル化するコンポーネントがこれに該当します。

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

共通の属性型

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

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

entityName 属性型

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


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

entityName の例としては _Continent_Region.database server があります。

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

systemName 属性型

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


simpleSystemName
pluginName#simpleSystemName

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


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

systemName の例としては、 CENTRAL_AMERICA.TEXAS_systemusers.500k+ の simpleSystemName、および com.sun.sjsas81#CENTRAL_AMERICA.TEXAS_systemusers.500k+ の pluginName#simpleSystemName 用の com.sun.sjsas81 の pluginName があります。

identifier 属性型

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


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

identifier の例としては NORTH_AMERICA_800AAA_555ABCD_ があります。

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 型の属性は、次のいずれかの値を取ります。

version 属性型

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


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

version の例として、最小値 0.0 から最大値 9.9 までの値があります。

schemaVersion 属性型

schemaVersion 型の属性は、値 5.0、5.1、または 5.2 のいずれかのみを取ります。

HostEntityName 属性型

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

pluginName 属性型

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

pluginHostEntityName 属性型

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