第 1 章 N1 Service Provisioning System Software XML スキーマの概要

プラン、およびコンポーネント言語、つまり XML スキーマは、N1^TM Service Provisioning System software 内でアプリケーションをモデル化および管理するために使用する制御構造の構文および意味論を定義します。

コンポーネントとは、アプリケーションを定義するリソース (ファイル、ディレクトリ、データベースレコードなど) ファイルの論理的なグループです。 コンポーネントには、アプリケーションの比較、インストール、アンインストール、制御に使用される命令のシーケンスも含まれます。 たとえば、インストールされたアプリケーションの「起動」または「停止」に使用される一連の命令は、アプリケーションの制御です。 命令としては、他のコンポーネントへの依存性チェックなどの事前状況や事後状況のテストや特定のプロセスが実行中であることの検証などがあります。 最後に、コンポーネントでは、コンポーネント自体およびプランの実行時に置換される値が入る可変部分としてコンポーネントが持つリソース内で使用される置換変数を宣言できます。

プランとは、一般的に 1 つ以上のコンポーネントの操作に使用される命令のシーケンスです。 たとえばプランは、プロビジョニングソフトウェア に 3 つのコンポーネントをインストールし、別のコンポーネントで 「起動」制御を開始するように指示できます。 また他のプランのシーケンスとしてプランを定義することも可能です。これにより、複数のプラン間で共有する共通の命令シーケンスを作成できます。

プランの種類

N1 Service Provisioning System software には、2 種類のプランがあります。

• 複合プラン (サブプランだけを含む)

• 単純プラン (他のサブプランを呼び出せない単純な手順の集合)

XML スキーマは、他のサブプランの呼び出しだけを行う最上位プラン、または簡単な手順を含みながら他のサブプランの呼び出しは行わない単純プランのどちらかを使用できるよう、この制限を適用します。 単純プランに含まれる手順は、すべて同じ対象ホストセット上で実行されるのに対して、複合プランの手順は、再帰的に複合プランに含まれる各単純プランに対して 1 つの対象ホストセットを使用することで、異なる対象ホストセット上でも実行できるので、この区別は重要です。

手順の種類

また N1 Service Provisioning System software で使用可能な手順は、3 種類あります。

• コンポーネント内からのみ呼び出し可能な手順。 このカテゴリはさらに、インストールブロックからのみ呼び出し可能な手順とアンインストールブロックからのみ呼び出し可能な手順に分けられます

• プランからのみ呼び出し可能な手順。 このカテゴリはさらに、複合プランからのみ呼び出し可能な手順と単純プランからのみ呼び出し可能な手順に分けられます

• プランからもコンポーネントからも呼び出し可能な手順

コンポーネントの種類

プラン同様、コンポーネントも複合コンポーネントと単純コンポーネントの 2 種類があります。 単純コンポーネントとは、1 つのリソースを持ち、他のコンポーネントを参照しないコンポーネントです。 複合コンポーネントとは、他のコンポーネントを参照しており、リソースは持たないコンポーネントです。 複合コンポーネントは、複合コンポーネントと単純コンポーネントの両方を参照する場合があります。

複合コンポーネントには、そのコンポーネントが参照するコンポーネントが含まれます。 参照先コンポーネントは、被包含コンポーネントと呼ばれ、参照元コンポーネントは包含コンポーネントまたはコンテナコンポーネントと呼ばれます。

複合コンポーネントは、各被包含コンポーネントを最上位コンポーネントとしてインストールするか、入れ子コンポーネントとしてインストールするかを宣言します。 被包含コンポーネントが最上位コンポーネントとしてインストールされた場合、プランによって直接インストールされたように、他のコンポーネントはそのコンポーネントを使用できます。 一方、被包含コンポーネントが入れ子コンポーネントとしてインストールされた場合は、包含コンポーネントしかそのサービスを使用できません。 必然的に、入れ子型被包含コンポーネントは包含コンポーネントが必要とする機能をより細かく定義しますが、それ以外の場合に他のコンポーネントにとって役立つことはありません。 最上位被包含コンポーネントは、包含コンポーネントだけではなく、その他のコンポーネントも使用できるサービスを定義します。

複合コンポーネントには、その他のコンポーネントへの参照のみが含まれており、コンポーネント自体は含まれていません。 参照先コンポーネントは、包含コンポーネントとは無関係に更新および管理されるその他の既存コンポーネントです。 コンポーネントを参照する複合コンポーネントの数に制限はありません。 コンポーネントの名前は、そのコンポーネントが他の複合コンポーネントから参照されているかどうかには影響されません。名前の重複はパスを使用して解決処理されます。

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

