EIP / Ch8 Introduction

EIP

Introduction †

一言要約 †

要約 †

Introduction †

メッセージングシステムによって統合される必要があるアプリケーションは、まれに、 共通のデータフォーマットであることに賛同する。 例えば、会計システムのCustomerオブジェクト、顧客管理システムのCustomerオブジェクトとは、異なる概念をもっている。

上記のこのことは、あるシステムでは、リレーショナルモデルにデータを永続化するかもしれない、 その一方で、他のアプリケーションは、フラットなファイルもしくは、XMLドキュメントを利用する。

存在するアプリケーションを統合するということは、私達が他のシステムと一緒により簡単に動作するためにアプリケーションを修正することの自由がないことを、意味する。

むしろ、統合ソリューションは、異なっているシステム間の違いを適応させ、解決しなければならない。 Message Translator パターンは、そのデータフォーマットの違いのための一般的なソリューションを提案する。 このチャプターでは、Message Translatorの特定のものを、探求する。

Envelope Wrapper †

たいていのメッセージングシステムは、フォーマットとメッセージヘッダーの中身が、特定の要件に考えられている。 私たちは、ペイロードの形式のメッセージを、メッセージング基盤の要件に準拠したEnvelope Wrapperにラップする。 複数のEnvelope Wrappersは、メッセージが、もし異なるメッセージング基盤を通過するなら結合させることができる。

Content Enricherは、もしターゲットシステムが、オペレーディングシステムが供給できないデータフィールドを要求してきたなら、必要とされる。 存在しない情報を参照したり、利用できるデータから算出することができる。

Content Filterは、Content Enricherとは逆で、メッセージから必要としないデータを削除する。

Claim Checkもまた、メッセージからデータを削除するが、あとで復旧するために保存している。

Normalizerは、多くの異なるフォーマットで届いたメッセージを共通のフォーマットに変換する。

Eliminating Dependencies †

メッセージ変換は、統合において深いテーマの１つである。 Message ChannelsとMessage Routersは、アプリケーション間で、他の場所に気付かさせるための１つのアプリケーションの必要性をなくすことで、アプリケーション基本的な依存は、削除することができる。(※翻訳が微妙）

１つのアプリケーションが、Message Channelにメッセージを送ることができ、アプリケーションがそのメッセージを消費したことを気にしなくてもよくなる。 しかし、メッセージフォーマットが他の依存の組合せを課すことになる。 もし１つのアプリケーションが、他のアプリケーションのデータフォーマットにメッセージをフォーマットしなければならないのなら、Message Channelのフォームに切り離すことは、いくぶん誤解である。メッセージを受けとるアプリケーション、もしくは、あるメッセージを受け取るアプリケーションから他のアプリケーションへの切替えのいくつかの変更では、メッセージを送信するアプリケーションをいまだ変更する必要性がある。Message Translatorsは、この依存を削除するのに役立つ。

Metadata Management †

メッセージをあるフォーマットから他のものへの変換は、メタデータとして扱うために必要となる。 メタデータは、実際のデータのフォーマットを記述している。 あるアプリケーションから他のアプリケーションへのメッセージは、ID:123の顧客は、California州のSanFrancisco?から、North Carolina州のRaleigh に異動したことを、わたしたちに教えてくれると同時に、関連したメタデータは、この住所変更メッセージは数字の顧客IDフィールドを使い、 それぞれ40文字までの２つのテキストフィールドに顧客のファーストネーム、ラストネームを保存する、ということを教えてくれるだろう。

メタデータは、ほとんどの統合ソリューション２つの並列システム間で相互作用として見受けられる 統合において、このように重要な役割を果たす。 多くのパターンは、メタデータの流れを設計したり、メタデータの流れを管理することに利用できる。 例えば、 Channel Adapterは、メッセージを、システムの外、中に移動させることができるだけでなく、 外部のアプリケーションからメタデータを抽出したり、中央のメタデータのリポジトリに、そのメタデータを読み込むことができる。 このリポジトリを利用することで、統合の開発者はアプリケーションのメタデータとCanonical Data Modelの間での変換を定義することができる。

↑の図では、顧客情報の交換に必要となる２つのアプリケーション間の統合を表現している。 それぞれのシステムが、顧客データのわずかに異なる定義で持っている。 アプリケーションAは、２つのわかれたフィールドに、ファーストネームと、ラストネームを保存しているのに対して、アプリケーションBは、１つのフィールドにこのファーストネームとラストネームを保存している。 同じように、アプリケーションAは、個客のZIPコードを保存していて、州はもっていない。 一方、アプリケーションBは、州の省略形だけを保存している。 アプリケーションAからアプリケーションBへのメッセージの流れは、変換させる必要があり、アプリケーションBは、要求されたフォーマットでデータを受け取ることができる。 もしChannel Adaptersもまたメタデータを抽出するこおとができるなら、変換を生成することでより簡単にできる。 このメタデータは、リポジトリに読み込まれ、Message Translatorの設定やバリデーションをとても簡単にしてくれる。 メタデータは、多くのフォーマットに保存されている。 XMLメッセージに利用される共通のフォーマットは、XSDである。(eXtensible Schema Definition) 他のEAIツールは、専用のメタデータのフォーマットを実装しているが、管理者は、メタデータを異なるフォーマットにインポートしたりエクスポートしたりすることができる。

Data Transformation Outside of Messaging †

多くのこれらの変換パターンを合併させた原理は、メッセージに基づいた統合の外側に適切である。 例えば、File Transferは、システムの間で変換機能を動作させなければならない。 同じように、Remote Procedure Invocationは、 たとえアプリケーションの内部のフォーマットは異なっていたとしても、呼び出されるサービスによって、特定されたデータフォーマットを要求しなければならない。 これは、呼び出しているアプリケーションが、データの変換をするために、典型的に要求している。

このチャプターでは、基本的なMessage Translatorパターンのバリエーションに注目している。 エンティティ間で構造の変換の詳細についてはふれない。

担当者のコメント †

みんなの突っ込み †