目次


異なる形態の Common Information Model

Comments

はじめに

統合が可能で、通常はミドルウェアにホストされるアプリケーションやコンポーネントを構築する際に、Common Information Model (共通情報モデル: CIM) を活用すると、それらのアプリケーションやコンポーネントが使いやすくなったり、プラグ・アンド・プレイで簡単にアプリケーションを使用できるため、作業を削減できたりするなど、さまざまな利点があります。組織は純粋にメッセージ・レイヤーのみに CIM を採用することも (本記事ではこの形態を「クラスト (Crust) CIM」と呼ぶことにします)、コア・レイヤーとメッセージ・レイヤーの両方に採用することも (本記事ではこの形態を「マントル (Mantle) CIM」と呼ぶことにします) できます。わかりやすく説明すると、クラスト CIM は純粋にメッセージ専用のものとして定義され、アプリケーションを統合する際の構文、セマンティクス、ハンドシェークのメカニズムに特化しています。内部のコンポーネントはメッセージ・レイヤーのエンティティーの構文やセマンティクスに従わない場合があります。一方、マントル CIM は構文の点でもセマンティクスの点でも実装とメッセージの両方を含めて定義されますが、ハンドシェークのメカニズムは定義されない場合があります。この記事では、マントル CIM を取り上げ、その「アロトロープ」、つまり (構成要素は同じだが) 異なる形態として存在するもの (および異なる形態として現れるもの) について分析します。

マントル CIM のアロトロープ

マントル CIM の主なアロトロープには、以下の 2 つがあります。

  • 昔ながらのアロトロープ (Traditional Allotrope: TA)
  • 一様に整えられたアロトロープ (Sheared Allotrope: SA)

TA は 2 次元で理解しやすく、柔軟ですが、実装するには処理が必要です。一方 SA は単純な 1 次元で、比較的厳格ですが、TA よりも実装に適しています。

昔ながらのアロトロープ (TA)

TA は通常、さまざまなオブジェクト、属性、関係を含んだオブジェクト指向モデルであり、すべてのエンティティーが何らかの形で相互に関係した単一のファブリックになっています。コンポーネント設計者は、適切なエンティティーを選択し、それらのエンティティーをそのコンポーネントの各操作リクエストとそれに対するレスポンスに接続する必要があります。TA の好例は、テレマネジメント・フォーラム (TeleManagement Forum: TMF) の共有情報データ (Shared Information Data: SID) モデルや IBM の金融サービス・モデル (情報フレームワーク (Information FrameWork: IFW)) の論理レイヤーです。

図 1. CIM のレイヤー
CIM のレイヤー
CIM のレイヤー

図 1 は、サンプル・コンポーネントの操作リクエストとそれに対するレスポンスがアンカー・オブジェクト E で接続されている TA を示しています。(注: アンカー・オブジェクトはリクエストとレスポンスの操作が直接接続されている CIM オブジェクトです。この記事に関連する記事「Exploring the Vector behavior of relationships in common information model (CIM) based service-oriented architecture (SOA) environments」で説明されているように、リクエストとレスポンスをアンカー・オブジェクトという 1 つまたは多数のオブジェクトに接続することができます。)

このサンプル・コンポーネントで対象となるエンティティーは、緑色で示したエンティティーです。

おわかりのように、TA には以下のような利点があります。

  • ファブリック内のすべての具象オブジェクトは、コンポーネントに対するビジネス・ニーズによって動作するアンカー・オブジェクトとして機能することができます。例えば ProductOrder はアンカー・オブジェクトになることができ、このオブジェクトを例えば CreateProductOrder というリクエストおよびレスポンスの操作に直接接続することができます。
  • ファブリックをトラバースして必要なオブジェクトに到達するには、ファブリック全体のうちの「N」個のホップを経由し、途中にあるメンバーをインスタンス化します。言い換えると、そのパスの最後にある終端オブジェクトまでトラバースする必要はありません。「終端オブジェクト」とは、選択されたパス内の最後のオブジェクトのことです。
  • 柔軟にトラバースを行えるため、設計者は自由に方向を選ぶことができます。例えば上記の図の場合、必要に応じて C から G へ、または C から K へとトラバースすることができます。

つまり TA は柔軟であり、設計者は適切なエンティティーを取捨選択してコンポーネントを作成することができます。その一方、TA には以下のような複雑さがあります。

  • 選択されたオブジェクトを変換プロセスで処理してからコンポーネントのファサードを作成する必要があります (注: 「ファサード」とは、外部の利用者側から見えるインターフェースのことです)。
  • ファブリック・レイヤーにも、ファサード・レイヤーにも、オブジェクトを処理するための複雑で柔軟なツールが必要です。
  • 同様に、TA CIM を使用してソリューション・コンポーネントを作成するには、高度なモデラーが必要です。