コンポーネントの参照

コンポーネントを参照する手順は多数あります。 これらの手順は、次の 2 つのカテゴリに分類できます。

• まだインストールされていないコンポーネントを参照する手順

  • Install

• すでにインストール済みのコンポーネントを参照する手順

  • Uninstall

  • Call

  • CheckDependency

  • CreateDependency

  • AddSnapshot

まだインストールされていないコンポーネントを参照する手順に必要なのは、コンポーネント名とオプションのバージョンの指定だけです。 一方、インストール済みコンポーネントを参照する手順では、対象コンポーネントのあるインストールパスを追加指定する場合もあります。 同じコンポーネントが同じマシンに複数回インストールされる場合があるので、インストール済みコンポーネントの場合には、installPath が必要です。

たとえば、以下の属性を持つ「apache」というコンポーネントがホストにインストールされているとします。

表 1–2 には、installPath とビルドバージョンのさまざまな組み合わせに対して参照されるインストール済みコンポーネントを示します。

共通イントールパスの書式

前の節に説明したように、インストールパスはインストール済みコンポーネント参照内に指定できます。 その場合、指定されたインストールパス属性は、インストール済みコンポーネント参照を解釈処理する前に共通書式に変換されます。 共通書式では、インストールパス内にあるマスターサーバーの OS に固有のパス区切り文字はすべて「/」に置き換えられ、末尾の「/」はすべて削除されます。 ルートインストールパス (「/」) は例外で、空のパスには変換されません。

Master Server が UNIX ベースのシステムで実行されている場合、この変換の影響は最低限に抑えられます。 「/」で終わるインストールパスは、「/」が含まれていないものとして扱われます。 たとえば、ディレクトリ「/opt/apache」にインストールされたコンポーネントを指すためには、「/opt/apache/」と「/opt/apache」の両方を使用できます。

この変換が行われるのは、インストール済みコンポーネントのインストールパスも共通書式で保存されるからです。

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

N1 Service Provisioning System software は、地域対応された環境でインストールおよび実行するために国際化されています。 地域対応された環境でこのソフトウェアを実行する場合は、以下の要件を守ってください。

• すべてのアプリケーションは、同一ロケールまたは同等のロケール内で実行する必要があります。 Remote Agent、Local Distributors、CLI Client は、Master Server と同一ロケールで実行する必要がある。

• ファイル名、ディレクトリ名などの入力には ASCII 文字しか使用できません。

パターンマッチング

コンポーネントまたはプラン内にある要素の属性の多くには、正規表現パターンを含むことができます。 特に指定がないかぎり、これらのパターンは完全な総称正規表現ではなく glob スタイルのパターンです。 つまり、0 以上の文字と一致させる場合は「*」が使用され、厳密に 1 文字だけと一致させる場合は「?」が使用されます。 角括弧 ([]) 内の文字は、厳密に 1 文字だけと一致させる文字の範囲を指定します。

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

プランとコンポーネントはどちらも、手順で使用する変数を宣言できます。 コンポーネント変数は、コンポーネントのインストール時に評価、設定されます。 したがって、コンポーネント制御ブロック内の手順が、コンポーネントによって範囲指定された変数を参照している場合、使用される値はコンポーネントのインストール時の変数の値です。 プラン変数は、プランの実行ごとに評価、設定されます。 したがって、プラン内の手順がプラン変数を参照している場合、使用される値はプラン実行時に定義された値となり、実行ごとに異なる可能性があります。

プランは、パラメタと変数の両方を宣言できます。 変数の値は、他の変数と定数の値をもとに宣言時に定義されます。 パラメタは、呼び出し元が値を定義する特殊な変数です。 最上位プランの場合、呼び出し元はプランの実行を開始したユーザーです。 ユーザーは、プランの実行前にプランで宣言した各パラメタに対して値を入力します。 <execSubplan> 呼び出しによってプランが呼び出された場合、<execSubplan> 呼び出しを含むプランが、呼び出されたプランによって宣言された各パラメタに値を明示的に渡す役割を担います。

