レベル: 中級 Julia McCarthy (julia@us.ibm.com), Software Architect, IBM
Brent Miller, Autonomic Computing Chief Architect, IBM
2008年 4月 29日 SDD (Solution Deployment Descriptor) とは、デプロイメント対象に関するデプロイメント・メタデータと、デプロイメント対象のアグリゲーションに関するデプロイメント・メタデータとを定義する一連の XML 文書で定義した新しい標準です。デプロイメントに関する情報はこれまでコードや文書に埋もれているのが一般的でしたが、この情報を外部化すると、さまざまなメリットがもたらされます。人間やソフトウェアなどの、SDD の使用者は、デプロイメントを成功に導くための要件、そしてデプロイメントの結果の両方に関して提供された情報を利用して、ソフトウェア環境の変更を一層効果的に計画し、その変更を成功させることができます。この記事では SDD について紹介し、この標準が提供するサポートの全体的な概要を説明します。
はじめに
SDD (Solution Deployment Descriptor) は、OASIS (Organization for the Advancement of Structured Information Standards) によって作成された新しい標準です。SDD は、ソフトウェア・リソースをデプロイするために処理するデプロイメント対象の要件、入力、そして結果に関するメタデータのフォーマットを定義します。また、SDD では 1 つのソリューションとしてまとめられた複数のデプロイメント対象のアグリゲーションに関するメタデータのフォーマットも定義しています。このメタデータは、デプロイメントだけでなく、その他デプロイメント関連の各種アクティビティー (デプロイメント計画など) の指針として使用することもできます。この記事では、SDD の背後にある概念を紹介し、SDD とは何かを説明します。
SDD を取り上げるこの記事ではさらに、デプロイメント関連の情報を標準化および外部化したメタデータによって表現するために SDD が提供する仕様の全体的な概要を説明します。この記事が対象としている読者は、SDD がデプロイメントの世界にどのように適合するかを理解したい方、SDD 標準の詳細を学びたい方、そして特にソフトウェアの開発、統合、デプロイメントに関わっている方々です。読者には、複合環境でのデプロイメントをはじめ、現在のソフトウェア・デプロイメント技術に関する一般的な知識があることを前提とします。
今後の記事では、SDD の使用方法についてさらに詳しく説明する予定です。これらの記事では、この入門記事で説明する概念を実現する SDD の要素を検討します。今回の記事および今後の記事は、OASIS によって公開された SDD 仕様とその関連文書 (「参考文献」を参照) を補完するものであり、それに代わるものではありません。
SDD とは何か
基本的に SDD は、デプロイメント情報をエンコードして外部化する標準的な方法を提供します。SDD は 2 つの XML 記述子ファイル (パッケージ記述子とデプロイメント記述子) から構成され、この 2 つのファイルにデプロイメント・メタデータ、つまりデプロイメント対象とデプロイメント対象のアグリゲーションとに関して記述した情報が含まれます。パッケージ記述子には、デプロイメント・パッケージの ID とその内容に関する記述があります。パッケージは一連の対象物で構成され、それらの対象物はソリューションを作り上げる一連の関連リソース上でデプロイメント・ライフサイクル操作を実行する際に使用されるデプロイメント対象で構成されます。こうして対象物を処理した結果、ソフトウェアがデプロイされることになります。これらのデプロイメント対象の入力、要件、可変性、そして結果を記述するのが、デプロイメント記述子です。
パッケージ記述子には、デプロイメント・パッケージの内容についての記述はありますが、デプロイメント・パッケージの形式についての記述や前提はありません。したがって、デプロイメント・パッケージには、URI (Uniform Resource Identifier) で識別可能な任意の場所の任意のファイルを含めることができます。パッケージ記述子に含まれる内容一覧には、パッケージに対応するデプロイメント記述子の URI が必ず含まれます。また、デプロイメント対象とサポート・ファイルすべての URI も含まれます。その他、識別可能なファイルの内容としては、README ファイル、使用許諾契約書、アグリゲーションが構成された SDD (アグリゲーションについては後で説明) のパッケージ記述子、そして SDD 向けに言語変換された一連のファイルなどがあります。一般に、ソフトウェアをデプロイするために必要なものは、それが何であろうとすべてデプロイメント・パッケージに含まれることになります。
デプロイメント記述子が提供するのは、デプロイメントを実行する際に使用されるデプロイメント対象についての情報です。デプロイメント記述子はサポートするデプロイメント操作ごとに基本コンテンツ、選択可能コンテンツ、またはローカライズ・コンテンツを定義します。基本コンテンツを構成するメタデータに対応する対象物は、デプロイメント対象のソフトウェアのコア・コンテンツをデプロイする際に使われます。選択可能コンテンツを構成するメタデータに対応する対象物は、デプロイメント時の選択内容によって変わるコンテンツを扱うために使われます。そしてローカライズ・コンテンツを構成するメタデータに対応する対象物は、複数言語のサポートを目的としたソフトウェアをローカライズするリソースを扱う際に使われます。
デプロイメント記述子は、アグリゲーションに関連付けられた要件、条件、入力、結果に関するメタデータを定義することによって、他の SDD とのアグリゲーション (後で説明) をサポートします。アグリゲーションが構成された SDD には、最上位レベルのソフトウェアの基本コンテンツ、選択可能コンテンツ、そしてローカライズ・コンテンツを概念的に構成するデプロイメント対象が定義されます。
デプロイメント対象について
デプロイメント対象とは、ソフトウェア・リソースを作成、または変更するためにデプロイメント環境内で処理可能なパッケージの中身のことです。これらのソフトウェア・リソースがまとまってソフトウェアになるわけですが、そのソフトウェアのデプロイメントは SDD によって記述され、実行可能ファイルやデータベース･テーブル定義などの項目が組み込まれます。デプロイメント対象の例としては、Linux® RPM ファイル、Microsoft® MSI ファイル、setup.exe、ZIP、カスタム・インストール実行可能ファイルなどが挙げられます。新しく登場した SDD 標準では、デプロイメント対象の形式やそれに代わるものを一切定義していません。
対象物はアトミックにも、モノリシックにもできます。アトミック対象物 (アトミック・コンテンツ単位と混同しないでください) は、インストール、構成、ローカライズ (言語変換) などの特定のデプロイメント操作を行うために使われます。つまり、アトミック対象物にはインストール対象物、アンインストール対象物、構成対象物などがあるということです。アトミック対象物は、これらの操作それぞれに対して定義されたコンテンツ単位 (インストール可能単位、構成単位、ローカライズ単位) によって記述されますが、アトミック対象物が単独で選択可能コンテンツを公開することはありません。一方、アトミック対象物からアグリゲーションを構成することは可能ですが、この場合、アグリゲーションが構成された対象物は複合インストール可能単位によって記述されます。
モノリシック対象物とは、単独で選択可能コンテンツを公開する対象物のことです。モノリシック対象物を使用するデプロイメント・ソフトウェアは、単一の対象物から適切なコンテンツを選択してデプロイすることができます
(デプロイメント・プロセス中に 1 つ以上の特定のアトミック対象物を選択する場合と比較してください)。 アトミック対象物と同様に、モノリシック対象物は特定のデプロイメント操作を行うために使われ、その記述はそれぞれの操作に定義されたコンテンツ単位で行われます。
SDD は、アトミック対象物とモノリシック対象物をどちらもサポートします。これらの対象物は、デプロイメント・ソフトウェアに適した形式にすることができます。例えば、オプションでクライアント・フィーチャーを選択するサーバー・ソフトウェアのデプロイメントの場合、1 つ目のアトミック対象物でサーバーをデプロイし、2 つ目のアトミック対象物でクライアントをデプロイするという実装方法、あるいはクライアント・フィーチャーの選択を入力として受け取る 1 つのモノリシック対象物で実装するという方法が考えられますが、いずれにしても SDD を使用して記述することができます。また、SDD ではアトミック対象物とモノリシック対象物の両方を必要とするコンテンツを記述することもできます。推奨されるのはアトミック対象のほうで、その理由はソフトウェアのデプロイメント特性をより完全に表現できるためです。アトミック対象物を使用すると、例えばクライアント・フィーチャーをデプロイした結果とサーバー・フィーチャーをデプロイした結果を一層明確に区別することができます。SDD がモノリシック対象物をサポートする主な目的は、インストール・プログラム全体を 1 つの対象物として扱う場合など、上記の例以外の理由でモノリシック対象物が必要となる場合に SDD を採用できるようにするためです。
アグリゲーションについて
アグリゲーションとは、ソフトウェア・ソリューションをデプロイする際に一緒に使用される複数のデプロイメント対象のメタデータを集めたものです。少数の対象物からなる単純なアグリゲーションで小規模なソフトウェア製品を構成する場合もあれば、多数の複雑なソフトウェア製品のアグリゲーションで大規模なソリューションを作り出す場合もあります。1 つのデプロイメント・パッケージを実現する上で意味を持つ対象物を任意に組み合わせると、1 つの SDD の中にアグリゲーションを構成することができます。
SDD がアグリゲーションをサポートする 1 つの手段として、複数のデプロイメント対象に関するメタデータを単一の SDD の中に定義できるようになっています。また、SDD がそのコンテンツの一部として別の SDD を識別できるようにすることによっても、アグリゲーションがサポートされています。この場合、実際には単一の SDD をルートとした SDD の階層ができることになります。階層を構成する個別の SDD はそれぞれ独立してデプロイすることもできますが、これらの SDD からアグリゲーションを構成することによって、ソリューション全体をより完全に記述することが可能になります。
1 つの SDD または SDD 階層で記述されるすべての対象物が、個々のデプロイメントで必ず使用されるというわけではありません。SDD では、それぞれのデプロイメントに固有の環境条件、デプロイヤーの入力、そしてデプロイヤーの選択によって変化するデプロイメント結果を表現することができます。SDD の中でフィーチャーを定義すると、デプロイヤーが選択可能なオプションの機能が有効になり、対象物を選択できるようになります。SDD の中で条件を定義した場合には、オペレーティング・システムのタイプなどの環境条件に基づいて対象物が選択されます。また、対象物の処理に対する可変入力をサポートする変数および引数によって、それぞれのデプロイメントに固有のニーズに合わせて対象物の処理をカスタマイズできるようになっています。
アグリゲーションがどのように定義されているか、あるいはどのような可変性が記述されているかに関わらず、各デプロイメントは特定のデプロイメント対象のセットを処理することになります。その結果、SDD が記述するデプロイメント環境に適切なソフトウェアの基本コンテンツ、選択されたコンテンツ、およびローカライズされたコンテンツが作成されます。
デプロイメント対象に関するメタデータ
デプロイメント記述子に含まれるメタデータは、デプロイメント対象の有用性を高めてくれます。その理由としては、メタデータによって、対象物を処理するために必要なシステム状態とソフトウェアが記述されて外部化されること、デプロイメント環境でのユーザー入力とリソース・プロパティーが対象物処理への入力に関連付けられること、そして対象物の処理結果が指定されることが挙げられます。
図 1. 対象物と関連メタデータ
対象物は図 1 に示されているようにデプロイメント環境にデプロイされます。SDD に含まれる、デプロイメント対象に関するメタデータには、以下のものがあります。
-
ID: 対象物を含めるパッケージの単位を識別するメタデータです (該当する場合)。SDD は、デプロイメントの際に SDD の中でパッケージ化する対象物の名前と提供者などの情報を指定する場合があります。パッケージ記述子に含まれるのは、パッケージ全体の ID です。特定の対象物に関連するパッケージの構成部分を識別することが役立つ場合には、インストール可能単位で ID が使用されます。ID はオプションです。
-
入力および出力: 入力と出力は、ユーザーが提供することも、システム状態情報から取得することも、SDD に固定値として定義することも可能です。あるいは、これらの方法を任意に組み合わせることもできます。例えば、SDD はソフトウェアをインストールする際に使用されるルート・インストール・ディレクトリーを入力として指定し、オペレーティング・システムの標準インストール・ロケーションのプロパティー (例えば、Windows® では「C:\Program Files」) から得た値をこの入力のデフォルト値として設定する場合があります。このデフォルトを上書きして、別のルート・インストール・ディレクトリーを指定すると、ユーザー入力が有効になります。
-
条件: 条件とはシステム状態の情報のことで、デプロイメントごとに異なる可能性のある環境をリソースという点から記述します。例えば SDD がデプロイメント環境のオペレーティング・システムのタイプに基づく条件を指定している場合、そのオペレーティング・システムのタイプに適した対象物がデプロイされることになります。
-
要件: リソースという点から記述された、デプロイメントを成功させるために必要なシステム状態です。例えば、SDD は、新規ソフトウェアをインストールする場合の前提条件として、特定データベースの特定バージョンがデプロイメント環境で使用可能でなければならないと指定する場合があります。要件の表現には、その要件を満たすための代替方法の表現を含めることができます。
-
結果: デプロイメントが成功した場合にその環境に存在することになる、新規リソースまたは変更されたリソースを識別します。例えば SDD は、その SDD を使って新規アプリケーションをインストールした後の、デプロイメントの結果にそのアプリケーションが存在していることを含めるように指定する場合もあります。
アグリゲーションに関するメタデータ
デプロイメント記述子に含まれるアグリゲーションに関するメタデータのおかげで、人間とソフトウェアはアグリゲーションを構成する対象物の相互作用、依存関係、関係、そしてアグリゲーションによってもたらされた固有の要件を一層理解しやすくなります。
図 2. アグリゲーション
図 2 のように、複数の SDD と複数のインストール可能単位を 1 つの SDD にアグリゲーションとして構成することができます。アグリゲーション・メタデータには以下のものがあります。
-
複合メタデータ: このメタデータには、アグリゲーションに関連する ID、要件、条件、結果、入力が一式含まれます。複数の対象物をアグリゲーションとして構成する場合には、それぞれ個別の対象物に関する情報に加え、そのアグリゲーションに関する情報が必要になります。複数の対象物に共通する要件、条件、入力については、繰り返しを避け、理解しやすいように、コンテンツ階層の「構成要素」にすることができます。
-
包含パッケージ: アグリゲーションを構成する SDD への参照です。包含パッケージ・メタデータには、入力マップとリソース・マップのほかに、アグリゲーションを構成する SDD の包含に関する要件が含まれます。
-
リソース・マップ: アグリゲーションを構成する側の SDD に記述されたリソースと、アグリゲーションが構成される側の SDD に記述されたリソースとの関係です。ソリューションに定義されたリソースは、ソリューションの個々のパーツに定義されたリソースにマッピングする必要があります。例えば、1 台のマシンをデータベース・サーバーとして使用し、別のマシンをアプリケーション・サーバーとして使用するソリューションがあるとします。このソリューションでは、ソリューションのアプリケーション・サーバーとして機能するオペレーティング・システム・リソースは、このソリューションのアプリケーションのデプロイメントに関して記述した各SDDのオペレーティング・システム・リソースにマッピングされます。さらに、ソリューションのデータベース・サーバーとして機能するオペレーティング・システム・リソースは、データベースのデプロイメントまたは構成を記述した各SDDのオペレーティング・システム・リソースにマッピングされることになります。
-
入力および出力マップ: アグリゲーションを構成する側の SDD に含まれる変数と、アグリゲーションが構成される側の SDD に含まれる入力パラメーターとの関係です。このマップは、個々の対象物に対する入力が重複する場合には特に役立ちます。入力をマッピングすると役立つ例として、ソリューションのコンテキストのなかで 1 つのデータベースと相互作用するすべての対象物が同じデータベース管理者 ID を使用しなればならない場合が挙げられます。
-
依存関係: 対象物相互の依存関係です。複数の対象物を使用するソリューションでは、ある対象物が他の対象物に依存する場合があります。つまり、ある対象物を処理するには、その前に別の対象物を処理しなければならないといった場合です。例えばデータベースを構成する対象物は、そのデータベースをデプロイする対象物に依存する可能性があります。SDD では、このような対象物相互の依存関係を表現することができます。SDD に定義される依存関係は、事前条件 (依存関係を表現する対象物を処理する前に処理しなければならない対象物)、同時条件 (デプロイメントで同時に処理する必要がある対象物)、または排他条件 (デプロイメントで同時に使用してはならない対象物) のいずれかのタイプとなります。
-
基本コンテンツ: SDD が記述する、ソフトウェアのコア (つまり基本) コンテンツとして見なされる対象物の定義です。基本コンテンツはシステム状態によって変わる可能性がありますが、デプロイヤーが基本コンテンツを選択することはできません。対象物は基本コンテンツのなかで直接定義されることも、別の SDD のアグリゲーションを構成する包含パッケージ定義を使用して組み込まれることもあります。
-
選択可能コンテンツ: オプションのコンテンツに関連付けられた対象物の定義です。選択可能コンテンツに含まれる対象物は、デプロイヤーがフィーチャーによって明示的に選択した場合にのみ処理されます。基本コンテンツの場合と同じく、対象物は選択可能コンテンツのなかに直接定義されることも、別の SDD のアグリゲーションを構成する包含パッケージ定義を使用して組み込まれることもあります。
-
フィーチャー: 選択可能コンテンツ階層で名前をつけて定義された対象物のグループです。デプロイヤーがオプションでコンテンツを選択できるようにしているソリューションの場合、フィーチャーによって、デプロイヤーの選択がソリューションを構成する対象物のサブセットに関連付けられます。
-
ローカライズ・コンテンツ: ローカライズ・ソフトウェアに関連付けられた対象物の定義です。ローカライズとは、ソフトウェアを特定の国の言語で使用できるように、その国の言語に翻訳し、その言語での使用に特化したソフトウェアを提供するプロセスのことです。ローカライズ・コンテンツは、基本コンテンツと選択可能コンテンツの階層に記述されたソフトウェアと関連付けることも、SDD のなかで単独で使用してローカライズ・パッケージのデプロイメントを記述することもできます (デプロイ済みのソフトウェアに新しい言語機能を追加する場合など)。基本および選択可能コンテンツの場合と同じく、対象物はローカライズ・コンテンツのなかに直接定義されることも、別の SDD のアグリゲーションを構成する包含パッケージ定義を使用して組み込まれることもあります。
 |
