はじめに

連載第1回から第３回までの記事では、SOA におけるビジネス・グロッサリーの役割および実装方法について解説しました。ビジネス・グロッサリーは、組織の情報を表す用語を定義するものです。一方標準データ・モデルは、組織の情報の構造を定義します。目指すのは、データ・モデリングを単一のデータベースと、それに関連する物理データ・モデルだけに限定することではありません。むしろ、標準データ・モデルは、SOA に含まれるすべてのデータベースや関連するレガシー・アプリケーションのエンティティーおよび関係すべてについてのリファレンスとなります。

データ・モデルは、ビジネス要件だけを考慮してトップダウンで開発される場合と、既存データ構造のリバース・エンジニアリングによってボトムアップで開発される場合があります。いずれの場合も、IBMが保険業界向けに提供する IBM Insurance Application Architecture (IAA) や、全国小売連盟によって作成された小売業界用の ARTS データ・モデルなどの業界データ・モデルを使用できます。どのように作成されたとしても、データ･モデルはSOA における共通のデータ構造を示します。

標準データ・モデルは、SOA プロジェクトの中で付加的に開発されていきます。その情報の範囲は、SOA プロジェクトが対象とする情報の範囲に一致します。ビジネス分析、要件収集、ユース・ケース設計の段階では、意図的にモデルに詳細を含めず、ビジネスにおいて最も重要な情報概念のみを入れます。プロジェクトが技術的なモデリングおよび詳細設計に移行するにしたがって、標準モデルの開発が進み、これらのアクティビティーを完全にサポートするようになります。後続の SOA プロジェクトでは、標準データ・モデルを拡張し、組織の SOA の範囲に加わったビジネス領域と情報タイプを追加します。

この記事では、標準モデルを使用することの動機付けについて説明し、 SOA において標準モデルがどのように開発、利用されるかについて詳しく述べていきます。

上に戻る

動機付け

SOA プロジェクトを成功させるには、競合する要因のバランスを慎重にとる必要があります。例えば、広範囲で再利用可能なビジネス・サービスを見つけるには、広範囲にわたる詳細なビジネス分析が必要です。同時に、明確なビジネス目ごとに短期のプロジェクトを連ねていくことは、SOA の開発という点で最も管理しやすく成功しやすいことが経験的にわかっています。しかしこの実際的なアプローチの代償として、目の前の要件にのみ焦点を合わせて実装を急ぐために、「間に合わせ」のサービスが実装されることがよくあります。その後新規要件が加わり、サービスのポートフォリオがしだいに大きく複雑になったとき、このようなサービスはSOA 全体の柔軟性や拡張性を制限することになります。

このアプローチの 1 つの特徴は、サービス・メッセージを介して公開されるデータ構造を調査すると明らかになります。同じビジネス情報を規則性なくさまざまな形で公開しているサービスが数多く存在したり、エンタープライズ・サービス・バス (ESB) およびビジネス・プロセスで実行されているデータ・マッピングのインスタンスがいくつも存在したりする場合、ソリューションのデータ・アーキテクチャーに配慮すれば、より単純で再利用性の高いソリューションを開発できたはずです。調査しないまま放っておくと、このアプローチは SOA の利点がすべて欠落した非常に複雑なソリューションになる可能性があります。

標準データ・モデルは、各サービスが持つメッセージの情報内容に共通のフォーマットを提供します。これにより、サービス間のメッセージ・フォーマットを水平方向に揃えられます。

多くの場合、標準メッセージ・フォーマットは複数の物理テーブルからのデータを必要とします。つまりメッセージには、サービスが異なるテーブルからのデータを結合できるようにするための構造情報が含まれなくてはなりません。これを機能させるには、標準メッセージ・モデルが標準データ・モデルに基づく必要があります。多くの企業では、社内で最も重要なエンティティーについて標準データ・モデルを既に開発しています。そのモデルを利用、拡張して、SOA 分析および設計プロセスをサポートすることが可能です。

水平方向の調整と同様、SOA のアーキテクチャー層で、垂直方向にデータ・フォーマットを揃えることは重要です。特別な理由もなくサービスのメッセージ・フォーマットが標準データ・モデルや最終的にデータベースに留まるデータとまったく異なる場合は、複雑になる可能性のある変換操作をSOA に実装する必要があります。データがサービス・インターフェースからデータベース行き来する際に、異なるフォーマット間でのマッピングが必要です。

