Common Information Model (共通情報モデル: CIM) は一般的に使用されるようになってきており、このモデルが持つ既知の利点を求めて業界内で活用されています。CIM には異なる形態があり、それぞれの形態の特徴や、利点、欠点を理解することが重要です。この記事では、それらの詳細について詳しく説明することで、企業が持つツールや専門的能力に応じて設計者が適切なパターンを選択できるようにします。

Lennox Thomas, Associate Partner GCTME, IBM

Lennox ThomasLennox Thomas (Lenny) は IBM USA の GBS Global Telco Center of Excellence に勤務するプリンシパル・コンサルタントです。彼は全世界の複雑な通信ソリューション数件でチーフ・アーキテクトを務めました。彼は応用数学とコンピューター科学で修士号を取得しています。彼は革新的なスキルで IBM 内外に知られています。



Gandhi Sivakumar, IBM certified Senior IT Architect, IBM

Gandhi SivakumarGandhi Sivakumar は IBM 認定シニア IT アーキテクトであり、SOA ベースの複雑な統合プロジェクトに従事しています。彼女は IBM Academy の幹部メンバーで、IBM 社内の多くのコミュニティーを指揮しています。彼女は技術革新に深い関心を持ち、数件の特許を申請しています。彼女はオーストラリア・コンピューター学会の州委員会のメンバーでもあります。



2012年 11月 29日

はじめに

統合が可能で、通常はミドルウェアにホストされるアプリケーションやコンポーネントを構築する際に、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 のレイヤー

図 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 の要素は変換を必要とせず、関連する類似のフラグメントといつでも結合することができ、適切なリクエストやレスポンスと組み合わせてファサードを作成することができます。上図は 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

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

まとめ

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

参考文献

学ぶために

製品や技術を入手するために

  • 皆さんに最適な方法で IBM 製品を評価してください。製品の試用版をダウンロードする方法、オンラインで製品を試す方法、クラウド環境で製品を使う方法、あるいは SOA Sandbox で数時間を費やし、サービス指向アーキテクチャーの効率的な実装方法を学ぶ方法などがあります。

議論するために

  • developerWorks コミュニティーに参加してください。ここでは他の developerWorks ユーザーとのつながりを持てる他、開発者によるブログ、フォーラム、グループ、ウィキを調べることができます。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


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