SDD が定義するデプロイメントを成功させる条件
これまでのセクションで説明してきたように、SDD はデプロイメントを成功させるための「条件」に関して SDD 作成者が持っている情報を伝えます。一方、SDD はデプロイメントを行う「方法」には触れていません。例えば、SDD はデプロイメントを成功させるのに必要な特定のオペレーティング・システムの具体的なバージョンを宣言することがありますが、デプロイメント環境でその情報を見つけ、SDD の宣言と比較して要件を満たしているかどうかを判断する方法については、SDD には記述されません。SDD では、あるタイプの特定の対象物を特定のターゲット・リソースによって処理すると、あるプロパティー値を持つ特定のリソースが作成されるということを宣言することはできます。この宣言から、SDD の使用者は SDD の意図する結果がどんなものかわかりますが、対象物とその関連情報をどのようにターゲット・リソースに提供して処理させるかはSDD には記述されていないため、わかりません。
SDD は、デプロイメントに成功する前と後のシステム状態、ならびに目的とする状態を実現するために必要な対象物と入力に関する SDD 作成者が持つ情報をエンコードして、外部化します。この情報をどのように処理するか、そして何の目的で使用するかは、SDD を使用するソフトウェア次第です。SDD に含まれる情報を使用してデプロイメントのオーケストレーションを行うソフトウェアによって、デプロイメントの達成方法にはさまざまな選択肢が生まれてきます。そこで役立つのが、プロファイル (後ほど説明します) です。プロファイルには、実装でどのように処理すればよいかを知っておかなければならない SDD 内の環境関連の値を記載することで、SDD が記述する「条件」と実装の「方法」のギャップを埋める役割を果たします。
実装が定義するデプロイメントの実行方法
前述のとおり、SDD を使用する実装には多くの選択肢があります。これらの選択肢によって、SDD の記述方法、実装間での相互運用性が変わってきます。SDD に含まれるメタデータの主要な用途は、デプロイメントのオーケストレーションを行うことです。SDD メタデータを使用してデプロイメントのオーケストレーションを行うデプロイメント・ソフトウェアの一例には、COSMOS ランタイムがあります。このオーケストレーションは増補をするには役立ちますが、対象物の処理時に行われるデプロイメント・アクションにとって変わるものではありません。
| |
SDD、IUDD、および Eclipse COSMOS
標準と実装にはどちらも取り掛かりとなる基点が必要となります。SDD 標準の基点となったのは IUDD (Installable Unit Deployment Descriptor) です。IBM は SDD 標準の基礎としての IUDD を OASIS SDD Technical Committee に提案しました。SDD は当然、IUDD と多くの点で異なっていますが、SDD は IUDD が進化した形であり、IUDD の概念と設計原則の多くはそのまま維持されています。
SDD の作成と使用を可能にするための実装は、Eclipse COSMOS (Community-driven Systems Management in Open Source) プロジェクト内で開始されました。このプロジェクトが目的とするのは、SDD のツールおよびランタイム・コードを対象としたオープンソースの基本リファレンス実装を作成することです。COSMOS で開発された実装は、他の実装の基礎として使用できます。このように共通して使用できる基本リファレンス実装があるということは、相互運用性を促進し、SDD 標準の導入に拍車をかけることになります。
IUDD と Eclipse COSMOS についての詳細は、「参考文献」を参照してください。
|
|
特定のデプロイメント環境に関する情報と併せて入力およびシステム状態に関するメタデータを使用すれば、デプロイメント・ソフトウェアが特定のデプロイメントに使用する必要のある対象物を判断することが可能になります。例えば、異なるオペレーティング・システム用の対象物が含まれるパッケージがあるとします。この場合、デプロイメント・ソフトウェアはデプロイメント時にデプロイメント・ターゲットのプラットフォームに関する情報を収集し、そのオペレーティング・システムにとって適切な対象物を選択します。デプロイメント・ソフトウェアはそれと同様に、言語の選択に関する情報を収集してから、この特定のデプロイメントに使用する特定の言語をサポートする対象物を選択することになります。
対象物を選択するために必要な分析の一環として、SDD に含まれるデプロイメント環境の状態情報を記述するプロパティー (要件、条件、プロパティー値など) が、該当するデプロイメント環境内での対応する実際の値との比較を含めたデプロイメント対象の選択があります。実装が高度になればなるほど、検出可能なリソースとリソース・プロパティーの範囲は広くなります。例えば、極めて単純な実装で判別できるのはオペレーティング・システムのタイプとバージョンだけであるとしても、高度な実装ではシステム・レジストリー、ファイル・スキャニング、構成データベースといった複数の情報源を使って、非常に広範なリソースの値を判別することが可能です。ただし、どんなに高度な実装でも、あらゆる SDD 作成者が指定する可能性のあるすべての値を評価することは難しいはずです。したがって、実装にはこの点における機能を拡張するためのメカニズムを用意することが奨励されています。このようなメカニズムがあれば、ソフトウェア開発者が、SDD のメタデータに含まれる広範な値を処理するために必要な機能を拡張することができます。SDD がサポートする特定の値のセットは、プロファイルと呼ばれます。SDD 1.0 仕様では実装機能の拡張方法についての形式は指定していませんが、ほとんどの要素と属性の拡張に対応するオープン・スキーマ・モデルを提供しています。実装の拡張に伴って、プロファイルを拡張して共通語彙を増やすことも可能です。
デプロイメント実装でもう 1 つ選択しなければならないのは、処理可能な対象物のタイプです。ここでも同じく、どんな対象物のタイプを選択するかによって、実装をどれだけ高度にしなければならないかが大きく変わってきます。単純な実装でサポートすると考えられるのは、ZIP ファイルや Linux RPM ファイルなど、1 つか 2 つのよく知られたタイプの対象物でしょう。一方、高度な実装では 10 以上の対象物のタイプをサポートする可能性があります。環境を評価する場合と同じく、実装があらゆる SDD 作成者によって指定される可能性のあるあらゆる対象物を処理することはまず不可能です。そのため、デプロイメント実装開発者には、環境の評価でも説明したような機能拡張メカニズムを提供し、追加された対象物のタイプの処理に対応できるようにすることが奨励されています。
「条件」と「方法」との架け橋
多くの標準イニシアティブと同じく、SDD の目標の 1 つは、相互運用性を促進することです。SDD が単独で相互運用性を確実にすることはできませんが、デプロイメント・ソフトウェアの相互運用性を実現する上で SDD は欠かせません。SDD が指定する「条件」と実装が決定する「方法」をつなげることが、相互運用性にとって重要な要素となるからです。
これが具体的に何を意味するのかというと、SDD に指定された情報を、SDD を処理するデプロイメント・ソフトウェアの機能と合致させる必要があるということです。いくつか例を挙げてみましょう。
- SDD が Linux についての要件を定義している場合、その SDD を処理できるのは、Linux の記述に使用される語彙を理解し、さらにデプロイメント環境のオペレーティング・システムが Linux であるかどうかを判断する方法がわかる実装のみとなります。
- SDD が IBM® WebSphere® Application Server のトレース設定に基づく変数を定義している場合、その SDD を処理できるのは、トレース設定の記述に使用される語彙を理解し、さらにそのトレース設定を検出して解釈する方法がわかる実装のみとなります。
- SDD に Linux RPM 対象物が含まれている場合、その SDD を処理できるのは、この対象物を理解して処理することができる実装のみとなります。
同様に、SDD に指定されているすべてのリソースと対象物は、その指定内容の曖昧さにかかわらず、デプロイメント・ソフトウェアの機能と合致していなければなりません。
プロファイルは、SDD の作成者と使用者が特定の使用ケースとデプロイメント環境との合致を実現できるようにする語彙を定義します。例えば、異なるオペレーティング・システムの要件を指定するには、SDD の作成者と使用者が該当するオペレーティング・システムの指定方法について合意しなければなりません。つまり、SDD が Linux オペレーティング・システムのメタデータを指定する場合、SDD の作成者と使用者とが「Linux」を表現する共通の方法について合意しなければならないということです。これは、他のデプロイメント環境についても同様です。さらに、要件、条件、入力、出力をはじめ、SDD に含まれる項目がデプロイメント環境の情報を参照する場合もあります。ディスク・スペース要件を例にとると、この要件はデプロイメント環境が使用する単位 (メガバイトやブロックなど) で表現する必要があります。また、プロセッサーに関連付けられたプロパティー (プロセッサー・タイプや処理速度など) も同じようにして表現しなければなりません。
プロファイルはこの共通語彙を定義する方法として、デプロイメント環境に関連するプロパティーを指定するために使う値を定義します。これらの値は任意の組み合わせで 1 つのプロファイルにまとめることができます。プロファイルは SDD 仕様準拠の条件ではありませんが、相互運用性の促進には役立ちます。SDD を使用するソフトウェアがサポート対象とするプロファイルを宣言すれば、SDD 作成者は自分が作成している SDD のコンテンツを、ターゲット・デプロイメント・ソフトウェアがサポートするプロファイルに定義された値に制限することができます。今後、SDD コミュニティーによって一般的な使用ケースとデプロイメント環境をサポートするプロファイルが開発されることが期待されています。
OASIS SDD Technical Committee では、さまざまなサンプルに対応可能な多数の値を定義したスターター・プロファイル (starter profile) を公開しました。これらのサンプルも SDD 仕様と併せて公開されています (「参考文献」を参照)。ただし、このスターター・プロファイルはあらゆる SDD で使用される可能性のある値すべてを網羅しているわけではありません。スターター・プロファイルがその基礎として使用しているのは、Distributed Management Task Force (DMTF) の CIM (Common Information Model) リソース・モデル (「参考文献」を参照) です。その他のケースに対応するには、他のプロファイルを作成するという方法があります。その際には、プロファイルの基礎として別のリソース・モデルも使用することができます。
使用ケースとデプロイメント環境にはありとあらゆる種類があるため、プロファイル単独では SDD 作成者と使用者との間で必要な合致を確実にすることはできません。そこで、この合致を実現するために追加するのが、広範な SDD 構成要素 (要件、変数、対象物など) を理解して処理できるように実装を拡張するメカニズムです。OASIS SDD Technical Committee によって作成、公開された SDD スターター・プロファイルでは、この目的で拡張できるように実装を作成することを推奨しています。つまり、例えば既存のソフトウェア・デプロイメント実装で IBM WebSphere Application Server のトレース設定を処理できない場合、トレース設定を理解、検出、解釈できるようにそのソフトウェアを拡張し、トレース設定に関するメタデータを宣言する SDD を処理できるようにすればよいということです。デプロイメント・ソフトウェアに対するこのような拡張は、それ自体がソフトウェアとしてデプロイされるため、これらの拡張を実際に SDD に組み込めば、デプロイメント・ソフトウェアが独自の拡張として処理することになります。するとこれらの拡張によって、処理されることのなかったその SDD 内のメタデータをデプロイメント・ソフトウェアが処理するというわけです。
共通語彙を定義するプロファイルの使用に加え、SDD スキーマの拡張性が SDD と実装間の合致を維持するために必要な柔軟性を実現します。実際の状況の中で拡張メソッドとプロファイルとの合致が示されることによって、時間とともに実装間での相互運用性が自然と現れてくることでしょう。
SDD の使用法
SDD に含まれるメタデータは、デプロイメント以外にも使用することができます。SDD は有効なデプロイメントに関して SDD 作成者が持っている情報を正確に伝えますが、メタデータをどのように使用して処理するかは実装によって異なります。環境分析などの機能を他のデプロイメント関連の目的で使用すると、SDD にエンコードされ、外部化されたデプロイメント・メタデータによってメリットがもたらされる場合があります。このようなデプロイメント以外の目的を SDD メタデータを利用して達成するソフトウェアを作成することは可能です。その一例は、デプロイメント計画です。デプロイメント計画には、実際のデプロイメント操作を実行する前にデプロイメント環境状態をチェックして、デプロイする上でどのソフトウェアを先にデプロイする必要があるかを判断しなければなりません。このようなデプロイメント計画は、特に新規リリースによる複数のデプロイメントが計画されている場合には、デプロイメントをスケジューリングしやすくし、その結果、データ・センターでの変更管理およびリリース管理プロセスが改善されることになります。
SDD を活用できるデプロイメント関連の目的の別の例としては、ソフトウェア・インベントリーもあります。SDD に含まれる最終的なリソースに関する情報を取り込めば、システムにインストールするリソース、そしてインストールされるリソースの要件を決定する 1 つのメカニズムとしての役割を果たします。レジストリーや構成データベースにデータを設定するソフトウェアを作成することで、この情報をデプロイメント時に取り込むことができます。注意する点として、これはあくまでも SDD の付加価値を引き出すことができる 1 つの方法でしかなく、SDD の情報を登録することは、SDD の使用要件ではありません。
まとめ
SDD は、ソフトウェア・デプロイメントとライフサイクルの管理、つまりインストール、構成、更新とアップグレード、ローカライズ、アンインストールの管理に関する情報を記録し、外部化する標準的な方法となります。SDD が開発者とソリューション統合事業者から獲得する情報は、一般的には記録されないため、デプロイメント時に使用できないのが通常です。情報が記録され、デプロイメント時に利用可能になっているとしても、大抵はそれぞれ独自のフォームになっています。
SDD はこのような状況を、SDD 作成者が対象物に関する情報を記録できるようにすることによって大幅に改善します。この情報には対象物のパッケージ化方法、対象物の提供元、そしてデプロイメントを成功させるためにデプロイメント環境に必要となるディスク・スペース、あらかじめ必要なソフトウェアなどが含まれます。
SDD の素晴らしい点は、ソフトウェア・プロバイダーとデプロイヤーとの間にあるギャップを、標準化および外部化されたメタデータによって埋めるところにあります。このことから、相互運用可能なソフトウェア・ライフサイクル管理システムには、SDD は不可欠の要素となります。
この入門記事では SDD の概念と構造を概説しました。SDD については説明することはまだたくさんあります。今後の記事で引き続き、この重要な新しい標準を掘り下げていきたいと思います。
参考文献
著者について | | | SWG AIM Install Strategy and Development の Julia McCarthy は、SDD (Solution Deployment Descriptor) 1.0 仕様の編集者を務めました。現在は OASIS SDD Technical Committee の書記として、IBM 内での SDD 導入の促進に取り組んでいます。IBM での勤務年数は 20 年に及び、ストラテジーからツールの開発までさまざまな職務を果たしています。 |
| 
| | Brent A. Miller は、IBM の Autonomic Computing Architecture の Senior Technical Staff Member で、IBM Autonomic Computing チームの主任として活躍しています。IBM での勤務は 24 年にわたり、プリンター開発、モバイル・クライアント、モバイル・ソフトウェア、パーベイシブ・コンピューティングなどに従事してきています。現在、OASIS SDD Technical Committee の議長を勤めています。 |
記事の評価
| 
