test

Solaris WBEM Services の管理

コアモデルの概念

次の節では、CIM のコアモデルについて説明しています。

システムとしてのコアモデル

コアモデルでは、システムとそれらの機能が管理対象オブジェクトとして記述されるアプリケーションを開発するために使用できるクラスと関連を提供します。これらのクラスと関連は、システムを構成するすべての要素 (物理的な要素および論理的な要素) に固有の特性を与えています。物理的な特性とは、空間を占有し、物理的な基本原則に従う性質を意味します。論理的な特性とは、物理的な環境面 (システム状態やシステムの能力など) を管理、調整するために使用される抽象概念を意味します。

コアモデルには次の論理要素が存在します。

表 A-1 コアモデルの要素

要素名 

説明 

システム 

ほかの論理要素をグループ化したもの。システムはそれ自体が論理要素であるため、ほかのシステムのコンポーネントとなり得る 

ネットワークコンポーネント 

ネットワークの接続形態を提供するクラス 

サービスとアクセスポイント 

システム機能にアクセスできる構造を構成するための機構を提供する 

デバイス 

ハードウェアエンティティの抽象概念またはエミュレーション。デバイスは、実際のハードウェアとしての形をとらないこともある 

次の節では、システムの特性をエミュレートするためにコアモデルに提供されているクラスと関連について説明します。

コアモデルが提供するシステムクラス

次の表は、システムとしてのコアスキーマを表すクラスを示しています。これらのクラスのインスタンスは、通常、そのクラスに含まれるオブジェクトの下位に属します。

表 A-2 コアモデルのシステムクラス

クラス名 

説明 

例 

Managed System

Element

システム要素階層の基底クラス。識別可能なシステムコンポーネントはすべて、このクラスに含めることができる 

ファイルやデバイス (ディスクドライブやコントローラなど) のようなソフトウェアコンポーネント、およびチップやカードのような物理的なコンポーネント 

Logical Element

抽象的なシステムコンポーネントを表すすべてのシステムコンポーネントの基底クラス 

論理デバイスの形をしたプロファイル、プロセス、またはシステム機能 

System

一連の管理対象システム要素の集合である論理要素。この集合は、機能的に一体として動作する。System のすべてのサブクラスには、インスタンスの集合が必要な Managed System Element クラスの明確なリストが存在する

LAN、WAN、サブネット、イントラネット 

Service

デバイスまたはソフトウェア機能 (あるいはこの両方) によって提供される機能の記述と管理に必要な情報を含む論理要素。Service は、機能の実装を設定、管理する多目的オブジェクトである。Service 自体は機能ではない

プリンタ、モデム、ファックスマシン 

コアモデルが提供するシステム関連

関連は、ほかのクラスによって共有される関係を定義するクラスです。関連クラスには、そのクラスの目的を示す ASSOCIATION 修飾子が付けられます。関連クラスは、2 つ以上の参照 (特定の関係を共有するクラスの名前) を持つ必要があります。関連のインスタンスは、常に関連クラスに属します。

関連には、次のような形式があります。

関連は、システムとそのコンポーネントである管理対象要素との間の関係を表現します。クラス間の関係の定義には、一般的な 2 種類の関連が使用されます。

CIM スキーマは、次に示す基本的な 2 種類の関連を定義します。

これらの関連タイプは抽象型です。つまり、関連クラスは、インスタンスを単独では所有しません。インスタンスはその下位クラスのうちの 1 つに属す必要があります。

コンポーネント関連

コンポーネント関連は、システムのコンポーネントとシステム自体の関係を表します。コンポーネント関連は、どの要素がシステムを構成するかを示します。コンポーネント関連を表す abstract クラスは、下位クラスにこのタイプの具体的な関連を作成するために使用されます。下位の具体的な関連は、「コンポーネント (クラス) が、ほかのコンポーネントとどのような構成関係にあるか」を表します。

コンポーネント関連は、その特有の役割として、システムと、システムの論理的なコンポーネントおよび物理的なコンポーネント間の関係を表します。

依存関連

依存関連は、互いに依存し合うオブジェクト間の関係を確立します。コアモデルは、次の依存関係を提供します。

コアモデルには、次の依存関係があります。

表 A-3 Core Model の依存関係

依存関連 

説明 

HostedService

サービスとその機能が存在するシステム間の関連。この関連の多重度は、1 対多である。1 つのシステムは、多くのサービスを管理できるため、サービスは、それらを管理しているシステムに強く依存している。 

一般に、サービスは、そのサービスを実装する論理デバイスまたはソフトウェア機能が入ったシステム上で管理されるので、このモデルでは、複数のシステムに渡って管理されるサービスは表されない。この場合システムは、単一のホストにそれぞれ置かれているサービスの集合ポイントの役割を果たすアプリケーションシステムとしてモデル化される 

HostedAccessPoint

サービスアクセスポイント (SAP) と SAP 上で提供されているシステム間の関連。この関連の多重度は 1 対多であり、システムに強く依存している。各システムは多数の SAP を管理できる。 

このモデルの特徴は、サービスアクセスポイントを、サービスがアクセスできるシステムと同じホストに置くことも別のホストに置くこともできることである。このため、このモデルは分散システム (コンポーネントサービスが複数のホストに置かれるアプリケーションシステム) と分散アクセス (アクセスポイントがほかのシステム上で管理されるサービス) の両方を表すことができる 

ServiceSAPDependency

サービスとサービスアクセスポイント間の関連。この関連は、サービスがその機能を提供するためには参照されている SAP が必要であることを示す 

SAPSAPDependency

2 つの SAP 間の関連のある SAP がそのサービスを利用またはそのサービスに接続するためには別の SAP が必要であることを示す。 

ServiceAccessBySAP

サービスのアクセスポイントを識別する関連。たとえば、プリンタは、複数のシステム上で管理される Netware、Apple Macintosh、または Windows のサービスアクセスポイントによってアクセスされる可能性がある 

コアモデルの拡張例

コアモデルから、多数の拡張機能を開発できます。たとえば、Managed System Element クラスの抽象化した Managed Element クラスを追加できます。コアモデルには、この Managed Element クラスの下位クラス (ユーザーや管理者など、管理対象のシステムドメインに含まれないオブジェクトを表現するクラス) を追加できます。