水平および垂直方向でのフォーマット不一致から発生する問題を回避できるのに加えて、標準データ・モデルを使用すると、データのビジネス・ユーザーとアプリケーション開発者間のコミュニケーションが向上するので、開発者の生産性を向上させることができます。最終的には、ビジネスが行うすべての作業はデータに集約されます。データに内在するビジネス上の意味を理解するのは、アプリケーション開発者がビジネスを理解する最も早く確実な方法の 1 つです。アプリケーション・サービスの開発において、開発者はこの点を理解して、アプリケーションがビジネス・ユーザーの情報ニーズを満たすようにする必要があります。

最後に、標準データ・モデルは効果的なデータ・ガバナンスのための重要な基盤となります。例えば、「それぞれの共通エンティティーの部分を保管するシステムがいくつあるか?」、「どのシステムが共通データを保守しているか?」、「データのリネージュはどうなっているか?」、「情報の品質を信頼できるか?」などといった重要な質問に答えるのに役立ちます。

データ・ガバナンスに関連した問題は、プロジェクトにおける最も複雑で重要な問題の一部である可能性があります。重要なイニシアチブの成功はデータの可用性とデータ品質にかかっているため、データ・ガバナンスの問題は IT 戦略に多大な影響を与えうるのです。

上に戻る

標準データ・モデル

プロジェクトの複雑さに応じ、標準データ・モデルの仕様は、抽象的なものと粒度の高いもの、2 つの異なるレベルで規定する場合があります。ただしほとんどの場合、これらは単純に1つのモデルに対して行われる 2 つの定義フェーズとして扱われます。概念データ・モデリングでは、標準データ・モデル内の初期段階の大まかな仕様を決定し、論理データ・モデリングではそのモデルの詳細を追加します。

概念データ・モデル

概念データ・モデルは、最も抽象度の高い標準データ・モデルです。ここでは、SOA プロジェクトの範囲内にある企業の戦略的な情報要件を表します。

ビジネス・エンティティーは、概念データ・モデルの基本構成要素です。エンティティーは、単一かつ重要で統一性のある情報概念の周辺にある属性のグループ (例: 人、製品、注文、支払) を表します。各属性は、情報概念の特徴をより細かいレベルで表します (例: 姓、有効期限、SKU 番号)。属性とエンティティーはどちらも、用語および意味論的定義の点でビジネス・グロッサリーに基づき、連携してします。概念データ・モデルは初期フェーズで作成され、通常、エンティティーと最も重要な関係のみが含まれます。

概念データ・モデルに必ずしも含まれるわけではありませんが、説明目的で主要な属性のいくつかを定義する場合があります。個々のエンティティーから成る属性はすべて、後から論理データ・モデリング・フェーズの中で追加されます。

SOA プロジェクトにおける概念データ・モデルの開発にはいくつかの目的があります。概念データ・モデルを開発する主な理由は、次のとおりです。

• ビジネス分析、ビジネス・プロセス・デザイン・モデリング、ユース・ケース・モデリング、およびサービス候補の特定といった、SOA プロジェクトの範囲内における様々な局面で使用される主要かつ大まかな情報グループに対し、共通の表現を与える。
  
  
• プロジェクトの後続のモデリングおよび設計アクティビティーで開始点および境界を共有するため。すべてのサービスが参加しているすべての基幹業務にわたるプロジェクトで機能するベースラインとなる情報コンテキストが設定されます。
  
  
• 情報の作成、更新、削除、配布、および使用に対する責任について、データ・ガバナンスに有効な手段を提供するため。データのオーナーシップおよび使用についてのポリシーは、SOA ガバナンス・モデルにおけるサービスのオーナーシップおよび使用法に対して定義される同様の責任と密接に結び付いています。
  
  

通常、概念データ・モデルは粒度が低く、検討中のエンティティーや関係を幅広く示すことを目的としています。サービス仕様の観点から十分な詳細を与えるというよりは、むしろ検討中の情報領域を示すことを目的としています。

このモデルを使用して、SOA チームはお客様の情報要件の構造および内容に対する理解を実際に見ることができます。概念データ・モデルは、次のようなものを提供します。

