情報の観点から考える SOA デザイン、第 1 回: 情報の観点から考えるサービス指向アーキテクチャー (SOA) の概要

ページオプション JavaScript を要するドキュメントオプションは表示されません

レベル: 中級

Brian Byrne, Industry Models and Integration Architect, IBM
David McCarty, IT Architect, IBM
Dr. Guenter Sauter, Information Architect, IBM
Peter Worcester, Services Solution Marketing Manager, IBM
John Kling, Consulting and Services Architect, IBM

2008年 1月 24日

この記事は、サービス指向アーキテクチャー (SOA) を設計するアーキテクトや現場の方々を対象としています。ここでは、情報の観点から考える SOA デザインを代表するパターンと機能を紹介します。ここで扱う主なパターンは、ビジネス・グロッサリー、標準モデル、およびデータ品質分析です。これらのパターンが SOA でどのように位置付けられているか確認し、どのように SOA ソリューションに貢献するか検討します。また、関連 IBM 製品である IBM InfoSphere Information Server、InfoSphere Data Architect、および IBM Industry Models を紹介します。 これは、連載第一回目の記事です。次回以降の記事では、各パターンをさらに詳しく検討し、それぞれを実装するために IBM 製品をどのように使用したらよいか説明します。

はじめに

SOA デザインの重要な目標は、サービスを特定し、仕様を決定することです。言い換えると、どの機能やデータをサービスとして公開するか検討し、その特定したサービスを定義、モデル化する方法を決定することです。IBM では、SOA 分析およびデザインのプロセスを定義する方法論として、サービス指向モデル化手法 (Service Oriented Modeling and Architecture: SOMA) を採用しています (リソースを参照のこと)。

SOMA (および他の多くの SOA 方法論) では、適切な粒度のサービス・インターフェースのデザインを決定したり、再利用性を確立したりするのに、ビジネス・プロセス分析とユース・ケース・デザインに大きく頼っています。「情報」の観点から SOA を考えるとき、データベース照会をWeb サービスとして公開するようなサービスの実装に限られることが多いでしょう。このような狭い視野では、既に確立されている情報アーキテクチャーの概念やパターンが SOA ソリューションにもたらし得る価値を完全に逃してしまいます。 SOA ソリューションにおいてスケーラブルで整合性があり再利用可能な情報へのアクセスを完全にサポートするには、情報アーキテクチャー のベスト・プラクティスを反映して、より広範なデザイン上の問題を考慮に入れる必要があります。

Information as a Service (サービスとしての情報)は、一連の体系的な手法によって、情報という側面から SOA デザインに取り組みます。どのようなビジネス情報がソリューション内に存在するか把握することにより、以下の SOA ソリューションの技術目標およびビジネス目標を最適にサポートする情報活用を実現する意思決定を目指します。

• サービスが企業全体で再利用可能である。
• コンシューマーに公開されるビジネス・データが正確かつ完全でタイムリーである。
• ビジネス・ドメインおよびテクノロジー層全体で共用するデータについて、すべての関係者がその構造や意味に対し共通の理解を持っている。
• 企業のビジネス・ドメインと結合している核となるデータ・エンティティーが、すべての基幹業務において整合性があり、信頼されている。
• 企業がデータおよびデータ・システムから最大のビジネス・バリューを得ている。

上記の目標は、選択したテクノロジーや実装に関係なく、SOA ソリューションのあらゆる部分に当てはまります。例えば、既存のアプリケーション・プログラミング・インターフェース (API) をサービスとして公開するには、公開されるデータに対しコンシューマー間で次のような理解が必要になります。データは信頼性があり、正確であるか？企業内の他のデータとどのような関係があるか？コンシューマーが理解可能なフォーマットで提示されているか？SOA プロジェクトでデータ分析、モデル化、およびデザインに対し体系化されたアプローチをとると、既存のビジネス要件を満たすと同時に、新たなビジネス要件が加わった場合にもそれに適応し得るソリューションを実装できます。

情報の観点から考える SOA デザインで挙げられるパターンの大半は、どのサービスにも適用されます。サービスをどのように実現するかとは関係なく、また、情報サービスに限定されるものでもありません。これらのパターンについては、後のセクションで説明します。