インストール、アンインストール、スナップショット、制御の各ブロックもパラメタと局所変数を宣言できます。 プランの場合と同様に、局所変数の値はローカルで定義され、パラメタの値はブロックの呼び出し元が渡した値をもとに定義されます。 どちらもプランの実行ごとに異なることがあります。

変数またはパラメタの値を再割り当てする機能はありません。

呼び出しの互換性

以下の場合に A の使用を安全に B の使用と置き換えられる場合、コンポーネント B はコンポーネント A に対して呼び出し互換性を持つと言えます。

• A の制御ブロックの呼び出し

• A のアンインストールブロックの呼び出し

• A のスナップショットブロックの呼び出し (addSnapshot の使用)

• A の依存性チェック (checkDependency または createDependency の使用)

• A の変数の参照 (config gen :[component:AB:var] の使用)

呼び出しの互換性とは、基本的に API/インタフェースの互換性を意味します。

よくあるのは、B と A が同じバージョンツリーの別のバージョンのコンポーネントという場合です。 ただし、B が A のインスタンスの場合、B が別のバージョンツリー内にある場合もあります。

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

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

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

インストールの互換性

B が A に対して呼び出し互換で、以下の場合に A の使用を安全に B の使用と置き換えられる場合、コンポーネント B はコンポーネント A に対してインストール互換性を持つと言えます。

• A のインストールブロックの呼び出し

• A からのコンポーネントの拡張

• A への参照を含むコンポーネント

インストールの互換性とは、基本的に構造上の互換性を意味します。

インストール互換性によって課される制約は、オリジナルがインストールされたデータ構造を変更せずに、既存のインストール済みコンポーネントを別のインストール互換コンポーネントに安全に置き換えるためのものです。 呼び出し互換のコンポーネントは、データ構造を適切に更新するために元のコンポーネントに再インストールしなければならない場合があるので、呼び出し互換性はインストール互換よりかなり弱いものです。

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

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

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

ブール型演算子

この節では、ブール型演算子として機能し、<if> 手順の条件内で使用される要素を紹介します。 ブール型演算子は、true または false として評価する属性を持っています。

istrue ブール型演算子

特定の値が true かどうかを判断するために使用するブール型演算子です。 「value」という属性を 1 つ含み、子要素は持ちません。 「value」属性の値が大文字小文字も含めて「true」と等しいときだけ、true となります。

istrue ブール型演算子の属性

istrue ブール型演算子の例

equals ブール型演算子

特定の値が別の値と等しいかどうかを判断するために使用されるブール型演算子です。 属性「value1」、「value2」、「exact」を含み、子要素は持っていません。 「value1」属性と「value2」属性の値が等しい ときだけ、true となります。 「exact」が true の場合は、大文字小文字を含めて等しくなければなりません。その他の場合は大文字と小文字は区別されません。

<istrue value="..."/> は、<equals value1="..." value2="true"/> の構文上の短縮形です。

equals ブール型演算子の属性

equals ブール型演算子の例

matches ブール型演算子

特定の値がパターンに一致するかどうかを判断するために使用されるブール型演算子です。 属性「value」、「pattern」、「exact」を含み、子要素は持ちません。 「value」属性が「pattern」属性の値に含まれる glob スタイルのパターンに一致する場合だけ、true となります。 「exact」が true の場合は、大文字小文字を含めて一致しなければなりません。その他の場合は大文字と小文字は区別されません。

matches ブール型演算子の属性

matches ブール型演算子の例

not ブール型演算子

別のブール型演算子の結果を否定するブール型演算子です。 属性を含まず、ブール型演算子である子要素を 1 つだけ含みます。 含んでいる演算子が true でない場合だけ、true となります。

not ブール型演算子の例

and ブール型演算子

他のブール型演算子の結果の AND 論理演算を行うブール型演算子です。 属性は含みません。 ブール型演算子の子要素をいくつでも含むことができます。 すべての子要素が true の場合だけ、true となります。

and ブール型演算子の例

or ブール型演算子

他のブール型演算子の結果の OR 論理演算を行うブール型演算子です。 属性は含みません。 ブール型演算子の子要素をいくつでも含むことができます。 True である子要素を 1 つ以上含む場合だけ、true となります。

or ブール型演算子の例

属性の種類

entityName 型

entityName 型の属性は最長 512 で、以下のパターンに一致します。

[a-zA-Z_][0-9a-zA-Z-_. ]* 

systemName 型

systemName 型の属性は最長 64 で、以下のパターンに一致します。

 [a-zA-Z_][0-9a-zA-Z-_. +]* 