• サービス候補間での情報共有の機会を特定し、資産の再利用を支援する基盤。
• 情報ニーズを失うリスク、または企業のより幅広い情報ニーズや戦略に SOA の情報管理を合わせるのに失敗するリスクを軽減する手段。
• 将来の変更が SOA ソリューションにもたらす影響を含め、企業内のビジネス・ユニット全体で情報の共有化要件および情報品質を分析する開始点。これは、後続プロジェクトの見積もりが正確に保たれる可能性が高くなり、連続したプロジェクトで遅延が発生する可能性が低くなることを意味しています。

ほとんどの場合、情報モデリングは情報エンジニアリングの表記を使用して文書化されますが、そのモデルを統一モデリング言語 (UML) に変換し、サービス・アナリストに公開できる点にも注目することは、複数のモデリング・ドメイン間における一貫性を推進するうえで重要です。この点を強調するために、下記の例に UML で表現された概念モデルを示します。同じモデルの内容が、UML と IE の表記間で簡単に交換が可能であることがわかります。

論理データ・モデル

論理データ・モデルは、先に開発した概念データ・モデルに基づいており、概念モデルにマップされたまったく別のモデルというよりは、通常同じモデルをさらに詳しく表したものです。論理データ・モデルの役割は、物理データ・モデル、メッセージ・モデル、およびコンポーネント・モデルのアーキテクチャー層にわたるデータ構造またはデータ表記の開発に入力データを提供することです。また、論理データ・モデルはサービス分析で使用される場合があり、ビジネス・プロセス・モデルなどのサービス・コンシューマーに公開される場合があります。

以下に、概念モデルと論理モデルの最も重要な相違点を示します。

• 論理データ・モデル内の各エンティティーには、主キーが割り当てられます。エンティティーの主キー とは、属性または属性のセットで、エンティティーのあるインスタンスを別のインスタンスと区別するものです。主キーの主な特徴は、一意性があり安定していることです。つまり、時間とともに変化することはありません。エンティティー内の複数の属性が結合して複合主キーを形成する場合があります。例えば、アカウント番号がすべてのタイプのアカウントに割り当てられる場合、アカウント・タイプをアカウント番号と一緒に使用して、アカウント・エンティティーの主キーをつくる必要があります。
• 概念データ・モデル・フェーズでは、説明だけのために属性をいくつか含む場合もありますが、論理データ・モデル・フェーズでは各エンティティーのすべての属性を含める必要があります。論理データ・モデルは、仕様で定めた情報構造の特徴すべてをサポートできるだけの属性を含まなければなりません。属性は、ビジネス・グロッサリーと整合性のあるビジネス名を、整合性のある命名規則と併せて使用する必要があります。
• 論理データ・モデル内のエンティティー間の関係は、参照エンティティーの主キーに関連付けられた外部キーを介して表されます。販売注文エンティティーが顧客番号主キーによって特定される顧客エンティティーを参照する場合、販売注文エンティティーは外部キーとして顧客番号を持ちます。顧客インスタンスは、顧客の主キーと販売注文の顧客を指す外部キーが同じ値である場合に販売注文インスタンスに関係します。場合によっては、概念データ・モデリング中に表された関係 (特に多対多の関係) がエンティティー自体として論理モデルで示されます。例えば、概念モデルが人からそれ自体への単純な再帰関係を示す場合があります。論理モデルに、関係する 2 人のキーを保持する RelatedPerson と呼ばれるエンティティーを、RelationshipType="spouse" など関係自体を定義する任意の属性と一緒に追加します。
• 正規化についての最終決定は、論理データ・モデルで行います。この結果、エンティティー対エンティティーの関係やスーパータイプ対サブタイプの階層の最終的な正規化された表記が決定されます。
• 論理データ・モデル内の属性は、物理データ・タイプとして割り当てられます。垂直調整の場合、これは、データベース・スキーマの生成に使用される物理データ・モデルと一致する必要があります。水平調整の場合、これはメッセージ・モデルと一致する必要があります。
• 特定の許容値、許容値の範囲、またはデータ値の他の論理制限を持つドメインを統制するルールが指定されます。これには、属性間の制限が含まれます (例: 出荷日は注文日よりも大きくなければならない)。これらのルールは論理データ・モデルの一部であるため、データベースによって施行されるに違いないと考えてはいけません。データ・ルールの施行は、これらのエンティティーを維持するサービスが担っています。サービスは、データベース・サービスかアプリケーション・コンポーネントを使用して、論理データ・ルールを施行できます。ルールをどのように施行するか、また、どのサービスで施行するかの決定は、データ・ガバナンスの重要側面です。