他方、情報アーキテクチャーの概念、特に IBM の情報アーキテクチャーに対する Information on Demand のアプローチをとることでも、いくつかの SOA コンポーネントの実装を最適に行うことができます。例えば、データ・フェデレーションは多くの場合、異種混合システムからリアルタイムでデータを収集し、そのデータを共通サービス・インターフェースを通じて公開する SOA コンポーネントの実装に最適なオプションです (リソースを参照のこと)。本記事には、情報サービスの実現に関連した考察が記載されています。

上に戻る

情報に関連した SOA のデザインの一般的なパターン

図1は、情報の観点から考える SOAデザインの基盤となる 3つの柱を示しています。3つの柱は次のとおりです。

• ビジネス・グロッサリーを通じたデータの意味体系の定義
• 標準モデリングを通じたデータ構造の定義
• データ品質分析

1. 情報の観点から考える SOA の概要
2. SOA でビジネス･グロッサリー･パターンを適用することの価値
3. SOAデザインでの IBM InfoSphere Business Glossary の使用
4. SOA で標準モデル･パターンを適用することの価値
5. SOA での InfoSphere Data Architect の使用
6. SOA でデータ品質分析を適用することの価値
7. SOA デザインでの IBM InfoSphere Information Analyzer の使用

この連載の後続記事で、それぞれの柱ごとにパターンの役割と価値を学習します。その後、このパターンに対応する IBM テクノロジーを紹介します。

ビジネス・グロッサリー

すべての SOA を成功させる基盤となるのは、プロセス、サービス、およびデータに関連する用語を定義した、共通のアクセスしやすいビジネス・グロッサリーを確立することです。SOA を実践する場合、組織内で受け入れられているビジネス言語や省略語を学ぼうとする際に用語に整合性がないことがよくあります。顧客、チャネル、収益など主要な用語の定義が一致していないと、それらの用語に関連したサービスを実装することが不可能になります。サービスのパラメーターの意味や取得するデータ・セットについてステークホルダー間の解釈が異なると、サービス実装を成功させることは到底不可能です。

ビジネス・アナリストや技術コミュニティー間で、プロセス、サービス、データを含む SOA ドメインのすべての側面で使用される用語について共通の理解があることが重要です。ビジネス・グロッサリーがあれば、核となるビジネス概念の周辺で使用される言語にあいまいさがなくなり、それによって起こるデータ要件に対する誤解を防ぐことができます。

ビジネス・グロッサリーは、用語の定義を統制する共通の語彙を確立することにより、誤った解釈を防ぎます。それぞれの用語は、説明と他のメタデータで定義され、分類法で位置づけられます。スチュワードは割り当てられた用語に責任を負っており、用語定義や用語のガバナンスに配慮します。ビジネス・グロッサリーのパターンの詳細については、この連載の後続記事に記載されています。

ビジネス・グロッサリー成功の鍵は、簡単にアクセスできるようにし、他の重要なモデリング成果物とリンクさせることと、プロジェクトのデザイン・フェーズで積極的な利用を求めることです。このパターンは、IBM InfoSphere Information Server に含まれている InfoSphere® Business Glossaryがサポートしています。この製品については、この連載の中で詳しく説明します。

グロッサリーの管理および共用ツールと併せて、IBM では業界固有の知的財産もモデルの形で提供しています。これらのモデルには、ステークホルダーとのデータ要件および分析の議論を実現するための、明確に定義されたビジネス用語が何千と含まれています。

標準データ・モデル

