以下の説明全体を通して、特に他の表示がない限り、同じ要素符号は、同じ要素を指すことが意図される。
本明細書において開示される発明は、全体がハードウェアの実施形態、全体がソフトウェアの実施形態、又は、ハードウェア要素とソフトウェア要素の両方を含む実施形態の形式を取ることができる。好ましい実施形態においては、本発明は、これらに限定されるものではないが、ファームウェア、常駐ソフトウェア、マイクロコード等を含むソフトウェアに実装される。
さらに、本発明は、コンピュータ又はいずれかの命令実行システムによって又はそれと関連させて使用されるプログラム・コードを提供する、コンピュータで使用可能の又はコンピュータで可読の媒体からアクセス可能なコンピュータ・プログラム製品の形を取ることができる。この記載の目的上、コンピュータで使用可能の又はコンピュータで可読の媒体は、命令実行システム、装置若しくはデバイスによって又はそれと関連させて使用されるプログラムを含み、格納し、通信し、伝搬し、又は転送することが可能ないずれかの装置とすることができる。
媒体は、電子システム、磁気システム、光学システム、電磁気システム、赤外線システム、若しくは半導体システム(又は装置若しくはデバイス)又は伝搬媒体とすることができる。コンピュータ可読媒体の例としては、半導体メモリ又は固体メモリ、磁気テープ、取り外し可能コンピュータ・ディスケット、ランダム・アクセス・メモリ(RAM)、読み取り専用メモリ(ROM)、磁気ハード・ディスク及び光ディスクを含む。光ディスクの現在の例としては、コンパクトディスク−読み取り専用メモリ(CD−ROM)、コンパクトディスク−読み取り/書き込み(CD−R/W)及びDVDが挙げられる。
プログラム・コードを格納し、又は実行し、或いはその両方を行うのに適したデータ処理システムは、システム・バスを通してメモリ要素に直接的に又は間接的に結合された少なくとも1つのプロセッサを含む。メモリ要素は、プログラム・コードの実際の実行中に用いられるローカル・メモリと、大容量記憶装置と、実行時に大容量記憶装置からコードを取得しなければならない回数を減らすために少なくともある程度のプログラム・コードの一時的な記憶場所を提供するキャッシュ・メモリとを含む。
入力/出力装置、すなわちI/O装置(これらに限定されるものではないが、キーボード、ディスプレイ、ポインティング装置等を含む)は、直接的に、又は介在するI/Oコントローラを通して、システムに結合することができる。
介在するプライベート・ネットワーク又は公衆ネットワークを通して、データ処理システムを他のデータ処理システム又は遠隔プリンタ若しくはストレージ装置に結合できるように、ネットワーク・アダプタをシステムに結合することもできる。モデム、ケーブル・モデム及びイーサネット・カードは、ごくわずかな、現時点で利用可能なタイプのネットワーク・アダプタである。
図1は、企業の様々なデータの統合を容易にするためのプラットフォーム100を表す。プラットフォームは、各々が複数の異なるコンピュータ・アプリケーション及びデータ・ソースを含むことができる複数のビジネス・プロセスを含む。プラットフォームは、上述のようなデータ・ソースとすることができるいくつかのデータ・ソース102を含むことができる。これらのデータ・ソースは、様々な物理位置からの様々なデータ・タイプを含むことができる。例えば、データ・ソースは、Sybase、Microsoft、Informix、Oracle、Inlomover、EMC、Trillium、First Logic、Siebel、PeopleSoft、IBM、Apache、又はNetscapeなどのプロバイダからのシステムを含むことができる。データ・ソース102は、IMS、DB2、ADABAS、VSAM、MD Series、UDB、XML、複合フラット・ファイル、又はFTPファイルなどのデータベース製品又は標準を用いるシステムを含むことができる。データ・ソース102は、Microsoft Outlook、Microsoft Word、Microsoft Excel、Microsoft Accessなどのアプリケーションによって作成又は使用されるファイル、並びに、ASCII、CSV、GIF、TIF、PNG、PDF等のような標準フォーマットのファイルを含むことができる。データ・ソース102は、様々な位置からもたらされるものとするか、又は集中的に配置することもできる。データ・ソース102から供給されるデータは、様々な形式のものとすることができ、互いに互換性のあるもの又は互換性のないものとすることができる異なるフォーマットを有する。
データ・ターゲットは、本明細書の後半で説明される。一般に、これらのデータ・ターゲットは、上述のデータ・ソース102のいずれかとすることができる。名称のこうした違いは、典型的には、データ統合プロセスにおいてデータ・システムがデータを提供するのか、又はデータを受け取るのかを示す。しかしながら、従来のデータ統合システムにおいてはデータ・ソースがデータを受け取り、データ・ターゲットがデータを提供することができるため、こうした区別は、(特に他の記載がない限り)データ・ソースとデータ・ターゲットとの間の能力に関して違いを与えることを意図するものではないことを理解すべきである。
図1に示されたプラットフォームはまた、データ統合システム104を含む。データ統合システムは、例えば、データ統合システム104が受信するクエリ又は検索コマンドの結果として、データ・ソース102からのデータの収集を容易なものとすることができる。データ統合システム104は、コマンドを1つ又は複数のデータ・ソース102に送信して、データ・ソース102がデータをデータ統合システム104に与えるようにすることができる。受信されたデータは、様々なメタデータを含む多数のフォーマットで存在する可能性があるため、データ統合システムは、受け取ったデータを、後で統合処理のために結合できるように再構成することができる。データ統合システム104によって実行できる機能は、より詳細に後述される。
プラットフォーム100はまた、幾つかの検索システム108を含む。検索システム108は、データ統合システム104から送信されたデータをさらに操作するのに用いられるデータベース又は処理プラットフォームを含むことができる。例えば、データ統合システム104は、データ・ソース102から受け取ったデータをクレンジングし、結合し、変形し、又は他の方法で操作して、検索システム108が処理されたデータを用いてビジネスに有用なレポート110を生成できるようにすることができる。レポート110は、データの関連を報告し、複雑なクエリに回答し、単純なクエリに回答し、或いはビジネス又はユーザにとって有用な他のレポートを作成するために用いることができ、生データ、テーブル、チャート、グラフ、及び検索システム108からのデータの他のいずれかの表現を含むことができる。
プラットフォーム100はまた、データベース又はデータベース管理システム112を含むことができる。データベース112は、情報を一時的に、仮に保存するために、又は永続的若しくは長期にわたって格納するために用いることができる。例えば、データ統合システム104は、データを1つ又は複数のデータ・ソース102から収集し、データを互いに互換性のある形式又は互いに結合することができる形式に変形することができる。データが変形されると、データ統合システム104は、後の検索のために、データを分解された形式、結合された形式、又は他の形式でデータベース112に格納することができる。
図2は、企業の複数のエンティティ及びビジネス・プロセス間のデータ統合を示す概略図である。示された実施形態においては、データ統合システム104は、ユーザ・インターフェース・システム202とデータ・ソース102との間の情報の流れを容易にする。データ統合システム104は、1つ又は複数のデータ・ソース102に存在するデータの抽出と場合によっては変形とを必要とするクエリを、インターフェース・システム202から受信することができる。インターフェース・システム202は、ラップトップ・コンピュータ若しくはデスクトップ・コンピュータ、携帯電話、携帯情報端末(「PDA」)、ネットワーク・プラットフォーム、及びそれに取り付けられた装置上で動作するウェブ・ブラウザといった、データ統合システム104と通信するためのいずれかの装置又はプログラム、又は、データ統合システム104とインターフェース接続される他のいずれかの装置又はシステムを含むことができる。
例えば、ユーザは、PDAを操作して、WiFi又はワイヤレス・アクセス・プロトコル/ワイヤレス・マークアップ言語(WAP/WML)インターフェースを介してデータ統合システム104に情報を要求することができる。データ統合システム104は、その要求を受信し、何らかの要求クエリを生成して、ウェブサイト又はFTPファイル・サイト等の他のデータ・ソース102からの情報にアクセスすることができる。データ・ソース102からのデータは、抽出され、要求するインターフェース・システム202(この例におけるPDA)と互換性のあるフォーマットに変形され、次いで、ユーザが見て操作するためのインターフェース・システム202に送信することができる。別の実施形態においては、データは、データ・ソースから予め抽出され、データ統合システム104によって使用されるデータ・ウェアハウス又は他のデータ機器とすることができる別個のデータベース112に格納することができる。データは、変形された状態で又はその元の状態でデータベース112に格納することができる。例えば、データは、別の変形プロセスにおいて多数のデータ・ソース102からのデータを結合することができるように、変形された状態で格納することができる。例えば、PDAからのクエリをデータ統合システム104に送信することができ、データ統合システム104は、データベース112から情報を抽出することができる。抽出に続いて、データ統合システム104は、そのデータを、PDAに送信する前にPDAと互換性のある結合フォーマットに変換することができる。
図3は、企業の複数のデータ・ソース102についてのデータ統合を提供するためのアーキテクチャを示す概略図である。データ統合システム104の実施形態は、場合によっては他の処理のなかでも、データ・ソースからのデータの抽出と、ソース・データについての列の値及びテーブル構造の分析とを実行するデータ発見ステージ302を含むことができる。データ発見ステージ302はまた、データ・ターゲットについてのテーブル構造、関係性及びキーに関する推奨を生成することができる。より高度なプロファイル作成機能及び監査機能は、日付範囲の検証、計算の精度、IF−THEN評価の精度等を含むことができる。データ発見ステージ302は、ソース・データにおける冗長な依存及び他の異常を排除すること等によって、データを正常化することができる。データ発見ステージ302は、さらなる分析のためにデータ・ソース102内の例外まで掘り下げるか又はメインフレーム・データの直接プロファイル作成を可能にする等の、付加的な機能を提供することができる。データ発見ステージ302の商業的な実施形態の限定する意味ではない例は、AscentialのProfileStage製品において見ることができる。
データ統合システム104はまた、後で変形されることになる品質データを生成するために、データを準備し、標準化し、適合させ、又は他の方法で操作する、データ準備ステージ304を含むことができる。データ準備ステージ304は、データ内の不整合を調整すること、又は(1対1の照合、1対多数の照合及び重複排除を含む)正確な照合を行うことといった、一般的なデータ品質機能を実行することができる。データ準備ステージ304はまた、特定のデータ拡張機能を提供することもできる。例えば、データ準備ステージ304は、国際間通信を改善させるために、住所が多国間の郵便基準に適合することを保証することができる。データ準備ステージ304は、空間的情報管理のために位置データを多国間ジオコーディング基準に適合させることができる。データ準備ステージは、住所情報が、Government Certified U.S. Address Correctionの下でU.S. Postal Service郵便料金割引を受ける資格があるものであることを保証するために、住所を変更又は追加することができる。同様の分析及びデータ改訂を、正しく住所が書かれた郵便について割引するカナダ及びオーストラリアの郵便システムに導入することができる。データ準備ステージ304の商業的な実施形態についての限定する意味ではない例は、AscentialのQualityStage製品の中に見ることができる。
データ統合システムはまた、データを変形し、データの質を高め、変形されたデータを配信するために、データ変形ステージ308を含むことができる。データ変形ステージ308は、データの再編成及び再フォーマットのような移行サービスを実行し、システム・ユーザのビジネス規則及びアルゴリズムに基づいて計算を実行することができる。データ変形ステージ308はまた、特定の分析コンテクストにおけるデータのより高度な調整処理のために、ターゲット・データをデータマート又はキューブとして知られているサブセットに編成することもできる。データ変形ステージ308は、データ統合システム104によって使用される種々のデータ・ソース及びデータ・ターゲットの種々のソフトウェア・アーキテクチャ及びハードウェア・アーキテクチャの橋渡しをする、ブリッジ、トランスレータ、又は他のインターフェース(以下に一般的に説明される)を利用することができる。データ変形ステージ308は、プラットフォーム100全体にわたるデータ統合ジョブを設計するために、グラフィカル・ユーザ・インターフェース、コマンド・ライン・インターフェース、又はこれらの何らかの組み合わせを含むことができる。データ変形ステージ308の商業的な実施形態についての限定する意味ではない例は、AscentialのDataStage製品の中に見ることができる。
データ統合システム104の段階302、304、308は、システム104の性能を最適化するために、並列実行システム310を連続的に又は組み合わせて用いて実行することができる。
データ統合システム104はまた、データ・ソース102と関連するメタデータを管理するためのメタデータ管理システム312を含むことができる。一般に、メタデータ管理システム312は、データ統合環境におけるツールの全てにわたって、メタデータの交換、統合、管理及び分析を提供することができる。例えば、メタデータ管理システム312は、AscentialのODBC MetaBroker、CA ERwin、Ascential PrifileStage、Ascential DataStage、Ascential QualityStage、IBM DB2 Cube Views及びCognos Impromptuのような、異なるソース内のデータの汎用アクセス可能な共通のビューを提供することができる。メタデータ管理システム312はまた、データ構造への変更についてのデータ系統及び影響分析のための分析ツールを提供することができる。メタデータ管理システム312はさらに、データ統合システム104内のデータについてのデータ定義、アルゴリズム及びビジネス・コンテクストのビジネス・データ用語集を準備するために用いることができ、この用語集は、企業全体で使用するために公開することができる。メタデータ管理システム312の商業的な実施形態についての限定する意味ではない例は、AscentialのMegaStage製品において見ることができる。
図4は、データ統合ジョブについてのデータ発見ステージ302を実行するファシリティの詳細を示す概略図である。この実施形態において、データ発見ステージ302は、データベース402内のデータのコンテンツ及び構造を判定するために、上述のデータ・ソース102のいずれかとすることができるデータベース402にクエリする。データベース402は、結果をデータ発見ステージ302に提供し、該データ発見ステージ302が、続いて抽出データをデータ統合システム104の他の部分に通信することを容易にする。1つの実施形態において、データ発見ステージ302は、多くのデータ・ソース102にクエリすることができ、その結果、データ統合システム104は、データをクレンジングし、データを中央データベース又はリポジトリ情報マネージャに整理統合することができる。
図5は、データ統合プロセス500についての発見ステップを達成するためのステップを示すフロー図である。特定のデータ統合プロセス500が以下に説明されるが、ここで用いられるデータ統合プロセス500は、データ・ソース102及びデータ・ターゲット、データベース112、データ統合システム104、並びに、本明細書において説明される他のコンポーネントを用いる任意のプロセスを指すことができる。1つの実施形態において、例示的な発見ステップのプロセス・ステップは、上述のデータ発見ステージ302等の発見ファシリティがデータを1つ又は複数のデータ・ソース102から抽出するコマンドを受け取る第1のステップ502を含むことができる。抽出コマンドの受け取りに続いて、発見ファシリティは、ステップ504に示すように、抽出されることになるデータが存在する適切なデータ・ソース102を識別することができる。データ・ソース102は、コマンドにおいて識別されてもされなくてもよい。データ・ソース102が識別される場合には、発見ファシリティは、識別されたデータ・ソース102にクエリすることができる。データ・ソース102がコマンドにおいて識別されない場合には、発見ファシリティは、データ抽出コマンドから要求されたデータ・タイプから又はコマンド内の情報の別の部分から、或いは要求されている他のデータへの関連付けを決定した後で、データ・ソース102を決定することができる。例えば、クエリは、顧客の住所についてのものとすることができ、顧客の住所データの第1の部分が第1のデータ・ソース102に存在し、第2の部分が第2のデータ・ソース102に存在することがある。発見ファシリティは、抽出コマンドを処理し、コマンド内のさらなる命令なしにその抽出活動を2つのデータ・ソース102に指図することができる。データ・ソース102が識別されると、データ・ファシリティが、ステップ508に示すように、データを抽出するためのプロセスを実行することができる。データが抽出されると、発見ファシリティは、データをデータ統合システムの別の部分に通信することを容易にすることができる。
図6は、データ統合プロセス500についての、上述のデータ準備ステージ304とすることができるクレンジング・ファシリティを示す概略図である。一般に、幾つかのデータ・ソース102から得られるデータは、誤りを有する場合があり、これらの誤りが、チェックされず、訂正されないままの場合には、データ統合システム104によって最終的に生成されるデータ解釈においてエラーを引き起こす可能性がある。会社の合併、買収、再編成、又はデータ・ソース102の他の整理統合は、新しいデータ・ラベル、頭字語、メトリックス、計算方法等を伴うことによって、データの品質問題をさらに複雑にすることがある。図6に示すように、クレンジング・ファシリティは、データ602をデータ・ソース102から受け取ることができる。データ602は、1つ又は複数のデータ・ソース102から得ることができ、不一致又は誤りを有する場合がある。クレンジング・ファシリティは、データ602の品質を選別し、訂正し、クリーニングし、又はその他に拡張する、自動、半自動、又は手動ファシリティを提供することができる。データ602がクレンジング・ファシリティを通過すると、それをデータ統合システム104の別の部分に通信することができる。
図7は、データ統合プロセス500におけるクレンジング・プロセス700のためのステップを示すフロー図である。実施形態において、クレンジング・プロセスは、データを1つ又は複数のデータ・ソース102(例えば、発見ファシリティを介して)から受け取るステップ702を含むことができる。クレンジング・プロセス700は、データをクレンジングする1つ又は複数の方法を含むことができる。例えば、このプロセスは、データを自動的にクリーニングするステップ704を含むことができる。このプロセスは、データを半自動的にクリーニングするステップ708を含むことができる。このプロセスは、データを手動でクリーニングするステップ710を含むことができる。データ若しくはデータの一部を自動的に訂正する、すなわちクリーニングするステップ704は、自動スペル・チェック及び訂正、比較データ、データの比較適時性、データの状態、又はデータ品質及び一致を高めるための他の技術等の、幾つかの技術の適用を含むことができる。半自動的にデータをクレンジングするステップ708は、ユーザがプロセス・ステップの幾つかと相互作用し、このシステムが割り当てられたクレンジング・タスクを自動的に実行するファシリティを含むことができる。半自動システムは、データをクレンジングするプロセス700を容易にするためにユーザがグラフィカル・ユーザ・インターフェースと相互作用する、グラフィカル・ユーザ・インターフェースのプロセス・ステップ712を含むことができる。プロセス700は、データを手動で訂正するステップ710をさらに含むことができる。このステップは、データの手動訂正、整理統合及び/又はクレンジングを容易にするために、ユーザ・インターフェースの使用をさらに含むことができる。クレンジング・プロセス700からのクレンジングされたデータは、データ変形ステージ308等の、データ統合システム104内の別のファシリティに伝送することができる。
図8は、データ統合プロセス500についての、上述のデータ変形ステージ308とすることができる変形ファシリティを示す概略図である。変形ファシリティは、クレンジングされたデータ802をクレンジング・ファシリティから受け取り、変形プロセスを実行し、データの質を高め、データをデータ統合システム104の内部の又はデータ統合システム104の外部の別のプロセスへ供給することができ、そこで、統合されたデータを閲覧し、使用し、さらに変形し、又は他の方法で操作することができる。例えば、ユーザは、データ・マイニングによってデータを調査することもできるし、或いは、ユーザ又はビジネスに有用なレポートを生成することもできる。
図9は、データ統合プロセス500の一部としてのデータ変形ステップを示すフロー図である。変形プロセス900は、ステップ902に示すように、クレンジングされたデータ(例えば、上述のデータ準備ステージ308から)を受け取ることを含むことができる。ステップ904に示すように、プロセス900は、所望の変形タイプの決定を下すことができる。変形プロセスを決定するステップ904に続いて、ステップ908に示すように、変形プロセスを実行することができる。次に、ステップ910に示すように、変形されたデータを別のファシリティに伝送することができる。
一般に、グラフィカル・ユーザ・インターフェースを用いて、データ統合システム104を制御し、特定のエンタープライズ・データに適用することができる。インターフェースは、データ・ソース、データ・ターゲット、及びデータに対して働く段階又はプロセスをモデル化するための視覚ツール、並びに、これらのデータ・エンティティ間の関係を確立して、所望のデータ統合タスクをモデル化するためのツールを含むことができる。グラフィカル・ユーザ・インターフェースは、以下により詳細に説明される。以下では、このような関係においてユーザ・インターフェースをどのように使用できるかを示すために一般的な例を提供する。
図10は、グラフィカル・ユーザ・インターフェース1018を用いてモデル化されるモーゲージ・データのための変形プロセス1000の例を示す。この例においては、ビジネス・エンタープライズは、特定のモーゲージに関するレポートを生成することを望む。モーゲージ残高情報は、上述のデータ・ソース102の1つとすることができるモーゲージ・データベースに常駐することができ、プロパティ情報のアドレスのような個人情報は、また、上述のデータ・ソース102の1つとすることができるプロパティ・データベースに常駐することができる。グラフィカル・ユーザ・インターフェース1018を設けて、変形プロセスを組織化することができる。例えば、ユーザは、モーゲージ・データベース1002のグラフィカル表示及びプロパティ・データベース1012のグラフィカル表示を選択し、例えば、通常のドラッグ・アンド・ドロップ操作を用いて、これらの表示1002、1012をインターフェース1018内の所定の位置にくるように操作することができる。次に、ユーザは、行変形プロセス1004のグラフィカル表示を選択して、組み合わせのための行を作成することができる。ユーザは、矢印として図10内で全体的に示されたプロセス・フローの方向をドラッグ・アンド・ドロップすることができ、その結果、データベースからのデータが、行変形プロセスに流入する。このモデルにおいては、ユーザは、如何なる不一致ファイルをも除去し、それらをストレージ・ファシリティに送るように選択することができる。これを達成するために、ユーザは、ストレージ・ファシリティ6114のグラフィカル表示をインターフェース1018内に配置することができる。ユーザが残りの一致ファイルをさらに処理することを望む場合には、ユーザは、例えば、2つのデータベースからのデータを組み合わせる別の変形及び集約プロセス1008のグラフィカル表示を付加することができる。最終的に、ユーザは、データ・ウェアハウス1010のグラフィカル表示を付加することによって、集約データをストレージ・ファシリティに送ることに決めることができる。ユーザがグラフィカル・ユーザ・インターフェースを用いてこのプロセスを設定すると、ユーザは、変形プロセスを実行することができる。
図11および図12は、データ統合プロセス500をビジネス・エンタープライズの他のプロセスに接続する複数の接続ファシリティを示す概略図である。実施形態において、データ統合システム104は、上述のデータ・ソース102の1つとすることができる統合ストレージ・ファシリティ1102と関連付けることができる。統合ストレージ・ファシリティ1102は、幾つかの他のデータ・ソース102から抽出され、データ統合システム104を介して処理されたデータを含むことができる。統合データは、1つ又は複数のコンピュータ・プラットフォーム1108A及び1108Bがデータを統合データ・ストレージ・ファシリティ1102から検索することを可能にする形式で格納することができる。コンピュータ・プラットフォーム1108A及び1108Bは、翻訳エンジン1104A及び1104Bを介してデータを統合データ・ファシリティ1102から要求することができる。例えば、コンピュータ・プラットフォーム1108A及び1108Bの各々は、別々の翻訳エンジン1104A及び1104Bと関連付けることができる。翻訳エンジン1104A及び1104Bは、統合されたデータをストレージ・ファシリティ1102から関連するコンピュータ・プラットフォーム1108A及び1108Bと互換性がある形式に翻訳するように適合させることができる。実施形態において、翻訳エンジン1104A及び1104Bは、データ統合システム104と関連付けることもできる。こうした関連付けを用いて、要求された情報によって翻訳エンジン1104A及び1104Bを更新することができる。このプロセスは、以下にさらに定義されることになるメタデータ処理を含むこともできる。
図11に全体的に示す、データ統合のためのハブ・モデルは、異なるコンピュータ・プラットフォーム1108A及び1108B及び他のデータ・ソース102に接続するための1つのモデルであるが、図12を参照して説明されるブリッジ・モデル等の他のモデルを用いることもできる。データ・ソース102への接続が本明細書において記載される場合には、文脈によって特別な又は他の表示がない限り、これらのモデルのいずれか又は他のモデルを用いることができることを認識すべきである。
図12は、ブリッジ・モデルを用いる複数の接続ファシリティを示す。このシステムにおいては、在庫システム、顧客関係システム及び会計システム等の、複数のデータ・ソース102は、複数のブリッジ1120又は接続ファシリティを介してエンタープライズ・コンピュータ・システム1300のデータ統合システム104に接続することができる。各々のブリッジ1120は、メタデータ・モデルを外部データ・ソース102に提供し、データ統合システム104とデータ・ソース102との間の情報の双方向転送を可能にするベンダ固有の翻訳エンジンとすることができる。エンタープライズ統合ベンダは、自社のデータ・ソース102用の独自のフォーマットを有することができ、それにより、異なる外部モデル毎に異なるブリッジ1120を要求することができる。各々のブリッジ1120は、接続ファシリティをデータ・ソース102内のデータの全て又は幾つかに提供することができ、別々のマップ又はモデルは、各々のデータ・ソース102へ及びそれからの接続について保持することができる。さらに、各々のブリッジ1120は、データ・ソース102間のデータの保全性を維持するために、エラー・チェック、調整又は他のサービスを提供することができる。データ・ソース102がこのように相互接続された状態で、データは、システム間で共有するか又は調整することができ、種々のデータ統合タスクは、あたかもデータ・ソース102が単一のデータ・ソース102又はウェアハウスを形成したかのように、データ・ソース102内のデータについて実行することができる。
図13は、データ統合プロセス500をビジネス・エンタープライズの他のプロセスに接続するためのステップを示すフロー図である。実施形態において、接続プロセスは、そのステップの間、データ統合システム104が処理データを中央ストレージ・ファシリティに格納するステップ1202を含むことができる。データ統合システム104はまた、ステップ1204において、1つ又は複数の翻訳エンジンを更新することもできる。図13の図示は、これらのプロセスが直列的に行われることを示すが、それらはまた、並列的に行うこともできるし、或いは、これらの何らかの組み合わせとすることもできる。このプロセスは、コンピュータ・プラットフォームがデータ要求を生成し、該データ要求が関連する翻訳エンジンに送られるステップ1208を含むことができる。ステップ1210は、データをストレージ・ファシリティから抽出する翻訳エンジンを含むことができる。翻訳エンジンはまた、ステップ1212において、データをコンピュータ・プラットフォームと互換性がある形式に翻訳することもでき、次いで、該データは、ステップ1214において、コンピュータ・プラットフォームに通信することができる。
図14は、データ統合システム104を含むエンタープライズ・コンピュータ・システム1300を示す。エンタープライズ・コンピュータ・システム1300は、コンピュータ、メインフレーム、携帯デバイス、データ・ソース、及び1つ又は複数のローカル・エリア・ネットワークを通じてローカル接続され、及び/又は例えば、インターネットを通じた仮想プライベート・ネットワークを用いて、1つ又は複数の広域エリア・ネットワーク又は公衆ネットワークを通じてリモート接続された他のデバイスの任意の組み合わせを含むことができる。エンタープライズ・コンピュータ・システム1300内のデバイスを単一のエンタープライズに相互接続して、データ、リソース、通信及び情報技術管理を共有することができる。一般的には、エンタープライズ・コンピュータ・システム1300内のリソースは、企業、協会、又は政府機関省庁、或いは大学のような一般的なエンティティによって使用される。しかしながら、特定のビジネス・モデルにおいては、エンタープライズ・コンピュータ・システム1300のリソースは、アプリケーション・サービス・プロバイダがオンデマンドのアクセスをリモート実行プリケーションに与える場合等、多数の異なるエンティティによって所有され(又はリースされ)、使用されてもよい。
エンタープライズ・コンピュータ・システム1300は、それぞれの翻訳エンジン1308(ブリッジ・ベースのシステムにおいては、上述のブリッジ1120とすることができる)を介して、ここではリポジトリ情報マネージャ(RIM)1304(以下では「ハブ」とも呼ばれる)と呼ばれる共通のデータ構造にアクセスする、複数のツール1302を含むことができる。RIM1304は、上述のデータ・ソース102のいずれかを含むことができる。3つの翻訳エンジン1308及び3つのツール1302が示されているが、3つより少ない及び3つより大幅に多い数を含む、任意の数の翻訳エンジン1308及びツール1302をエンタープライズ・コンピュータ・システム1300内で用いることができることを認識する。ツール1302は、一般に、例えば、様々なタイプのデータベース管理システム、及び、RIM1304に格納された共有データにアクセスする他のアプリケーション・プログラムを含む。ツール1302、RIM1304及び翻訳エンジン1308は、単一のコンピュータ・システム上で処理し、保持することもできるし、或いは、それらは、例えば、データ・アクセス要求、翻訳されたデータのアクセス要求及び異なるコンポーネント1302、1304、1308間の応答を転送するネットワーク(図示せず)によって相互接続することができる多数のコンピュータ・システム上で処理し、保持することもできる。
ツール1302は、それらが実行している間に、データ・アクセス動作、すなわち、RIM1304からのデータの検索又はそれへのデータの格納を開始するデータ・アクセス要求を生成することができる。データは、後述されることになるアトミック・データ・モデル及びフォーマットでRIM1304に格納することができる。一般的には、ツール1302は、後述されるように、多種多様な特性データ・モデル及びフォーマットでRIM1304に格納されたデータを表示することになり、データ・アクセス要求を受け取ったときに、各々の翻訳エンジン1308は、必要に応じて、RIM1304のそれぞれのツールの特性モデル及びフォーマットとアトミック・モデル・フォーマットとの間でデータを翻訳することになる。例えば、データ項目がRIM1304から検索されることになる検索タイプのアクセス動作中に、翻訳エンジン1308は、アクセス要求に応答して検索されることになるデータ項目を共同して備えるRIM1304において1つ又は複数のアトミック・データ項目を識別することになり、RIM1304がアトミック・データ項目を翻訳エンジン1308の1つに提供することを可能にする。今度は、その翻訳エンジン1308が、RIM1304から受け取るアトミック・データ項目を、ツールの特性モデル及びフォーマット、すなわちデータの「ビュー」によって要求される1つ又は複数のデータ項目の中に集約させ、集約されたデータ項目を、アクセス要求を発したツール1302に提供することになる。RIM1304内のデータが更新されることになるデータ格納中に、翻訳エンジン1308は、ツール1302の1つについて特性モデル及びフォーマットに格納されることになるデータを受け取ることができる。翻訳エンジン1308は、RIM1304のためにデータをアトミック・モデル及びフォーマットに翻訳し、翻訳されたデータを格納のためにRIM1304に提供することができる。データ・ストレージ・アクセス要求がデータを更新することを可能にする場合には、RIM1304は、現在のデータの代わりに翻訳エンジン1308から新しく提供されたデータを使うことができる。一方、データ・ストレージ・アクセス要求が新しいデータを提示する場合には、RIM1308は、翻訳エンジン1308によって提供されるアトミック・フォーマットで、データをRIM1308の現在のデータに付加することができる。
エンタープライズ・コンピュータ・システム1300は、新しいツール1302が該システム1300に付加される際に、RIM1304及び翻訳エンジン1308のアトミック・フォーマットを保持し、更新するデータ統合システム104をさらに含む。データ統合システム104によって実行される特定の動作を自動的に実行するか又は手動で制御することができることが認識される。簡潔に言えば、システム1300が最初に確立されるとき、又はそのデータ・モデル及びフォーマットが現在のデータ・モデル及びフォーマットと異なるシステム1300に1つ又は複数のツール1302が付加されるときに、データ統合システム104は、如何なる違いをも判定し、RIM1304内のデータのデータ・モデル及びフォーマットを修正して、新しいツール1302のデータ・モデル及びフォーマットに対応することができる。そうした動作において、データ統合システム104は、システム1300に現在存在するいずれかのツール1302及び付加されることになる新しいツール1302のデータ・モデルに共通のアトミック・データ・モデルを決定し、RIM1304のデータ・モデルを新しいアトミック・データ・モデルに更新することを可能にする。さらに、データ統合システム104は、RIM1304の更新されたアトミック・データ・モデルに基づいて現在システム1300にある如何なるツール1302とも関連する翻訳エンジン1308を更新することができ、新しいツール1302のための翻訳エンジン1308を生成することもできる。したがって、データ統合システム104は、現在該システムにあるあらゆるツール1302、並びに、付加されることになるツール1302を含む、全てのツール1302の翻訳エンジン1308がRIM1304のアトミック・データ・モデル及びフォーマットに準拠することを保証する。
さらに進める前に、種々のツール1302に有用となり得る特性データ・モデル及びフォーマット、並びに、RIM1304に有用なアトミック・データ・モデル及びフォーマットを示す特定の例を提供することが助けになるであろう。ツール1302についての特定の特性データ・モデル及びフォーマットは、特定のエンタープライズ・コンピュータ・システム1300に存在する特定のツール1302に依存することになると認識される。さらに、RIM1304のための特定のアトミック・データ・モデル及びフォーマットは、ツール1302のために使用されるアトミック・データ・モデル及びフォーマットに依存し得るものであり、システム1300内のツール1302の全てについてのデータ・モデル及びフォーマットの最もきめ細かい要素の集約又は結合を示すことができると認識される。
図15は、飲用カップ又は液体を入れるための他の容器等の、カップについての設計のデータベースに関する例を提供する。このデータベースは、カップを設計し、製造するために使用することができる。このアプリケーションにおいては、ツール1302を用いて、設計図、寸法、外面処理、色、材料、柄(又はそれがないもの)、費用データ等のようなカップの設計要素を、RIM1304に付加することができる。ツール1302を用いて、RIM1304に格納されたカップの設計要素を修正し、RIM1304内の特定のカップの設計要素を再使用し、それを多数の異なるカップ設計と関連付けることもできる。RIM1304及び翻訳エンジン1308は、多数の異なるツール1302が要素についての共通スキーマ又はモデル及びフォーマット配列に関して一致をはかる必要なしにRIM1304に格納された要素を共有できる機構を提供することができる。
この例において、RIM1304は、後述されるようにデータ項目をエンティティ関係フォーマットに格納することができ、各々のエンティティはデータ項目であり、関係はデータ項目間の関係を反映する。このエンティティは、オブジェクトの形態であり、それは、オブジェクト指向環境のクラス及びサブクラスのメンバー又はインスタンスとすることができる。RIM1304のための他のモデル及びフォーマットを使用できることが認識される。
図15は、カップ設計のデータベースについての例示的なメタデータ構造を示す。クラス構造は、メイン・クラス1402、該メイン・クラス1402から依存する容器及び柄についての2つのサブクラス1404、及びその両方が容器サブクラス1404から依存する側部及び基部についての2つの下位レベルのサブクラス1408を含むことができる。エンティティ関係フォーマットにおいて「エンティティ」と呼ばれる、クラス1402内の各々のデータ項目は、在庫内のカップの特定のカップ又は特定のカップのタイプを表すことができ、それはカップの種々の特性を定める関連する属性を有し、各々の属性は、その属性について特定の属性識別子及びデータ値によって識別される。
エンティティ関係フォーマットにおける「エンティティ」でもある、柄及び容器サブクラス1404内の各々のデータ項目は、在庫内の特定のカップの容器及び柄の特性、又は特定のカップのタイプを表すことができる。より具体的には、容器サブクラス1404内の各々のデータ項目は、色、側壁特性、基部特性等のような、カップ・クラス1402内のデータ項目によって表されるカップの容器特性を表すことができる。さらに、柄サブクラス1404内の各々のデータ項目は、曲率、手触り、色、位置等のような、カップ・クラス1402内のデータ項目によって表されるカップの柄特性を表すことができる。さらに、サブクラス1404間でデータ項目をリンクする働きをする、柄サブクラス1404及び容器サブクラス1404内のデータ項目間には1つ又は複数の関係が存在し得ることが認識される。
例えば、容器が柄を有するかどうかを示す関係が存在し得る。さらに、又はその代わりに、容器がいくつの柄を有するかを示す関係が存在し得る。さらに、容器上の柄の位置を指定する位置関係が存在し得る。数及び位置の関係は、第1の関係の特性(容器が柄を有する)として、又は別個の関係としてみなすことができる。2つの下位レベルのサブクラス1408は、容器のサブクラス1404と関連付けられ、容器の種々の要素を表すことができる。図15に示される例においては、サブクラス1408は、側壁タイプのサブクラス1408及び基部タイプのサブクラス1408を含むことができ、その各々は、カップのクラス1402の要素を特徴付ける。容器及び柄等の、カップ及びカップの特性は、任意の所望レベルの詳細を用いてオブジェクト指向の方法で定義できることが認識される。
図15にはっきりと示されていないが、1つ又は複数の翻訳エンジン1308は、データの1つの表示を要求するツール1302と、データを異なるフォーマットで格納できるRIM1304との間の通信を調整することができることを認識すべきである。より一般的には、RIM1304に格納されたカップのデータを表示するため、図15に示されるツール1302の各々が、多少異なるか又は完全に異なる特性データ・モデル及びフォーマットを有し得る。すなわち、データ項目がカップである場合には、カップの特性は、該データ項目に関連したカップ設計についての属性及び属性値としてRIM1304に格納することができる。
検索アクセス要求において、ツール1302は、検索されることになるカップのクラス1402内のカップのデータ項目の識別をそれらの関連する翻訳エンジン1308に提供することができ、それに応じて、該要求において識別できる該データ項目の属性データの少なくとも幾つかを受け取ることを期待することになる。同様に、ストレージ・タイプのアクセス要求に応答して、こうしたツールは、更新されるか又は作成されることになるカップのデータ項目の識別及び更新されるか又は新しいデータ項目を作成する際に使用されることになる関連する属性情報をそれらの関連する翻訳エンジン1308に提供することになる。
他のツール1302は、容器及び柄についての属性を有するカップのメイン・クラス1402ではなく、サブクラス1404において容器及び柄のエンティティとして別個にカップを表示する特性データ・モデル及びフォーマットを有することができる。そうした表示においては、その各々がそれぞれの容器及び柄を記述する属性を有する、各々のカップに関連した2つのデータ項目、すなわち、「容器」及び「柄」が存在し得る。その場合には、各々のデータ項目は、各々が独立して検索可能かつ更新可能となり得るものであり、新しいデータ項目は、2つのクラスの各々について別個に作成することができる。こうした表示について、ツール1302は、検索タイプのアクセス要求において、検索されることになる容器又は柄の識別をそれらの関連する翻訳エンジン1308に提供することになり、それに応じて、データ項目の属性データを受け取ることを期待することになる。同様に、ストレージ・タイプのアクセス要求に応答して、こうしたツール1302は、更新されるか又は作成されることになる「容器」又は「柄」のデータ項目及び関連する属性データの識別をそれらの関連する翻訳エンジン1308に提供することになる。したがって、これらのツール1302は、容器及び柄のデータを別々に表示し、容器及び柄の属性データを別々に検索し、更新し、格納することができる。
RIM1304において同じアトミック・データ構造を使用する別の例として、ツール1302は、クラス1402−1408内の側壁、基部及び柄のエンティティとして別個にカップを表示する特性フォーマットを有することができる。こうした表示において、その各々がカップのそれぞれの側壁、基部及び柄を記述する属性を有する、各々のカップに関連した3つのデータ項目、すなわち、側壁、基部及び柄が存在し得る。その場合には、各々のデータ項目は、独立して作成し、検索し、又は更新することができる。こうした表示について、ツール1302は、そのデータ項目が動作させられることになる側壁、基部又は柄の識別をそれらの関連する翻訳エンジン1308に提供することができ、各々について別々に動作(作成、検索、格納等)を実行することができる。
上述のように、RIM1304は、カップのデータを「アトミック」データ・モデル及びフォーマットに格納することができる。すなわち、図15に示されるクラス構造を用いて、RIM1304は、集団的ツール1302によって用いられるクラス構造についての最も詳細なフォーマットを表すデータ構造のような整合性のあるデータ構造の中に、各々のクラス及びサブクラスに対応するデータ項目としてデータを格納することができる。
翻訳エンジン1308は、RIM1304内のアトミック・データ構造とツール1302によって使用されるデータ表示との間の関係に基づいて、各々のツール1302によって保持される表示と、RIM1304によって保持されるアトミック・データ構造との間で翻訳することができる。翻訳エンジン1308は、ツール1302の表示とRIM1304のデータ構造との間で翻訳するときに、多数の機能を実行することができる。例えば、クラス又はサブクラスを結合するか又は分離する、属性名又は識別子を翻訳する、属性値を生成するか又は除去する等である。データ項目を作成し、データ項目を検索し、データ項目を除去し、又はデータ項目を修正する等の、要求される翻訳は、多数のコンテクストにおいて行うことができる。新しいツール1302がデータ統合システム104に付加される際に、該システム104は、RIM1304内のデータ構造、並びに、新しいツール1302について要求できる翻訳エンジン1308を更新することができる。RIM1304内で使用される基礎データ構造が新しいツール1302に適応するように変更された場合、又は他の理由でデータ構造が再編成された場合には、既存の翻訳エンジン1308も更新される必要がある。
より一般的には、データ統合システム104が新しい要求又は既存の要求についての新しい考えに適合される際に、該システム104は、データについて新しいアトミック・モデルを作成するために、RIM1304についての基礎クラス構造を更新し、再生することができる。同時に、翻訳エンジン1308は、ツール1302をRIM1304の新しいデータ構造に再マッピングするために修正することができる。この後者の機能は、新しく構成されたデータ構造に特に関連するそうした翻訳エンジン1308のみに関係することができる一方で、他のものは、修正されることなく使用され続けることができる。データ統合システム104を使用するオペレータは、それぞれのツール1308によって使用されるデータ・モデル及びフォーマットとRIM1304によって使用されるデータ・モデル及びフォーマットとの間のマッピング関係を決定し、指定することができ、それぞれの翻訳エンジン1308を生成し、更新するために使用できるマッピング関係から規則データベースを保持することができる。
RIM1304を介する更新の正確な伝搬を保証するために、データ統合システム104は、各々のツール1302を、その関連するデータ項目が「マスター物理項目」と考えられることになるクラス、及びもしあれば他のデータ項目への特定の関係と関連付けることができる。例えば、データ統合システム104は、ツールのデータ・モデルのオブジェクトと最も意味的に同等に見える特定のクラスをマスター物理項目として選択することができる。もしあれば、マスター物理項目に関連する他のデータ項目は、グラフにおいて第2の物理項目と考えることができる。例えば、カップのクラスは、カップ設計全体に対して動作するツール1302についてのマスター物理項目を含むことができる。図15において「関係」と指定された矢印は、マスター物理項目と第2の物理項目との間の可能性のある関係を示す。更新動作を実行する際に、更新されることになるデータ項目と関連付けられる有向グラフは、適切な属性及び値が更新された状態で、マスター物理項目から横断することができる。有向グラフを横断する際に、グラフ・ノードとしてグラフ内の各々のデータ項目を適切に訪問し、更新できることを保証して、これによりデータ項目が更新されることを保証するために、通常のグラフ横断アルゴリズムを使用することができる。
上記の例は、オブジェクト指向プログラミング環境におけるメタデータ管理を一般に説明するものである。しかしながら、エンタープライズ・コンピュータ・システム1300内のデータと共に、様々なソフトウェア・パラダイムを有用に用いることができると認識される。例えば、図16を参照して説明されるアスペクト指向プログラミング・システムを、上述のエンタープライズ・コンピュータ・システム1300と共に有効に用いることができる。機能1410を有するツール1302の例が図面に示されている。各々の機能1410は、IDロギング1412及びメタデータ更新1414等の幾つかの外部サービスと相互作用するように書き込むことができる。一般的なオブジェクト指向環境においては、外部サービス1412−1418は、それらを呼び出す機能1410に応答するためにしばしば「クロスカット」されなくてはならない、すなわち、ツール1302の更新された機能1410の呼び出しに対応するように記録されなくてはならない。
例として、スケルトン・コードにおいては、ログイン及び検証を実行する機能1410についてのオブジェクト指向プログラミング(”OOP”)コードは次のようになり得る。
DataValidation(...)
//Login user code
//Validate access code
//Lock data objects against another functions use code
//=Data Validation Code=
//Log out user code
//Unlock data object code
//Update metadata with latest access code
//More operations the same as above
上記の例においては、機能1410のコードが、外部サービス1412−1414とのアクションを呼び出す。いわゆるクロスカットは、アプリケーション・ライタが外部サービス1412−1414を記録する必要があるときにはいつも行われ、コードの適切な相互作用のために要求される。これは、再設計の複雑さを著しく増加させ、時間及びエラーの可能性を悪化させる可能性がある。
アスペクト指向プログラミング(AOP)においては、機能1410についての結果として得られるコードは、OOPコード(実際には、C++等のOOPプラットフォームを用いてAOPをデプロイすることができる)と同様なものとすることができる。しかしながら、AOP環境においては、アプリケーション・ライタは、機能1410についての機能固有の論理のみをコード化し、論理がどのように外部サービス1412−1418にアクセスするかを定義するためにウィーバ規則のセットを使用することになる。ウィーバ規則は、機能1410がいつ、どのように他のサービスと相互作用するかを記述し、それによりツール1302のコア・コードと外部サービス1412−1418とを共に織り込む。機能1410についてのコードがコンパイルされるときに、ウィーバは、コア・コードと、最終的な機能1410を作成する適切な個々のサービスを呼び出すためのサポート・コードとを結合することになる。スケルトン・コードにおいては、機能1410についての一般的なAOPコードは、次のようになり得る。
DataValidation(...)
//Data Validation Logic
クロスカットするコードは、機能1410についてのコードから除去される。次に、アプリケーション・ライタは、AOPコードに適用されるウィーバ規則を作成することができる。スケルトン・コードにおいて、機能1410についてのウィーバ規則は、
1)各々の動作開始時のIDログ
2)各々の動作終了時のIDログ・アウト
3)最終動作後の更新メタデータ
を含むことができる。
機能1410についての結果として得られるAOPスケルトン・コードは、次のようになり得る。
DataValidation(...)
−ID Logger.in
//Data Validation Logic
−ID Logger.out
−Metadata.update
アプリケーション・ライタによって作成される簡易コードは、要求されたクロスカット・コードについての問題なしに、ツール1302を作成することに完全に集中させることを可能にする。同様に、サービス1412−1418の1つへの変更は、ツール1302の機能1410への何の変更も要求しない場合がある。コードをこのように構造化することは、ツール1302を作成するか又は修正するときに、コーディング・エラーの可能性を大幅に減少させ、外部サービス1412−1418についてのサービス更新を単純化することができる。
翻訳エンジン1308がエンタープライズ・コンピュータ・システム1300におけるデータ及びメタデータを処理する可能性のある唯一の方法であることも認識される。翻訳エンジン1308は、上述のように、ブリッジ1120を含むか又はそれから構成することもできるし、或いは、翻訳エンジン1308を介して渡されるデータが翻訳エンジン1308によって接続される両方のコンピュータ・システムと互換性がある場合に、最小共通係数法を用いることもできる。さらにもう一つの実施形態において、翻訳は、基準に準拠する全てのコンピュータ・プラットフォームが標準化ファシリティを介してデータを通信し、抽出することができるように標準化ファシリティについて実行することができる。データを処理する他の多くの方法及び考えられるその関連するメタデータが存在し、本明細書において説明されるエンタープライズ・コンピュータ・システム1300と共に有効に用いることができる。
こうした背景について、ここでは、データ統合システム104並びにツール1302及び翻訳エンジン1304によって実行される特定の動作をより詳細に説明する。
図17は、データ統合システム104に関連させて、メタデータ管理システム312、すなわちメタデータ・ファシリティを使用するためのプロセス1500を示すフロー図である。最初に、新しいツール1302は、ステップ1502に示すように、データ統合システムに付加することができる。示されるように、データ統合システム104は、RIM1304(もしあれば)の現在のアトミック・データ・モデル及びフォーマット、並びに、付加されることになるツール1302のデータ・モデル及びフォーマットについての情報を最初に受け取ることができる。ステップ1503に示すように、次に、新しいツール1302がデータ統合システム104に付加されるべき第1のツール1302であるかどうかの判断を下すことができる。新しいツール1302が第1のツール1302である場合には、プロセス1500は、ツール1302によって要求される表示か、又はユーザによって選択されるその他のあらゆるきめ細かいデータ・モデル及びフォーマットのいずれかを用いて、アトミック・データ・モデルが選択されるステップ1504に進むことができる。
新しいツール1302が第1のツール1302ではない場合には、プロセス1500は、新しいツールのクラス及び属性構造を含む、新しいツールのデータ・モデル及びフォーマット間の対応関係、並びに、そのクラス及び属性構造とRIMの現在のアトミック・データ・モデル及びフォーマットのクラス及び属性構造との間の関係付けが判定されることになるステップ1508に進むことができる。RIM1304及び翻訳エンジン1308の更新規則データベースは、それから生成することができる。ステップ1510に示すように、データ統合システム104は、規則データベースを使用して、RIMのアトミック・データ・モデル及びフォーマット、並びに、上述の既存の翻訳エンジン1308を更新することができる。データ統合システム104はまた、付加されるべきツール1302のために翻訳エンジン1308を確立することができる。
一般的に図18および図19に示すように、翻訳エンジン1308がツール1302について生成され又は更新されると、翻訳エンジン1308は、ツール1302の種々の動作と関連させて使用することができる。
ステップ1602に示すように、ツール1302は、アクセス要求を生成することができ、それを関連する翻訳エンジン1308に転送することができる。翻訳エンジン1308は、アクセス要求を受け取った後に、ステップ1604に示すように、該要求が検索要求であるか又は格納要求であるかといった要求のタイプを判断することができる。ステップ1608に示すように、要求が検索要求である場合には、翻訳エンジン1308は、ツールのデータ・モデル及びフォーマットとRIMのデータ・モデル及びフォーマットとの間のその関連付けを用いて、該要求をRIM1304用の1つ又は複数の要求に翻訳することができる。翻訳エンジン1308は、それぞれのデータ項目をRIM1304から受け取ったときに、データ項目を、RIM1304から受け取ったモデル及びフォーマットからツール1302によって要求されたモデル及びフォーマットに変換することができ、データ項目を適切なフォーマットでツール1302に提供することができる。
ステップ1614に示すように、翻訳エンジン1308は、要求が既に格納されているデータ項目を更新するための要求を含む格納要求であると判断する場合には、翻訳エンジン1308は、RIM1304を用いて、ツール1302と関連付けられたマスター物理項目からそれぞれのクラス及びサブクラスの有向グラフを生成することができる。動作が更新動作である場合には、有向グラフは、グラフ・ノードとして、それぞれのクラス及びサブクラス内の既存のデータ項目を含むことになる。動作が新しいデータを格納することになる場合には、有向グラフは、グラフ・ノードとして、要求に含められた新しいデータを格納するのに使用できる空のデータ項目を含むことになる。有向グラフが確立された後に、翻訳エンジン1308及びRIM1304は、ステップ1618に示すように、該グラフを横断するように動作し、要求において要求されるようにデータ項目のコンテンツを確立し又は更新する。グラフの横断動作が完了した後に、翻訳エンジン1308は、ステップ1620に示すように、格納動作が完了したことをツール1302に知らせることができる。
上述のデータ統合システム104は、大きな利点を与えることができる。例えば、このシステム104は、ツール1302を特定のデータ・モデルに拘束することなしに、及び異なるツール1302間で情報を交換する情報交換プログラムを要求することなしに、エンタープライズ・コンピュータ・システム1300内の多数のツール1302によって情報の効率的な共有及び更新を提供することができる。データ統合システム104は、該システム104内のツール1302のいずれかのために使用できるアトミック・データ・モデル及びフォーマットにおいてデータを保持するRIM1304を提供することができ、該フォーマットは、新しいツール1302が該システム104に付加されるときに、通常の方法で容易に更新し、発展させることができる。さらに、各々のツール1302をマスター物理項目のクラスと明確に関連付けることによって、有向グラフは、RIM1304内のデータ項目間で確立することができる。結果として、RIM1304内の情報の更新は、通常の有向グラフの横断手順を用いて効率的に達成することができる。
図20は、データ統合プロセスの複数のプロセスの並列実行のための並列実行ファシリティ1700を示す概略図である。実施形態において、プロセス1700は、プロセス開始ファシリティ1702を含むことができる。プロセス開始ファシリティ1702は、実行される必要があるジョブの範囲を決定し、(例えば、それらが依存していないため)第1及び第2のプロセスを同時に実行できると判断することができる。決定が下されると、2つの処理ファシリティ1704及び1708は、それぞれ、第1のプロセス及び第2のプロセスを実行することができる。これらの2つのジョブの実行に続いて、別の処理ファシリティ1712上で第3のプロセスに着手することができる。第3のプロセスが完了すると、対応するプロセス・ファシリティ1712は、情報を変形ファシリティ1714に通信することができる。実施形態において、変形ファシリティ1714は、それが第1及び第2の処理ファシリティ1704、1708等の1つ又は複数の他の並列プロセスから情報を受け取るまでは、変形プロセスを開始することができない。情報の全てが提供されると、変形ファシリティ1714は、変形を実行することができる。この並列プロセス・フローが、一度に幾つかのプロセス(例えば、互いに依存しないプロセス)を実行し、次いで、(例えば、共通ファシリティが2つの並列ファシリティの結果に依存する場合には)2つ又はそれ以上の並列実行から共通ファシリティに情報を提供することによってランタイムを最小にする。この実施形態においては、幾つかのプロセス・ファシリティは、説明の便宜を図り、別個のファシリティとして示されている。しかしながら、これらのファシリティの2つ又はそれ以上を同じ物理ファシリティとすることができることを理解されたい。処理ファシリティの2つ又はそれ以上は、異なる物理ファシリティとすることができ、種々の物理位置に常駐することができることも理解されたい(例えば、ファシリティ1704は、ある物理位置に常駐することができ、ファシリティ1708は、他の物理位置に常駐することができる)。
図21は、データ統合プロセスの複数のプロセスの並列実行のためのステップを示すフロー図である。実施形態において、並列プロセス・フローは、ジョブ・シーケンスを決定するステップ1802を含むことができる。ジョブ・シーケンスが決定されると、ステップ1804に示すように、ジョブは、2つ又はそれ以上のプロセス・ファシリティに送ることができる。ステップ1808において、第1のプロセス・ファシリティは、特定のルーチン及びプログラムを受け取り、実行し、処理された情報を第3のプロセス・ファシリティに通信することができる。ステップ1810において、第2のプロセス・ファシリティは、特定のルーチン及びプログラムを受け取り、実行し、完了すると、処理された情報を第3のプロセス・ファシリティに通信することができる。第3のプロセス・ファシリティは、情報の2つのソース上でそれ自体のルーチンを実行する前に、処理された情報を第1及び第2のプロセス・ファシリティから受け取るのを待機することができる。同様に、プロセス・ファシリティは、同じファシリティとするか又は同じ場所に常駐することもできるし、或いは、プロセス・ファシリティは、異なるものとするか及び/又は異なる場所に常駐することもできることを理解すべきである。
より一般には、並列処理を用いるスケーラブル・アーキテクチャは、SMP、クラスタリング及びMPPプラットフォーム、並びに、グリッド・コンピューティング・ソリューションを含むことができる。これらは、基礎となるデータ統合プロセスの修正を必要としない方法でデプロイすることができる。本明細書において説明されるシステムと共に使用できる現在市販の並列データベースとしては、IBM DB2 UDB、Oracle及びTeradataデータベースが挙げられる。並列処理に関連する概念は、レコードがジョブのデータ・フローによって定義される一連の処理機能を介して直接移動させられる、パイプライニングの概念である。パイプライニングは、暫定データ・ストレージのための要件を取り除き、処理ステップ間の入力/出力管理を取り除く等の、多数の処理利点を提供する。パイプライニングは、処理効率を向上させるためにデータ統合システム内で用いることができる。
図22は、複数のデータ・ソースからの入力及び複数のデータ・ターゲットへの出力からなる、データ統合ジョブ1900を示す概略図である。ビジネス・エンタープライズにおいて、上述のデータ・ソース102のいずれかとすることができる、幾つかのデータ・ソース1902A、1902B及び1902Cからデータを収集し、データの組み合わせを使用することが望ましいものとなる。実施形態において、データ統合システム104を用いて、幾つかのデータ・ソース1902A、1902B及び1902Cからデータを収集し、クレンジングし、変形し、又は他の方法で操作し、種々のツール、ターゲット、又は他のコンピュータ・システムからそれにアクセスできるように、上述のデータベース112のいずれかとすることができる共通データ・ウェアハウス又はデータベース1908にデータを格納することができる。これは、例えば、上述のデータ統合プロセス500を含むことができる。データ統合システム104は、上述のツール1302とすることができる、種々のツール1910A及び1910Bからそれに直接アクセスできるように、収集されたデータをストレージ・ファシリティ1908に格納することもできるし、或いは、ツールは、本明細書において説明されたように、自動、手動又は半自動のいずれで生成されようとも上述の翻訳エンジン1308とすることができるデータ・トランスレータ1904A及び1904Bを介してデータにアクセスすることもできる。データ・トランスレータ1904A、1904Bは、別個のファシリティとして示されているが、それらは、データ統合システム104、ツール1302に組み込むこともできるし、或いは、他の方法で所望のタスクを達成するように配置することもできることを理解されたい。
図23は、複数のデータ・ソースからの入力及び複数のデータ・ターゲットへの出力からなる、別のデータ統合ジョブ1900を示す概略図である。ビジネス・エンタープライズにおいて、上述のデータ・ソース102のいずれかとすることができる、幾つかのデータ・ソース1902A、1902B及び1902Cからデータを収集し、データの組み合わせを使用することが望ましいものとなる。実施形態において、データ統合システム104は、データを幾つかのデータ・ソース1902A、1902B及び1902Cから収集し、クレンジングし、変形し、又は他の方法で操作し、上述のデータ・ソース102のいずれかとすることもできる幾つかのターゲット1910A及び1910Bに、組み合わされた形で収集された情報を伝えることができる。これは、例えば、リアルタイム又はバッチ・モードで達成することができる。収集された情報の全てを、将来のある時点で、アクセスされることになる中央データベースに格納するのではなく、データ統合システム104は、データ要求がターゲット1910A及び1910Bによって作られる時点で又はその付近で、データをデータ・ソース1902A、1902B及び1902Cから収集し、処理することができる。データ統合システム104は、このような実施形態においては、依然としてメモリを含むことができると理解されたい。実施形態において、メモリを使用して、処理が完了したときにターゲットに渡されることになるデータを一時的に格納することができる。
図22及び図23を参照して説明されたデータ統合ジョブ1900の実施形態は、汎用的なものである。こうしたデータ統合ジョブ1900は、多数の商業、教育、政府及び他の環境において適用することができ、データ・ソース102、データ統合システム104、データ・ターゲット及び/又はデータベース112の多くの異なるタイプを含むことができることが認識される。
図24は、ビジネス・エンタープライズのためのデータ・マネージャがデータ統合ジョブ1900を設計することができる、グラフィカル・ユーザ・インターフェース2102を示す。実施形態において、グラフィカル・ユーザ・インターフェース2102をユーザに提供して、データ統合ジョブのセット・アップを容易にすることができる。ユーザ・インターフェースは、データベース、変形ツール、ターゲット、パス識別子、及びユーザによって使用される他のツールを含む、ツール・パレット2106を含むことができる。ユーザは、例えば、ドラッグ・アンド・ドロップ作業、ドロップ・ダウン・メニュー、コマンド・ライン、その他のあらゆる制御、ツール、ツールボックス、又は他のユーザ・インターフェース・コンポーネントを用いて、ツール・パレット2106からワークスペース2104内にツールをグラフィカルに操作することができる。ワークスペース2104を用いてデータベース、データ・フロー・パス、変形ステップなどをレイアウトして、上述のデータ統合ジョブ1900等のデータ統合ジョブを構成することができる。実施形態において、ジョブが構成されると、それを、この又は別のユーザ・インターフェースから実行することができる。ユーザ・インターフェース2102は、アプリケーション又は他のプログラミング環境によって、或いは、ユーザがウェブ・ブラウザを用いてアクセスできるウェブ・ページとして生成することができる。
図25は、データ・マネージャがデータ統合ジョブ1900を設計することができる、グラフィカル・ユーザ・インターフェース2102の別の実施形態を示す。実施形態において、ユーザは、グラフィカル・ユーザ・インターフェース2102を用いて、データ・ターゲット/ソースを表すアイコンを選択し、これらのアイコンを機能又は他の関係と関連付けることができる。こうした環境においては、ユーザは、幾つかのアイコン間の関連付け又はコマンド構造を作成して、上述のデータ統合ジョブ1900のいずれかとすることができるデータ統合ジョブ2202を作成することができる。
ユーザ・インターフェース2102は、多数のリソースへのアクセスを提供し、プラットフォーム100及びデータ統合システム104内でツールを設計することができる。例えば、ユーザ・インターフェース2102は、タイプ・デザイナ・データ・オブジェクト・モデリングを含むことができる。タイプ・デザイナを用いて、データ構造の特性を定義し、データの包含を定義し、データ検証規則を作成すること等を行うタイプ・ツリーを作成し、管理することができる。タイプ・デザイナは、XML、COBOL Copybooks、及びSAP R/3、BEA Tuxedo及びPeopleSoft EnterpriseOne等のアプリケーションに特有の構造のようなフォーマットで記述されるデータについてのタイプ・ツリー(すなわち、データ・オブジェクト定義)を自動的に生成するインポータを含むことができる。
ユーザ・インターフェース2102は、変形規則及びビジネス規則を構成するために使用されるマップ・デザイナを含むことができる。マップ・デザイナは、入力及び出力としてタイプ・デザイナを用いて作成されたデータ・オブジェクトの定義を使用することができ、データを変形しルーティングするための規則、並びに、作成されるマップを分析し、コンパイルし、テストする環境を指定するために使用することができる。
データベース設計インターフェースをモデリング・コンポーネントとして提供して、クエリ、表及びリレーショナル・データベースに格納されるデータの格納手順に関するメタデータをインポートすることができる。データベース設計インターフェースは、マッピング及び実行要件を満たすために、種々のオブジェクトの、更新キー及びデータベース・トリガ等の特性を識別することができる。統合フロー・デザイナを用いて、データ統合プロセスを定義し、管理することができる。より具体的には、統合フロー・デザイナを用いて、マップ及びマップ・システム間の相互作用を定義し、ワークフローの論理的整合性を検証し、マップ・システムを準備し、実行することができる。コマンド・サーバ・コンポーネントは、グラフィカル・ユーザ・インターフェース内でコマンド駆動実行を提供することができる。これは、例えば、マップ・デザイナ環境内のマップをテストするために用いることができる。リソース・レジストリは、実行時にエンタープライズ内の特定のリソースに分解するエイリアスを用いてパラメータ設定を抽出するために使用される、リソース・エイリアス・リポジトリを提供することができる。
ユーザ・インターフェース2102は、種々のアドミニストレーション及び管理ツールへのアクセスを提供することもできる。例えば、ユーザがデプロイディレクトリを指定し、ユーザ及びユーザ・アクセス権利を構成し、リスニング・ポートを指定し、Java Remote Method Invocation(RMI)についての特性を定義することを可能にする、イベント・サーバ・アドミニストレーション・ツールを提供することができる。管理コンソールは、ユーザがシステムを開始し、停止し、一時停止し、再開することができるイベント・サーバについての管理及び監視を提供し、イベント・サーバのステータスに関する情報及び実行されるマップを表示することができる。イベント・サーバ・モニタは、マップが動作する際に、単一のマップの動的な詳細表示を提供し、特定の時点でのアクティビティのスナップショットを作成することができる。
図26は、ビジネス・エンタープライズの種々のデータの統合を容易にするプラットフォーム2300を表す。プラットフォームは、例えば、上述のプラットフォーム100とすることができ、ETL(Extract、Transform、Load)と呼ばれることがある、種々のソースからのデータ抽出、所望のフォーマットへのデータ変形、及び種々のターゲットへのデータ・ロード等の公知のエンタープライズ・アプリケーション統合(EAI)サービスを提供できる統合スイートを含むことができる。プラットフォーム2300は、Enterprise Java Beans(EJB)及びJava Messaging Service(JMS)等のウェブ・サービス・プロトコル2302を介することを含む、エンタープライズのコンピュータ・アプリケーションによってアクセスできるサービスとして、通常のデータ統合プラットフォーム2702を公開することを容易にするリアルタイム統合(RTI)サービス2704を含むことができる。製品スイートは、以下の例において詳細に説明されるように、データ統合又はエンタープライズ・アプリケーション統合スイートとすることができるが、本明細書において説明される原理を用いて、相互に関係するプログラム又は機能の任意のスイートをサービス指向アーキテクチャ内のサービスとしてデプロイし、管理できることが認識される。したがって、製品スイートは、例えば、自動文書アセンブリ、ワード処理、スプレッドシート等のようなツールを含むオフィス・オートメーション又は生産性スイートを含むことができる。或いは、生産性スイートは、例えば、設計、ビジュアル・レンダリング、原価計算、シミュレーション等についての種々のサービスとしてデプロイされた別個のソフトウェア・パッケージ又は機能を有するコンピュータ自動設計スイートとすることができる。別の例として、簿記、会計、税金の書類作成、及び電子納税申告製品のような財務製品の統合スイートは、サービス指向アーキテクチャを用いて、製品レベルにおいて又は各々の製品に特有のサービスの集合としてのいずれかでサービスとしてデプロイすることができる。同様に、経済のモデリング・ツール、財務分析ツール(例えば、個々の会社の会計報告、株式取引パターン、市場取引パターン等用)、及び電子取引ツールは、統合株式取引スイート内のサービスとしてデプロイすることができる。
図27は、サービス指向アーキテクチャ(SOA)2400の概略図を示す。SOAは、ビジネス・エンタープライズのエンタープライズ・コンピュータ・システム1300のインフラストラクチャの一部とすることができる。SOA2400においては、サービスは、迅速なアプリケーションの開発を可能にし、冗長コードを回避する、アプリケーションの開発及びデプロイのための構築ブロックとなる。各々のサービスが、該サービスのためのデータ入力ソース又は該サービスのためのデータ出力ターゲットといった、周囲の環境には見えないビジネス論理又はビジネス規則のセットを具体化する。結果として、サービスは、適切な入力及び出力がサービスとアプリケーションとの間に確立されているという条件で、様々なアプリケーションと関連させて再使用することができる。サービス指向アーキテクチャ2400は、サービスを環境の変更から保護することを可能にし、その結果、たとえ周囲のコンピュータ環境が変更されても、該アーキテクチャは機能する。結果として、サービスは、インフラストラクチャの変更の結果として記録される必要がない場合があり、このことは、時間及び努力の節約をもたらし得る。図27の実施形態は、ウェブ・サービスのためのSOA2400の実施形態である。ここで用いられる「サービス指向アーキテクチャ」、「サービス指向のアーキテクチャ」、「SOA」等のような変形語は、図27を参照して説明され、より一般的には、本明細書全体を通して説明されるSOA2400を一般的に指すために互換性をもって用いられることが意図される。
図27のSOA2400においては、サービス・プロバイダ2402、サービス・リクエスタ2404及びサービス・レジストリ2408の、3つのエンティティが存在する。レジストリ2408は、公開又は専用とすることができる。サービス・リクエスタ2404は、適切なサービスについてレジストリ2408を検索することができる。適切なサービスが発見されると、サービス・リクエスタ2404は、サービスを呼び出すのに必要な、Web Services Description Language(WSDL)コードのようなコードを受け取ることができる。WSDLは、ウェブ・サービスを記述するために従来の方法で使用されるプログラミング言語である。次に、サービス・リクエスタ2404は、サービスを呼び出すために、例えば、適切なフォーマット(ウェブ・サービス・メッセージのためのSimple Object Access Protocol(SOAP)フォーマット等)のメッセージを介して、サービス・プロバイダ2402とインターフェース接続することができる。SOAPプロトコルは、ウェブ・サービスにおいてデータを転送するための好ましいプロトコルである。SOAPプロトコルは、ウェブ・サービス・クライアントとウェブ・サービス・サーバとの間のメッセージのための交換フォーマットを定義する。SOAPプロトコルは、Extensible Markup Language(XML)スキーマを使用し、XMLは、データをタグ付けするウェブ・サービスに一般的に使用される総称言語仕様であるが、他のマークアップ言語を使用することもできる。
図28は、SOAPメッセージの例を示す。SOAPメッセージ2502は、転送エンベロープ2504(HTTP若しくはJMSエンベロープ等)、SOAPエンベロープ2508、SOAPヘッダ2510及びSOAP本体2512を含むことができる。以下は、SOAPフォーマットの要求メッセージ及びSOAPフォーマットの応答メッセージの例である。
ウェブ・サービスは、ウェブにわたって公開し、配置し、呼び出すことができるモジュラ式の、自己記述型の、内蔵型のアプリケーションとすることができる。例えば、図27のウェブ・サービスの実施形態においては、サービス・プロバイダ2402は、ウェブ・サービスをレジストリ2408に公開し、該レジストリは、例えば、どんなウェブ・サービスが利用可能であるかについてのリストを提供する、Universal Description Discovery and Integration(UDDI)レジストリ、又は専用レジストリ若しくは他の公開レジストリとすることができる。ウェブ・サービスは、例えば、WSDLフォーマットで公開することができる。サービスを発見するために、サービス・リクエスタ2404は、サービス・レジストリをブラウズし、WSDL文書を検索することができる。レジストリ2408は、ブラウズ・ファシリティ及び検索ファシリティを含むことができる。レジストリ2408は、WSDL文書及びそれらのメタデータを格納することができる。
ウェブ・サービスを呼び出すために、サービス・リクエスタ2404は、WSDLで記述されたSOAPメッセージ2502をサービス・プロバイダ2402に送り、それに応答してSOAPメッセージ2502を受け取り、WSDLで記述された応答メッセージをデコードする。それらの複雑さによって、ウェブ・サービスは、データ要求等の単純な動作から複雑なビジネス・プロセス動作に及ぶ多彩な機能を提供することができる。ウェブ・サービスがデプロイされると、他のアプリケーション(他のウェブ・サービスを含む)は、ウェブ・サービスを発見し、呼び出すことができる。他のウェブ・サービス標準は、プラットフォームにわたるウェブ・サービスの相互運用性を促進するために設立されたオープンな業界組織の、Web Services Interoperability Organization(WS−I)によって定義される。例としては、WS−Coordination、WS−Security、WS−Transaction、WSIF、BPEL等が挙げられ、本明細書において説明されるウェブ・サービスは、何らかのこうした標準によって考慮されるサービスを包含するものと理解されたい。
図29を参照すると、WSDL定義2600は、ウェブ・サービスについてのインターフェース、位置及び符号化スキームを定義するXMLスキーマである。定義2600は、サービス2602を定義し、該サービス2602をアクセスさせることができるポート2604(インターネット・アドレス等)を識別し、ウェブ・サービスを呼び出してそれと通信するのに使用されるバインディング2608(Enterprise Java Bean又はSOAPバインディング等)を定義する。WSDL定義2600は、ポート・タイプ2612、ウェブ・サービスのための入側メッセージ部分2616及び出側メッセージ部分2618、並びに、サービスによって実行される動作2614を定義することができる抽出定義2610を含むことができる。
ウェブ・サービスを呼び出すことができる種々のプロバイダからの様々なウェブ・サービス・クライアントが存在する。ウェブ・サービス・クライアントとしては、.Netアプリケーション、Javaアプリケーション(例えば、JAX−RPC)、Microsoft SOAPツールキット内のアプリケーション(Microsoft Office、Microsoft SQL Server及びその他)SeeBeyondからのアプリケーション、WebMethods、Tibco及びBizTalk、並びに、AscentialのDataStage(WS PACK)が挙げられる。本明細書において説明されるエンタープライズ・データの統合方法及びシステムにおいて他のウェブ・サービス・クライアントを使用することもできると理解されたい。同様に、・Netアプリケーション、Javaアプリケーション、Siebel及びSAPからのアプリケーション、I2アプリケーション、DB2及びSQL Serverアプリケーション、エンタープライズ・アプリケーション統合(EAI)アプリケーション、ビジネス・プロセス管理(BPM)アプリケーション、及びAscential SoftwareのReal Time Integration(RTI)アプリケーションを含む、種々のウェブ・サービスのプロバイダが存在し、これらの全ては、本明細書において説明されるウェブ・サービス・クライアントと共に使用することができる。
本明細書において説明されるRTIサービス2704は、WSDL等のオープン・スタンダード仕様を用いて、データ統合プロセスのサービス・インターフェースを記述することができる。データ統合サービスの定義が完了したときに、それは、WSDLウェブ・サービスの定義言語(必ずしもウェブ・サービス特有であるとは限らない言語)を使用することができ、これは、一般的に上述されたように、サービス名、サービス動作、各々の動作シグニチャ、及びサービスについてのバインディングを与える抽象定義である。WSDL定義2600(XML文書)内には、種々のタグが存在し、この構造は、図29と関連させて説明される。サービス毎に、その各々がバインディングを有する多数のポートが存在し得る。抽象定義は、当該データ統合サービスについてのRTIサービスの定義である。ポート・タイプは、その各々が入力引数及び出力引数のセットを有する、動作のセットについての入口ポイントである。
WSDLは、ウェブ・サービスについて定義されたものであるが、1つのみのバインディングを定義したものである(SOAP over HTTP)。WSDLは、その後、EJB、JMS等のような、種々の他のバインディングのためのWSDL拡張子を含めるように、業界組織体を通して拡張された。RTIサービス2704は、WSDL拡張子を用いて、種々の他のプロトコルについてのバインディングを作成することができる。このようにして、単一のRTIデータ統合サービスは、単一のサービスに対して同時に多数のバインディングをサポートすることができる。結果として、ビジネスは、データ統合プロセス500を受け、それを抽出プロセスのセットとして公開し(プロトコルに完全にとらわれない)、次いで、バインディングを付加することができる。サービスは、任意の数のバインディングをサポートすることができる。
ユーザは、既存のデータ統合ジョブ1900を受け、適切なRTI入力及び出力段階を付加し、異なるネイティブ・プロトコルを使用する種々のアプリケーションによって呼び出すことができるサービスとしてジョブを公開することができる。
図30を参照すると、上位レベルのアーキテクチャが、データ統合プラットフォーム2700について表され、該プラットフォームは、例えば、リアルタイムのデータ統合について上述され、適合されたプラットフォーム100にわたってデプロイすることができる。例えば、上述のデータ統合システム104とすることができる通常のデータ統合ファシリティ2702は、データ統合ジョブを処理するための方法及びシステムを提供することができる。データ統合ファシリティ2702は、サービス指向アーキテクチャ内のサービスを含む、リアルタイム統合ファシリティ、すなわちRTIサービス2704を介して1つ又は複数のアプリケーションに接続することができる。RTIサービス2704は、エンタープライズの種々のアプリケーション2708を呼び出すこともできるし、或いは、それらによって呼び出されることもできる。データ統合ファシリティ2702は、一致、標準化、変形、クレンジング、発見、メタデータ、並列実行、及びデータ統合ジョブを実行するのに必要な同様のファシリティを提供することができる。実施形態において、RTIサービス2704は、エンタープライズのアプリケーション2708によってリアルタイムで呼び出すことができるサービスとしてデータ統合ファシリティ2702のデータ統合ジョブを公開する。RTIサービス2704は、データ統合ファシリティ2702を公開し、その結果、データ統合ジョブは、サービスとして、同期的又は非同期的に使用することができる。ジョブは、例えば、エンタープライズ・アプリケーション統合プラットフォーム、アプリケーション・サーバ・プラットフォーム、並びに、Java及び.Netアプリケーションから呼び出すことができる。RTIサービス2704は、バッチ及びリアルタイム・サービスにわたって同じ論理を再使用し、適用することを可能にする。RTIサービス2704は、Enterprise Java Bean(EJB)、Java Message Service(JMS)、又はウェブ・サービス・バインディング等の種々のバインディング2710を用いて呼び出すことができる。
図31を参照すると、実施形態において、RTIサービス2704は、リアルタイム・データ統合プロセスの種々の要素のための接続ファシリティとして機能する、RTIサーバ2802上で動作する。例えば、RTIサーバ2802は、マサチューセッツ州、ウェストバラ所在のAscential Software社からのDataStageサーバ等の、複数のエンタープライズ・アプリケーション統合サーバを接続することができ、その結果、RTIサーバ2802は、他のサーバ間でのプーリング及びロード・バランシングを提供することができる。RTIサーバ2802は、J2EEアプリケーション・サーバ上で動作する別個のJ2EEアプリケーションを含むことができる。1つより多くのRTIサーバ2802をデータ統合プロセスに含めることができる。
J2EEは、エンタープライズ・アプリケーションの設計、開発、組み立て及びデプロイへの、コンポーネント・ベースのアプローチを提供する。中でも、J2EEは、多層の分散アプリケーション・モデル、コンポーネントを再使用する能力、統一したセキュリティ・モデル、及びトランザクション制御機構を提供する。J2EEアプリケーションは、コンポーネントから構成される。J2EEコンポーネントは、その関係するクラス及びファイルと共にJ2EEアプリケーションに組み込まれ、他のコンポーネントと通信する、内蔵タイプの機能ソフトウェア・ユニットである。
J2EE仕様は、クライアント側で動作するコンポーネントであるアプリケーション・クライアント及びアプレット、サーバ上で動作するウェブ・コンポーネントであるJava Servlet及びJavaServer Pages(JSP)技術コンポーネント、及びサーバ上で動作するビジネス・コンポーネントであるEnterprise JavaBean(EJB)コンポーネント(エンタープライズ・ビーン)を含む、種々のJ2EEコンポーネントを定義する。J2EEコンポーネントは、Javaで書き込まれ、如何なるプログラムとも同じ方法でコンパイルされる。J2EEコンポーネントと「標準」Javaクラスとの間の違いは、J2EEコンポーネントは、それらがJ2EEサーバによって実行され管理される場合に、J2EEアプリケーションに組み込まれ、J2EE仕様に適格となり準拠していることを検査され、生産のためにデプロイされるということである。セッション・ビーン、エンティティ・ビーン及びメッセージ駆動ビーンの、3種類のEJBが存在する。セッション・ビーンは、クライアントとの過渡的会話を表す。クライアントが実行を終えるときに、セッション・ビーン及びそのデータは消える。これとは対照的に、エンティティ・ビーンは、データベース表の1つの行に格納される永続的なデータを表す。クライアントが終了するか又はサーバがシャット・ダウンする場合に、基礎サービスは、エンティティ・ビーンのデータが保管されることを保証する。メッセージ駆動ビーンは、セッション・ビーンの機能とJava Message Service(JMS)メッセージ・リスナの機能とを結合して、ビジネス・コンポーネントがJMSメッセージを非同期的に受け取ることを可能にする。
J2EE仕様はさらに、コンポーネントと、該コンポーネントをサポートする下位レベルのプラットフォーム別の機能との間のインターフェースであるコンテナを定義する。ウェブ、エンタープライズ・ビーン又はアプリケーション・クライアント・コンポーネントが実行される前に、それは、J2EEアプリケーションに組み込まれ、そのコンテナにデプロイされる必要がある。組み立てプロセスは、J2EEアプリケーション内のコンポーネント毎に及びJ2EEアプリケーションそれ自体についてコンテナ設定を指定することを含む。コンテナ設定が、セキュリティ、トランザクション管理、Java Naming and Directory Interface(JNDI)ルックアップ及び遠隔接続等のサービスを含む、J2EEサーバによって提供される基礎サポートをカスタマイズする。
図32は、典型的なJ2EEサーバ2908及び関連アプリケーションについてのアーキテクチャ2900を示す。J2EEサーバ2908は、J2EEアーキテクチャのランタイム・アスペクトを構成する。J2EEサーバ2908は、EJBコンテナ及びウェブ・コンテナを提供する。EJBコンテナ2902は、J2EEアプリケーションについてのエンタープライズ・ビーン2904の実行を管理する。エンタープライズ・ビーン2904及びそれらのコンテナ2902は、J2EEサーバ2908上で動作する。ウェブ・コンテナ2910は、J2EEアプリケーションについてJSPページ2912及びサーブレット・コンポーネント2914の実行を管理する。ウェブ・コンポーネント及びそれらのコンテナ2910も、J2EEサーバ2908上で動作する。一方、アプリケーション・クライアント・コンテナ2918は、アプリケーション・クライアント・コンポーネントの実行を管理する。アプリケーション・クライアント2920及びそれらのコンテナ2918は、クライアント側で動作する。アプレット・コンテナは、アプレットの実行を管理する。アプレット・コンテナは、ウェブ・ブラウザ及びクライアント上で共に動作するJavaプラグ・インから構成することができる。
J2EEコンポーネントは、一般的には、デプロイのためにJ2EEアプリケーションに別々にパッケージ化され、バンドル化される。各々のコンポーネント、GIF及びHTMLファイル又はサーバ側のユーティリティ・クラス等のその関連ファイル、及びデプロイディスクリプタは、モジュールに組み込まれ、J2EEアプリケーションに付加される。J2EEアプリケーション及びそのモジュールの各々は、それ自身のデプロイディスクリプタを有する。デプロイディスクリプタは、コンポーネントのデプロイ設定を記述する.xml拡張子を有するXML文書である。そのモジュールの全てを有するJ2EEアプリケーションは、Enterprise Archive(EAR)ファイルで供給される。EARファイルは、.ear拡張子を有する標準Java Archive(JAR)ファイルである。各々のEJB JARファイルは、デプロイディスクリプタ、エンタープライズ・ビーン・ファイル、及び関連ファイルを含む。各々のアプリケーション・クライアントJARファイルは、デプロイディスクリプタ、アプリケーション・クライアントのためのクラス・ファイル、及び関連ファイルを含む。各々のファイルは、デプロイディスクリプタ、ウェブ・コンポーネント・ファイル、及び関連リソースを含む。
RTIサーバ2802は、リアルタイム・エンタープライズ・アプリケーション統合環境のためのホスティング・サービスとして機能することができる。RTIサーバ2802は、本明細書において説明される機能を実行できるJ2EEサーバとすることができる。RTIサーバ2802は、エンタープライズ・アプリケーション統合サービスのための安全かつスケーラブルなプラットフォームを提供することができる。RTIサーバ2802は、セッション管理、ロギング(Apache Log4J ロギング等)、構成及び監視(J2EE JMX等)、セキュリティ(J2EE JAAS、J2EEアドミニストレータを介するSSL符号化等)を含む、様々な通常のサーバ機能を提供することができる。RTIサーバ2802は、ローカル又は専用ウェブ・サービス・レジストリとして機能することができ、それは、多くの通常のウェブ・サービスのために用いられるUDDIレジストリのような公開ウェブ・サービス・レジストリにウェブ・サービスを公開するのに使用することができる。RTIサーバ2802は、データ統合ジョブを実行するのに使用されるもののような、他のサービス間でのリソース・プーリング及びロード・バランシング機能を実行することができる。RTIサーバ2802は、RTIサービスを確立し、管理するためのアドミニストレーション・コンソールとして機能することもできる。RTIサーバ2802は、JBOSS 3.0、IBM Websphere 5.0、BEA WebLogic 7.0及びBEA WebLogic 8.1等の、種々の環境と関連させて動作することができる。
確立されると、RTIサーバ2802は、データ統合ジョブ(Ascential Softwareプラットフォームによって実行されるDataStage及びQualityStageジョブ等)が、ウェブ・サービス、エンタープライズJavaビーン、Javaメッセージ・サービス・メッセージ等によって呼び出されることを可能にする。RTIサーバ2802と共にサービス指向アーキテクチャを使用するアプローチは、バインディングの決定がデータ統合ジョブ設計から分離されることを可能にする。また、同じデータ統合ジョブについて多数のバインディングを、確立することができる。データ統合ジョブは、環境を問わずに多数のバインディングを扱うことができるため、多数のアプリケーションにわたって、並びに、バッチ及びリアルタイム・モードにわたって処理論理を再使用することがより容易になり得る。
図33は、RTIサービスを管理するために提供することができるRTIコンソール3002を示す。RTIコンソール3002は、RTIサービスの作成及びデプロイを可能にすることができる。中でも、RTIコンソールは、ユーザが、所与のRTIサービスへのインターフェースを提供するためにどんなバインディングを使用するかを確立し、RTIサービスのランタイム使用についてのパラメータを確立することを可能にする。RTIコンソールには、グラフィカル・ユーザ・インターフェースが提供され、Microsoft Windowsベースの環境、又はウェブ・ブラウザ・インターフェースのようなインターフェースをサポートする任意の適切な環境において作動することができる。RTIコンソールの使用についてのさらなる詳細を以下に提供する。RTIコンソール3002は、設計者によって、サービスを作成し、サービスの動作を作成し、ジョブをサービス動作に付加し、ユーザによって所望されるバインディングを作成して、種々のプロトコルによってサービスを実行するために使用可能である。
再度、図30を参照すると、RTIサービス2704は、データ統合プラットフォーム2702と種々のアプリケーション2708との間に位置させることができる。RTIサービス2704は、アプリケーション2708がデータ統合プラットフォーム2702にリアルタイム又はバッチ・モードで同期的又は非同期的にアクセスすることを可能にすることができる。データ統合プラットフォーム2702において確立されたデータ統合規則は、エンタープライズ・コンピュータ・システム1300にわたって共有することができる。データ統合規則は、プラットフォーム2702の知識を必要とすることなく、如何なる言語ででも書き込むことができる。RTIサービス2704は、リアルタイムでのデータ統合を容易にするために、ウェブ・サービス定義を活用することができる。データ統合ジョブのフローは、本明細書において説明される方法及びシステムによって、バッチ環境又はリアルタイム環境と関連させることができる。本発明において説明される方法及びシステムは、コンテナの概念、すなわちプロセスにおける定義済み入口ポイントと定義済み出口ポイントとの間に収容されるビジネス論理部分を含む。データ統合プロセスをコンテナ内のビジネス論理として構成することによって、データ統合は、バッチ・モード及びリアルタイム・モードで使用することができる。ビジネス論理がコンテナに入ると、バッチ・モード及びリアルタイム・モード間の移動を単純化することができる。データ統合ジョブは、リアルタイム・サービスとしてアクセスすることができ、例えば大きなバッチのファイルを処理するために、同じデータ統合ジョブにバッチ・モードでアクセスし、リアルタイム・モードの場合と同じ変形を行うことができる。
図34を参照すると、RTIサービス2704の実施形態を可能にするためのアーキテクチャ3100のさらなる詳細が提供される。RTIサーバ2802は、典型的なJ2EE準拠サーバによって提供されるような監査3104、認証3108、許可3110及びロギング3112のためのファシリティを含む種々のコンポーネントを含むことができる。RTIサーバ2802は、データ統合プラットフォーム2702上で実行されるデータ統合ジョブに関連するリソース等のリソースをプールして割り当てるように動作することができる、プロセス・プーリング・ファシリティ3102をさらに含むことができる。プロセス・プーリング・ファシリティ3102は、データ統合ジョブを実行している種々のサーバにわたってサーバ及びジョブの選択を提供することができる。選択は、マシン間のロードのバランスを取ることに基づくか、又はどのデータ統合ジョブがどのマシン上で実行されること(又は最も効果的に実行されること)が可能かに基づくものとすることができる。RTIサーバ2802は、SOAPバインディング・ファシリティ3116、JMSバインディング・ファシリティ3118及びEJBバインディング・ファシリティ3120等の、バインディング・ファシリティ3114をさらに含むことができる。バインディング・ファシリティ3114は、RTIサーバ2802と、ウェブ・サービス・クライアント3122、JMSキュー3124又はJavaアプリケーション3128等の種々のアプリケーションとの間のインターフェースを可能にする。
さらに図34を参照すると、RTIコンソール3002は、RTIサーバ2802のためのアドミニストレーション・コンソールとすることができる。RTIコンソール3002は、アドミニストレータがRTIサービスを作成してデプロイし、該サービスのランタイム・パラメータを構成し、該サービスへのバインディング又はインターフェースを定義することを可能にすることができる。
アーキテクチャ3100は、マサチューセッツ州、ウェストバラ所在のAscential Software社によって提供されるDataStageサーバ等のサーバを含む1つ又は複数のデータ統合プラットフォーム2702を含むことができる。データ統合プラットフォーム2702は、RTIサーバ2802へ及びRTIサーバ2802からの要求を整理するデータ統合プラットフォーム2702上で実行されるプロセスである、RTIエージェント3132を含む、RTIサーバ2802との相互作用をサポートするファシリティを含むことができる。したがって、プロセス・プーリング・ファシリティ3102が特定のマシンをリアルタイム・データ統合ジョブのためのデータ統合プラットフォーム2702として選択すると、それは、要求をそのデータ統合プラットフォーム2702のためのRTIエージェント3132に渡すことができる。データ統合プラットフォーム2702上では、上述のデータ統合ジョブ1900のような1つ又は複数のデータ統合ジョブ3134が実行されていてもよい。データ統合ジョブ3134は、任意的に、呼び出し時に開始される必要があるのではなく常時オンになっていてもよい。例えば、データ統合ジョブ3134は、処理時に新しい接続を開く必要があるのではなくデータが来てデータ統合ジョブ3134を呼び出すのを待機する、データベース、ウェブ・サービス等との既にオープンされた接続を有することができる。したがって、既にオンになっているデータ統合ジョブ3134のインスタンスを、RTIエージェント3132によって呼び出し、ファイル、データ行、データ・バッチ等とすることができるRTIサーバ2802からの特定の入力を用いて、データ統合ジョブ3134の実行と共に、直ちに開始することができる。
各々のデータ統合ジョブ3134は、RTI入力段階3138及びRTI出力段階3140を含むことができる。RTI入力段階3138は、RTIエージェント3132からデータ統合ジョブ3134への入口ポイントであり、RTI出力段階3140は、RTIエージェント3132に戻る出力段階である。RTI入力及び出力段階に関しては、データ統合ジョブ3134は、プラットフォームに依存しないビジネス論理部分とすることができる。RTIサーバ2802は、各々のRTIデータ統合ジョブ3134のRTI入力段階3138についてどんな入力が要求されているかを承知している。例えば、所与のデータ統合ジョブ3134のビジネス論理が顧客の姓及び年齢を入力とする場合には、RTIサーバ2802は、そのデータ統合ジョブ3134のRTI入力段階3138への、ストリング及び整数の形の入力を渡すことができる。RTI入力段階は、入力を受け、それを、どんな固有のアプリケーション・コードをも用いてデータ統合ジョブ3134を実行するのに適したフォーマットにする。
実施形態において、本明細書において説明される方法及びシステムは、設計者がデータ統合プロセスからRTIサービス・インターフェースへの自動のカスタマイズ可能なマッピング機構を定義することを可能にする。特に、RTIコンソール3002は、設計者がデータ統合プロセスについての自動化したサービス・インターフェースを作成することを可能にする。中でも、ユーザ(又は規則のセット若しくはプログラム)が特定の目的に適合するように汎用サービス・インターフェースをカスタマイズすることを可能にする。変形等のトランザクションのフローを有するとともに、RTI入力段階3138及びRTI出力段階3140を有するデータ統合ジョブが存在する場合には、該ジョブについてのメタデータは、例えば、該ジョブのコンポーネント又は段階間で交換されるデータのフォーマットを指定することができる。テーブル定義は、RTI入力段階3138が受け取ることを期待するものを記述する、すなわち、例えば、データ統合ジョブの入力段階は、1つのストリング及び2つの整数の、3つの呼び出しを期待することができる。一方、データ統合ジョブのフローの終了時に、出力段階は、形式(string,integer)の呼び出しを返すことができる。ユーザが、このジョブを使用することになっているRTIサービスを作成する場合には、定義される動作が、入力においてどんなデータが期待されるか及び出力においてどんなデータが返されることになるかを反映することが望ましい。通常のオブジェクト指向プログラミング法と比較すると、ジョブが、RTI入力段階3138に関連したRTI入力テーブル3414及びRTI出力段階3140に関連したRTI出力テーブル3418等のメタデータに基づく動作のシグニチャを定義する場合には、サービスはクラスに対応し、動作は方法に対応する。
例として、ユーザは、RTI入力テーブル3414において特定のRTI動作についての入力引数として(string,int,int)を定義することができる。struct:(string;int)としてRTI出力テーブル3418内の出力を定義することができる。実施形態において、入力及び出力は単一のストリングとすることができる。他のフィールド(より多くの呼び出し)が存在する場合には、ユーザは、入力マッピングをカスタマイズすることができる。15の整数を用いて動作する代わりに、ユーザは、Opt(struct(string,int,int)):struct(string,int)のようなSTRUCT(多数のフィールドを有する複合タイプ,複合動作に対応する各々のフィールド)を作成することができる。ユーザは、入力パラメータを、1つの複合入力タイプとしてグループ化されるようにグループ化することができる。結果として、配列を処理することが可能になり、その結果、トランザクションは、Opt1(array(struct(string,int,int)))として定義される。例えば、入力構造は、(Name,SSN,age)とすることができ、出力構造は、(Name,birthday)とすることができる。配列は、RTIサービスを介して渡すことができる。終了時に、このサービスは、配列についての対応する応答を出力する。配列は、単一のトランザクションへの多数行のグループ化を可能にする。RTIコンソール3002においては、チェックボックス5308は、配列をイネーブルにするためにユーザが「多数行を受け入れる」ことを可能にする。入力を定義するためには、RTIコンソール3002において特定の行をチェックし又はチェック解除して、それが入力として動作のシグニチャの一部になるかを決定することができる。ユーザは、動作に対して特定の入力列を公開することを望まない場合があり(例えば、それが特定の動作について常に同じとなることがあるため)、その場合には、ユーザは、入力についての静的値を固定して、動作が静的値ではない変数のみを確認するようにすることができる。
同様のプロセスは、RTIコンソールを用いて出力の特定の列を無視する等の動作、すなわち特定の動作のシグニチャの一部として格納できるアクションについて出力をマッピングするために使用することができる。
実施形態において、RTIサーバ2802からのデータ統合プラットフォーム2702を通過するRTIサービス要求は、ファイルのバッチ、すなわち大きなセットでではなく、個々の要求のパイプラインで供給される。パイプライン・アプローチは、個々のサービス要求がデータ統合ジョブ3134の既に実行しているインスタンスによって直ちにピックアップされることを可能にして、エンタープライズにバッチ統合ジョブの完了を待機するように要求するのではなく、迅速なリアルタイムでのデータ統合をもたらす。パイプラインを通過するサービス要求は、ウェーブとして考えることができ、各々のサービス要求は、ウェーブ・マーカの発端及びウェーブ・マーカの終端によってマーク付けすることができ、その結果、RTIエージェント3132は、特定のサービス要求についての新しいサービス要求の開始及びデータ統合ジョブ3134の完了を認識する。
ウェーブ・マーカの終端は一連の作業単位を表し、各々の単位はウェーブ・マーカの終端によって分離されている。ウェーブ・マーカの終端を用いることにより、このシステムが同じサービスを用いてバッチ動作とリアルタイム動作との両方を実行することが可能になる。バッチ環境においては、データ統合ユーザは、一般的には、データ移動はリソース集約的であるため、所与の段階における最大処理量を実行するというようにデータ・フローを最適化し、まとめて次の段階に伝送して、データを移動しなければならない回数を減少させることを望んでいる。これとは対照的に、リアルタイム・プロセスにおいては、データ統合ユーザは、フローを通してできるだけ迅速に各々のトランザクション要求を移動させることを望む場合がある。ウェーブ・マーカの終端は、(システムが一般的にバッチ・モードでそうするように)処理を開始するのにより多くのデータを待機するのではなく、データ統合ジョブに対する特定の要求をフラッシュすることを知らせる信号をジョブ・インスタンスに送る。ウェーブ・マーカの終端の利点は、所与のジョブ・インスタンスが同時に多数のトランザクションを処理することができ、その各々がウェーブ・マーカの終端によって他のトランザクションから分離されることである。ウェーブ・マーカの2つの終端間にあるのは、いずれもトランザクションである。
パイプライン化は、多数の要求がサービスによって同時に処理されることを可能にする。プロセス・プーリング・ファシリティ3102のロード・バランシング・アルゴリズムは、データ統合ジョブの新しいインスタンスを開始する前に、(パイプラインを埋める)その最大容量まで単一のインスタンスを埋めることができる。リアルタイム統合モデルにおいては、(システムが一般的にバッチを処理する前にバッファを埋めるバッチ・モードとは違って)再呼び出しをリアルタイムで処理するときに、ウェーブ・マーカの終端により、多数のトランザクションがデータ統合ジョブのフローの中にパイプライン化されることが可能となる。ロード・バランシングについては、依然として未使用の処理能力を有する状態でジョブがビジーとなり得るため、バランスは、ジョブがビジーであるかどうかだけに基づくものではないことが望ましい。
一方、パイプラインの容量がその最大に達する前に新しいデータ統合ジョブのインスタンスを開始することを防止することが望ましい場合がある。これは、ロード・バランシングが動的であり、付加的な特性に基づく必要があることを意味する。RTIエージェント・プロセスにおいて、RTIエージェント3132は、RTIサーバ2802によってアクセスされる各々のデータ統合プラットフォーム2702上で実行するインスタンスについて承知している。RTIエージェント3132においては、ユーザは、データ統合プラットフォーム2702上で実行するジョブ・インスタンスの各々についてバッファを作成することができる。種々のパラメータをRTIコンソール3002に設定して、動的なロード・バランシングを支援することができる。1つのパラメータは、ジョブ・インスタンスによる処理を待機するバッファに定めることができるバッファの最大サイズ(要求数において実測される)である。一定の処理能力をもたらすことになる単一の要求だけを有することが好ましい場合もあるが、実際には、通常、処理能力において違いがあり、その結果、ジョブ・インスタンス毎にバッファを有することが望ましい場合が多い。第2のパラメータは、パイプラインしきい値であり、それは、どの時点で新しいジョブ・インスタンスを開始することが望ましいものとなり得るかを表すパラメータである。実施形態において、遅延がトラフィックの異常増加をもたらす可能性があるため、しきい値は、新しいインスタンスを自動的に開始するのではなく、警告標識を生成することができる。第3のパラメータは、特定の時間より長い時間にわたってしきい値を超える場合に、新しいインスタンスが開始されると判断することができる。要するに、バッファ・サイズ、しきい値及びインスタンス開始の遅延等のパイプライン化特性は、ユーザが制御することができるパラメータである。
実施形態において、データ統合プラットフォーム2702の全ては、Ascential Software社からのDataStageサーバを用いるマシンである。それらの各々にデータ統合ジョブ3134が存在する場合があり、それはDataStageジョブとなる場合がある。RTI入力段階3138の存在は、バッチ処理時にジョブ・インスタンスが開始されるバッチ・モードと違って、ジョブ3134が常時アップされ、実行され、要求を待機することを意味する。動作においては、データ統合ジョブ3134は、データベース、ウェブ・サービス等とのその必要な接続の全てと共にアップされ実行され、RTI入力段階3138は、リスニングし、何らかのデータが入ってくるのを待機する。トランザクション毎に、ウェーブ・マーカの終端は、データ統合ジョブ3134の段階を通して移動することができる。RTI入力段階3138及びRTI出力段階3140は、データ統合ジョブ3134とRTIサービス環境のその他のものとの間の通信ポイントである。
例えば、ビジネス・エンタープライズのコンピュータ・アプリケーションは、トランザクション要求を送ることができる。RTIサーバ2802は、RTIデータ統合ジョブ3134が、実施形態において、Ascential Software社からのDataStageサーバである種々のデータ統合プラットフォーム2702上で実行されていると判断することができる。RTIサーバ2802は、コンピュータ・アプリケーションから、RTI入力段階3138が特定のデータ統合ジョブ3134について確認する必要があるものの中に、要求内のデータをマッピングすることができる。RTIエージェント3132は、データ統合プラットフォーム2702の各々の上で実行されているものを追跡することができる。RTIエージェント3132は、RTI入力段階3138及びRTI出力段階3140と共有されたメモリを用いて動作することができる。RTIエージェント3132は、ウェーブ・マーカの終端を用いてトランザクションにマーク付けし、トランザクションをRTI入力段階3138に送り込み、データ統合ジョブ3134が完了する際にウェーブ・マーカの終端を認識し、RTI出力段階3140から結果を取り出し、トランザクションを開始したコンピュータ・アプリケーションに結果を送り戻すことができる。
本明細書において説明されるRTI方法及びシステムは、データ統合プロセスが実行時バインディング(late binding)多重アクセス・プロトコルによってアクセス可能な管理された抽象サービスのセットとして公開されることを可能にする。Ascentialプラットフォーム等のデータ統合プラットフォーム2702を用いて、ユーザは、データ統合プロセス(一般的には、グラフィカル・ユーザ・インターフェースにおいてフローで表される)を作成することができる。次に、ユーザは、種々のアプリケーションによって、リアルタイムで同期的又は非同期的に呼び出すことができるサービスとしてフローによって定義されたプロセスを公開することができる。RTIサービスを最大限に利用するためには、JMSキュー(プロセスがデータをキューに送ることができ、アプリケーションがキューからデータを検索することができる)、Javaクラス、及びウェブ・サービス等の種々のプロトコルをサポートすることが望ましいであろう。バインディング多重アクセス・プロトコルは、種々のアプリケーションがRTIサービスにアクセスすることを可能にする。バインディングがアプリケーション別のプロトコル要件を処理するため、RTIサービスは、抽象サービスとして定義することができる。抽象サービスは、特定のプロトコル又は環境によってではなく、サービスが何を実行しているかによって定義される。より一般的には、RTIサービスを、ディレクトリにおいて発行し、多数のユーザと共有することができる。
RTIサービスは、多数の動作を有することができ、各々の動作はジョブによって実行することができる。サービスを作成するために、ユーザは、特定のウェブ・サービス、javaクラス等について承知している必要がない。RTIサービスを介して公開されることになるデータ統合ジョブを設計するときに、ユーザは、サービスがどのように呼び出されることになるかを承知している必要がない。ユーザは、RTIサービスを構築することができ、次いで、所与のデータ統合要求について、システムはRTIサービスを実行することができる。何らかの時点で、ユーザは、RTIサービスを1つ又は複数のプロトコルに結合し、該プロトコルは、ウェブ・サービス、Enterprise Java Bean(EJB)、JMS、JMX、C++、又はサービスを具体化できる多数のプロトコルのいずれかとすることができる。特定のRTIサービスについては、幾つかのバインディングが存在する場合があり、その結果、該サービスは、異なるプロトコルを有する異なるアプリケーションによってアクセスすることができる。
RTIサービスが定義されると、ユーザは、バインディング又は多数のバインディングを付加することができ、その結果、異なるプロトコルを用いる多数のアプリケーションが同時にRTIサービスを呼び出すことができる。通常のWSDL文書においては、サービス定義は、ポート・タイプを含むが、必然的にサービスがどのようにして呼び出されるかを伝える。ユーザは、特定のWSDL定義済みジョブに付加できる全てのタイプを定義することができる。例としては、SOAP over HTTP、EJB、Text Over JMS及びその他が挙げられる。例えば、EJBバインディングを作成するために、RTIサーバ2802は、Enterprise Java BeanのJavaソース・コードを生成することになる。サービスのデプロイにおいては、ユーザは、RTIコンソール3002を用いて、コンパイル・コードといった特性を定義し、Javaアーカイブ・ファイルを作成し、次いで、それをエンタープライズ・アプリケーションのユーザに与えて、ユーザのJavaアプリケーション・サーバ内にデプロイし、その結果、各々の動作がJavaクラスの1つのメソッドとなる。結果として、RTIサービス名とJavaクラス名との間に1対1対応が存在し、並びに、RTI動作名とJavaメソッド名との間にも対応が存在し得る。その結果、Javaアプリケーション・メソッドの呼び出しが、RTIサービス内の動作を呼び出すことになる。その結果、SOAP over HTTPを用いるウェブ・サービスとEJBを用いるJavaアプリケーションとが、RTIサービスを介して全く同じデータ統合ジョブに進むことができる。入口ポイント及び出口ポイントは、特定のプロトコルを必要とせず、そのため同じジョブが多数のプロトコルで動作することがある。
SOAP及びEJBバインディングが同期プロセスをサポートする一方で、他のバインディングは、非同期プロセスをサポートする。例えば、SOAP over JMS及びText over JMSは、非同期である。例えば、実施形態において、メッセージをキューに付加することができる。RTIサービスは、入力キューへの非同期入力を監視し、非同期的にその出力を別のキューに送ることができる。
図35は、RTIサービスのための内部アーキテクチャの概略図3200である。このアーキテクチャは、J2EE準拠サーバであるRTIサーバ2802を含む。RTIサーバ2802は、データ統合プラットフォーム2702のRTIエージェント3132と相互作用する。プロセス・プール・ファシリティ3102は、データ統合ジョブが渡されることになる適切なデータ統合プラットフォームのマシン2702を選択することによってプロジェクトを管理する。RTIサーバ2802は、データ統合ジョブを処理するためのジョブ・プール・ファシリティ3202を含む。ジョブ・プール・ファシリティ3202は、ジョブ及び各々が利用可能かどうかについてのステータスを列挙する、ジョブ・リスト3204を含む。ジョブ・プール・ファシリティは、キャッシュ・マネージャ及びRTIサーバ2802に渡されるジョブを処理する動作ファシリティを含むことができる。RTIサーバ2802は、該RTIサーバ2802を介してアクセスできるサービスのためのレジストリにWSDL記述を発行する等の、適切な公開又は専用レジストリとの相互作用を管理するためのレジストリ・ファシリティ3220をさらに含むことができる。
RTIサーバ2802は、EJBコンテナ3208をさらに含むことができ、該コンテナは、J2EEに従う、RTIサービスのためのRTIセッション・ビーン・ランタイム・ファシリティ3210を含む。EJBコンテナ3208は、メッセージ・ビーン3212、セッション・ビーン3214、及びRTIサービスを使用可能にするエンティティ・ビーン3218を含むことができる。EJBコンテナ3208は、JMSインターフェース3222、EJBクライアント・インターフェース3224、及びAxisインターフェース3228を含む種々のインターフェースを容易にすることができる。
図36を参照すると、RTIサーバ2802とRTIエージェント3132との相互作用のアスペクトは、RTIエージェント3132が、次にデータ統合ジョブのためにジョブ・インスタンス3302に渡されるサービス要求のパイプラインを管理することである。ジョブ・インスタンス3302は、データ統合プラットフォーム2702上で実行され、RTI入力段階3138及びRTI出力段階3140を有する。必要に応じて、1つより多くのジョブ・インスタンス3302が、特定のデータ統合プラットフォーム2702上で実行されている場合がある。RTIエージェント3132は、サービス要求がRTIサーバ2802からそれに渡される際のジョブ・インスタンスのオープン及びクローズを管理する。通常のバッチ・タイプのデータ統合とは対照的に、RTIサービスのための各々の要求は、ジョブのパイプライン3304においてRTIサーバ2802、RTIエージェント3132、及びデータ統合プラットフォーム2702を介して伝わる。パイプライン3304は、例えば、パイプライン3304の種々のパラメータを設定することによって、RTIエージェント3132において管理することができる。例えば、パイプライン3304は、バッファを有することができ、そのサイズは、最大のバッファ・サイズ・パラメータ3308を用いてユーザによって設定することができる。管理者は、RTIエージェント3132が新しいジョブ・インスタンス3302を開始する前に受け入れることになる遅延時間、すなわち、インスタンスの開始遅延3310等の他のパラメータを設定することもできる。管理者はまた、パイプラインが所与のジョブ・インスタンス3302を受け入れることができるサービス要求数を表す、パイプラインについてのしきい値3312を設定することもできる。
RTIサービスは、検索可能なレジストリにおいて管理することができる。RTIサービスは、該サービスに付加されたプロトコルを使用している、それに付加された書き込み済みアプリケーションを有することができる。例えば、顧客を付加し、顧客を削除し、又は顧客の住所を確認する等の顧客管理動作は、既知のウェブ・サービス・プロトコルを使用することもできるし、或いはそれに付加することもできる。顧客管理アプリケーションは、該アプリケーションがRTIサービスのクライアントである場合には、RTIサービスに付加することができる。換言すれば、事前定義アプリケーションは、該アプリケーションがRTIサービスを呼び出すか又は使用する場合には、RTIサービスに付加することができる。結果としては、ユーザがオンデマンドのサービスを特定のデバイスにダウンロードし、該デバイスから(該デバイスの上で)それを実行することができる。
例えば、ポケットPC等のモバイル・コンピューティング・デバイスは、ホスティング環境を有することができる。モバイル・コンピューティング・デバイスは、多数のダウンロードされたアプリケーション及び利用可能なアプリケーションと共に、モバイル・データ統合サービスのためのアプリケーションのようなアプリケーションを有することができる。モバイル・デバイスは、アプリケーションをブラウズすることができる。それが、RTIサービスに付加されているアプリケーションをダウンロードするときには、アプリケーションは、モバイル・デバイスに無線でダウンロードされるが、それは、同時にそれに付加されたRTIサービスを呼び出す。結果として、ユーザは、同時にエンタープライズからリアルタイムで統合データにアクセスできる状態で、モバイル・アプリケーションのデプロイを有することができる。したがって、エンタープライズがユーザに最新のデータを持たせることから利益を得る場合に、RTIサービスは、非常に効果的なモデルをモバイル・コンピューティング・アプリケーションに提供することができる。
一般的な形のエンタープライズ・コンピュータ・システム1300のためのデータ統合システム104の種々の態様をここで説明してきたが、種々の市販のアプリケーション及び他のアプリケーションを包含するデータ統合システム104についての幾つかの例をここで提供する。
図37に示すように、RTIサービス3412を用いるデータ統合システム104は、金融サービス業界と関連させて使用することができる。リアルタイム・データ統合は、金融サービス業界におけるビジネス・エンタープライズが、ともすれば存在することになるリスクを回避することを可能にする。例えば、金融機関3402の1つの支店が消費者3404の貸付申し込み3410を扱う間、別の支店が株式3408の取引を実行する場合には、該機関3402は、貸付を行う際に快諾できる以上の多くのリスクを負う可能性がある。リアルタイム・データ統合は、所与の取引が実行されるときに金融機関が消費者3404のより正確なプロファイルを有することを可能にする。したがって、RTIサービス3412は、貸付申し込みに関連したコンピュータ・アプリケーションが消費者3404の株式勘定についての最新の詳細データを要求することを可能にし、この株式勘定は、株式取引3408を扱う金融機関3402のアプリケーションと関連したデータからRTIサービス3412を介して検索することができる。もちろん、金融機関ばかりでなく、多くの企業の財務部は、リアルタイム・データ統合から利益を得ることができる同様の財務的な決定を下すことができる。
ビジネス・エンタープライズは、各種の環境において及び多くの目的で、本明細書において説明されるRTIサービス等の、リアルタイム・データ統合サービスから利益を得ることができる。一例は、動作報告及び分析の領域にある。中でも、RTIサービスは、大量のバッチ・データを伴うリアルタイム・トランザクション分析についての整理統合された表示を提供することができる。図38を参照すると、エンタープライズ・データ・ウェアハウス、データマート、データベース等のような、ビジネス・エンタープライズの重要なデータ・ソース3504の全てに対してリアルタイムで呼び出すRTIサービス3502を構成することができる。次に、RTIサービス3502は、整合性のあるデータ・レベルの変形を、データ・ソース3504からのデータに適用することができる。このように使用されると、RTIサービスは、ソース・システム分析を自動化し、伝送途中のリアルタイムのデータ品質管理を提供することもできる。金融サービス領域の詐欺検出及びリスク分析、在庫管理、小売領域の予測及びマーケット・バスケット分析、金融領域の順守活動、並びに、小売領域の減少分析及びスタッフ・スケジューリング等のこうしたRTIサービスから利益を得ることができるビジネス・エンタープライズの多くの動作報告又は分析プロセスが存在する。1つより多くのソースからのデータから利益を得ることができる如何なる分析又は報告タスクも、同様に、明確に定義されたデータ統合ジョブに従ってリアルタイムで実行中にデータを検索し統合するRTIサービスから利益を得ることができる。
本明細書において説明されるようなRTIサービスから利益を得ることができる別のクラスのビジネス・プロセスは、レコード・データベースのマスタ・システムを作成することを含むビジネス・プロセスのセットである。図36を参照すると、エンタープライズは、顧客3604等の特定のトピックについてのデータを含む多くのデータベースを有することができる。例えば、顧客の情報は、販売データベース3608、CRMデータベース3610、サポート・データベース3612及び金融データベース3614において見ることができる。実際には、実ビジネス・エンタープライズにおいては、これらの部門の各々がそれら自身の多数のデータベースを有することは珍しくない。データ統合努力からの所望の利点の1つは、多くのデータベースにわたるデータ整合性を確立することである。例えば、顧客の住所変更等のトリガ・イベント3618については、ビジネスの1つのエンティティのみが最初に情報を受け入ることができるが、全ての異なる部門が変更にアクセスできることが好ましいであろう。RTIサービスは、ネイティブ・データベースにおける変更を要求することなく、レコードのマスタ・システムを作成する可能性を与える。したがって、異なるプロトコルを使用するものを含む異種の情報のサイロをリンクするRTIプロセス3602を定義することができる。多数のバインディングをサポートすることによって、RTIプロセスは、異なるフォーマットの種々のアプリケーションへの入力を受け入れ、出力をそれらに提供することができる。一方、RTIサービスのビジネス論理は、全ての入力データについてのデータの標準化を実行し、全てのデータについてのメタ・リネージュ情報を提供し、異種のデータ・ソース間のリンケージを維持する等の、データ統合タスクを実行することができる。結果は、RTIサービスとしてアクセスできる、リアルタイムの最新のマスター・レコード・サービスである。
マスター・レコードから利益を得ることができるアプリケーションの多くの例が存在する。金融サービスにおいては、機関は、顧客マスター・レコード、並びに、全エンタープライズにわたるセキュリティ・マスター・レコードを有することを望む場合がある。通信、保険、及び膨大な顧客を扱う他の業界においては、マスター・レコード・サービスは、整合請求処理、クレーム処理等をサポートすることができる。小売エンタープライズにおいては、マスター・レコードは、POSアプリケーション、ウェブ・サービス、顧客マーケティング・データベース、及び在庫同期化機能をサポートすることができる。製造及び物流作業においては、ビジネス・エンタープライズは、設計、製造、在庫、販売、返品、サービス義務、保証情報等についての情報のような、異なるソースからの製品に関するデータについてのマスター・レコード・プロセスを確立することができる。他の場合には、ビジネスは、RTIサービスを用いて、ERPインスタンスの整理統合をサポートすることができる。マスター・レコードを具体化するRTIサービスにより、異なるデータ・ソースが互いに通信できるようにするためにネイティブ・アプリケーションへのコード化を必要としないデータ統合の利益が与えられる。
図40の実施形態は、マスター顧客データベース3700を提供する。マスター顧客データベース3700は、内部システムと外部システムとの両方を含む、顧客についてのあるデータを含む多くの異なるデータベースにわたる統合顧客表示を含むことができる。マスター顧客データベースは、全ての異なるソースから顧客についての「最適な」データを含むことになるマスタ・システムとなる。マスター顧客データベースを確立するために、データ統合は、データの一致、標準化、整理統合、変形及び強化を必要とし、これらの全てがRTIサービス3702によって実行される。あるデータをバッチ・モードで処理することができる一方で、新しいデータは、急速に変化しているデータが利用可能な最も正確なデータであることを保証するために、リアルタイムで処理される必要がある。マスター顧客データベースは、小売、金融サービス、製造、物流、専門サービス、医療及び製薬、通信、情報技術、バイオテクノロジ、又は多くのその他を含む、ほぼあらゆる分野におけるビジネス・エンティティによって使用され得る。同様のデータ管理は、協会、学術機関、政府機関、又はその他のあらゆる大きな組織若しくは機関について望ましいものとなり得る。
本明細書において説明されるRTIサービスはまた、変形、検証及び標準化ルーチン等のデータ統合タスクをトランザクション・ビジネス・プロセスに公開する多くのサービスをサポートすることもできる。したがって、RTIサービスは、実行中のデータ品質、強化及び変形を提供することができる。アプリケーションは、ビジネス・エンタープライズ全体にわたる標準ビジネス論理の再使用を促進する、サービス指向アーキテクチャを介してこうしたサービスにアクセスすることができる。図41を参照すると、上述のRTIサービス2704とすることができるRTIサービス3802は、AscentialのDataStageプラットフォーム等のデータ統合プラットフォーム3804によって具体化されるもののような、データ変形、検証及び標準化ルーチンのセットを具体化する。アプリケーション3808は、実行中にデータ統合タスクを達成するために、RTIサービス3802を呼び出すイベントをトリガすることができる。
多くのビジネス・プロセスが、リアルタイム変形、検証及び標準化ルーチンから利益を得ることができる。これは、テレマーケティング業界におけるコール・センターのアップセリング及びクロスセリング、金融業界における再保険のリスク検証、小売業におけるPOS会計の作成、並びに、医療及び情報技術サービス等の分野における強化されたサービス品質を含むことができる。
図42を参照すると、リアルタイム統合サービスから利益を得ることができるビジネス・プロセスの例は、損害保険等の保険証券についての引受業務等の引受プロセス3900である。資産引受プロセスは、テキスト・ファイル3902、スプレッドシート3904、ウェブ・データ3908等のような、異なるタイプの様々な異なるデータ・ソースへのアクセスを必要とする場合がある。データは、不整合となり、エラーを起こしやすい場合がある。補助データを得るためのリードタイムが、引受決定を遅らせる。メイン引受データベース3910は、あるデータを含むことができるが、他の関連データは、環境データベース3912、占有データベース3914及び地理データベース3918等の、種々の他のデータベースに含めることができる。結果として、引受決定は、異なるソース及びデータベースからのデータが決定時に統合されない場合には、欠陥のある仮定に基づいて下されることがある。
リアルタイム統合サービスを用いて種々のデータ・ソース3902、3904、3908、3912、3914、3918へのアクセスを統合することによって、引受決定の速度及び正確さを改善することができる。図43を参照すると、RTIサービスは、引受決定の品質を改善することができる。テキスト・ファイル、スプレッドシート及びウェブ・ファイルは、各々をRTIサービスに入力することができ、該RTIサービスは、ウェブ・インターフェース3902等を介してRTIサーバ3904上で実行される上述のRTIサービス2704のいずれかとすることができる。環境データベース3912、占有データベース3914、及び地理データベース3918、並びに、引受データベース3910は、全てデータ統合ジョブ4012によって呼び出すことができ、該データ統合ジョブは、Ascential Software社のQualityStage製品によって具体化されるようなCASSプロセス4010及びWaveプロセス4008を含むことができる。RTIサービスは、それらのデータベースの各々についてプロトコルのためのバインディングを含むことができる。この結果は、全てがRTIサービスによってイネーブルとなる、スケジュールの全てからの現在の情報、並びに、異なるデータベースから利益を得る引受決定の統合プロセスである。例えば、引受プロセスは、現在の住所情報を必要とし、上述のようなRTI統合ジョブは、異なるソースから何千もの住所を迅速に統合することができる。
エンタープライズ・データ・サービスもまた、本明細書に説明されるように、データ統合から利益を得ることができる。特に、RTI統合プロセスは、標準的な整理統合されたデータ・アクセス及び変形サービスを提供することができる。RTI統合プロセスは、内部と外部の両方の、異なるデータ・ソースへの仮想アクセスを提供することができる。RTI統合プロセスはまた、実行中のデータの品質強化及び変形を提供することができる。RTI統合プロセスはまた、該プロセスを通過する全てのメタデータを追跡することもできる。図44を参照すると、1つ又は複数のRTIサービス4102、4104は、データ・サービスを提供するために、エンタープライズ内で動作することができる。それらの各々が、データ統合ジョブ4108をサポートすることができる。データ統合ジョブ4108は、エンタープライズの内部と外部の両方の、異なる固有言語及びプロトコルを有する異種のデータ・ソースとすることができるデータベース4110にアクセスすることができる。エンタープライズ・アプリケーションは、RTIサービス4102、4104を介してデータ統合ジョブ4108にアクセスすることができる。
図45を参照すると、リアルタイム統合サービスから利益を得ることができる別のビジネス・エンタープライズは、トラック輸送業者等の分散エンタープライズである。トラック輸送業者は、場所から場所へと商品を運ぶ複数のトラック4202を扱うことがある。トラック4202は、トラック4202が或る場所に到着するときにトラック4202がログインすることを可能にするアプリケーションのような単純なアプリケーション4204を実行する、リモート・デバイスを有することがある。トラック4202のドライバは、ドライバがチェックポイントへの到着といったデータを入力するために使用できるLandStarサテライト・システム・デバイス等の、モバイル・コンピュータ・デバイスを有することが多い。エンタープライズそれ自体は、運賃勘定アプリケーション4208、エージェント・プロセス4210、及びチェック呼び出しアプリケーション4212といった、幾つかのコンピュータ・アプリケーション又はデータベースを有することがある。しかしながら、これらのネイティブ・アプリケーションは、有用な情報をドライバに提供することができるプロセスを処理するが、一般に、トラック4202のモバイル・デバイス上で動作するようにはコード化されていない。例えば、ドライバが移動をスケジューリングできることを望む場合があるが、移動スケジューリング・アプリケーションは、トラック4202のモバイル・デバイスに常駐していないデータ(どんな他の移動が完了したか等)を要求する場合がある。
図46を参照すると、RTIサービス・モデルを用いて、一連のデータ統合サービス4302を、ドライバがモバイル・デバイスを用いるなどしてウェブ・サービスとしてアクセスできるアプリケーション4310をサポートするように定義することができる。例えば、アプリケーション4310は、ドライバがトラック輸送業者・エンタープライズからのデータを用いて彼のスケジュールを更新することを可能にすることができる。RTIサーバ3904は、アプリケーション4310がウェブ・サービス4308としてアクセスするデータ統合サービス4302からデータ統合ジョブを発行する。データ統合サービス4302は、運賃勘定アプリケーション4208及びエージェント・プロセス4210からのデータを含む、どんな他のジョブが既に完了したかといった、エンタープライズからのデータを統合することができる。上述のRTIサービス2704のいずれかとすることができるRTIサービスは、例えばスケジューリング・アプリケーションを提供するために、ドライバのアプリケーションのためのスマート・グラフィカル・ユーザ・インターフェースとして機能することができる。ドライバは、アプリケーションをモバイル・デバイスにダウンロードして、サービスを呼び出すことができる。結果として、RTIサービス・モデルを用いると、モバイル・デバイス上でRTIサービスを使用するアプリケーションのためのインフラストラクチャが都合よく提供される。
別の例(図示せず)として、データ統合を、在庫管理及び生鮮商品の配送といったサプライ・チェーン管理を改善するのに用いることができる。例えば、サプライ・チェーン・マネージャが種々の小売店の場所で現在の在庫レベルの現在のピクチャを有する場合には、マネージャは、低い在庫レベル又は高い需要を有する店へのさらなる配送又は部分出荷を指示して、商品のより効率的な配送をもたらすことができる。同様に、マーケティング・マネージャが(その国の異なる地方等の)小売店又は倉庫における在庫レベルに関する現在の情報及び需要に関する現在の情報を有する場合には、マネージャは、需要が少ないか又は在庫レベルが意外と高い品目の価格を下げるなどしてその情報に対処するために、値付け、広告、又は販売促進を構造化することができる。もちろん、これらは例に過ぎず、好ましい実施形態において、マネージャは、非常に複雑なビジネス決定をリアルタイムに下すことを可能にする広範なデータ・ソースにアクセスすることができる。
こうしたシステムの可能性のあるアプリケーションは、文字通り無限にある。減量会社は、データ統合を用いて、既存の顧客から会社への収益を上げるために使用できる新しいマーケティング機会についての顧客データベースを作成することができる。金融サービス会社は、データ統合を用いて、銀行業者、管理者及び分析家のための顧客収益性の報告及び分析についての単一の有効なソースを作成することができる。製薬会社は、データ統合を用いて、種々のテキスト・データ・フィールド内の自由形式のデータを含む、異なる標準及びフォーマットを用いて様々なレガシ・データ・ソースからデータ・ウェアハウスを作成することができる。ウェブ・ベースの市場プロバイダは、データ統合を用いて、買い物客とオン・ライン商店との間の数百万もの日々の取引を管理することができる。銀行は、データ統合サービスを用いて、現在の顧客についてより多くを学び、普通預金、当座預金、クレジット・カード、預金証書、及びATMサービス等の製品の提供を改善することができる。通信会社は、データ統合システムを並列処理する高い処理能力を用いて、コーリング・キャンペーンの引き受け数を増加させることができる。輸送会社は、データ統合システムを並列処理する高い処理能力を用いて、1日に4回というように1日の間にサービスを再値付けすることができる。投資会社は、データ統合システムを並列処理する高い処理能力を用いて、SECトランザクションの解決時間要件に応じ、一般に時間、費用、及び金融トランザクションを解決するのに必要な努力を減少させることができる。医療プロバイダは、データ統合システムを用いて、米国医療保険の携行性と責任に関する法律の条件を満たすことができる。ウェブ・ベースの教育プロバイダは、データ統合システムを用いて、学生のライフサイクルを監視し、求人努力並びに生徒の進捗及び保留を改善することができる。
特定の市販のデータ統合システム・アプリケーションについての多数の付加的な例をここで提供する。
図47は、財務報告について使用できるデータ統合システム104を示す。この例において、システム4400は、販売及び発注処理システム4402、総勘定元帳4404、データ統合システム104、並びに、金融及び会計の財務報告データ・ウェアハウス4408を含むことができる。販売・発注処理システム4402、総勘定元帳4404、及び金融・会計財務報告データ・ウェアハウス4408は、各々が上述のデータ・ソース102のいずれかのようなデータ・ソース102を含むことができる。販売・発注処理システム4402は、価格、量、日付、時間、発注数及び注文書の取引条件その他のデータ、並びに、システム4400によって処理及び/又は記録できる如何なるトランザクションをも特徴付けるその他のあらゆるデータ等の、販売及び発注処理中に収集されるデータを格納することができる。総勘定元帳4404は、バランス・シート、キャッシュ・フロー、損益計算書及び財務契約データ等のその財政を追跡するビジネスに関係し得るデータを格納することができる。金融及び会計の財務報告データ・ウェアハウス4408は、財務及び会計部門に関係するデータ、並びに、異なる財務及び会計システムからのデータ等のビジネス機能を格納することができる。
システム4400は、1つ又は複数のデータ統合システム104を含むことができ、該システムは、データを販売及び発注処理システム4402及び総勘定元帳4404から抽出することができ、上述のように、こうしたデータを転送し、分析し、処理し、変形し、又は操作することができる、上述のデータ統合システム104のいずれかとすることができる。如何なるこうしたデータ統合システム104も、金融・会計財務報告データ・ウェアハウス4408、データ・リポジトリ又は上述のデータ・ソース102のいずれかとすることができる他のデータ・ターゲット内にこうしたデータをロードすることができる。データ統合システム104のいずれも、リアルタイムの更新又は入力を任意のデータ・ソース102から受け取るように構成し、及び/又は対応する金融・会計財務報告データ・ウェアハウス4408又は他のデータ・ターゲットへの対応するリアルタイム出力を生成するように構成することができる。任意的に、データ統合システム104は、営業日の終わり若しくは報告周期の終わりに又はユーザ要求等の任意の外部イベントに応じて、周期ベースでデータを抽出し、転送し、分析し、処理し、変形し、操作し、及び/又はロードすることができる。
このようにして、現在の金融及び会計情報を会社に提供できるデータ・ウェアハウス4408を作成し、保持することができる。このシステム4400により、会社がその財務実績とその財務目標とをリアルタイムで比較することが可能となり、会社が偏差に迅速に対応することが可能になる。このシステム4400はまた、会社があらゆる法的又は規制上の必要条件、或いは私的な借金又はその貸付の他の契約とのその順守を評価することを可能にし、このようにして、それがそのアクションと関連した如何なる付加的な費用又は違約金をも算出することを可能にすることができる。
図48は、小売又は他の店若しくは会社において、POS、顧客関係管理、及び他のアプリケーション及び/又はデータベースと共に使用される、顧客についての現在の正確な権限リストを作成し、保持するのに使用されるデータ統合システム104を示す。この例においては、システム4500は、POSアプリケーション4502、POSデータベース4504、顧客関係管理アプリケーション4508、顧客関係管理データベース4510、データ統合システム104、及び顧客データベース4512を含むことができる。
POSアプリケーション4502は、ネットワーク若しくは独立型コンピュータ、手持ちサイズのデバイス、手のひらサイズのデバイス、携帯電話、バーコード・リーダ、又は以上の任意の組み合わせ、或いは販売、交換、返品又は他の業務の処理又は記録についてのその他のあらゆるデバイス又はそれらのデバイスの組み合わせの上で動作するか又は格納されるコンピュータ・プログラム、ソフトウェア又はファームウェアとすることができる。POSアプリケーションは、上述のデータ・ソース102のいずれかを含むことができるPOSデータベース4504にリンクすることができる。POSデータベース4504は、販売、交換、返品、及び/又は価格、量、日付、時間、発注番号データ等の他のトランザクション中に収集されたデータ、並びに、POSアプリケーション4502によって処理又は記録できる如何なるトランザクションをも特徴付けるその他のあらゆるデータを含むことができる。顧客関係管理アプリケーション4508は、ネットワーク若しくは独立型コンピュータ、手持ちサイズのデバイス、手のひらサイズのデバイス、携帯電話、バーコード・リーダ、又は以上の任意の組み合わせ、或いは名前、住所、会社組織、誕生日、注文履歴、信用格付け、及び如何なる顧客、他の個人若しくはエンティティをも特徴付けるか又はそれに関連するその他のあらゆるデータ等の、顧客、他の個人若しくはエンティティについての情報の入力、格納、分析、操作、表示及び/又は検索のためのその他のあらゆるデバイス又はそれらのデバイスの組み合わせの上で実行するか又は格納されるコンピュータ・プログラム、ソフトウェア又はファームウェアとすることができる。顧客関係管理アプリケーション4508は、上述のデータ・ソース102のいずれかを含むことができる顧客関係管理データベース4510にリンクすることができ、顧客、他の個人及び/又はエンティティについての情報を含むことができる。
上述のデータ統合システム104のいずれかとすることができるデータ統合システム104は、別個にPOSアプリケーション4502又はデータベース4504、顧客関係管理アプリケーション4508又はデータベース4510、或いは顧客データベース4512のいずれかからデータを抽出するか、又はそのいずれかにデータをロードすることができる。データ統合システム104はまた、上述のように、こうしたデータを分析し、処理し、変形し、又は操作することもできる。例えば、顧客サービス担当者又は他の従業員は、冷凍庫又は洗濯機等の家庭用耐久財の購入後の儀礼訪問中に、顧客関係管理アプリケーション4508を用いて顧客の住所を更新することができる。次に、顧客関係管理アプリケーション4508は、更新された住所データを顧客関係管理データベース4510に転送することができる。次に、データ統合システム104は、更新された住所データを顧客関係管理データベース4510から抽出し、それを共通フォーマットに変形し、それを顧客データベース4512にロードすることができる。顧客が次回購入するときに、レジ係又は他の従業員は、POSアプリケーション4502を用いて取引を完了することができ、該アプリケーションは、データ統合システム104を介して、顧客データベース4512内の更新された住所データにアクセスすることができ、その結果、レジ係又は他の従業員は、それを該POSアプリケーション4502に入力するのではなく、ただ住所情報を確認しさえすればよい。さらに、POSアプリケーション4502は、新しい取引データをPOS販売データベース4504に転送することができる。次に、データ統合システム104は、取引データをPOSデータベース4504から抽出し、それを共通フォーマットに変形し、それを顧客データベース4512にロードすることができる。結果として、新しい取引データは、POS及び顧客関係管理アプリケーション及びデータベース、並びに、ビジネス・エンタープライズによって保持されるその他のあらゆるアプリケーション又はデータベースにアクセス可能である。
このようにして、その顧客の各々に関する現在の正確で完全なデータを小売又は他の店若しくは会社に提供できる顧客データベース4512を作成し保持することができる。こうした情報を用いて、店又は会社は、その顧客により良い応対をすることができる。例えば、顧客サービスにより、顧客の次の購入の際にその顧客に割引が与えられる場合には、POSアプリケーション4502を用いるレジ係又は他の従業員は、割引を確認し、割引が使用されたという通知を記録することができる。このシステム4500はまた、店又は会社が顧客の不正を防止することを可能にすることもできる。例えば、電話を通じて顧客の苦情を受ける顧客サービス担当者又は他の従業員は、顧客関係管理アプリケーション4508を用いて、製品が依然として店又は製造業者の保証期間内であるかを彼らが判断できるようにする特定の製品の購入日付を判定するためにPOS情報にアクセスすることができる。
図49は、薬の補充、又は小売薬局において生成され又は格納される他の情報を、薬局卸売業者又は他の関係者と共に使用するための業界標準XML又は他の言語に変換するために使用できるデータ統合システム104を示す。この例においては、このシステム4600は、小売薬局4602、薬の補充情報、データ統合システム104、及び薬局卸売業者4604を含むことができる。
小売薬局4602は、ネットワーク若しくは独立型コンピュータ、手持ちサイズのデバイス、手のひらサイズのデバイス、携帯電話、バーコード・リーダ、又は以上の任意の組み合わせ、或いは薬の補充又は他の情報を収集し、生成し、又は格納するためのその他のあらゆるデバイス又はそれらのデバイスの組み合わせの上で動作し又は格納されるアプリケーション、コンピュータ・プログラム、ソフトウェア又はファームウェアを使用することができる。こうしたアプリケーション、コンピュータ・プログラム、ソフトウェア又はファームウェアは、在庫レベル、在庫日数、補充される注文等の薬の補充情報を含む上述のデータ・ソース102のいずれかのような少なくとも1つのデータ・ソース102を含むことができる、1つ又は複数のデータベースにリンクすることができる。こうしたアプリケーション、コンピュータ・プログラム、ソフトウェア又はファームウェアはまた、上述のデータ統合システム104のいずれかとすることができる1つ又は複数のデータ統合システム104にリンクすることもできる。薬局卸売業者4604は、ネットワーク若しくは独立型コンピュータ、手持ちサイズのデバイス、手のひらサイズのデバイス、携帯電話、バーコード・リーダ、又は以上の任意の組み合わせ、或いは業界標準XML又は別の言語若しくはフォーマットにおいて、薬の補充情報を受け取り、分析し、処理し、又は格納するためのその他のあらゆるデバイス又はそれらのデバイスの組み合わせの上で動作するか又は格納されるアプリケーション、コンピュータ・プログラム、ソフトウェア又はファームウェアを使用することができる。こうしたアプリケーション、コンピュータ・プログラム、ソフトウェア又はファームウェアはまた、薬の補充情報を含む、上述のデータ・ソース102のいずれかを含むことができるデータベースにリンクすることができる。
システム4600は、上述のデータ統合システム104のいずれかとすることができる1つ又は複数のデータ統合システム104を含むことができる。データ統合システム104は、薬の補充情報を小売薬局4602から抽出し、薬の補充情報を業界標準XMLに変換し、又は別の方法でこうした情報を分析し、処理し、変形し、又は操作し、次いで、自動的に又は要求時に、こうした情報を薬局卸売業者4604にロードするか又は転送することができる。例えば、顧客が所与の小売薬局4602で風邪薬Xの最後から2番目のボトルを購入する場合がある。販売した直後に、その小売薬局のシステムは、薬局4602が特定の期日前に特定のボトル数だけ風邪薬Xの在庫を増やし、次いで、薬の補充情報をデータ統合システム104に送る必要があると判断することができる。次に、データ統合システム104は、薬の補充情報を業界標準XMLに変換し、それを薬局卸売業者のシステムにアップロードすることができる。次に、薬局卸売業者4604は、所与の薬局4602が指定日前に要求されたボトル数を受け取ることを自動的に保証することができる。
このようにして、サプライ・チェーンの中断及び費用が最小限となるような形で小売薬局4602が薬局卸売業者4604と通信できるようにするシステム4600を作成することができる。このシステム4600は、小売薬局4602が在庫要求を薬局卸売業者4604に自動的に通信することができるようにして、過剰在庫保持費用、期限切れ製品及び取引による浪費、並びに、薬局卸売業者への返品に関連した他の費用を削減する。このシステム4600は、付加的なデータ統合システム104が補足されて、信用履歴レビュー、支払い、並びに、薬局卸売業者のための良好な信用リスク及び適時支払いを保証する他の金融サービスをサポートすることができる。
図50は、データが動作の最適化、意思決定及び他の機能のために使用されることを可能にする、エンタープライズ・アプリケーション統合、メッセージ指向ミドルウェア及びウェブ・サービス等の、ビジネス・アプリケーション及び統合技術4708から呼び出される予め構築されたサービス4704を介して製造分析データ4702へのアクセスを提供するのに使用できるデータ統合システム104を示す。この例においては、システム4700は、在庫、部品、販売、給与、人材及び他のデータ等の製造分析データ4702、予め構築されたサービス4704、ビジネス・アプリケーション及び統合技術4708、ユーザ4710、データ統合システム104、及びユーザ・ビジネス・アプリケーション4712を含むことができる。
ユーザ4710は、ネットワーク若しくは独立型コンピュータ、コンピュータ・システム、手持ちサイズのデバイス、手のひらサイズのデバイス、携帯電話、又は以上の任意の組み合わせ、或いはその他のあらゆるデバイス又はデバイスの組み合わせの上で動作するか又は格納されるビジネス・アプリケーション及び統合技術4708を用いて、製造分析データへのアクセスを提供するために予め構築されたサービス4704を呼び出すことができる。予め構築されたサービス4704は、上述のデータ統合システム104、或いは、データ又は他の情報を転送し、分析し、修正し、処理し、変形し、又は操作することができる他のインフラストラクチャとすることができる。予め構築されたサービス4704は、上述のデータ・ソース102のいずれか等のデータ・ソース102を含むことができるデータベースを使用することができ、製造分析データ4702は、該データベースに格納することができる。ユーザ・ビジネス・アプリケーション4712は、ネットワーク若しくは独立型コンピュータ、手持ちサイズのデバイス、手のひらサイズのデバイス、携帯電話、又は以上の任意の組み合わせ、或いは、製造分析データ4702又は他の情報の処理又は分析のためのその他のあらゆるデバイス又はそれらのデバイスの組み合わせの上で動作するか又はそこに格納されるコンピュータ・プログラム、ソフトウェア又はファームウェアとすることができる。ユーザ・ビジネス・アプリケーション4712は、上述のデータ・ソース102のいずれか等のデータ・ソース102を含むデータベースにリンクすることができる。
システム4700は、上述のデータ統合システム104のいずれかとすることができる1つ又は複数のデータ統合システム104を含むことができ、それは、ビジネス・アプリケーション及び/又は統合技術4708又は他のユーザ関連又は外部イベントを介して、或いは、周期ベースでユーザ入力に応答して、製造分析データ4702又は他のデータを抽出し、分析し、修正し、処理し、変形し、又は操作することができ、該データの表示、格納若しくはさらなる処理、分析、又は操作のためにユーザ・ビジネス・アプリケーション4712に利用できる結果を作ることができる。
例えば、既存のビジネス・アプリケーション及び統合技術4708を用いるマネージャは、予め構築されたサービス4704を介して特定の製造分析データ4702にアクセスすることができる。マネージャは、在庫にある特定のグループの部品の数及び部品を組み立てるのに十分な従業員を用意するのに関連した給与費用を決定することができる。データ統合システム104は、必要なデータを在庫、部品、給与及び人材データベースから抽出し、分析し、統合し、これらの結果をマネージャのビジネス・アプリケーション4712にアップロードすることができる。次に、ビジネス・アプリケーション4712は、これらの結果を幾つかのテキスト及びグラフィカル・フォーマットで表示し、さらなる分析要求に対してユーザ(管理者)に促すことができる。
このようにして、エンタープライズにわたる管理者及び他の意思決定者は、それらが要求するデータにアクセスすることを可能にするシステム4700を作成することができる。このシステム4700は、エンタープライズ内のアクタが所与の時点で利用可能な全データの統合表示に基づいてより多くの情報を得て決定を下すことを可能にする。さらに、このシステム4700は、エンタープライズが多くの異なるデータ・ソース102からのデータを迅速に統合し、短時間でエンタープライズの広範囲の分析を得ることができるため、エンタープライズがより速い決定を下すことを可能にする。全体的に、このシステム4700は、エンタープライズがその動作、意思決定、及び他の機能を最適化することを可能にする。
図51は、イベント駆動ベースで薬物動態データ・ウェアハウス4802にロードするための臨床試験の研究成果を分析的に処理するのに使用できるデータ統合システム104を示す。この例においては、システム4800は、臨床試験研究4804、臨床試験研究データベース4808、イベント4810、データ統合システム104、及び製薬動態データ・ウェアハウス4802を含むことができる。
臨床試験研究4804は、各々が上述のデータ・ソース102のいずれかのようなデータ・ソース102を含む1つ又は複数の臨床試験研究データベース4808に格納可能なデータを生成することができる。各々の臨床試験研究データベース4808は、患者の名前、住所、健康状態、取次ぎ及び投薬、所与の薬についての吸収速度、分布速度及び消失速度、政府の認可及び倫理委員会の認可情報、並びに、臨床試験研究4804と関連し得るその他のあらゆるデータ等の、臨床試験研究4804の際に収集されるデータを含むことができる。薬物動態データ・ウェアハウス4802は、臨床試験研究データベース4808に格納されたもの等のデータを含む臨床試験研究4804に関係するデータ、並びに、薬の相互作用及び特性、生化学、化学、物理学、生物学、生理学、医学論文又は他の関連情報若しくはデータに関連するデータ及び情報を含む上述のデータ・ソース102のいずれかを含むことができる。外部イベント4810は、ユーザ入力、或いは、特定の研究又は他の結果若しくはその他のあらゆる指定イベントの達成とすることができる。
システム4800は、上述の1つ又は複数のデータ統合システム104を含むことができ、該システムは、外部イベント4810に応答して、或いは、営業日の終わり又は報告周期の終わり等の周期ベースで、臨床試験研究データ4804又は他のデータを抽出し、修正し、変形し、操作し、又は分析的に処理することができ、薬物動態データ・ウェアハウス4802に利用可能な結果を作ることができる。例えば、外部イベント4810は、研究助成金アプリケーションと関連させて特定の情報の要件とすることができる。助成金審査委員会は、それが関連する臨床試験資金の割り当てを約束する前に、進行中の臨床試験における薬物吸収反応についてのデータを要求する場合がある。システム4800を用いて、必要なデータを臨床試験研究データのデータベース4808から抽出し、該データを分析的に処理して、例えば、薬物の平均、中間、最大及び最小吸収速度を求め、これらの結果を他の研究のものと、同様の薬物について比較することができる。次に、この情報全てを助成金審査委員会に提供することができる。
このようにして、研究者及び第三者が、完了した臨床試験及び進行中の臨床試験からの情報を含む完全で正確な薬物動態情報に迅速にアクセスすることを可能にする、システム4800を作成することができる。このシステム4800は、研究者及び第三者が、深刻化する前に事前結果を生成し、悪影響又は傾向を検出することを可能にする。このシステム4800はまた、研究者及び第三者が所与の研究の進行中又は最終結果を他の研究、学説又は確立された原理のものにリンクすることも可能にする。さらに、システム4800は、新しい研究、試験及び実験の設計において研究者及び第三者を支援することができる。
図52は、Javaアプリケーション4908を介して利用可能な研究のリスト4904を科学者4902に提供し、彼らが選択された研究に対する抽出、変形及びロード処理4910を開始することを可能にするために使用できるデータ統合システム104を示す。この例においては、システム4900は、科学者のグループ4902、利用可能な研究のリスト4904、Javaアプリケーション4908、研究データベース4912、選択された研究のリスト4914、抽出、変形及びロード処理4910、並びに、データ統合システム104を含むことができる。
研究データベース4912は、タイトル、要約、全テキスト、研究データ及び結果、並びに、該研究に関連した他の情報を格納することができる、上述のデータ・ソース102のいずれかを含むことができる。Javaアプリケーション4908は、コンピュータ、手持ちサイズのデバイス、手のひらサイズのデバイス、携帯電話、又は以上の任意の組み合わせ、或いは、データベース内の完全な研究リスト又は特定のユーザ定義済み又は他の特性に応答するデータベース内の研究リストを生成できるその他のあらゆるデバイス、又はそれらのデバイスの組み合わせの上で動作し又は格納される1つ又は複数のアプレットから構成することができる。科学者、実験室のスタッフ又はその他の人は、このリストから研究のサブセットを選択し、選択された研究のリスト4914を生成することができる。
システム4900は、利用可能な研究のリスト4904又は研究データベースからのデータを抽出し、修正し、変形し、操作し、処理し、又は分析することができる、上述の1つ又は複数のデータ統合システムを含むことができる。例えば、科学者4902、実験室のスタッフ又はその他の人は、ウェブ・ブラウザを通じてJavaアプリケーション4908を用いて、特定の指定された薬物又は健康状態に関連する全ての利用可能な研究のリスト4904を要求することができる。次に、科学者4902、実験室のスタッフ又はその他の人は、こうしたリストから特定の研究を選択するか又は他の研究をこうしたリストに付加して、選択された研究のリスト4914を生成することができる。次に、科学者4902、実験室のスタッフ又はその他の人は、抽出、変形及びロード処理4910のために、選択された研究のリストをデータ統合システム104に送ることができる。科学者4902、実験室のスタッフ又はその他の人は、特定のフォーマットで、選択された研究から全ての代謝率又は他の指定されたデータを出力として要求することができる。
このようにして、科学者4902、実験室のスタッフ又は第三者がそうした研究からデータ及び他の情報を抽出し又は操作する機能によって関連研究のディレクトリにアクセスすることを可能にするシステム4900を作成することができる。このシステム4900は、科学者4902、実験室のスタッフ、又は第三者が、不要な実験の繰り返しを避けるために、或いは研究を繰り返し又は結果を調整する目的でそれらの結果若しくは予測と矛盾する特定の研究を選択するために、関連する前のデータ又は他の情報を得ることを可能にすることができる。システム4900はまた、科学者4902、実験室のスタッフ、又は第三者が、実験室で実験を実際に行うことなく新しい実験をシミュレートするために、前の研究から結果を得て、統合し、分析することを可能にすることもできる。
図53は、顧客理解及び親密さを改善する目的で又は他の目的で、顧客データがPOS5004、顧客関係管理5008及びセールス・フォース・オートメーション・システム5010等の多数のシステムにわたって入力される際に、顧客データ相互参照5002を作成し保持するのに使用できるデータ統合システム104を示す。この例においては、システム5000は、POS5004、顧客関係管理5008、セールス・フォース・オートメーション5010又は他のシステム5012、データ統合システム104、及び顧客データ相互参照データベース5002を含むことができる。
POS5004、顧客関係管理5008及びセールス・フォース・オートメーション・システム5010は、各々が1つ又は複数のアプリケーション及び/又はデータベースから構成される。これらのアプリケーションは、ネットワーク若しくは独立型コンピュータ、手持ちサイズのデバイス、手のひらサイズのデバイス、携帯電話、又は以上の任意の組み合わせ、或いは、その他のあらゆるデバイス又はそれらのデバイスの組み合わせの上で動作し又は格納されるコンピュータ・プログラム、ソフトウェア又はファームウェアとすることができる。これらのデータベースは、上述のデータ・ソース102のいずれかを含むことができる。POSアプリケーションは、販売、交換、返品又は他の取引の処理又は記録のために使用することができ、POSデータベースは、販売、交換、返品、及び/又は価格、量、日付、時間及び注文番号のデータ等の他の取引中に収集されるデータ、並びに、システム5000によって処理又は記録できる如何なる取引をも特徴付けるその他のあらゆるデータを含むことができる。顧客関係管理アプリケーションは、名前、住所、企業構造、生年月日、注文履歴、信用格付け、及びあらゆる顧客、他の個人若しくはエンティティを特徴付け又はそれに関連するその他のあらゆるデータといった、顧客、他の個人又はエンティティ或いはその全てについての情報の入力、格納、分析、操作、表示及び/又は検索のために使用することができる。顧客関係管理データベースは、顧客、他の個人及び/又はエンティティについての情報を含むことができる。セールス・フォース・オートメーション・アプリケーションは、リード生成、接触相互参照、スケジューリング、性能追跡及び他の機能のために使用することができ、セールス・フォース・オートメーション・データベースは、販売リード及び接触、販売部の個々のメンバーのスケジュール、成果目標及び実際の結果、並びに、他のデータと関連させた情報又はデータを含むことができる。
システム5000は、POS5004、顧客関係管理5008、セールス・フォース・オートメーション5010及び他のシステム5012からデータを抽出し、修正し、変形し、操作し、処理し、又は分析することができ、そして結果を顧客データ相互参照データベース5002で利用可能にする、上述の1つ又は複数のデータ統合システム104を含むことができる。例えば、システム5000は、営業日の終わり又は報告周期の終わりにといった周期ベースで、或いは、ユーザ要求等のあらゆる外部イベントに応答して、POS5004、顧客関係管理5008、セールス・フォース・オートメーション5010及び他のシステム5012のいずれか又は全てからデータを抽出することができる。次に、システム5000は、データを共通フォーマットに変換するか又はその他の手法でエンタープライズにわたって他のアプリケーションで利用可能な顧客データ相互参照データベース5002にロードするためにデータを転送し、処理し、又は操作することができる。データ統合プロセス104はまた、如何なるデータ・ソース102からもリアルタイム更新又は入力を受け取るように構成することができ、又は顧客データ相互参照データベース5002への対応するリアルタイム出力を生成するように構成することができ、或いはその両方が可能である。
このようにして、エンタープライズにわたる相互参照顧客データ5002へのアクセスをユーザに提供するシステム5000を作成することができる。システム5000は、クレンジングされ、整合性があり、重複のない顧客データを、全てのシステム5000で使用するためにエンタープライズに提供し、より深い顧客理解とより強力な顧客関係をもたらすことができる。
図54は、重複を避けるために、内部システムにわたって格納される顧客データを、インバウンド顧客レコード5104のオンデマンド自動化相互参照及び一致5102に提供し、どんな所与の顧客にも全システム間のデータ・レコードを提供するために使用できるデータ統合システム104を示す。この例においては、システム5100は、インバウンド顧客レコード5104、データ統合システム104、及び内部顧客データベース5108を含むことができる。
インバウンド顧客レコード5104は、名前、住所、企業構造、生年月日、購入された製品、定期メンテナンス及び他の情報等の、顧客との又は顧客に関する取引又は対話中に収集される情報を格納することができる。内部顧客データベース5108は、上述のデータ・ソース102のいずれかを含むことができ、顧客との又は顧客に関する取引又は対話中に収集されるデータを格納することができる。内部データベース5108は、ネットワーク若しくは独立型コンピュータ、手持ちサイズのデバイス、手のひらサイズのデバイス、携帯電話、又は以上の任意の組み合わせ、或いは、その他のあらゆるデバイス又はそれらのデバイスの組み合わせの上で動作し又は格納されるコンピュータ・プログラム、ソフトウェア又はファームウェアとすることができる内部アプリケーションにリンクすることができる。
システム5100は、インバウンド顧客レコード5104又は内部顧客データベース5108からのあらゆるデータを抽出し、修正し、変形し、操作し、処理し、又は分析することが可能な、上述の1つ又は複数のデータ統合システムを含むことができる。さらに、データ統合システム104は、内部顧客データベース5108内のデータに照らしてインバウンド顧客レコード5104を相互参照する(5102)ことができる。例えば、内部顧客データベース5108は、顧客によって購入される製品に関連する情報を有するデータベース、顧客によって購入されるサービスに関連する情報を有するデータベース、各々の顧客の組織の規模に関する情報を提供するデータベース、及び顧客についての信用情報を含むデータベースとすることができる。システム5100は、製品、サービス、規模及び信用情報に照らしてインバウンド顧客レコード5104を相互参照して、不一致を明らかにし、訂正し、顧客毎にデータ・レコードの精度及び一意性を保証することができる。
このようにして、正確で完全な顧客レコードを可能にするシステム5100を作成することができる。このシステム5100は、より深い顧客知識をエンタープライズに提供することができ、良好な顧客サービスを可能にする。システム5100は、顧客データベースに収容されたデータに頼る販売員が、顧客によって既に購入された製品及びサービスに対して補足的な製品及びサービスを提案し、顧客の事業規模に適応させることを可能にすることができる。
種々のデータ統合システム及びビジネス・エンタープライズを説明してきたが、エンタープライズにおけるデータ統合サービスを提供するためのアーキテクチャをここでより詳細に説明する。
図55を参照すると、アーキテクチャのハイレベル概略図は、データ統合ソリューションの開発、デプロイ、動作及びライフサイクル管理を統一する統合アプリケーションとして動作するように複数のサービスをどのように組み合わせることができるかを示す。単一のプラットフォームへのデータ統合タスクの統一は、設計及びデプロイの異なるフェーズについての別個のソフトウェア製品の必要性を排除することができる。
アーキテクチャ5200は、GUI/ツール・フレームワーク5202、インテリジェント・オートメーション層5203、1つ又は複数のクライアント5204、API5208、コア・サービス5210、製品機能サービス5212、メタデータ・サービス5222、メタデータ・リポジトリ5224、コンポーネント・ランタイム5220を有する1つ又は複数のランタイム・エンジン5214、及びコネクタ5218を含むことができる。アーキテクチャ5200は、上述のサービス指向アーキテクチャ2400のいずれか等のサービス指向アーキテクチャ5201上にデプロイすることができる。
メタデータ・リポジトリ5224に格納されるメタデータ・モデルは、設計からデプロイまでのプロセスの全てのステップにおいてシステム全体を通してデータの共通内部表示を提供する。モデルは、他のシステム・コンポーネントにアクセス可能なディレクトリに登録することができる。共通モデルは、メタデータ(データ・プロファイル情報を含むデータ記述データ)、データ統合プロセスの仕様、ユーザ、マシン及びソフトウェア構成等を含む多数のスイート全体の項目の共通表示(全ての製品機能サービスに共通)を提供することができる。これらの共通モデルは、ユーザがどんな製品機能を使用していても、エンタープライズ・リソース及び統合プロセスの共通のユーザ・ビューを可能にすることができ、統合製品機能間のモデル翻訳の必要性をなくすことができる。
サービス指向アーキテクチャ(SOA)5201は、サービスの全てを包含するように示され、GUI5202からランタイム・エンジン5214及び接続5218を通じてコンピュータ環境への全てのサービスの調整を提供することができる。メタデータ・リポジトリ5224に格納できる共通モデルは、SOA5201がシームレスに複数のサービス間の相互作用を提供することを可能にする。SOA5201は、例えば、共通コア・サービス5210、製品機能サービス5212及びメタデータ・サービス5222の使用によってGUI5202をデータ統合設計及びデプロイの全てのアスペクトに公開することができ、インテリジェント・オートメーション層5203を介して動作することができる。共通モデル及びサービスは、設計及びデプロイプロセス中の種々のアクションについてGUI5202におけるオブジェクトの共通表示を提供することができる。GUI5202は、SOA5201の調整サービスとインターフェース接続する複数のクライアント5204を有することができる。クライアント5204は、ユーザが複数のスキル・レベルを有するデータ統合設計とインターフェース接続することを可能にし、ユーザが組織的に適切なレベルにわたってチームとして働くことを可能にする。SOA5201は、共通コア・サービス5210及び製品機能サービス5212へのアクセスを提供し、並びに、データ統合設計内の機能及びサービスにAPI5208へのバックエンド・サポートを提供することができる。サービスは、複数のクライアント5204及び他のサービスによって共有し、再使用することができる。
インテリジェント・オートメーション層5203は、アーキテクチャ5200内のメタデータ及びサービスを用いて、関連するユーザ選択のみを示すか、又は共通の、頻発する、及び/又は明らかな動作を自動化すること等によって、GUI5202内のユーザ選択を単純化することができる。インテリジェント・オートメーション層5203は、自動的に特定のジョブを生成し、設計及び設計選択を診断し、性能を調整することができる。インテリジェント・オートメーション層5203はまた、ビジネス・コンテクストのワークフロー管理又はモデリング等の、上位レベルの設計パラダイムをサポートすることもでき、より一般的には、プロジェクト又は他のコンテクスト認識を適用して、ユーザがより迅速に、かつ、効率的にデータ統合ソリューションを実行するのを支援することができる。
共通コア・サービス5210は、1つ又は複数の共通レジストリのためのディレクトリ・サービス、ロギング及び監査サービス、監視、イベント管理、トランザクション・サービス、セキュリティ、ライセンス交付(ライセンス交付ポリシィの作成及び強化、並びに、外部リスニング・サービスとの通信等)及びプロビジョニング等の、データ統合ソリューションの設計及びデプロイの全てのアスペクトにわたって通常使用できる共通機能サービス、並びに、SOAの管理サービスを提供することができる。共通コア・サービスは、共通のGUI5202への機能及びオブジェクトの共通表示を可能にすることができる。
他の製品の特定の機能サービスは、製品機能サービス5212に含めることができ、サービスを特定の適切なクライアント5204及びサービスに提供することができる。これらは、例えば、外部メタデータをインポートし、ブラウズすること、並びに、プロファイルを作成し、分析し、レポートを生成することを含むことができる。他の機能は、アーキテクチャを介してデータ統合サービスを設計し、コンパイルし、デプロイし、実行するためのサービス等の、より設計指向なものとすることができる。製品機能サービス5212は、適切なタスクが使用されている場合には、GUI5202にアクセス可能となり、タスク指向GUI5202を提供することができる。タスク指向GUIは、データ統合設計におけるアクションに適したユーザ専用機能を提供することができる。
アプリケーション・プログラム・インターフェース(API)5208は、そこにサービス、リポジトリ、エンジン及びコネクタのいずれか又は全てを含む、完全なアーキテクチャへのアクセスのためのプログラミング・インターフェースを提供することができる。API5208は、種々のサービスによって使用され、及び/又はそれらから作成される機能の通常使用されるライブラリを含むことができ、再帰的に呼び出すことができる。
メタデータ及びリポジトリ・サービス5222は、メタデータ・リポジトリ5224へのアクセスを制御することができる。全ての機能は、それ自体の機能別モデルによって表わされるメタデータをメタデータ・リポジトリ5224内の共通リポジトリに保持することができる。機能は、共通モデルを共有するか又はメタデータ・マッピングを使用して、それらのそれぞれのモデル間のセマンティクスを動的に翻訳することができる。データ統合設計に使用される全ての内部メタデータ及びデータは、メタデータ・リポジトリ5224に格納することができ、外部メタデータ及びデータへのアクセスは、該メタデータ・リポジトリ5224に格納され、メタデータ及びリポジトリ・サービス5222によって制御されるハブ(メタデータ・モデル)によって提供することができる。メタデータ及びメタデータ・モデルは、メタデータ・リポジトリ5224に格納することができ、メタデータ及びリポジトリ・サービス5222は、メタデータ・バージョニング、永続性、メタデータ及びメタデータ・モデルのチェック・イン及びチェック・アウト、並びに、それが他のメタデータと調整される前に、ユーザによって作成される暫定メタデータのためのリポジトリ・スペースを保持することができる。メタデータ及びリポジトリ・サービス5222は、リポジトリ・ハブを用いて、メタデータ・リポジトリ5224へのアクセスを、GUI5202、内部クライアント5204及び外部クライアントの複数のサービスに提供することができる。メタデータ・リポジトリ5224への他のサービス及びクライアント5204によるアクセスは、メタデータがSOA5201によって調整されるシームレスなトランザクションにおいて他のサービスによってアクセスされ、変形され、組み合わされ、クレンジングされ、クエリされることを可能にすることができる。
幾つか存在する場合があるランタイム・エンジン5214は、アダプタ及びコネクタ5218を用いて、外部ソースと通信することができる。エンジン5214をユーザによって作成される設計に公開して、コンピュータ環境に基づいてコンパイルされデプロイされるソリューションを作成することができる。ランタイム・エンジン5214は、遅いバインディングをコンピュータ環境に提供することができ、コンピュータ環境の考慮事項とは無関係のデータ統合ソリューションを設計する能力をユーザに提供することができる。ランタイム・エンジン5214は、データ統合ソリューションをコンパイルし、高い処理能力又は高い並行性のための適切なデプロイランタイムを提供することができる。サービスは、インターフェース及び種々のサービスのための使用規格へのアクセスを提供するレジストリからJ2EE構造としてデプロイすることができる。サービスは、異機種ハードウェア及びソフトウェア環境と共に使用するために、HTTP、Corba/RMI、JMS、JCA等のような、多数のプロトコルをサポートすることができる。これらのプロトコルとのバインディングは、ランタイム・エンジン5214によって自動的に選択されてもよいし、或いは、デプロイプロセスの一部としてGUI5202からユーザによって手動で選択されてもよい。
外部コネクタ5218は、ネットワーク又は他の外部リソースへのアクセスを提供し、外部リソースへの、多数の実行エンジン及びJava又は格納されている手順等の他の変形実行環境のための共通アクセス・ポイントを提供することができる。
種々のランタイム・エンジン5214を選択し使用するのを支援するために、付加的な機能層を設けることができると認識される。これは、高い処理能力又は高い並行性デプロイをサポートして提供されたときに特に有用である。例えば、ランタイム・エンジン5214は、場合によっては無制限の長さの大きなトランザクション、並びに、リアルタイム・トランザクションの連続するストリームを構文解析するようになっているトランザクション・エンジンを含むことができる。ランタイム・エンジン5214は、小さな個々のトランザクションを処理するようになっている並列性エンジンをさらに含むことができる。並列性エンジンは、パイプライン化され又は他の方法でパーティション化されたフローに分割される前処理された入力(及び出力)を受け取るように適合させることができる。別の例としては、並行性ランタイム・エンジン5214は、大量の小さな個々のトランザクション等の対話式要求への迅速な応答のために最適化することができる。コンパイル及び最適化層は、並列性エンジンへの出力を小さなチャンクに前処理すること等によって、これらの種々のエンジン間に統合プロセスをどのように割り当てるかを決定することができる。コネクタをアーキテクチャ内に集中させることによって、種々のエンジン間のプロセスの分散をより綿密に制御し、ユーザ・インターフェース・レベルでこうした制御へのアクセスの可能性を提供することが可能である。同様に、変形プロセスにおける接続の共通中間表示が、あらゆる自動化戦略のデプロイ、及び実行エンジンの異なる組み合わせの選択、並びに、例えばメタデータ又はプロファイルに基づく最適化を可能にする。
本明細書において説明されるアーキテクチャ5200は、高度の柔軟性及びカスタマイズ可能性をユーザの作業環境に提供する。これは、例えば、既存の又は計画されたワークフロー及び設計プロセスを中心としてユーザ環境を構成するために適用することができる。ユーザは、コンポーネントを構成し、それらを結合してコンポジションにすることによって特定の機能サービスを作成することができ、該コンポジションは、今度は、新しいコンポーネント設計へのモジュール性の再帰的ネスティングを可能にするコンポーネントとして機能することもできる。コンポーネント及びコンポジションは、メタデータ及びリポジトリ・サービス5222によって提供されるアクセスによってメタデータ・リポジトリ5224に格納することができる。メタデータ及びリポジトリ・サービス5222は、複数のサービスとの共通インターフェースを共通データ定義に提供することができ、固有のデータ・フォーマット及び業界標準フォーマットへのサポートを提供することができる。本明細書において説明されるアーキテクチャのモジュール性は、共通コア・サービス5210から選択されたコンポーネント及び製品機能サービス5212の他のコンポーネント、並びに、全アーキテクチャの他のコンポーネントを有するパッケージへの、如何なるエンタープライズ機能及び統合プロセスのパッケージ化をも可能にする。システム・コンポーネントからパッケージを作る能力は、共通コア・サービス5210として提供することができる。このパッケージ化機能によって、それがアーキテクチャ5200内に既にあるアトミック・サービス、コンポーネント及びコンポジションの組み合わせとして表現が可能であるとすれば、如何なる任意の機能をも構成することができる。アーキテクチャ5200のパッケージ化機能をユーザ・インターフェースのタスク指向と組み合わせて、ユーザが望む如何なるワークフロー又は設計方法にも特に適合したユーザ・インターフェースを達成することができる。
図56は、例えば、上述の機能、サービス又はパッケージのいずれかとすることができる多数のタスクとしてユーザ・インターフェースを定義するためのタスク・マトリックスを示す。ユーザ・インターフェースは、設計の柔軟性を維持するために基礎機能から強力に分離できるという利点がある。こうしたアーキテクチャにおいては、ワークフローによって決定されるタスクは、インターフェースをユーザに提供するために解釈されるタスク・マトリックス5250内で編成することができる。タスク・マトリックス5250は、各々が多数のタスク5254及び多数のメニュー5256(以下のインターフェースにおいて説明される「ピラー」)を含む、1つ又は複数のコンテクスト5252を含むことができる。
1つ又は複数のコンテクスト5252は、例えば、メニュー内のタスクの多数の異なる表示に関するものとすることができる。多数の別個に定義されたコンテクストの使用によって、インターフェースは、スキル・レベルに依存する表示又はセキュリティ・レベルに依存する表示等の、様々な任意の表示をもつ設計とすることができる。より一般的には、多数の任意のコンテクストを提供することによって、設計の柔軟性の付加的な側面が、タスク・マトリックス5250内で実現される。これは、多数の方法で使用することができる。例としては、医療提供業者及び保険業者は、両者が内部レコードを保持し、特定の方法で第三者と取引するために、HIPAA等の規制スキームの下で責任を負う場合がある。この場合、提供業者及び保険業者は、個人識別情報を暗号化するか又は提供業者によって保険業者に送られる支払要求についての共通フォーマットを使用するというように、多数のタスクを共通にすることができる。保険業者及び提供業者のためのデータ統合プロセスは、著しい違いをも要求しながら、共通の相当な数のタスクを共有することができる。2つのコンテクスト5252を提供業者及び保険業者のために用いて、より一般的なHIPAA準拠のインターフェース定義の下で同じ共通タスクのセットに基づいて2つの異なるワークフローを定義することができる。
各々のタスク5254が、任意の数の、システムによって提供されるユーザ定義済みタスク又は共通タスク、機能、サービス等、或いは、ワークフローに関連する単一の有用なタスクに組み合わされるこうしたタスク、機能及び/又はサービスの組み合わせとすることができる。タスク5254は、インターフェース内で有用なダイアログ、ウィザード、ヘルプ・ウィンドウ等を含むこともできるし、或いは、それらと関連付けることもできる。タスク・マトリックス5250において識別されるタスク5254は、例えば、インターフェース内のそれらの位置、インターフェースの特定の制御領域との関連付け、タスクと関連付けられた制御、入力及び出力等に対して事前定義することができる。したがって、ユーザ・インターフェースを介してアクセス可能なタスクのために、タスク・マトリックス5250におけるタスクの存在を示しさえすればよい。任意的に、各々のタスク5254とメニュー5256との交差部分は、タスク5254の発生に関連する1つ又は複数の指定を含むことができる。したがって、タスク・マトリックス5250は、ビジュアル要素、制御、位置、入力、出力、スキル・レベル・パラメータ等を指定することができる。
各々のメニュー項目5256は、ワークフローのフェーズに対応することができる。タスク・マトリックス5250を用いると、ワークフローに対する関連タスクをユーザ環境内の適切な位置において実現することができる。
ワークフロー・ベースのインターフェース設計の迅速なデプロイをさらに支援するために、ユーザ・インターフェースそれ自体を、ビジュアル・スタイル、制御、制御パネル、ワークスペース、ツール、ウィザード、ダイアログ等の集合として定義することができる。同時に、タスクは、例えば、サービス指向アーキテクチャ内のサービスとして定義することができる。したがって、タスク・マトリックス5250の使用によって、各々が1つ又は複数のサポーティング・タスク5254を有するメニュー項目5256の任意の組み合わせは、ナビゲーション方法としてあらゆるデータ統合又は他のワークフローを表すように都合よく配列することができる。
インターフェースは、共通データ・セットに逆らって動作することができ、その結果、変更は、ワークフローの種々のフェーズ(すなわち、メニュー)間及びフェーズ内のタスク間で持続するという利点がある。各々のタスク5254及び各々のメニュー5256は、同じデータ・セットに関する異なる機能的な見方を表すことができる。したがって、アーキテクチャは、ワークフローがワークフローの異なるフェーズのアプリケーション毎にデータを渡す、既存のアプリケーション・ベースの環境を通じて、著しい改善を提供することができる。さらなる利点としては、タスク・マトリックス5250それ自体は、個人の好み又は設計問題に応じてユーザが修正することができる。タスク・マトリックス5250を修正するためのツールは、サービスとして公開し、ユーザ・インターフェース又はサービス指向アーキテクチャにおいてそのサービスへのクライアントとして機能する他のツールを介してユーザによりアクセス可能となり得る。
ワークフロー内でタスクを編成するために特定の構成が識別されるが、任意の数のデータ構造又は他の格納機能を用いて、ユーザ・インターフェースの定義を格納し、検索し、修正することができることを認識すべきであり、ユーザ・インターフェースそれ自体のアーキテクチャが柔軟性と設計の容易さとの間の所望のトレード・オフによって、種々のレベルの特定性で定義できることをさらに認識すべきである。
図57を参照すると、複数のユーザのスキル・レベルと共通設計ライブラリ5300との相互作用の理解を与えるために、GUI5202のより詳細な図が示される。GUI5202は、全システムの基礎機能から、より具体的には、アーキテクチャの他のアスペクト、並びに、メタデータ・リポジトリ5224内のメタデータ・モデル及び設計から強力に分離することができる。このような「分離した」設計においては、アーキテクチャの機能の全てをサービスとしてユーザ・インターフェースに提供することができる。ユーザ・インターフェースは、今度は、これらのサービスにアクセスするための下位レベルのツール及びユーザ制御の共通のセットを提供することができる。このアプローチは、インターフェースか又は基礎システムのいずれかについての比較的直接的な拡張性を可能にし、データ統合プロセスの全ての段階のためのシームレスな作業環境を提供することができる。新しいワークフロー又は異なるユーザが現れる場合には、インターフェースは、それに応じて、既存のモデル及びデータ統合ジョブ又はプロセスに影響を及ぼすことなく適合させることができる。新しいサービス又はモデルが開発される場合には、ユーザ・インターフェースを修正することなく(もちろん、異なるユーザ・インターフェースを所望しない限り)それらをサービス指向アーキテクチャに付加することができる。
GUI5202のアーキテクチャは、システム・アーキテクチャ又はメタデータ・モデルの詳細な知識なしにユーザが設計5304を操作するための制御及びコンポーネントを提供する比較的低スキルのユーザのためのインターフェース等の、システムの代替的な表示を提供することができる。別の高スキル・レベルのユーザ・インターフェースは、同じメタデータ・モデル上で動作しながら、モデル設計のより詳細な制御を提供することができる。高スキル・レベルのGUIは、例えば、より多くの機能及びより大きなカスタマイズへのアクセスを提供することができる。同様に、GUI5202は、監視、デプロイ及び動作制御のような行動によって定義することもできるし、或いは、重役、役員、経営幹部、管理者、分析家、会計係、エンジニア等のような職業によって定義することもできる、代替的な役割に依存する表示を提供することができる。役割は、経営幹部が社長、副社長等として分類される場合、又は分析家がマーケティング分析家、ビジネス分析家、金融分析家等の一人である場合のような階層によって定義することもできる。別の例としては、GUI5202は、特にモバイル・デバイス向けになっているか、又はより具体的には、Research In Motion Limited社からのBlackBerry7730及びDell Inc.社からのAxim X30による使用向けになっているユーザ・インターフェース等の、プラットフォームに依存する表示を提供することができる。さらにより具体的には、タスク・マトリックスは、ラップトップ・コンピュータを用いる技術員向けに、又はMotorolaの携帯電話を用いる会社の役員向けに定義することができる。各々のユーザ・プロファイルは、全てが共通の共有メタデータ・モデル上で動作する状態で、別個のタスク・マトリックスとして実現することができる。
GUI5202は、他の外部ツールの必要なく設計の初めから最終的なデプロイまでの設計ソリューションの全てのアスペクトについての統合ユーザ環境を提供することができる。GUI5202は、カタログ管理、検索、クエリ、ナビゲート、パーソナライズ、スクリプト、永続性、又はデータ統合ソリューションの設計5304に関連した他のタスク等の共通機能を全てのユーザ・レベルに提供することができる。ユーザは、スキル別又は役割別のユーザ・インターフェース機能を用いてデータ統合設計ソリューション5304にアクセスすることができる。異なるユーザ・ビュー5302は、設計機能の複数のレベルの複雑さを可能にすることができる。例としては、多くのデータ統合設計ソリューション5304において、種々のスキルを有する種々の組織からのユーザが共にチームになって、単一の設計ソリューション5304を開発することができる。GUI5202は、様々なスキルのユーザが彼らの専門分野に適用可能な機能及びサービスを取り扱うことを可能にするように構成可能となり得る。アーキテクチャ5200は、こうしたチームが同じメタデータ、モデル及び設計において協働することを可能にすることができ、ライブ・モデルが全てのユーザに共通であるため、変更が種々のチーム・メンバによって行われる際に、グローバルな可視性を提供することができる。
ユーザのスキル・レベルに関係なく、ユーザ・ビュー5302は、設計ソリューション5304を作成する各種のユーザによる使用のための共通の機能ライブラリ及び設計ウィザード5300に公開することができる。ライブラリ及び設計ウィザード5300機能は、ユーザ・ビュー5302のスキル・レベルに基づくアクセスを提供することができ、スキル・レベル・ベースで利用可能な機能を制限することができる。ユーザ・ビュー5302は、メタデータ及びモデルへの共有アクセスによってチーム協働を可能にすることができる。
ユーザ・ビュー5302は、データ統合設計ソリューション5304のためのタスク及びコンテクスト指向ガイダンスによって編成することができる。データ統合設計が複雑化するのに伴って、ユーザが設計ソリューション5304に取り組んでいるあいだ、タスク指向の選択肢を提供することが有利になる。例として、ユーザがクエリを作成している場合には、ユーザをクエリの適切な設計に案内するために利用可能なクエリタスクの選択肢を表示することができる。設計の異なるアスペクトが付加され又は修正される際に、適切なコンテクスト機能及びサービスがユーザに利用可能になり、ユーザを堅牢な設計ソリューション5304に案内するのを助けることができる。例としては、ユーザは、データ・ソース・コンポーネントを設計に付加することができ、インターフェースは、如何なる適切なメタデータ・カタログ、インポート、サンプル・データ及びデータ・プロファイル機能をも表示することができる。さらに、利用可能なカタログは、既に現在の設計に関連付けられているデータ・ソースのみを表示することができる。ユーザには、ユーザが他の設計アスペクトを再使用することができるように同じデータ・ソースを使用した他のデータ統合設計を示すこともできる。
設計ソリューション5304に取り組んでいるあいだ、ユーザ・ビュー5302は、設計ソリューション5304を見た目にはあまり複雑にしないように設計の特定の細部についての制限的な表示にすることができる。ユーザは、ユーザがモデル、集約及び関連付け、ビジネス・プロセス、制御フロー、データ・アクセス、エラー処理、又は他の設計アスペクト等の、その時点で動作させられている設計アスペクトにのみ重点を置くことができるようにするために、複数の設計層を隠すか又は公開することが可能である。
図57の態様は、内部と外部の両方の複数のリソースを用いる、多数の作成サイトを有するエンタープライズ環境に適用可能である。ユーザ・ビューは、異なる位置でのモデリング、分析、作成、テスト、動作、及びアドミニストレータ等のトランザクションによって、複数の地理的な位置から設計ソリューション5304を取り扱うことができる。図57について上述した全ての態様は遠隔位置で利用可能である。
図58は、SOAについての役割及び関係を記述するUMLダイアグラムを示す。SOAクライアント5412は、サービス・ディレクトリ5418を介してサービス5414を見つけ出し、インスタンス化することができる。各々のサービス5414が、コンポーネント・サービス5420等の共通の共有サービスを含む、それらの実装の一部として他のサービス5414を使用することができる。コンポーネント・サービス5420は、データベース、ファイル、アプリケーション、キュー等の任意の外部リソース・コネクタを設計時に使用できるサービスとして公開することができる。
クライアント5412は、サービス5414へのクライアントとして機能するプログラマティック又はユーザ・インターフェースの汎用化を表す。プロセス・デザイナ5402は、例えば、モデル又はプロセスを操作するためのグラフィカル・ユーザ・インターフェース又はプログラマチック・アクセスを提供することができる。API5410は、上述のアーキテクチャ5200によって提供される如何なるサービスとすることもできるサービス5414にアクセスするために、外部プログラムのためのアプリケーション・プログラミング・インターフェースを提供することができる。ウィザード5408は、例えば、メタデータ・モデルを作成するか又は統合タスクの循環収集を実行するといった設計ステップの事前パッケージ化された収集を提供することができる。コンパイラ5404は、インターフェースをコンパイル及びランタイム・サービス、又は他のデプロイサービスに提供することができる。これらの特定のインターフェースの各々、並びに、任意の数の他のインターフェース又はこれらのインターフェースの組み合わせは、上述のアーキテクチャ5200内の動作を実行するためのサービス5414へのクライアント5412として機能することができる。
各々のサービス5414は、第1のサービスが第2のサービス、すなわち、それ自体の別のインスタンスを使用でき、今度はそれが、第3のサービス、すなわち、それ自体の別のインスタンスを使用でき、そしてまた以下同様に使用できる、という点で再帰的となる。サービスの他の組み合わせを用いるサービスの再帰的又はネスト構造は、一般にクライアント5214に対し透過的である。より具体的には、アーキテクチャ5200内の各々の製品機能、並びに、サービス5414の組み合わせは、クライアント5412による使用のためにサービスに組み入れることができる。クライアント5412に公開されるサービス5414は、共通コア・サービス5210、製品機能サービス5212、メタデータ及びリポジトリ・サービス5222、又はサービス・ディレクトリ5418に分類整理することができるその他のあらゆるサービスの一部とすることができる。
クライアント5412は、サービス・ディレクトリ5418を介してサービス5414を見つけ出し、インスタンス化することができる。サービス5414がインスタンス化されると、それは、設計に使用することができる。UMLダイアグラムにおいて分かるように、サービス5414がサービス・ディレクトリ5418から情報を受け取るときに、サービス・ディレクトリ5418対サービス5414の1対多数の関係が存在し得る。例としては、クライアント5412は、インスタンス化されていないサービス5414を要求することができる。要求は、サービス・ディレクトリ5418に渡すことができ、それは、サービス5414をインスタンス化し、サービス5414をクライアント5412に公開することができる。このプロセスは、インスタンス化されるサービス5414によって使用されるサービス等の第2のサービスをインスタンス化することもできる。
コンポーネント・サービス5420は、個々のコンポーネントの機能へのアクセスを提供することができ、データベース、ファイル、アプリケーション、キュー、メタデータ、又は他の利用可能なリソース等の外部リソースをサービス5414として公開することができる。公開されたこれらの外部リソースは、設計時に(プロセス・デザイナ5402を介して)ユーザにサービス5414として利用可能となり、ランタイム時にランタイム・エンジンに利用可能となり得る。また、コンポーネント・サービス5420及びコネクタ5218を介して、外部リソースは、SOAアーキテクチャ5200内のサービスにアクセスできる場合がある。
図59を参照すると、SOA5201環境の概略図は、SOA5201がどのように他のアーキテクチャ5200のクライアント及びサービスにインターフェース接続するかを示す。SOA5201のコアは、サービス・バインディング5512、SOAインフラストラクチャ5514、及びサービス実装5518とすることができる。サービス・バインディング5512は、GUI5508、アプリケーション5504、スクリプト・オーケストレーション5502、管理フレームワーク5500及び他のクライアント等のクライアントの、SOA5201の内部又は外部とすることができるサービスへのバインディングを可能にすることができる。バインドされたサービスは、共通コア・サービス5520の一部とすることができ、サービス・バインディング5512は、サービス記述レジストリ5510にアクセスして、サービスをインスタンス化することができる。サービス・バインディング5512は、クライアントが同じ又は異なる技術を用いてローカル又は外部とすることができるサービスを使用することを可能にすることができる。外部サービスへのバインディングは、外部サービスを公開することができ、それらは、内部サービスと同じ方法で呼び出すことができる。サービスへの通信は、同期又は非同期とすることができ、異なる通信経路を使用することができ、ステートフル又はステートレスとすることができる。サービス・バインディング5512は、HTTP、CORBA/RMI、JMS、又はJCA等の複数のプロトコルへのサポートを提供することができる。サービス・バインディング5512は、コンピュータ環境によって自動的にサービス・バインディングについての適切なプロトコルを決定することもできるし、或いは、ユーザが、設計ソリューション5304の一部としてGUI5508からプロトコルを選択することもできる。
管理フレームワーク5500のクライアントは、SOA5201のサービスをインストールし、公開し、分類整理し、構成し、監視し、他の方法で管理するためのファシリティを提供することができる。管理フレームワーク5500は、接続によってクライアント、内部サービス、外部サービス、又は内部若しくは外部メタデータ内のメタデータへのアクセスを提供することができる。
オーケストレーション・クライアント5502は、複数のSOA5201のサービスを設計ソリューション5304に組み込むことによって、複数の複雑な製品機能及びワークフローを設計することを可能にすることができる。これらのサービスは、共通コア・サービス5520、内部サービス5524に対し外部のサービス、内部プロセス5528、又はユーザ定義済みサービス5522から構成することができる。SOA5201のオーケストレーションが、エンタープライズ環境において統一されたデータ統合設計を提供する機能のコアである。クライアント、コア・サービス、メタデータ・リポジトリ・サービス、デプロイエンジン、並びに外部サービス及びメタデータ間のオーケストレーションが、広範なエンタープライズの要求を満たす設計を可能にする。統一された手法は、エンタープライズ設計のためにスイート全体を共にバインドするアーキテクチャを提供し、アーキテクチャを介してデプロイ設計ソリューション5304までの設計プロセス全体のシームレスな表示を可能にする単一のGUI5508を可能にすることができる。
アプリケーション・クライアント5504は、サービスが必要に応じて共通機能を呼び出すことを可能にすることによって、SOA5201の調整されたサービスへの付加的な機能をプログラマチックに提供することができる。アプリケーション・クライアント5504の機能は、サービスが機能を呼び出し、あたかもそれらがサービスの一部であるかのようにそれらを適用することを可能にすることによって、SOA5201のサービス機能を強化することができる。GUIクライアント5508は、これらのサービス及びリソースをグラフィカルに表示し、操作することを可能にすることによって、SOA5201のサービス及びリソースへのユーザ・インターフェースを提供することができる。GUI5508は、上記の図57の説明においてより十分に説明されている。
SOAインフラストラクチャ5514は、J2EEベースのものとすることができ、サービスがデプロイ環境とは無関係に作成されることを可能にするためのファシリティを提供することができる。SOAインフラストラクチャ5514は、リソース・プーリング、インターセプト、直列化、ロード・バランシング、イベント・リスニング、及び監視等のデプロイ環境のサポートにおいて付加的な機能を提供することができる。SOAインフラストラクチャ5514は、コンピュータ環境にアクセスでき、GUI5508に利用可能なサービスに影響を与え、コンテクスト指示のGUI5508をサポートすることができる。
SOAインフラストラクチャ5514は、例えば、エンタープライズ・ジャバ・ビーン(EJB)及びリアルタイム統合(RTI)を用いてリソース・プーリングを提供することができる。リソース・プーリングは、複数の並行サービス・インスタンスが内部と外部の両方の少数のリソースを共有することを可能にすることができる。
SOAインフラストラクチャは、多数の有用なツール及び機能を提供することができる。インターセプトは、暗号化、圧縮、追跡、監視、及びサービスに対し透過的とすることができる他の管理ツールの挿入を提供することができ、これらのサービスの報告をクライアント及び他のサービスに提供することができる。直列化及び非直列化は、複数の呼び出しプロトコルにわたり且つ異なる技術にわたる複合サービス要求及びデータ転送サポートを提供することができる。ロード・バランシングは、複数のサービス・インスタンスが複数のサーバにわたって分散させられることを可能にすることができる。ロード・バランシングは、複数のサーバ上で1つ又は複数のプロセッサにアクセスする高い並行性処理又は高いスループット処理をサポートすることができる。イベント・リスニング及び生成は、監視された外部イベントに基づくサービスの呼び出しを可能にすることができる。これは、特定の条件が生じる可能性がある場合に、第1のサービスの機能に基づいて第2のサービスの呼び出しを可能にすることができる。イベント・リスニングは、前に呼び出したときと同じ識別子を用いてサービスを呼び出すことができることを指定する呼び戻し機能をサポートすることもできる。
サービス記述レジストリ5510は、全ての他のサービスについての全てのインターフェース及び使用規格を保持するサービスとすることができる。サービス記述レジストリ5510は、キュー及び選択サービスを提供して、設計ソリューション5304と共に使用されるサービス、バインディング及びプロトコルのインスタンスを作成することができる。例としては、SOA5201が、呼び出されるサービスのキュー又は選択を要求することになる場合には、クライアント又は他のサービスが、サービスのインスタンスをSOA5201に要求することができる。次に、サービス記述レジストリ5510は、サービス・バインディング5512によるバインディングのためのサービス・インスタンスを返すことができ、次いで、設計ソリューション5304に使用することができる。
共通コア・サービス5520は、設計ソリューション5304及びランタイムデプロイソリューションを作成するために呼び出すことができる複数のサービスを含むことができる。共通コア・サービス5520は、設計ソリューション5304のための共通サービスの全てを含むことができ、それにより他のサービスをこれらのサービス自体の機能を保持する必要性から解放する。サービス自体は、設計ソリューション5304を完了する要求通りに、共通コア・サービス5520内の他のサービスを呼び出すことができる。複数のクライアントは、サービス・バインディング5512、SOAインフラストラクチャ5514及びサービス記述レジストリ5510を介して共通コア・サービス5520内の他のサービスを呼び出すことができる。複数のクライアントは、サービス・バインディング5512、SOAインフラストラクチャ5514及びサービス記述レジストリ5510を介して共通コア・サービス5520にアクセスすることができる。共通コア・サービスは、メタデータ・リポジトリ・サービス5222及びSOAインフラストラクチャ5514を介して外部サービスによってアクセスすることもできる。
付加的な外部サービスは、サービス実装5518を介してSOAインフラストラクチャ5512によってサポートされる環境のいずれかにアクセスすることができる。サービス実装は、アダプタ及びコネクタ5218の使用によって外部サービスへのアクセスを提供することができる。サービス実装5518によって、サービス5524は、設計ソリューション5304を作成するために他のソフトウェア製品によって提供される特定の製品機能を公開することができる。これらのサービス5524は、調査、設計、作成、テスト、デプロイ、動作、監視、調整、又は他の機能を提供することができる。例としては、サービス5524は、データ統合ジョブを実行することができ、メタデータ、メタ・モデル又はサービスについてSOA5201にアクセスすることができる。
サービス実装5518は、プロセス5528のためのアクセスを、他のツールを用いて作成され、サービスとしてSOAインフラストラクチャ5514に公開される統合プロセスに、提供することができる。他のツールのユーザがこれらの統合プロセスを作成することができ、これらのプロセスは、サービスとしてSOA5201及びクライアントに公開することができる。
サービス実装5518は、ユーザが彼ら自身のカスタム・プロセスを定義し又は作成し、それらをSOAサービスとして公開することを可能にするユーザ定義済みサービス5522へのアクセスを提供することもできる。ユーザ定義済みサービス5522をSOAサービスとして公開することにより、それらをSOA5201の全てのクライアント及びサービスに公開することが可能になる。
図60は、リポジトリ・サービス5222とツール5604、レガシ・ツール5602及び外部ツール5600との相互作用を示す。リポジトリ・サービス5222は、アクセスのためのサービスを内部ツール5604、レガシ・ツール5602及び/又は外部ツール5600のためのメタデータ・モデルに提供することができる。これらのサービスの各々は、リポジトリ・サービス5224によって保持されるリポジトリ空間内にメタデータ又はメタモデルを保持することができる。リポジトリ・サービス5224は、セマンティック・ハブ5614へのモデル・マッピング(矢印によって示される)を通じて、種々のツールが他のメタデータにアクセスするための機能を提供することができる。
アーキテクチャ5200において、ツール5604は、それらの作業メタデータのための別個のモデルを使用し、リポジトリ・サービス5222によって提供されるリポジトリ5224に格納することができる。リポジトリ5224は、SOA5201の複数のサービスによって共有できるツール別のモデル、メタデータ・モデル及び共通モデルを格納することができる。ツール5604は、SOA5201を介してリポジトリ5224にアクセスすることができ、設計ソリューション5304のためのデータ及びメタデータを提供することができる。データ・プロファイル、データ・クレンジング、設計ソリューション5304、又は他のデータ統合関連アクション等の活動については、リポジトリ5224内に別個の機能領域が存在してもよい。
リポジトリ・サービス5222は、レガシ・ツール5602と相互作用することができ、レガシ・モデル・リポジトリ5612を維持することができる。レガシ・モデルは、メタデータの共存、メタデータのマイグレーション、メタデータの並行バージョン、又は設計ソリューション5304に対する他のメタデータ及びモデリング要求のために使用することができる。レガシ・モデル・リポジトリ5612は、リポジトリ・サービス5222によって維持することができ、レガシ・モデル・リポジトリ5612からリポジトリ5224へのマッピングを用いて、レガシ・ツール5602は、サービスとしてツール5604に公開することができる。リポジトリ5224からレガシ・ツール5612への同じマッピングを用いることにより、これらのツールは、サービスとしてレガシ・ツール5602に公開されることになる。レガシ・モデル・リポジトリ5612がリポジトリ5224及びツール5604に公開された状態で、レガシ・モデル・リポジトリ5612からのメタデータ及びデータは、並行メタデータとして保持することもできるし、或いは、既存のリポジトリ・メタデータと一致させることもできる。
リポジトリ・サービス5222は、外部ツール5600についてメタデータ及びモデルをインポートし、エクスポートする(5608)ための主要サービスとすることができる。外部メタデータ及びモデルをインポートして、リポジトリ・サービス5224によって保持できる外部表示モデル5610を作成することができる。これらの外部表示モデルは、設計ソリューション5304及びデプロイのためにSOA5201に公開することができる。リポジトリ・サービス5222においては、モデルは、他のモデルを参照することができ、ツールが並行して複数のモデルにアクセスすることを可能にすることができる。リポジトリと外部リポジトリとの間のモデル参照は、複数のツールがリポジトリ5224において同じメタデータ又はモデルを共有することも可能にする。
リポジトリ・サービス5222は、セマンティック・ハブ・モデルを用いて、外部表示モデル5610、レガシ・モデル5612、並びに、外部ツール5600、レガシ・ツール5602及びツール5604へのリポジトリ・モデル5224にアクセスを提供することができる。セマンティック・ハブ・モデルは、外部表示モデル5610、レガシ・モデル5612及びリポジトリ・モデル5224間のマッピングを維持する整合モデルとすることができ、ツール5604がメタデータを共有できるようにするために部分的なマッピングのみが要求される。他のシステム・コンポーネント間のセマンティック・ハブ・モデル5614のマッピングの使用により、ツール5604は、ユーザ設計ソリューション5304についてレガシ・モデル5612及び外部表示モデル5610にアクセスすることができる。セマンティック・ハブ・モデル5614のマッピングは、SOA5201のサービスについての外部表示モデル5610のライブ・メタデータ分析を提供することができる。ツール5604は、レガシ・モデルにアクセスすることができ、レガシ・メタデータ及びモデルの共存と、リポジトリ5224へのマイグレーションをサポートすることができる。ツール5604は、レガシ・モデル5612と相互作用することができ、それらをメタデータ及びモデルの付加的なバージョンとしてサポートすることができる。レガシ・モデル5612は、リポジトリ5224のモデルにマイグレートすることができる。セマンティック・ハブ・モデル5614を介して、外部ツール5600及びレガシ・ツール5602は、SOAコネクタ5218にアクセスすることによってSOA5201のサービスにアクセスすることができる。
図61は、上述のリポジトリ・サービス5222等のリポジトリ・サービスのためのアーキテクチャを示す。アーキテクチャは、GUIクライアント、非GUIクライアント及びサービス等のインターフェース5700を含むことができる。アーキテクチャは、XMIストリーム5702、アプリケーション・プログラミング・インターフェース5704、インポート/エクスポート機能5608、定義及び拡張機能5710、ナビゲーション機能5712、クエリ機能5714、内部分散、ロッキング及びキャッシュ・サービス5708、内部永続性及びバージョニング・サービス5718、オブジェクト管理サービス5720、並びに、データベース5722をさらに含むことができる。一般に、アーキテクチャは、モデルの履歴及び永続性を保存するデータベース機能を提供しながら、データベース5722内のモデルへのプログラマチック・アクセス又は他のアクセスを各種のユーザ及びユーザ・タイプに提供する。リポジトリ・サービス5222は、メタ・モデル(すなわち、メタデータのモデル)、並びに、ジョブ、サービス又は他の機能における実行のためのモデル・インスタンス等の設計モデルを保持することができる。
インターフェース5700及びXMIストリーム5702は、リポジトリ・サービス5222と外部ユーザとの間の如何なる適切なフォーマットの通信をも提供することができる。インターフェース5700は、プログラミング・インターフェース、メッセージ指向インターフェース、及び/又はリポジトリ・サービス5222への外部アクセスのための他のインターフェースを提供することができる。例えば、XMIメタデータ交換(XMI)ストリーム5702は、メタモデル及びインスタンス・ファイルの保管−復元−交換フォーマットを符号化し、伝送するための標準的なメッセージ指向フォーマットを提供することができる。XMIストリーム5702は、リポジトリ・サービス5222のインポート及びエクスポート機能5608と直接通信することができる。
アプリケーション・プログラミング・インターフェース(API)5704は、例えば、リポジトリ・サービス5222にアクセスするクライアントから属性値及びオブジェクトIDを受け取ることができる。APIは、リポジトリ5222の構造か又はリポジトリ5222にアクセスするインターフェース5700の形態及び機能のいずれか、或いは、その両方についての情報を別個に保持する反射インターフェースを含むことができる。ユーザは、直接的なプログラマチック・インターフェース(例えば、Javaクラス)を用いて、又は例えば、リポジトリ・サービス5222の構造についての情報をあまり要求しない、及び/又はリポジトリ・サービスにアクセスしているユーザについての、インターフェース5700からの明示的な情報をあまり要求しないプログラミング・インターフェース5704の反射形態を用いて、データベース5722内のメタデータにアクセスすることができる。例えば、アプリケーション・プログラミング・インターフェース5704は、既知のインターフェース5700によって使用されるモデルを検出し、及び/又は記述して、リポジトリ・サービス5222にアクセスする定義及び拡張機能5710を含むことができる。アプリケーション・プログラミング・インターフェース5704は、既知のGUI(又は非GUI)クライアント・インターフェース5700によって提供されるナビゲーションの構造及び形態の認識を有するナビゲーション機能5712をさらに含むことができる。これらの機能5704、5710、5712を用いることにより、リポジトリ・サービス5222は、既知の構成を有する種々のインターフェース5700からの要求を良好にインターセプトし、応答することができる。代替的には、如何なるモデル認識のクライアント又はサービスも、モデル定義からコンパイルされた任意のモデル別のクラスに直接アクセスすることができる。
クエリ機能5714は、GUI、非GUIクライアント及びサービス等のインターフェース5700からの適切なフォーマット済み要求についてリポジトリ・サービス5222を直接公開することができる。例えば、クエリ機能5714は、直接クライアント及びサービス5700からクエリを受け取るか又は表現を更新することができ、直接応答オブジェクトIDによって応答することができる。検索等の他の一般的に使用されるデータ検索及び更新機能は、クエリ機能5714と共に又はそれに加えて含めることができる。クエリ機能5714は、データベース5722として使用される任意の市販のリレーショナル・データベース、又はデータをリポジトリ・サービス5222内に格納するのに有用なその他のあらゆる標準的な若しくは独自のデータベースによって定義することができる。
オブジェクト管理サービス5720は、データベース5722へのアクセスを制御するために、例えばオブジェクト分散、ロッキング及びキャッシュ・サービス5708を用いて、並びに、データベース5722内のオブジェクトのバージョニング及び他の関連形態を管理するためにオブジェクト永続性及びバージョン・サービス5718を用いて、データベース5722内のデータを管理することができる。例えば、永続性及びバージョニング・サービス5718は、多数の後継ブランチ及び自動又は半自動マージによって、メタ・モデルとモデル・インスタンスの両方のバージョニングをサポートすることができる。永続性及びバージョニング・サービス5718は、他のシステム・リビジョン又は更新を乗り切るインスタンスによってカスタム又はユーザ定義済みモデルをサポートすることもできる。別の例としては、永続性及びバージョニング・サービス5718は、多数の並行モデル・バージョンの使用をサポートすることができる。同時に、リポジトリ・サービス5222は、Mircosoft SCCI規格等に従って、外部ソース制御及びバージョン管理システムへのインターフェースを提供することができる。モデル間参照は、永続的なものとすることができる。より一般的には、メタデータ・サービスは、リポジトリ・アーキテクチャ内の任意の層(データベース及び如何なるコア・サービスよりも上)に常駐することができ、例えば、インポートされた項目等のメタデータ項目の調整、インパクト分析、変更伝搬及びデータ・リネージュ等の分析、報告及び文書化、エンタープライズ全体及び個人カタログのためのカタログ化及びカテゴリ化スキーム、協働及びワークフロー・サポート、並びに、スクリプト機能のための機能を提供することができる。
データベース5722は、例えば、上述のデータ・ソース102のいずれかとすることができる。動作(例えば、ランタイム)リポジトリ及び設計リポジトリ(共通リポジトリ又はコア・リポジトリとも呼ばれる)を含むことができる論理リポジトリは、個人、チーム/プロジェクト、区分、又はエンタープライズ・リポジトリ、並びに、集中化又は非集中化リポジトリを含む、多数の及び/又は分散リポジトリとして柔軟に構成することができることが認識される。さらに、リポジトリは、異なるリポジトリ・インスタンス間の自動同期を提供することができる。リポジトリ・サービス5222は、外部クライアント及びサービス5700に対し透過的な方法でリポジトリの構成を管理するために機能又はサービスを含むことができる。
図62を参照すると、コンポーネント及びコンポジション・モデルを記述するハイレベルのUML図が示される。コンポーネントは、種々のタイプの変形及び統合等の、外部リソースを含むことができる設計ソリューション5304のきめ細かい要素とすることができる。コンポーネントは、サービスとして公開し、SOA5201によって調整することができるコンポジションの中に共にリンクすることができる。したがって、データ統合プロセスにおけるサービスについてのコンポーネント・ベースの設計又は記述がここでは説明される。コンポーネントの要素が、以下に説明される。
コンポーネントは、段階エディタ等の、少なくとも1つの関連する設計時オブジェクト、designtime5814と共に、定義、componentdef5810を有することができる。複数のdesigntime5814オブジェクトは、設計要件によってcomponentdef5810と関連付けることができる。componentdef5810は、そのコンポーネントについて特性の名前及びタイプを指定できる、複数の特性定義オブジェクト、propertydef5802をさらに含むことができる。
柔軟なソリューション作成のサポートにおいて、アーキテクチャ5200は、抽象と具象の両方のコンポーネントをサポートする。抽象コンポーネントは、柔軟な増分的作成をサポートすることができ、部分的な指定のみによってオブジェクトを表すことができる。abstractcomponentdef5820は、データベース又はプロセス等の特定のタイプの抽象コンポーネントを表すことができ、設計ソリューション5304において後の時点で具体化し得る。具象コンポーネントは、完全に定義されたオブジェクトであり、concretecomponentdef5818によって定義される。
具象コンポーネントは、生成されたコード、高いスループット、デバッギング、チェックポイント、又はプロセス状態の永続性等の、デプロイエンジン毎のランタイム5814の実行オブジェクトを有することができる。ランタイム実行オブジェクトは、設計ソリューション5304のデプロイにおける初期化、公開、実行、取得、配置、波の終端、リセット、異常終了等の、コンポーネント・インスタンスのライフサイクル動作をサポートすることができる。connectordef5828オブジェクトは、外部リソースに接続することができ、かつ、サービス又はメタデータ等の外部リソースへの公開を提供することができる、concretecomponentdef5818を定義することができる。
きめ細かいコンポーネントは、より複雑な機能のコンポジションを形成するために、相互接続することができる。一般に、特定のランタイム環境内で識別できる高性能のインターフェースのために、きめ細かいコンポーネントを使用し又は共に構成することができる。したがって、コンポーネント・ベースの設計は、本明細書において説明されたサービス指向アーキテクチャとは無関係に有用なものとなり得る。しかしながら、コンポジションは、compositiondef5822によって定義され、それは再帰的であり、他のSOA5201の調整済みサービスによって再使用可能であり、他のSOA5201クライアント及びサービスにサービスとして公開することができる。compositiondef5822の最外レベルは、特殊なcompositiondef5822とすることができるprocessdef5830とすることができる。compositioninstance5824は、各々の新しい定義済みcompositiondef5822を用いて作成することができ、compositioninstance5824は、インスタンスについての特性値を含むことができる。
コンポジションは、コンポーネントの全てが具象化したときにだけ実行することができる。設計プロセスの間、抽象コンポーネントとして開始するプロセス又はデータベース等の如何なるコンポーネントも、具象コンポーネントになるように定義される必要がある。同時に、抽象コンポーネントのための設計は、具象コンポーネントの最終設計か又は他の外部設計要因のいずれかに応じて、変更することもできるし、或いは、再配列することもできる。したがって、単一の設計又はモデル内の種々のレベルの抽象化において設計を修正できるプログレッシブ設計を実現することができる。共通のコンポジション及び統合プロセス・モデルは、設計ソリューション5304のためのGUI5202を介して公開することができる。コンポジションは、それ自体をコンポーネントと考えることができ、コンポジションは、ユーザからさほどのプログラミング・スキルを要求することなくより複雑なコンポジション・サービスを作成するために互いにリンクすることができる。コンポーネント及びコンポジションは、GUI5202において作成することができ、あまりスキルのないユーザによりコンポーネント及びコンポジション設計についてウィザードにアクセスすることができる。アーキテクチャ5200のコンポジション・モデルは、それらが特性、入力及び出力、作業単位、ローカル変数、範囲、制御制約、イベント、ステートレス及びステート・ベースの設定、例外、並びに、再帰的コンポジション等の、SOA5201によって調整されることを可能にする属性を含むことができる。
図63は、コンポジション・モデルのEnterprise Integration Language(EIL)の例が、XML表示5914によって示される。表された統合プロセスは、SOA5201を介してクライアント又は他のサービスから一連の作業項目メッセージを受け取ることができる。この例においては、これらの作業メッセージの各々が、データベース・ルックアップ5904、変形5908、関係行へのサブレコードの促進5910、及びデータベースへの挿入5912を要求することができる。最も外側のアトミック5900範囲は、実行のためのシーケンスを指定することができる。この例においては、ルックアップ5904、変形5908、関係行へのサブレコードの促進5910、及びデータベースへの挿入5912は、逐次的に実行される必要がある。アトミック範囲5900には、独立5902範囲が、データベースへの挿入5912によって順に実行できる完全なシーケンスとして公開される。
内側の独立5902範囲は、閉鎖されたシーケンス、データベース・ルックアップ5904、変形5908、及び関係行へのサブレコードの促進5910が互いから独立したパイプライン形式になり得ることを示すことができる。これは、パイプライン化又は並行処理を用いる実行を容易にすることができる。
このようにして、EILモデルは、コンポジションの異なるシーケンスがどのように相互作用するかを定義することができ、すなわち該モデルは、直列的に幾つかのシーケンスを実行し、並列的に他のものを実行するための許可を与えることができる。
XML表現5914は、EILモデルのスクリプト解釈を示すことができる。当業者であれば、EILモデルへのXMLスクリプトの関連性を理解することができるであろう。
図64を参照すると、クライアント及びサービス関係を説明する図58のUML、並びに、コンポーネント及び構成関係を説明する図62のUMLにおいて説明されたような、クライアント、サービス、及びコンポーネントの関連性のUML図が示されている。これらの2つのモジュールの全作業についての詳細な説明に関する図58及び図62の前の記述を参照する。
クライアント5412は、SOAサービス5414を用いるデータ統合開発のためのユーザ対話及びAPIを与えることができる。個々のコンポーネントは、SOAサービス5414及びクライアント5412とインターフェースする設計時間及びランタイム・インターフェースを与えることができる。設計時間5808コンポーネントは、クライアント5412とインターフェースすることができ、設計ソリューション5304のために、利用可能なコンポーネント機能をもつSOAサービス5414によって調整される。この設計時間5808コンポーネント及びSOAサービス5414との調整は、プロセス・デザイナ5402においてユーザに対して利用可能なコンテクストを与えることができ、コンテクストに対して敏感なGUIをサポートすることができる。
ランタイム5814コンポーネントは、SOAサービス5414とインターフェースして利用可能なサービスを伴う設計ソリューション5304のデプロイを調整することができる。SOAサービス5414は、SOAサービス5414を設計ソリューション5304の設計要件及びハードウェア環境のランタイム要件に対して公開する設計時間コンポーネント5808及びランタイム・コンポーネント5814の両方との接続を有することができる。SOAサービス5414は、ランタイム・コンポーネント5814及び設計ソリューション5304のための設計時間コンポーネント5808によるデプロイを調整することができる。外部リソースとの通信を担当するコンポーネント・サービス5420は、通信サービスをSOA5414に公開して、設計ソリューション5304のデプロイ及び設計のために外部リソースに公開されるSOAサービス5414を与えるために、コンポーネント・インスタンス5812を使用することができる。SOAサービス5414に対する外部リソースの公開は、外部リソース及びサービスへのSOA5201のクライアント及びサービスの公開を抑留することができる。
図65を参照すると、第1コンポーネント6100から第2コンポーネント6102に渡されるデータの概略的表現が示されている。アーキテクチャ5200のランタイム・データ表現は、複数のサービス及び接続が共通のマナーでデータと共に働くことを可能にする共通のデータ表現を使用することができる。アーキテクチャ5200のリポジトリ・サービス5222は、XML、EDI、COBOL、バイナリ構造、ネイティブ言語フォーマット、ネイティブ・マシン・フォーマットその他の産業データ・フォーマットのような複数のデータ構造とインターフェースすることができる。多数のデータ構造を効率よく処理するために、アーキテクチャ5200は、共通の内部データ構造を使用することができる。
リポジトリ・サービス5222は、不必要な変換を回避するために最小限のデータ翻訳によりデータをメモリ6114に渡すことができ、それによりデータ転送効率を高めることができる。データは、共用可能メモリ6114に渡すことができ、そこで、データ統合ジョブを実行するコンポーネントのために必要とされるデータのみが翻訳され、共用可能メモリ6114に散在され集合される。BLOB及びCLOBといった大きな非解釈データ項目は、ソースからターゲットへの参照によって渡すことができる。リファレンスのみを与えることによって、データはデータの必要な部分のみが翻訳され、次いでメモリ6114に散在され/集合されることのみが要求されるので、大きな非解釈データがメモリにコピーされる必要はない。
データを第1コンポーネント6100から第2コンポーネント6102に渡す例は、散在−集合リスト6104にアクセスするコンポーネントを示す。散在−集合リスト6104は、共用可能メモリ6114にあり、ソース又はターゲット・データ表現内のデータのより小さい部分へのポインタを有することができる。データ表現は、XMLテキスト6108、データベース・フェッチ・バッファ6110、COBOLレコード6112、又は他のデータ・フォーマットとすることができる。散在−集合リスト6104は、データ表現が共用可能メモリ6114に一度ロードされることを可能にし、データ表現へのポインタは、必要なデータを指し示すために操作される。実際のデータを動かす代わりに散在−集合リストにおけるポインタを操作することによって、最も繰り返しの多いデータ・コピー及びメモリ再分配をなくすことができる。ポインタがコンポーネントのために確立されると、必要なデータのためのデータ翻訳が自動的に行われ、それは共用メモリ6114において翻訳されないデータの大部分を残す。データ処理は、他のコンポーネントによる再使用のために、散在−集合6104リストへのポインタと共に、変換されたデータ値をキャッシングすることによってさらに強化される。
これらの技術を用いて、非常に高性能の形で、構成コンポーネント間でデータを渡すことができる。
図66は、アーキテクチャ5200のための共通エンジンを示す。共通エンジンの枠組みは、フロー・デザイナ6210、ウィザード6212、格納されたモデル又は前のプロジェクトのような例6214、テンプレート6216などを用いて共通中間統合プロセス仕様6220とインターフェースすることができるプログラマ6204、統合デザイナ6202、及びビジネス分析家6200といったユーザを含むことができる。ランタイム・コンパイル及び最適化層6230は、高スループット・エンジン6240、高並行性エンジン6242、格納された手順6244、コンピュータ・プログラム・コード6246などのようなエンジンの使用に対する種々の度合いの自動又は手動制御を与えることができ、それは次に、共通のコンポーネント及び接続6250を介して外部リソースと通信することができる。
多くのデータ統合サービス及び機能は、変換、導出、集約、ルーティング、メタデータ・マッピング、品質アサーションのような変形、及び他のデータ変形を要求する。アーキテクチャ5200は、GUI5202と変形ロジックとを結合する単一の変形仕様を与えることができる。変形の枠組みは、リレーショナル、階層的、XML、任意的及び他の業界標準フォーマットのような複数のデータ・フォーマットのための統一された変形方法を与えることができる。前述のように、変形のような処理は、データのサブセットに限定することができるという利点があり、データのかなりの部分は、どんな変形もなしに渡すことができる。
図55に示すように、アーキテクチャ5200は、種々の組織位置からのユーザが彼らの能力に適した環境で働くことを可能にするスキル・ベースの単一のGUI5202を提供する。この変形の枠組みは、この能力を活用し、データ変形と共に働くGUIの一部として複数のユーザ・インターフェースを与えることができる。この変形の枠組みは、ビジネス分析家6200、統合デザイナ6202、プログラマ6204、及び彼らのスキル・セットに合わせられたインターフェースを介するその他のユーザのためのアクセスを提供することができる。
フロー・デザイナ6210、ウィザード6212、例6214及びテンプレート6216は、メタデータ、メタデータ・モデル、サービス、コンポーネント、構成、その他の前述のプロセス設計要素のいずれかを含むことができる共通中間統合プロセス仕様6220を設計し修正するために、種々のユーザ6200、6204、6206によって用いられる、統合プロセスを設計するための可能なユーザ・インターフェース・ツールの網羅的でない集合体を表す。さらに、これらの又は付加的な可能な設計ユーザ・インターフェースの各々は、ユーザのスキル・レベル、役割、技術プラットフォームなどと整合性が取れた設計詳細へのユーザの異なるレベルのアクセスを可能にする。
例えば、ビジネス分析家6200は、条件付き分岐、イベント検出、及びフィルタ・ルールといったより高レベルの論理設計に、より関係していることがある。ビジネス分析家6200は、例えば、ビジネス分析家6200のプログラミング・スキルと一致している単純な設計フロー及び変形表現式構築機能を可能にするより単純化され又はより統合された機能を用いて統合プロセス仕様6220を開発するために、ウィザード6212、例6214、又はテンプレート6216を使用する傾向がある。
統合デザイナ6202は、品質表明、データ変換、キー表現、ルーティング、フィールドレベル変形及びデータ・クレンジングのためのより複雑なプログラミング能力を可能にすることができる。統合デザイナは、直接の、明示設計のための表現言語と共に動作する、より深い能力を可能にする、ウィザード6212、例6214、及びテンプレート6216、並びに、他の高又は低レベルGUIインターフェースを使用することに加えて、プロセスの明示的なモデル部分のためのフロー・デザイナ6210を使用することができる。このGUIレベルは、統合デザイナ6202に関して依然としてスキル・レベルの制約があり、援助を要求する表現構築又は他のタスクのためのウィザード6212へのアクセスを有することができる。
プログラマ6204は、カスタム変形機能及びカスタム・コンポーネントに対する最大の制御を可能にするために、フロー・デザイナ6210、GUI、又はコマンド・ライン・インターフェースを使用することが好ましいが、他のインターフェース6212、6214、6216を、設計プロセスの全体を通して交換可能に使用することができる。プログラマ6204は、記録レベル及びデータ・セット・レベル論理の機能を含む、統合プロセス設計のための詳細の微細レベルへのアクセスを有することができる。プログラマは、この限りではないが、共通コンポーネント及び接続6250の要素を書く又はカスタマイズする機能、SOA5201を介してアクセスされるユーザ定義されたサービスを作成し使用する機能、並びに、コンパイル及び最適化処理層6230への詳細なアドバイスを与える機能を含む、よりきめ細かい機能へのアクセスを可能にする。
種々のインターフェース6210−6216を用いると、ビジネス分析家6200、統合デザイナ6202、及びプログラマ6204のようなユーザは、統合プロセスを実行するのに用いられるイベント・エンジン及びコンポーネント並びに接続から同じく独立した表現である、共通中間統合プロセス仕様6220を使用する統合プロセスを設計することができる。この中間統合プロセス仕様6220は、EIL5900のような共通中間統合プロセス仕様言語又はその他の等価な表現で表すことができる。
コンパイル及び最適化プロセス層6230は、共通中間統合プロセス仕様6230を、この限りではないが、高スループット・エンジン6240、高並行性エンジン6242、1つ又はそれ以上のデータベース格納手順6244、及び/又は、この限りではないがC、C++、C♯、COBOL、並びにJavaBeans及びEnterprise JavaBeansを含むJavaを含む従来のプログラミング言語のいずれかのコンピュータ・プログラム生成コード6246の1つ又はそれ以上のセグメント、又は、ここで説明されるシステムに適した多目的コンピューティング・アルゴリズムを翻訳し、解釈し、及び/又は実行することができるその他の実行環境を含む、1つ又はそれ以上の実行エンジン環境に固有の実行仕様に翻訳することができる。コンパイル及び最適化プロセス層6230は、データ・ソース102及びデータ・ターゲット102に関するメタデータ・リポジトリ5214に格納されたメタデータの知識、並びに、コンピュータ・システム環境構成に関する情報を用いて、統合プロセス仕様6230を、種々のエンジン及び実行環境に適した効果的な命令の組み合わせにどのように翻訳するかについての決定を下すことができる。さらに、コンパイル及び最適化プロセス層6230は、SOA5201を介して利用可能な多数のサービス5414のいずれかを用いて、統合プロセス仕様6220をどのように最良にコンパイルし最適化するかについての情報を得た判断を下すために、データ・プロファイル情報のような付加的なメタデータを導出することができる。
異なる統合プロセス実行エンジン及び環境6240、6242、6244、6246などは、コンポーネント・インプリメンテーション5814及びコネクタ6310を含む、所定の及び/又はユーザ定義の共通コンポーネント及び外部データ・ソース並びにターゲット接続6250を使用することができる。
カスタム設計された変形コンポーネント、並びに、ビジネス分析家6200、統合デザイナ6202及びプログラマ6204のようなクライアントによって作成される接続要素は、リポジトリ・カタログにおける別の共用可能な要素としてリポジトリ5224に格納することができ、そこから、実行可能な統合プロセスを生成するためにコンパイル及び最適化層6230によって使用され得る。
図67を参照すると、アーキテクチャ5200、サービス6300、コンポーネント6302及びエンジン6304がコネクタ・コンポーネント6310を介して外部リソースにアクセスすることを可能にする接続アーキテクチャが示されている。これらのサービスは、上記の図面に既に定義されている。
コネクタ・コンポーネント6310の役割は、外部リソースのインターフェースをカプセル化し、これらの外部リソースをコンポーネント6308及びサービスと共に使用するために安定化させることである。コネクタの役割は、データを、変形をより効率よく完了させることができる変形コンポーネントのような他のコンポーネント6308に、小さな変形を伴って渡すことである。既述のように、変形は、送信された外部データ内の限られた量のデータに関してのみとすることができる。コネクタ6310を用いてほんのわずかにデータを変形することにより、コネクタ6310がデータをコンポーネント及びサービスに効率よく移動させることが可能になる。コネクタは、コンポーネント・サービス6302を介する設計時間インターフェース又はデプロイエンジン6304へのランタイム・インターフェースを与える専門化されたコンポーネントとすることができる。
コネクタ6310の一部として、アダプタ6312は、特定の外部リソースへのコンポーネント・インターフェースを与えるコンポーネントのサブ・クラスとすることができる。コネクタ6310においては、単一の外部リソースのライフサイクルを管理することができる低レベルコンポーネントとして、複数のコネクタ6314が存在する。接続6314は、読み取り、書き込み、送信し、受信し、クエリし、又は外部リソースを更新することができる関連するイベント・リスニング及びリソース・アクセスを有することができる。
接続管理インターフェース6312は、接続6314を支援してプーリング機能を提供することができる。プーリングは、主に高並行性の実行環境のために用いることができ、並行データのスムーズな伝送を可能にする。高スループットの実行環境においては、同じ接続管理インターフェースを用いることができるが、整合接続を与えるために高デューティサイクルの再使用を可能にする持続的な接続を維持することができる。コネクタ6310は、インストール、設計時間インターフェース、メタデータ・インターフェース、コンパイル、検証、デバッグ、モニタリング、インスタンス生成、状態管理、プーリング、キャッシング、トランザクション、例外処理、データ・アクセス、イベント検出、永続性、リース、BOMプロダクション、データ・サンプリング、及びサンプル・データ生成といった、複数の外部リソース・ライフサイクル機能を与えることができる。コネクタ6310は、モデルによって説明することができ、リポジトリ5224に格納することができ、外部リソースにアクセスするためのセマンティック・ハブ・モデル5614にアクセスすることができる。コネクタ6310は、ODBC/JDBC、JCA、EJB及びウェブ・インターフェースといった外部リソースへのラップ・インターフェースをラップすることができる。
本発明は、特定の好ましい実施形態と関連して説明されたが、他の実施形態が当業者によって理解され、本開示の範囲内に入ることを意図されていると理解されたい。