上記リストの最後の 2 点は、論理モデルに通常関連付けられるものの範囲を超えています。しかし、SOA のコンテキストでは、サービス間で共用されるデータの整合性および品質要件が厳しいため、非常に重要です。図 2 は、論理データ・モデルの例を示しています。

上に戻る

サービス分析モデル

サービス分析モデルは、サービスおよびコンポーネント仕様のデータ構造を表します。サービス分析モデル内で表される構造は、概念モデル (または正式な概念モデルが存在しない場合は、論理データ・モデル) 内で表される構造を直接反映します。多くの場合、標準データ・モデルが情報エンジニアリングの手法を採用している一方、サービス分析モデルは UML の手法を採用しており、ビジネス定義は 2 つの間で交換されます。概念定義の交換という特質については、次回の連載記事で説明します。

図 3 は、サービス分析モデルの例を示しています。

サービス分析モデルの目的は、包括的なデータ・アーキテクチャーに適合した方法でソフトウェア・コンポーネントおよびサービスの仕様を導くことです。標準データ・モデルが、ビジネス・ユースを反映するよう構造化された正規化フォームでビジネス・エンティティー、属性、および関係を記述するのに対し、サービス分析モデルは、データの再利用という特性やサービス・コンシューマーのニーズに基づいてこの標準モデルの集約および非正規化を定義します。

多くの場合、単一コンポーネント・モデルは、派生した標準メッセージ・モデル (XML 形式) およびコンポーネント仕様から定義されます。この場合、概念モデルは、コンポーネント内のビジネス・タイプの定義とコンポーネントのインターフェースを介して受け渡されるビジネス・タイプの定義を導きます。これにより、データ永続性、ソフトウェア・コンポーネント、およびサービス定義全体におけるデータ構造の調整の利点をさらに得ることができます。

上に戻る

標準メッセージ・モデル

標準メッセージ・モデルは、サービス・バス上でのビジネス情報の交換に使用される標準化フォーマットを表します。アーキテクチャーの異なる層を通るすべてのデータ構造が必ずしもこのモデルに準拠するわけではありません。とはいえ、標準メッセージ・モデルはデフォルトのビジネス・データ交換フォーマットを提供します。結果的にすべてのコンポーネントは、それ自身のデータ・フォーマット(恐らく、ソフトウェア・コンポーネント内の)と、デフォルトのデータ・フォーマット(サービス・バスで共用される) さえ認識すればよいことになります。標準メッセージ・モデルは論理データ・モデルに基づく一方で大幅に非正規化されていることがよくあります。これは関係グラフとタイプ階層の両方の複雑さを軽減し、サービス・コンシューマーがサービス・メッセージをより理解しやすくするためです。

標準メッセージ・モデルは、個々のプロジェクトに応じて多様な方法を使用することになる場合があります。大部分をトップダウンで推進するプロジェクトの場合、サービス分析モデルはサービス・デザイン・モデリングを介して最終的に技術サービス仕様、コンポーネント仕様、および設計段階のクラス・モデルにたどり着きます。設計段階のクラス・モデルには、標準メッセージ・モデルを構成するデータ・タイプや構造が含まれます。ESB 統合とボトムアップのサービス公開に焦点を合わせているプロジェクトの場合、メッセージ・モデルは人の手を介して直接 XML で作成されることもあれば、メッセージ・フロー・デザインおよびサービス・コード生成ツールで作成されることもあります。

標準メッセージ・モデルで最もよく使用される表記は、一連の XML スキーマです。これでタイプおよびメッセージ定義を作成すると、公開サービスを記述する WSDL スキーマで直接再利用できるという利点があります。

標準メッセージ・モデルの構成要素は次のとおりです。

1. すべてのメッセージで使用されるビジネス・エンティティーおよびビジネス属性を表す定義済みのタイプ、エレメント、および属性のセット。個々の定義には以下が含まれます。
   • 技術データ・タイプ、フォーマット、構造、および名前
   • タイプの許容値を統制するルール
   • タイプのビジネス上の意味体系
2. メッセージのセットを定義したもの。個々のメッセージには、すでに定義したタイプ、エレメント、および属性のセットが関連セットとして含まれており、これらはビジネス文書に特定の意味論的内容およびコンテキストを与えるように構造化されています。

図 4 は、標準メッセージ・モデルを示しています。