整合性のある用語集の整備はサービスをデザインする際の出発点としては好ましいものですが、それだけでは不十分です。ビジネス情報がどのように構造化されているか明確に理解することも必要です。サービスの入出力パラメーター、つまりメッセージは、単一のデータ・タイプよりもはるかに複雑であることが多く、エンティティーの複雑な定義やエンティティー間の関係を表していることがあります。SOA アーキテクトがサービス・モデルのデータ・フォーマットをデザインする際に標準モデルを活用すると、SOA プロジェクトの開発期間が大幅に短縮され、品質も大幅に向上します。結果としてプロセス、サービス/メッセージ、およびデータ・モデルが整頓されることで、デザインは加速し、データ・モデリングの標準的なガイダンスを使用することで、余計な変換をしなくて済むようになります。SOA ライフ・サイクルの初期に、詳細なサービス・データ・モデルをステークホルダーに明らかにしておくことが同じくらい重要です。これにより、複数のビジネス・ドメインで最も再利用可能なデータ・セットを特定しやすくなり、より広範なサービス・コンシューマーのニーズに合わせてサービスを定義することで、サービスの重複を減らします。

この記事および後続の記事で扱う重要な課題は、どのようにして一貫性のある情報フォーマットを水平方向、つまりサービス間で保ち、垂直方向、つまりSOA コンテキスト内のプロセス、サービス、およびデータ層間で確実に保つかです。標準データ・モデルは、SOA プロジェクトに関連するデータを持つさまざまなシステムの主要なエンティティー、その属性、および関係について整合性のある定義を提供します。標準データ・モデルはこのデータ層の共通フォーマットを確立し、標準メッセージ・モデルはこのサービス層の統一フォーマットを定義します。標準データおよびメッセージ・モデルのパターンについては、この連載の後の記事で説明します。

Industry Models が提供するプロセス、サービス、データ・モデルの統合セットは、サービス・アーキテクチャーの分析およびデザインの促進に使用でき、複数のモデリング・ドメインにまたがるデータ定義の整合性を確実に保証します。 特定の業界ドメインをモデル化するためのベスト・プラクティスを定義し、拡張可能なフレームワークを提供するので、サービスを追加するたびに SOA をデザインしなおす必要がありません。

後の記事で、関連データ・モデリング・ツール InfoSphere Data Architect と関連性のあるモデルの構造についてさらに詳しく説明します。

データ品質分析

上述の概念を検討することにより、モデルおよびメタデータ成果物間で高い整合性を保ったサービス・デザインを提供できます。しかし、これでは、サービスが返すデータの品質が許容範囲にあることは保証されません。元のリポジトリーおよびアプリケーションの規則や制約を満たすデータであっても、企業レベルの要件を満たさない場合があります。例えば、ある ID が単一システム内でユニークであったとしても、企業内でユニークだと言えるでしょうか？単一のアプリケーションでは取るに足らない品質の問題が、企業レベルの SOA でより広範囲に公開された際に大きな問題となる場合があります。例えば、欠落している値、重複項目、一貫性のないデータ・フォーマットは、元のアプリケーション範囲ではあまり表に出なくとも、SOA で新たなコンシューマーに公開した際に問題となります。

したがって、公開されるデータの品質が SOA プロジェクトの要件を満たしているかどうか、その判断をどう効果的に行うかが重要です。 ここで提案する解決策は、サービスの分析およびデザイン中にデータ品質を診断することです。サービスをサポートするソース・システムをカタログした後、データ品質の調査を始めることができます。例えば、データがそれを定義している整合性のルールに準拠しているか確認する必要があります。データ重複があるか、また、この問題をデータのマッチングや収集の際、どのように解決すればよいか検証しなければなりません。このような分析に基づいて、サービス実装の選択時、データが潜在的なサービス・コンシューマーの要求するレベルの正確性および意図を満たすような、適切な対応が可能になります。この連載の後の記事で、このパターンについて説明します。

データ品質診断の効果は、適切なツールを決定することで大きく向上します。IBM InfoSphere Information Server に組み込まれている InfoSphere Information Analyzer は、データ品質分析パターンをサポートします。 InfoSphere Information Analyzer については、連載内の別の記事で説明します

上述の問題および概念は、SOA のすべてのサービスに適用されます。標準モデリングおよびデータ品質分析は、サービスのタイプに関わらず、サービスの整合性およびその出力データに価値を提供できます。

上に戻る

情報サービス固有のパターン

情報サービス の実現方法は、情報アーキテクチャーや Information on Demand (情報をアプリケーションやプロセスから分離することで利益をもたらす) により決定します。