identifier 型

identifier 型の属性は最長 32 で、以下のパターンに一致します。

[a-zA-Z_][0-9a-zA-Z_]* 

pathName 型

pathName 型の属性は最長 512 で、以下のパターンのどれかに一致します。

 "/" ( "/" identifier )+ 

pathReference 型

pathReference 型の属性は、以下の構文を持っています。

pathReference: 	
	absolutePath 	
	relativePath  

absolutePath: 
	"/"
	"/" relativePath

relativePath:
	relativePathStart
	relativePathStart "/" relativePath  

relativePathStart:
	".."
	identifier 

modifierEnum 型

modifierEnum 型の属性の値は、ABSTRACT または FINAL のどちらかです。 一般的に、ABSTRACT は関連エンティティが派生コンポーネントによって無効にされる必要があることを指し、FINAL は関連エンティティが無効にできないことを指します。

accessEnum 型

accessEnum 型の属性の値は、PUBLIC、PROTECTED、PATH、または PRIVATE です。 一般的に、PUBLIC は関連エンティティのアクセスが無制限なことを指し、PROTECTED はアクセスが派生コンポーネントと同じパスのエンティティに限られることを指します。PATH は、アクセスが同じパスのエンティティに限られることを意味し、PRIVATE はアクセスが宣言コンポーネントだけに限られることを意味します。

version 型

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

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

schemaVersion 型

schemaVersion 型の属性は、現在 1 つの値しか持てません。

4.1 

コンポーネント変更の互換性

この節では、コンポーネントに加えることができる変更と、それが呼び出し互換およびインストール互換 (またはその一方) であるかどうかを示します。

コンポーネント属性の変更

プラットフォームの変更

この節では、プラットフォームに加えることができる変更と、それが呼び出し互換およびインストール互換 (またはその一方) であるかどうかを示します。

ここでは、プラットフォーム X が Y の子孫の場合、プラットフォーム X は Y より固有となります。 X が Y の祖先の場合、プラットフォーム X は Y より一般的になります。

LimitToHostSet の変更

この節では、LimitToHostSet に加えることができる変更と、それが呼び出し互換およびインストール互換 (またはその一方) であるかどうかを示します。

プラットフォームと異なり、limitToHostSet は明示的な制御の存在しない一般的なクライアント固有のホストセットを指定します。 メンバーシップはいつでも変更される可能性があるので、多少でも固有のホストセットの概念を強制することはできません。

Extends の変更

この節では、Extends に加えることができる変更と、それが呼び出し互換およびインストール互換 (またはその一方) であるかどうかを示します。

変数の変更

この節では、変数に加えることができる変更と、それが呼び出し互換およびインストール互換 (またはその一方) であるかどうかを示します。

コンポーネント Ref リスト の変更

この節では、コンポーネント Ref リスト に加えることができる変更と、それが呼び出し互換およびインストール互換 (またはその一方) であるかどうかを示します。

コンポーネント Ref の変更

この節では、コンポーネント Ref に加えることができる変更と、それが呼び出し互換およびインストール互換 (またはその一方) であるかどうかを示します。

リソースの変更

この節では、リソースに加えることができる変更と、それが呼び出し互換およびインストール互換 (またはその一方) であるかどうかを示します。

インストール、制御、アンインストールブロックの変更

この節では、インストール、制御、アンインストールブロックに加えることができる変更と、それが呼び出し互換およびインストール互換 (またはその一方) であるかどうかを示します。

スナップショットブロックの変更

準備、キャプチャ、クリーンアップブロックを処理する場合以外、スナップショットブロックの互換性マトリックスは、基本的に上記の他のブロックのマトリックスと同じです。

Diff Ignore の変更

この節では、Diff Ignore に加えることができる変更と、それが呼び出し互換およびインストール互換 (またはその一方) であるかどうかを示します。

ignore 指示は、diff 実行時にしか考慮されず、既存のスナップショットの状態に影響を与えることはありません。

属性と子要素の順序

このマニュアルでは、特定の要素内で使用できる属性および子要素は基本的に表を使って説明しています。1 つの表で属性を、別の表で子要素を一覧表示しています。 表内の属性の順序は重要ではありません。関連要素内では、どの順序でも使用できます。 一方、表内の子要素の順序は、他に記載のないかぎり重要です。関連要素内では、表内と相対的に同じ順序で子要素を使用する必要があります。