標準メッセージ・モデルは、最終的には、サービス分析モデルを介して論理データ・モデルとビジネス・グロッサリーに基づきます。標準データ・モデルは、ビジネス・エンティティー、属性、および関係を、ビジネス・ユースを反映するよう構造化された正規化フォームで記述します。標準メッセージ・モデルは、標準データ・モデルの一連の概観を提供し、それぞれの概観は関連エンティティーの小規模サブセットを再利用可能なメッセージとして公開しますが、必ず標準データ・モデルで定義されたエンティティーおよび関係の構造に従います。

上に戻る

まとめ

要約すると、相互に関連するさまざまなモデルがあり、それらはサービス契約、サービスのソフトウェア実装、およびデータ・プラットフォームに関わるデータ構造の分析および定義に使用されます。データ・タイプの表現における整合性は非常に重要で、標準データ・モデルの仕様を通じて促進されます。標準データ・モデルは、SOA プロジェクトのビジネス要件に基づいたエンティティー、属性、および関係の共通の表記です。ビジネス・グロッサリー、プロセス、サービス/メッセージ・モデル、および物理データ・モデルと一致している必要があります。これにより、サービス実行中にデータがアーキテクチャー層を通って流れる際、意味体系および構造の相互運用性が保証されます。

もしこの概念を活用することで、プロジェクトが抱える問題に対処でき、データ・モデリングの課題においてツールを活用する方法に興味がある場合は、次回の記事「SOA での InfoSphere Data Architect の使用」をお読みください。

参考文献

学ぶために

• このシリーズ（US）の残りの記事をお読みください。
  
  

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

• • IBM InfoSphere Information Server、特にInfoSphere Business Glossaryを使用してエンタープライズ語彙および分類システムを作成、管理、および共用してください。
  
  
• データ・モデリングおよび統合デザインを単純化するには、InfoSphere Data Architectを使用してください。
  
  
• プロジェクトを加速し、リスクを軽減するには、IBM Industry Modelsを使用してください。
  
  
• Optimで、データ駆動型アプリケーションのデザイン、開発、デプロイ、および管理のためのより包括的なデータ管理ソリューションを探索してください。
  
  

議論するために

• developerWorks blogs（US）から developerWorks コミュニティーに加わってください。
  
  

著者について

Brian Byrne は、分散システムの設計と開発の分野で 10 年以上の経験があり、業種を越えて Industry Models のアーキテクチャーを推進することに 7 年間を費やしました。Brian は現在、IBM の Information Management 組織でアーキテクトを務めています。

John Kling は、IBM の Global Business Services 内の Information Services Practice でアーキテクトを務めています。 彼は、データ品質、データ統合、およびマスター・データ管理に重点を置く大規模なお客様との提携業務の指揮を担当しています。 現在は、フォーチュン 500 社の SAP 実装のデータ・チーム・リーダーです。

David McCarty は、フランスの La Gaude にある IBM の European Business Solution Center に駐在し、IBM のお客様とともに IT システムの設計と開発に携わり 20 年の経験があります。彼は現在、SOA ソリューションでデータ・システムを有効利用するための技術とベスト・プラクティスを開発する Information as a Service Competency Center の一員です。

Guenter Sauter は、IBM のソフトウェア・グループ内にある Information Platform & Solutions 部門のアーキテクトです。彼は、IBM のマスター・データ管理および情報プラットフォーム技術を越えてアーキテクチャー・パターンおよび使用法のシナリオを推進しています。彼は最近まで、Information as a Service のためのアーキテクチャー・アプローチ、パターン、およびベスト・プラクティスを開発するアーキテクト・チームのリーダーでした。彼は、 IBM の SOA Scenario on Information as a Service の技術上の共同責任者です。

Peter は 3 年前に IBM に入社しました。その前はほぼ 25 年にわたってアメリカ国防総省、GE Corporate、Morgan Stanley などで働いてきました。彼はこれらの組織で、技術リーダーの立場にあり、Enterprise Architecture および Enterprise Data Integration で貴重な経験を得ました。彼は最初、Information as a Service のアーキテクト・チームの一員として Sr. IT Architect として IBM に入社しました。現在は、IPS Global Services 組織のソリューション・マーケティング・マネージャーとして、MDM ソリューションを専門にしています。

この記事を評価する

コメント

上に戻る

目次

• はじめに
• 動機付け
• 標準データ・モデル
• サービス分析モデル
• 標準メッセージ・モデル
• まとめ
• 参考文献
• 著者について
• コメント