ほとんどの SOA プロジェクトは、何もない状態から始まるのではなく、既存の IT 環境を基盤にします。SOA 固有の課題も一部ありますが、従来の情報アーキテクチャーにおける既知の問題は 、大抵 SOAにも当てはまります。多くの場合、典型的な組織の情報環境は、効果的な SOA 変換を実現するのに理想的な状態ではありません。企業全体という視点から見ると、組織のコアとなる情報を提供する、完全で正確かつ正式なデータ・ソースが欠落していることがよくあります。代わりに、データの保管および処理が基幹業務、チャネル、または製品タイプにより異なっているため、それぞれに対応したさまざまなテクノロジーが使用されています。大組織の多くでは、中心的な企業情報が複数の垂直システムにおいて散乱し、複製されているため、企業のコンテキストではなく特定のコンテキスト内でそれぞれが情報を保持しています。このような状況がビジネス・プロセス内の不整合をさらに後押ししており、たいていビジネス・プロセス自体も企業の各部分で大幅に異なっています。Information On Demand、とりわけ、データ、内容、情報統合、マスター・データ、および分析サービスを使用すると、正確かつ整合性があり統合された情報を正しいコンテキストで提供する情報サービスを実現できます。

例として、正式な信頼できるソースや単一レコードシステムが欠落している状況を考えてみましょう。組織のサプライ・チェーン・システムの中に、サプライヤー情報を保持するシステムが5つあると仮定します。それぞれのシステムは、所有部門におけるサプライヤー・データの正規のソースとみなすことができます。サプライヤー・データを共用するにはサービスをいつ構築し、サプライヤー・データのソースは何にすべきでしょうか？

• 5つの現行システムのうち、サプライヤー・データのオリジナル・コピーを持つものはありますか?それはどのシステムですか？
• この目的のために新規のデータベースを作成しますか？このデータ・ソースは既存ソースとどのように関連付けますか？
• データは、5つのシステムすべてから同時に取得する必要がありますか？その場合、データを結合し、コンシューマーが必要なフォーマットに変換する規則を理解するのは、データ・アーキテクト、サービス・デザイナー、ビジネス・プロセス・デザイナー、またはビジネス・アナリストの責務ですか？

多くの場合、このようなばらばらのデータ定義は、参照モデル (多くの場合、論理データ・モデル) にマッピングし直すことによってのみ理解でき、データ定義の重複、ギャップ、矛盾が特定できます。再利用できる戦略的な企業情報はビジネス・エンティティーのセットと見なし、組織全体で再利用するために標準化し、業界標準の構造、意味体系、およびサービス契約に準拠する必要があります。目標は、企業情報にアクセスするための正式かつ固有で一貫した手段となる、一連の情報サービスを作成することです。特定のアプリケーションを通じてのみすべての情報にアクセスできるようにすると、情報の範囲が SOA で必要な企業のコンテキストではなく、アプリケーションのコンテキストに制限されてしまいます。この目標となるサービス指向環境では、組織のビジネス機能やデータを、複数の部門および基幹業務で再利用可能な企業資産として使用できます。これにより、次の情報サービスの原則が実現されます。

• サービス・インターフェースを通じ、単一の論理ソースから一貫性のある完全な情報のビューを表示します。これは多くの場合、信頼できる情報の提供と呼ばれます。
• 情報サービス層の下に存在する異種混在環境とそれに起因する複雑性を、必要に応じて(実行時など)隠蔽します。ただし、情報のリネージュ、つまり、論理ビジネス・エンティティーから実データ・ストアへのマッピングは、必要な際に見ることができます (例えば、データ・スチュワードによるデータ・ガバナンスや影響分析などの場合)。
• 情報サービスの正式なデータ・ソースを明確に特定し、企業全体で効果的に利用します。
• 情報サービスについての有益なメタデータを使用できます。
  • サービスを通じて公開される情報の品質が分かり、ビジネスの期待に沿ったものになる。情報サービスは、定義済みのデータ標準に準拠する。
  • 情報の現行性 (データの経過期間) がわかる。必要な待ち時間で情報を配布するための効果的なメカニズムがある。
  • 情報の構造および意味体系がわかり、異なるアーキテクチャー層 (データ・パーシスタンス層、アプリケーション層、サービス/メッセージ層、およびプロセス層) において共通の方法で提示される。