実際の経験に基づいて言えば、TA CIM を採用しているのは、多くのアプリケーションからなるエコシステムを持ち、外部サプライヤー・パートナーのアプリケーションとのやり取りを必要とし、複雑なツールや専門技術を活用できる能力を持った中規模の企業および大企業です。

一様に整えられたアロトロープ (SA)

SA は、関係が単方向の (つまり、関係が一方向のみで定義された) フラットなモデルです。SA には以下の 2 つの形態があります。

  • 一様に整えられたファサード指向のアロトロープ (Facade Oriented Sheared Allotrope: FOSA)
  • 一様に整えられたオブジェクト指向のアロトロープ (Object Oriented Sheared Allotrope: OOSA)

一様に整えられたファサード指向のアロトロープ (FOSA)

FOSA は直接実装される傾向があります (図 2 を参照)。

図 2. FOSA
FOSA
FOSA

FOSA には以下のような特徴があります。

  • FOSA の要素はファサードに対して直接作成され、比較的単純です。
  • オブジェクトは単方向の関係を持ち、通常はフラグメントとして作成されます。必要に応じて、オブジェクトは適切なフラグメントと結合されます。
  • FOSA の要素は変換を必要とせず、関連する類似のフラグメントといつでも結合することができ、適切なリクエストやレスポンスと組み合わせてファサードを作成することができます。上図は ProductOrder と CustomerDetails というフラグメントが ManageProductOrder という操作リクエストに結合されている状態を示しています。
  • FOSA は通常、XSD で記述されたものとして作成されます。

FOSA には以下のような利点があります

  • フラグメントは最初から実装されている傾向があり、変換プロセスが必要ありません。そのため、単純な XML ツールで FOSA を処理することができます。
  • XSD を扱える設計者であれば十分に FOSA を扱うことができます。

FOSA には以下のような欠点があります。

  • 任意の具象オブジェクトがアンカー・オブジェクトとして機能できる TA とは異なり、最上位のオブジェクト以外はアンカー・オブジェクトになることができません。フラグメント内で最上位にはないオブジェクトがアンカー・オブジェクトになる必要がある場合には、新しいフラグメントを作成しなければなりません。
  • 事前に方向性が決定されているため、方向性に影響を与える変更の場合、新しい関係を持つ新しいフラグメントを作成しなければなりません。図 2 の ProductOrder フラグメントについて考えてみてください。例えば、ビジネスで ProductOrderItem というサービスを作成する必要がある場合、ProductOrderItem から ProductOrder へとトラバースするための新しい関係を持った新しいフラグメントを作成しなければなりません。しかし TA の場合には、設計者は ProductOrderItem から ProductOrder へという既存の双方向の関係を利用してフラグメントを作成することができます。

実際の経験に基づいて言えば、FOSA を採用しているのは、ツールの予算が限られた小規模な企業です。

一様に整えられたオブジェクト指向のアロトロープ (OOSA)

OOSA はオブジェクトや属性を含むファブリックで構成されますが、関係は単方向 (つまり、一方向のみで定義された関係) になっています。任意の具象オブジェクトがアンカー・オブジェクトになることができ、このオブジェクトをコンポーネントの操作リクエストとそれに対するレスポンスに容易に接続することができます。OOSA は通常、コンポーネントを TA からファサードに変換する間の中間的なステップとして現れます。しかし、自らの企業で作成する CIM に OOSA モデルを採用する企業はほとんどありません。OOSA が中間ステップとして現れる典型的な例は IBM の IFW の物理モデル・レイヤーです。

図 3. OOSA
OOSA
OOSA

図 3 の OOSA は TA と似ていますが、方向性が固定されています。OOSA の利点は TA と同じですが、方向性は純粋に単方向です。図 3 の例を考えると、設計者は C から K にトラバースすることはできず、G にトラバースすることしかできません。選択されたオブジェクトは相変わらず変換プロセスを経ないとファサードを生成することができません。ただし OOSA を直接処理するために必要なスキル・レベルは TA の場合に比べると低くてすむかもしれません。

まとめ

マントル CIM にはさまざまな形態があり、それぞれの形態に独自の利点と欠点があります。どの形態を採用するかは、企業の規模、ツールの能力、経験に依存します。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=SOA and web services
ArticleID=847114
ArticleTitle=異なる形態の Common Information Model
publish-date=11292012