レベル: 中級 Akram Bou-Ghannam, Ph.D. (akram@us.ibm.com), Executive IT Architect (Senior Certified), IBM
Andrew Hoppe, Ph.D. (ahoppe@us.ibm.com), Advisory Software Engineer, IBM
2008年 06月 04日 この記事では、企業内の情報の価値とアクセシビリティーを最大限にするとともに、SOA の世界における情報中心の企業になるためのエンタープライズ情報戦略とアーキテクチャー・フレームワークについて説明します。
はじめに
簡素化が進む傾向のなか、企業は SOA をデータ層に拡張する手段として情報サービスを提供するようになってきています。情報サービスによって、複合 SOA アプリケーションをデプロイする際に必要となる企業内のプロセスと情報のリンクと結合は可能になります (「The Emerging Vision for Data Services: Becoming Information-Centric in an SOA World」を参照)。その一方で、情報サービスの柔軟性を最大限にし、できるだけ再利用できるように構築するにはどうしたらよいでしょうか。この記事では、企業内の情報の価値とアクセシビリティーを最大限にするとともに、SOA の世界における情報中心の企業になるという構想を実現させるためのエンタープライズ情報戦略とアーキテクチャー・フレームワークについて説明します。
情報サービス・アーキテクチャーで焦点となるのは、データ・アーキテクチャー、そしてさまざまなシステムにまたがる情報のソース、関係および意味を把握することです。その目標は、ソースとソース間の複雑な関係を理解するための分析プロセスを行わなくても、各アプリケーション開発者が発見して使用できる再利用可能なサービスを構築することです。この記事で提案するアーキテクチャーでは、情報モデルとメタデータがその重要な構成要素となります。
情報モデルはデータを理解するための共通基盤となり、同意に基づき、ビジネスによる見解、ビジネス語彙、ビジネス・ルールを反映します。企業は通常、物理的に異なる多数のデータ・フォーマットを保持しており、その管理に苦労しています。しかし、これらのデータを共通データ・フォーマットに変換するのは困難であり、現実的でもありません。ここで提案する情報モデルは企業内の特定のデータ・モデルを反映することはしません。代わりに、セマンティクスを使用してデータに関する共通の理解を確立することによって、企業のデータを効率的に管理できるようにします。つまり、セマンティクスによって、各種の (大抵は一貫性のない) データ・モデルを情報モデルに対応付けるというわけです。このプロセスにおいては、セマンティクスによって、企業のデータが持つビジネス上の意味を統一した方法で記述できるようになります。セマンティクスはメタデータを使用してデータが持つ正式な意味を取り込みます。データ・セマンティクスは、企業が持つ基本データを理論的に説明することによって確立されますが、このプロセスは物理的なデータ・スキーマを同意に基づくエンタープライズ・ビジネス情報モデルに定義された概念に関連付けるというプロセスです。図 1 に示す SOA 情報アクセス・ディストリビューション・アーキテクチャーでは、セマンティック・サービスはセマンティック/論理サービス (Semantic/logical services) 層に表されています。
ここで提案するアーキテクチャーが持つメタデータ駆動型という性質は、極めて高い柔軟性をもたらす効果もあります。このアーキテクチャーが導入しているセマンティック/論理情報サービス層は、オンデマンド・アプリケーションをデプロイするには欠かせない疎結合を、メタデータを使用して可能にしています。セマンティックな調整とメタデータにより、企業はアプリケーションと物理データ・リポジトリーとの間の固定的な結合を排除することができます。この固定的な結合こそが、エンタープライズ・アーキテクチャーを硬直した柔軟性のないものにする主な原因です。
連載第 2 回では、別のビジネス・シナリオと事例をこのアーキテクチャーに当てはめて紹介するとともに、今回の記事で紹介する概念についても説明します。また、IBM の製品とツールを使用した実装のロードマップについても説明します。
企業における情報に対する挑戦
大半の企業は未だ情報ではなくデータを提供しているため、稼働中の情報システムには多くの欠点が存在する結果となっています。このような、情報ではなくデータを使用するエンタープライズ情報システムは、開発するにも、拡張、維持するにも費用がかかります。そこには大量の冗長データが含まれ、さらには古くなって使い物にならない情報が存在することもよくあります。多くの場合、このようなシステムはユーザーの質問に対して不完全な回答しか提供しなかったり、ユーザーにとって該当する情報の特定が困難であったりするだけでなく、ユーザーがアクセスする場合にも概して IT の支援が必要となったりします。
一般的な企業にはモノリシック構造でミッションに特化した他とは連携の取れないシステムが多数あります。稼働中のエンタープライズ・アプリケーションの大半はモノリシック構造のアプリケーションが占めています。このようなアプリケーションのビジネス・ロジックは、他のアプリケーションで簡単に再利用できるようなモジュールの形式で外部から利用することはできません。こうしたシステムは統合されていないため、ほとんどの企業は効果的にデータを集約する能力に欠けています。この能力の欠如のために、コストのかかる多くのカスタム・コードを実装してビジネス要件を満たさなければならなくなり、その結果、大きなビジネス・チャンスを逃してしまうという事態になりがちです。さらに、企業にはシステムの統合に加え、情報に対する見解を統一する能力も求められます。例えば、顧客に関する企業の見解を打ち出すことが、エンタープライズ・ビジネス戦略の主要な要件の 1 つとなっています。
企業のデータ問題は、会社の最終決定に強大で無視できない影響を及ぼします。これらの問題は一般に以下の側面での問題として現れてきます。
情報の品質: 統合されずに分散されたデータ環境は冗長で一貫性のないデータを生み出す原因となり、結果的には情報の品質問題をもたらします。情報の品質問題は、顧客との関係や社内業務の誤った取り扱いという形で現れてきます。そのためこの問題は、ビジネスに年間数百万ドルの負担をかけています。
ビジネス・アジリティー: 絶えず変わり続けるビジネス要件に対応しなければならない現代の企業にとって、柔軟性は不可欠です。データ問題は、再利用可能性とアジリティーを妨げる柔軟性のない環境を作り出します。
IT コスト: 統合が行われていない企業における柔軟性の欠如は、新しいビジネス条件を実装する際の時間とコストを大幅に増やします。このような環境では、企業全体に重複して散在するデータベースを管理して維持するにはコストがかかります。なぜなら多くのポイント・ツー・ポイントの対応付けや変換が必要になってくるためです。
ほとんどの企業では日常業務の一環として、大々的にデータの複製を行っています。このことが広範囲に及ぶ冗長性を生み出し、エンタープライズ・アーキテクチャーの複雑さと柔軟性のなさを増長させ、エンタープライズ規模の SOA 実装を困難にしています。複製によって作り出される企業内で重複した一貫性のないデータ・ソースが原因となって、企業の至るところに重複した一貫性のないビジネス・ロジックが作り出されることになります。
オンデマンド情報の構想
情報は、ビジネス・イノベーションの鍵です。オンデマンド情報という構想には、リアルタイムで、しかもコンテキストのなかで信用できる情報を提供するという手段により、情報をビジネスの最適化に利用するという狙いがあります。さらにビジネスのリスクを減らす狙いや、ビジネス活動の内容をより目に見える形にするという狙いもあります。
オンデマンド企業のビジネスを推進するアプリケーションは、動的に構成可能な疎結合アプリケーションへと移行しつつあります。そのため、オンデマンド企業は密結合された融通の利かないアプリケーションではなく、動的に構成可能な疎結合アプリケーションを構築するための戦略を採用します。オンデマンド企業の狙いは、さまざまな種類のアプリケーション・コンポーネントからサービスをオンデマンドで、あるいはジャスト・イン・タイム方式で再構成して組み立てることです。
オンデマンド情報の構想を実現するには、さまざまなビジネス・コンテキストで再利用できる疎結合情報サービスを作成しなければなりません。次のセクションでは、この疎結合を実現するためのアーキテクチャーを提案します。ここで重要な点となるのは、ビジネス・コンテキストによって情報エンティティーの組み合わせと使い方が異なるということです。その一例として、IBM での事例を検討してみましょう。
IBM では、顧客組織の情報をさまざまなビジネス・コンテキストとビジネス・プロセスで使用しています。例えば、営業と財務の場合です。直販のビジネス・コンテキストは、信用販売と融資のビジネス・コンテキストとは異なります。後者では、IBM の信用機関 (IBM Global Finance) が顧客の購入資金を融資します。そのため、「融資」のビジネス・コンテキストには、「直販」のビジネス・コンテキストの場合とは異なる顧客組織の情報が必要となります。営業の場合、顧客情報のなかで該当する情報は営業地域と営業担当ですが、財務の場合に重要な情報は顧客の収益と信用格付けです。このような情報は通常、コアの顧客データ (組織名や住所、地区、地域など) にはなりません。コアとなる組織データには、名前や住所などの IBM には依存しない法的情報、そして IBM Geography および IBM Region などの IBM 固有の分類情報も含まれます。このように、財務のビジネス・コンテキストにおける顧客組織のエンティティーには、営業のビジネス・コンテキストとは異なる意味と構成があるため、このすべてのデータは別のエンタープライズ・データベースに保存されることになるはずです。
オンデマンド・エンタープライズ情報アーキテクチャー
図 1 に、オンデマンド企業の SOA 情報アクセス・ディストリビューション・アーキテクチャーを示します。このアーキテクチャーで採用しているのは、アプリケーション (エンタープライズ・プロセス) とエンタープライズ・データとの疎結合を最大限にする抽象化層を使用した情報サービスです。プロセスとデータをできる限り疎結合にすることで、情報サービスを最大限再利用できるようにしています。今回の記事ではこのアーキテクチャーの詳細に目を向け、ここに提案するアーキテクチャー抽象化に従った情報サービスを実装することで、柔軟性および応答性に優れたオンデマンド企業を実現する方法を説明します。
図 1. オンデマンド企業のための SOA 情報アクセス・ディストリビューション・アーキテクチャー
このアーキテクチャー案では、企業内の情報ソース (図 1 の一番下にあるデータ・リポジトリー (Enterprise information sources)) は密接に結合されてもいなければ、特定のエンタープライズ・アプリケーションに限定されてもいません。データ操作サービス (下の方にある層 (Data manipulation services)) が物理リポジトリーからデータを抽出し、セマンティック・サービス (Semantic/logical services) がこのデータを情報に変換します。つまり、セマンティック・サービスが物理データを変換して、(同意に基づいた (データに対する) ビジネスによる見解 (つまり情報モデル) に準拠した) 論理表現によるデータにするということです。このように、情報サービスは基礎となるデータ・リポジトリーを該当するビジネス・コンテキストに合わせて構成 (活用) することによって、構成プロセスに柔軟性をもたらします。
前にも述べたように、同じ情報でも、それぞれのビジネス・コンテキストによってその構成と用途はさまざまに異なります。例えば、直販のビジネス・コンテキストにおいて使用される顧客情報には、たいていの場合、顧客融資のビジネス・コンテキストで使用される顧客情報とは異なるエンティティーが含まれるはずです。したがって、顧客情報サービスが直販ビジネス・コンテキストに合わせて (アーキテクチャーに示したさまざまな抽象化レベルで) 作成されている場合、顧客融資ビジネス・コンテキストを対象に新しいソリューションを (新しいビジネス・コンテキストで) 構成する際には、直販ビジネス・コンテキスト用の顧客情報サービスの一部を再利用することができます (その他の顧客情報については新規に作成する必要があるかもしれません)。しかしもし、さまざまな抽象化層で再利用可能な基礎となるサービスの仕様を考慮せずに、ある特定のビジネス・コンテキストだけに対応するように顧客情報サービスをモノリシック構成で固定的に作成していたとしたら、基礎となるサービスを再利用して新しいビジネス・コンテキストのソリューションを構成することが可能な柔軟なアーキテクチャーを提供することは不可能となります。
この記事の残りでは、アーキテクチャー案の概要を紹介し、このアーキテクチャーを作成する方法をステップバイステップで説明します。
SOA と情報サービスを使うことによるエンタープライズ情報の利用
SOA は、情報とソフトウェア・アセットを簡単に結合させて再利用しやすくします。SOA により、IT 管理者はデータを遥かに強力なエンタープライズ・アセットに変えるための新しい手法を開発することが可能になります。情報は SOA 戦略に不可欠の要素です。そして IT でのビジネス投資によるメリットとして最も期待されるのが情報の可用性です。Gartner Research によると、「SOA によって活用できるエンタープライズ情報がない限り、SOA への投資は無駄になる」ということが示されています (「Service-Oriented Business Applications Require EIM Strategy」(Gartner Research、2005年3月))。
情報サービスは SOA 戦略には不可欠なものであり、情報サービスが組み込まれた SOA 戦略では、プロセスとアプリケーションに対応したデータ統合の手法を一元化および標準化します。情報サービスは各種の情報ソースからのさまざまなデータとコンテンツを同じように統合して管理し、すべてのビジネス・プロセスに対し、利用可能な情報を標準的かつ一貫した管理可能な方法でパッケージ化して 1 つのサービスにします。情報サービスは、サービスのベースを構成する情報システムやリポジトリーの複雑さを情報の利用者には見えなくする仮想エンタープライズ情報環境の役割も果たしています。こうした環境は情報システムへのアクセスを制御する単一のアクセス制御ポイントとなり、情報を利用する人、プロセス、アプリケーションは、情報がどこにどういう形で保存されているのかを知らなくても、このポイントから信頼できる情報にアクセスすることができます。このようにすることで、情報システムとリポジトリーは情報の利用者 (人、プロセス、アプリケーション) に影響を与えることなく進化することができます。
情報サービスは、データとアプリケーションとの間の密結合を緩め、企業全体でデータを制御して共有できるように設計しなければなりません。以下に、情報サービスが実現する内容をまとめます。
- プロセス間で一貫したデータの定義およびパッケージ化
- データに対する一貫したルールの適用
- データ品質の改善
- 制御および保守の一元化
情報サービスは、メタデータが持つ関係を利用して、プロセスが確実に情報のソースを理解できるようにすることもできます。
情報サービス・アーキテクチャーの構築
このセクションでは、図 1 に示したアーキテクチャーを構築する方法をステップバイステップで説明し、情報を利用するのにカスタム・アクセスが必要だった企業からサービスとしての情報を提供する企業への変容を遂げられるようにします。このプロセスを通して、情報サービス抽象化層、サービスの仮想化および接続性を追加します。
カスタム・アクセスが必要な情報からサービスとしての情報への変換
図 2 に示しているのは、ビジネス・アプリケーション (Business applications) から直接、情報 (Information sources) へのカスタム・アクセスを行う直接結合の手法です。この手法では、それぞれのビジネス・アプリケーション (あるいはビジネス・アプリケーション内のプロセス) が情報へのカスタム・アクセスを行うため、データに対する見解がビジネス・アプリケーション間で矛盾する結果となります。例えば、アプリケーションのあるプロセスが、別のアプリケーションのプロセスとは異なる情報ソースからアカウント・データを取得するなどです。直接結合の手法は一貫性のないアプリケーション・ルール (またはビジネス・ロジック) を適用することにもなり、プロセスによって異なる計算が行われる結果となってしまいます。ルールの適用に一貫性がないということは、同じロジックが複数の場所で保守されることになるため、複雑さとコストが増すことになります。
図 2. 情報へのカスタム・アクセスの手法
図 3 に、サービスとしての情報というSOA の手法を示します。SOA ではプロセスに対するデータ統合の手法をまとめて標準化し、情報をビジネス・プロセスに対するサービスとしてパッケージ化します。そのため、すべてのプロセスで一貫性のある管理しやすい情報を標準化された方法で利用することができます。この手法では、データの定義とパッケージ化はプロセス間で一貫することになり、一貫性のあるルールがデータに適用されることからデータ品質が向上し、さらに制御と保守も一元化されます。サービスとしての情報はデータとアプリケーションとの間の密結合を緩めるため、企業全体でデータを制御し、共有できるようになります。
図 3. サービスとしての情報という手法
図 3 の一番下にあるエンタープライズ情報のソース (Information sources) に含まれる情報は、そこからメリットが得られるあらゆるプロセスや個人が利用できるようにしなければなりません。このような情報ソースとリポジトリーは、多くの企業で見られる他とは連携を取らない数々のアプリケーション (DB2 で動作する SAP アプリケーションやその他のリポジトリーで動作するカスタム・エンタープライズ・アプリケーションなど) の特色となっています。情報ソースには、外部供給者やビジネス・パートナーからの異なるソースが含まれる場合もあります。企業が図 1 に示した柔軟な情報アーキテクチャーをベースに情報をサービスとして提供すれば、エンタープライズ・アーキテクトとアプリケーション開発者は新しいツールやアプリケーションを作成する際に、これらの情報サービスをそのまま利用することができ、情報がどのソースから提供されているのかを理解する必要がありません。情報サービスは、情報がどこにあるかに関わらず、情報を統合して統一した見解を提供し、データそのものにビジネスのコンテキストおよび価値を追加するからです。サービスとしての情報は、プロセスやアプリケーションから情報を切り離すことによって情報へのアクセスを仮想化するため、情報を変更するのも、プロセスやアプリケーションを変更するのも簡単かつ迅速になります。サービスとしての情報によってもたらされる、情報を提供する際の柔軟性は、あらゆるオンデマンド・ビジネスの目標を達成する上で欠かせないものです。
柔軟性、データ・ガバナンス、開発の容易性、そしてパフォーマンスとスケーラビリティーに関する直接結合の手法と SOA の手法の比較については、「付録」を参照してください。
サービスの仮想化および接続性の追加
まず始めに、図 4 に示す接続性および相互運用性 (Connectivity & interoperability) の層を追加して、SOA 情報アクセス・ディストリビューション・アーキテクチャーを強化します。この接続性と相互運用性の層は、SOA の ESB (Enterprise Service Bus) アーキテクチャー構造を表します。もっと簡単に言えば、企業全体で非同期通信と同期通信を行い、メッセージング、メソッド呼び出し、サービス統合、FTP などの手法を使用する層と考えることができます。この層はポイント・ツー・ポイント接続をインターフェース自体から分離することによってサービスを仮想化します。サービス・インターフェースはサード・パーティー・ブローカーに入れられることから、インターフェースが管理しやすくなり、アプリケーションの結合と分離がより迅速かつ柔軟に行えるようになります。アプリケーションとインターフェースのすべてはこの層で見つけられるため、アプリケーションとインターフェースの両方を再利用することができます。
図 4. 接続性および相互運用性の層の追加
情報サービス・アーキテクチャー層の追加
このアーキテクチャーの情報サービスには、ビジネス情報サービス (Business information services)、セマンティック/論理サービス (Semantic/logical services)、そしてデータ操作サービス (Data manipulation services) という 3 つのタイプがあり、これらのサービスが図 5 に示す情報サービス (Information services) のアーキテクチャー層を定義します。柔軟なオンデマンド企業のための再利用可能なサービスを作成するには、アプリケーションとデータとの疎結合を最大限にするこれらのアーキテクチャー層がなくてはなりません。
図 5. 情報サービス層の追加
データ操作サービス層
データ操作サービスとは、データの値とその値の表現を保存、転送、または表示目的で直接操作する処理ロジックのことです。データ操作サービスは情報サービス層の下位レベルに位置し、永続化、アクセス、そしてデリバリーを目的として物理的にデータを操作します。このサービスが提供するのは、物理的にデータに接続し、「データの取得方法は？」という質問に答えるためのメカニズムです。データ操作サービスは以下のタイプのサービスで構成されます。
- データ永続化サービス: 従来はデータベース管理システムに任せられている CRUD (作成、読み取り、更新、削除) などのデータ・アクティビティーを実行するサービスです。
- データ・アクセス・サービス: データ・アクセスの許可、制限、ロギングを行うサービスです。データ・アクセス・サービスは、許可および制限 (アクセスを対象としたポリシーおよびルール) に基づいてデータへのアクセスを提供または阻止します。
- データ・イベント監視サービス: データ・ソースで行われたデータ変更を監視、捕捉、配信することが可能なサービスです。データ・イベントの監視には、データベース・トリガー、データ複製、データベース・リカバリー・ログの処理など、よく知られたデータベース手法が関係します。データ・イベント監視サービスは、WebSphere® Data Event Publisher をはじめとするデータ・イベント監視ツールをベースに作成することができます。イベント監視サービスは、LOB クライアントに非同期で情報を配信する上で不可欠の要素です。ソース・テーブルに対する変更 (イベント) は、ログから捕捉されて XML 形式のメッセージに変換されます。このプロセスは、ビジネス・インテリジェンスと MDM (Master Data Management) に対応したデータ駆動型 EAI (Enterprise Application Integration) シナリオおよび変更のみの更新に最適なプッシュ型データ統合モデルを実現します。
ビジネス情報サービス層
情報とは、コンテキストを持ったデータのことです。ビジネス情報サービスは情報を「ビジネス・コンテキスト」のなかで表し、エンタープライズ情報モデルに定義された、(データに対する) ビジネスによる共通の見解でデータを表現します。ビジネス情報サービスは、ベースとなるサービスとして以下を行う一連のサービスを使用します。
- 必要なデータとそのロケーションを定義する標準的方法を開発する
- ソース間の関係を把握し、その関係とビジネスでデータをどう捉えるかを記述するビジネス用語とがどう関連するのかを把握する
- さまざまなアプリケーションとデータベースで該当するデータがどこに保存されているかを判断する
この層にビジネス・コンテキストを導入することで、基礎となる情報サービスを再利用して (および動的にサービスを組み立てて) 動的ソリューションの振る舞いを実現できるようになります。コンテキスト情報に応じた実行環境が設定されるため、同じ入力に対してサービスの出力が異なるものになるからです。このように、複数のチャネル (クライアント) が実行時にサービスを再利用できるようにすることによって、(コストのかかる開発作業を行わなくても) 柔軟性を向上させています。
前述の「直販」と「融資」のビジネス・コンテキストで使用される顧客情報の例からわかるように、同じ情報でもビジネス・コンテキストによってその構成と使用方法は変わってきます。
セマンティック/論理サービス層
セマンティック・サービスにより、セマンティック・モデルを表現し、モデル同士の関係を識別して、異なるセマンティック・モデルでデータを調整するために必要な変換を実行することが可能になります。この層に含まれるのは、例えば、モデル 1 で X のラベルが付いた項目はモデル 2 で Y のラベルが付いた項目と同じであるなど、データが一貫した意味を持つことを確実にするためのビジネス・ルールとメカニズムです。そのため、この層にはさまざまなデータ構造とリポジトリーで一貫した意味を維持するために必要なアクションの表現が含まれます。
この層が表現し、使用するメタデータは、各層を隣接するサービス層から確実に分離させる上で重要な鍵となります。セマンティック調整とメタデータを使用して、アプリケーションと物理データ・リポジトリーとの間の固定的な結合を排除すれば、オンデマンド・アプリケーションをデプロイするために必要な疎結合が実現します。各層が上下の層と緩やかに結合されているだけであれば、その柔軟性、適応性、そして非依存性は高くなります。さらに、このアーキテクチャーのメタデータ駆動型という性質は、極めて高い柔軟性ももたらします。
例: 1 つのクライアント組織内でのさまざまな見解
このセクションでは、アーキテクチャー案の原則を説明する一例を紹介します。これは、このアーキテクチャーを IBM でのクライアント組織情報管理に適用した場合の例です。
エンタープライズ規模の IBM クライアント情報アプリケーションでは、IBM のクライアントとなっている法的に認められた組織に関する情報を取り込んで保存します。情報は多数のデータベースに保存され、これらの組織に関する情報をできるだけ多く提供します。この情報には、組織が IBM とビジネスを行っているという事実に関するデータ、そして IBM との関係には依存しない組織に関する法的情報も含まれます。
データ操作層
各種の IBM データベースで維持管理される物理データには、以下のようなさまざまな情報が含まれることが考えられます。
企業組織データベース:
企業管理データベース:
- 地区 - 国のマッピング
- 地域 - 国のマッピング
営業データベース:
- その組織に関する IBM 営業区域についての情報
- その組織に割り当てられた営業担当に関する情報
財務データベース:
これらのデータ・グループの作成、アクセス、維持管理を行う複数のサービスが、このアーキテクチャーのデータ操作層を構成します。これらのサービスは、データ操作層のメタデータを定義し、使用します。メタデータには、各種データベースの位置、スキーマ、ルール、接続、ユーザーの ID とパスワードなどがあります。
セマンティック/論理サービス層
セマンティック/論理サービス層は、各種のビジネス・エンティティーを定義する汎用ビジネス・モデルを表します。ビジネス情報モデルはデータに対するビジネスによる見解を表すもので、セマンティック/論理サービス層に固有のものではありません。セマンティック/論理サービス層に含まれるサービスは、ベースにあるデータ・ソースでのさまざまな表現をビジネス情報モデルの共通表現に変換します。
組織の定義には、企業全体で例外なく認められている部分があります。組織の名前は OrgName によって指定され、その OrgLocation は本社住所のエンティティー (企業全体で共通して定義されて保存される HQAddress。HQStreetAddr から HQCountry までの複数のプロパティーで構成) からなります。また、組織には法的な IBM に特有ではない属性もあります。
ロケーションには他に、OrgGeography および OrgRegion というプロパティーもあります。この 2 つは IBM 特有の属性で、別個の管理部門が企業全体での属性として、国単位で定義します。
図 6 に、組織モデルの構成要素を示します。
図 6. 組織モデル
Resource Definition Framework の「トリプル表記」(「参考文献」を参照) を使用すると、このビジネス情報モデルのメタデータは以下のようにも表現することもできます。
リスト 1. 組織モデルのメタデータ
Enterprise:Organization rdf:type rdf:Class
Enterprise:OrgName rdf:type rdf:Property
Enterprise:OrgName rdfs:domain Enterprise:Organization
Enterprise:OrgLocation rdf:type rdf:Class
Enterprise:OrgLocation rdfs:domain Enterprise:Organization
Enterprise:HQAddress rdf:type rdf:Class
Enterprise:HQAddress rdfs:domain Enterprise:OrgLocation
Enterprise:OrgGeography rdf:type rdf:Property
Enterprise:OrgGeography rdfs:domain Enterprise:OrgLocation
Enterprise:OrgRegion rdf:type rdf:Property
Enterprise:OrgRegion rdfs:domain Enterprise:OrgLocation
Enterprise:HQStreetAddr rdf:type rdf:Property
Enterprise:HQStreetAddr rdfs:domain Enterprise:HQAddress
….
Enterprise:HQCountry rdf:type rdf:Property
Enterprise:HQCountry rdfs:domain Enterprise:HQAddress
|
注: 接頭辞 rdf は RDF 要素を定義し、接頭辞 rdfs は RDF スキーマ要素を定義します。
営業部門は独自の目的で、組織に関するこれとは別の IBM 特有の情報を維持管理します (図 7 を参照)。
図 7. 営業情報モデル
リスト 2. 営業情報モデルのメタデータ
Sales:SalesInfo rdf:type rdf:Class
Sales:SalesRegion rdf:type rdf:Property
Sales:SalesRegion rdfs:domain Sales:SalesInfo
Sales:SalesRep rdf:type rdf:Property
Sales:SalesRep rdfs:domain Sales:SalesInfo
|
財務部門もまた別の組織プロパティーを対象とします (図 8 を参照)。
図 8. 財務情報モデル
リスト 3. 財務情報モデルのメタデータ
Finance:FinanceInfo rdf:type rdf:Class
Finance:Revenue rdf:type rdf:Property
Finance:Revenue rdfs:domain Finance:FinanceInfo
Finance:CreditRating rdf:type rdf:Property
Finance:CreditRating rdfs:domain Finance:FinanceInfo
|
最後に、ビジネス全体のコンテキストでは Organization_Sales および Organization_Finance のエンティティーが定義されます (図 9 を参照)。
図 9. ビジネス・レベルの情報モデル
リスト 4. ビジネス・レベルの情報モデルのメタデータ
Business:Organization_Sales rdfs:subClassOf Enterprise:Organization
Sales:SalesInfo rdfs:domain Business:Organization_Sales
Business:Organization_Finance rdfs:subClassOf Enterprise:Organization
Finance:FinanceInfo rdfs:domain Business:Organization_Finance
|
企業、営業、財務、そしてビジネスの各ドメイン (RDF 表記の接頭辞) はそれぞれにビジネス情報の定義、解釈が可能なコンテキストとなります。RDF の XML 表現では、XML 名前空間がこれに相当します。
図 10 に、SOA による情報アーキテクチャー案を使用してビジネス情報を提供する方法を説明します。例えば、組織データに対するリクエストが営業部門から出されたとします。すると組織情報サービスがこのリクエストを受け取り、リクエストのビジネス・コンテキスト (営業) を検出して営業コンテキストのサービスを呼び出します。
営業コンテキストのサービスは、Organization_Sales (ビジネス情報メタデータ) のビジネス・レベルのセマンティック定義を認識し、まずエンタープライズ (コア) セマンティック・サービスを呼び出してエンタープライズ・レベルの組織情報を取得します。
エンタープライズ・セマンティック・サービスが使用するのはセマンティック/論理メタデータです。このサービスはエンタープライズ・データ・サービスを使用して組織の住所を構成する個々の要素を取得し、これらの要素を使って OrgAddress を作成します。さらに OrgAddress の構成要素である HQCountry を基に、同じくエンタープライズ・データ・サービスを使用して OrgGeography と OrgRegion を取得し、OrgAddresses、OrgGeographies および OrgRegions から OrgLocations を作成します。
次に、営業コンテキストのサービスが営業データ・サービスで SalesInfo を取得し、すべてを 1 つにまとめてリクエストの送信側に Organization_Sales エンティティーを返します。
データ操作層に属している財務、企業、および営業データ・サービスは、データ操作層のメタデータを使用するように構成されています。このメタデータに含まれるのは、データベースのロケーション、スキーマ、接続、ルールなどに関する情報です。
※訳注: 上記段落に inormation という語が出てきますが、information の誤りのようなので、そのように訳してあります。
このアーキテクチャー案で最も重要な特徴の 1 つは、異なるレベルでサービスを再利用できることです。注目する点として、例えば Organization_Finance エンティティーを取得するには、エンタープライズ・セマンティック・サービスとエンタープライズ・データ・サービスを再利用することができます。導入する必要があるのは財務サービスだけです。
さらに、コンテキスト依存のメタデータは、ビルディング・ブロックからビジネス、営業、財務コンテキストなどの他のビジネス・レベルのサービスを構築することも可能にします。例えば、マーケティング部門による組織のデータについての見解は、組織のロケーションに営業情報、財務情報、マーケティング固有の情報の一部を加えた複合データであるという場合があります。この見解は、ビジネス、営業および財務コンテキストを使用するマーケティング・コンテキストを作成すれば実現できます。マーケティング・コンテキストに合わせたビジネス・レベルの情報サービスを構築する際には、この例でのすべてのサービスを再利用することができます。
図 10. この例をアーキテクチャー層に適用した場合
まとめ
この記事では、エンタープライズ情報にアクセスするためのアーキテクチャー・フレームワークについて説明しました。このアーキテクチャーは情報アクセス機能を (1) 物理データの操作、(2) ビジネス用語のセマンティクス/論理の定義、(3) エンタープライズ・レベルのビジネス・コンセプトの定義、のそれぞれを行う層に分離しています。いずれの層でも機能は SOA サービスとしてカプセル化されるため、広範にアクセス可能で柔軟かつ再利用可能なビルディング・ブロックからエンタープライズ・レベルの情報サービスを構成することができます。このアーキテクチャーは、ビジネス・データを個々のビジネス・アプリケーション内に隠すことなく、企業全体でビジネス・データにアクセスし、解釈し、構成できるというオンデマンド情報の構想を実現に近づけます。その例として、このアーキテクチャーを使用してビジネス・クライアント組織データに異なるレベル、そして異なるビジネス・コンテキストでアクセスするアプリケーションを紹介しました。
連載第 2 回では、さらなるビジネス・シナリオと事例をこのアーキテクチャーに当てはめて説明し、今回の記事で紹介した概念を説明します。また、IBM の製品とツールを使用した実装のロードマップについても説明します。
付録: 直接結合に勝る SOA アーキテクチャーの利点
このセクションでは、SOA の手法と直接結合の手法を、柔軟性、データ・ガバナンス、開発の容易性、そしてパフォーマンスとスケーラビリティーという決定要素の点で比較します。
柔軟性: この場合に関係するのは、データ・モデルおよびデータ・ストアとの疎結合、そして再利用です。SOA の手法では、データをデータベースから取得するか、計算によって算出するかに関わらず、サービス自体にデータの取得方法がカプセル化されます。このような手法では、ソリューション・アーキテクトがデータ・アクセス・ロジックをビジネス・ロジックから分離しやすくなり、この記事で説明した情報サービスのアーキテクチャー層を使用した慎重な設計によって再利用を促進することができます。
直接結合の手法では、データベース・ビューを使用して実際のテーブル・フォーマットからの分離レベルを設定することはできますが、それでもアプリケーション・ロジックで SQL とアクセス･プロトコルの詳細をコードにしなければならないことに変わりはありません。データ・アクセス・ロジックはアプリケーション・ロジックと織り交ぜられているため、データ・アクセス・ロジックを記録するのが難しいだけでなく、再利用するのも、変更するのも困難です。
データ・ガバナンス: SOA の手法では、サービス・イネーブルメントのためのミドルウェアがサービスへのアクセスを監査して制御するための制御ポイントおよび組み込み機能を提供します。一方、直接結合の手法の場合、データ・アクセス・ロジックがアプリケーション・ロジックと織り交ぜられているため、データ・アクセス・ロジックの再利用、記録、変更は容易ではありません。
開発の容易性: この場合に関係するのは、コンサーン (関心事) の分離、ツールのサポート、そしてスキル要件です。SOA の手法では、アプリケーション開発者がデータ管理の詳細を考慮する必要はありません。SOA の手法は一般に、開発者にとって選択したデータを公開する情報サービスを生成するための高度なツールとなります。直接結合の手法ではツールのサポートが一切ないので、アプリケーション開発者はデータ管理の詳細を直接扱わなければなりません。この場合、開発者には実装に固有のデータ管理スキルが求められます。
パフォーマンスとスケーラビリティー: この場合に関係するのはデータ転送量です。サービス指向はデータ転送を少なくするストアード・プロシージャーの使用を奨励すると同時に、さまざまな最適化 (ビューのキャッシング、索引付けなど) の使用も奨励します。SOA を実装するアプリケーションまたは情報サーバーは、一般にスケーラビリティーをサポートしますが、ハイパフォーマンス・アプリケーションの場合、パスが非常に長くなることによって応答時間が問題になる可能性があります。
直接結合の手法では通常、パスが非常に長くなることはありませんが、アプリケーション・ロジックが不完全だと大量のデータ転送で複数のトランザクションが呼び出される可能性があります。すべては、データベース・サーバーのスケーラビリティーおよび接続プールを管理するミドルウェア次第です。
参考文献
著者について  | 
| |
Dr. Bou-Ghannam は、IBM EBI (Enterprise Business Information) での SOA イネーブルメントのリーダーを務める Executive IT Architect (Senior Certified) です。再利用可能なビジネス、統合、情報サービスの構築、そして再利用可能な資産による SOA アプリケーションの構築を重点に、EBI での SOA 変換を推進しています。彼が興味を持つ分野は、SOA、SOA によるエンタープライズ情報のアクセスとディストリビューション、インテリジェントな自律エージェント、IT アーキテクチャーおよび方法論です。Dr. Bou-Ghannam は IBM Master Inventor で、彼の名前で複数の内部資料および外部資料が発表されています。連絡先は akram@us.ibm.com です。 |
| 
| |
Dr. Hoppe は IBM Enterprise Business Information Center of Excellence の Advisory Software Engineer で、IBM 顧客情報のオブジェクト指向分析を主導しています。Rational® の買収を機に、15 年の学界での経験、そしてソフトウェア開発のさまざまな分野での 15 年の業界経験を携えて IBM に入社しました。興味とする対象には、SOA の他、オブジェクト指向分析、設計と実装、ソフトウェア開発方法論と慣例、そして Web 技術があります。コンカレントおよび OO プログラミングに関する著作があり、コンファレンスでもこの話題について講演しています。連絡先は hoppea@us.ibm.com です。 |
記事の評価
| 