• 適切なプロセス、ポリシー、および組織構造に基づく情報サービスのガバナンスが可能になります。
  • 情報のセキュリティーを保証し、後付けの実装ではなくソリューションに組み込まれ、セキュリティーおよびプライバシー・ポリシーに準拠する。
  • サービスの変更を監査できる。
  • 情報サービスを、組織内の潜在的なコンシューマーが簡単に見つけることができる。
  • ガバナンスの総合的なアプローチが敷かれ、サービス層と情報層の両方に対応する。

Information as a Service は、Information On Demand を通じて定義されているように、SOA の世界では情報アーキテクチャーの概念および機能の活用法を指します。SOA には Information On Demand に含まれていない重要な機能と概念があり、同様に Information On Demand にも SOA に含まれていない重要な機能と概念があります。しかし、内容、情報統合、マスター・データ・サービスの活用など、かなりの部分が重なっており、それらは SOA プロジェクトのデリバリーを大幅に向上させます。次の図は、左側に示されている SOA 参照アーキテクチャー (リソースも参照のこと) と右側の Information On Demand 参照アーキテクチャーとの関係を示しています。

SOA デザイン・フェーズの中で、アーキテクトはプロジェクトの要件に基づいてどのパターンを使用するか、アーキテクチャーに関する決定をしなければならない場合があります。表1 に、適用される可能性のある主要なパターンを大まかにですがいくつか示します。

IBM InfoSphere Information Server は、統一されたメタデータ管理プラットフォームを提供することで、SOA デザイン・フェーズで重要な役割を果たします。このプラットフォームはリポジトリーとフレームワークで構成され、さまざまなデザイン・ツールを使用して成果物にアクセスし、それを保守し、他の Information Server コンポーネントやサード・パーティー・ツールと成果物を共用することを可能にします。この共用メタデータ・プラットフォームの価値は、メタデータ成果物をツール間で簡単に共用し、その整合性を保つ点にあります。

上に戻る

まとめ

この記事の目的は、情報の観点から考える SOA デザインといくつかの主要パターン (ビジネス・グロッサリー、標準モデル、およびデータ品質分析) について概要を説明することです。各デザイン・アクティビティーで業界モデルを活用することの意義がお分かりになったでしょうか。これらのトピックのいずれかに興味を持った場合は、この連載の後続の記事をお読みください。

参考文献

• この記事で紹介されたトピックについてより詳しく知りたい場合は、この連載（US）の第2回以降の記事をご覧ください。
  
  
• 「Information service patterns（US）」シリーズには、この記事で扱われた情報サービスのパターンが記載されています。(developerWorks。2006-2007)。
  
  
• SOA 参照アーキテクチャーについて詳しくは、「Design an SOA solution using a reference architecture（US）」を参照してください。
  
  
• テクノロジー ブックストア: この記事や他の技術的なトピックに関する書籍を参照できます。
  
  

• IBM InfoSphere Information Server、特にInfoSphere Business Glossaryで、企業の用語および分類システムを作成、管理、共用できます。
  
  
• InfoSphere Data Architect は、データ・モデリングおよび統合デザインを単純化します。
  
  
• IBM Industry Models（US）は、プロジェクトを加速し、リスクを軽減します。
  
  
• InfoSphere Information Analyzer は、データ・ソースの構造、内容、および品質の理解に役立ちます。
  
  

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

著者について

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

		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 ソリューションを専門にしています。

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

記事の評価

サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。 この情報はお客様が目的を達成するうえで役に立ちましたか？ はい いいえ わからない   お気軽にご意見・ご感想をお寄せください。   この記事は役に立ちましたか？ 1 2 3 4 5 不充分・不完全である 大変素晴らしい

この記事を共有する del.icio.us newsing FC2ブックマーク Choix！ ニフティクリップ Yahoo!ブックマーク MM/memo CZブックマーク livedoorクリップ はてなブックマーク Buzzurl（バザール）

上に戻る