EIP
Messaging (メッセージング) †
企業は、個別に構築され、異なる言語とプラットフォームで実装された、多様なアプリケーションを持っている。
その企業はデータを共有し気の利いた方法で処理する必要がある。
多様なアプリケーションが一緒に動作し、情報を交換できるために、どうやって私はそれらを統合すれば良いのか？
File Transfer(43) と Shared Database(47) は、アプリケーションがそのデータ(でも、機能ではない)を共有することを可能とする。
Remote Procedure Invocation(50) は、アプリケーションが機能を共有する(でも、同様に密結合する)ことを可能とする。
たいていの場合、インテグレーションの難しさは、分離されたシステムを出来るだけ即時に協調することである。アプリケーション実行とアプリケーション開発の両方の観点で信頼できないものになるとった方法でシステムを連結することになってしまう。
File Transfer(43)を用いることで、即時性を犠牲にして、うまく祖結合を保つことが出来る。
システムは、互いにぴったりとついていくことは出来ない。
協調動作(collaborative behavior)は、とても遅い方法だ。
Shared Database(47) は、データベースですべてを結合するということを犠牲にして、信頼できる方法でデータを一緒にし続けられる。
協調動作(collaborative behavior)に対処することにも失敗している。
それらの問題に直面すると、Remote Procedure Invocation(50) は魅力的な選択肢に見える。
しかし、単一アプリケーションモデルからアプリケーション統合に拡張することは、他のたくさんの弱点を掘り返す。
それらの弱点は、分散開発の本質的な問題に起因している。
そのRPCはローカル呼び出しに見えるにも関わらず、それと同様には振舞わない。
リモート呼び出しはより遅くて、失敗する傾向がより高い。
多様なアプリケーションが企業を横断して伝達するとしても、ひとつのアプリケーションの障害により、他のすべてのアプリケーションが障害になるといったことは、望んでいない。
また、呼び出しが高速であると仮定したシステムを設計したくは無いし、あるアプリケーションが他のアプリケーションの詳細を知っていることも望んでいない。たとえ、それらがただのインターフェースの詳細であってしても。
我々が必要としていることは、何か File Transfer(43) のようで、多数の小さなデータパケットをすばやく生成できて、簡単に伝送できるものである。それは、受信するアプリケーションが新たなパケットが受け付けられるときに、自動的に通知されるようになることである。
その転送は、それが成功することを保証するために、リトライメカニズムが必要である。
ディスク構成、もしくは、そのデータを保存するためのデータベースの詳細は、Shared Database(47)とは違い、アプリケーションからは隠されている必要がある。それにより、そのストレージスキーマと詳細は、企業に対する要求の変更を反映するために、簡単に変更することが出来る。
とあるアプリケーションは、Remote Procedure Invocation(50)のように、他のアプリケーションの挙動(behavior)を起動するために、失敗しがちではないように、他のアプリケーションにパケットを送ることが出来るべきである。
転送元は受信先を、特にリトライが必要な場合も、待つ必要が無くするため、そのデータ伝送は非同期であるべきである。
カスタマイズできるフォーマットを使って、何度も、すぐに、信頼性高く、非同期に、データパケットを送信するためにメッセージングを使用する。
非同期メッセージングは、基本的に、分散システムの問題に対する実用的な対処である。
メッセージを送ることは、両方のシステムとも同時に動作していることを要求しない。
さらに、非同期方式による通信について考えることは、リモートアプリケーションとの動作は遅いと開発者が認識することを強いる。それは、高凝集(high cohesion)(ローカルな多くの動作)と低粘着(low adhesion)(リモートな選択的動作)のコンポーネント設計を推し進める。
メッセージングシステムは、File Transfer(43)を使用するときに得たしっかりした分離をも与えている。
メッセージは、通過する際に、送信元か受信先のどちらかがその変換について知ることなしで、変換される。
その分離は、メッセージを多数の受信先にブロードキャストするか、多数の受信先のひとつへルーティングするか、もしくは、他のトポロジーをインテグレーターが選択するすることを許している。
これは、アプリケーション開発からインテグレーション方針を分離している。
人というものは、アプリケーションインテグレーションからアプリケーション開発を分離しがちであるので、このアプローチは、人の性質にそむくのではなく、それとうまく動作する。
変換するということは、分離したアプリケーションはとても違った概念モデルを持つことが出来る、ということを意味する。
もちろん、これは、意味の不一致(semantic dissonance)が発生することを意味する。
しかしながら、メッセージングからみると、意味の不一致(semantic dissonance)を防ぐためにShared Database(47)で使われる方法は複雑すぎて、現実的にはうまく動作しない、ということである。
また、意味の不一致(semantic dissonance)は、サードパーティアプリケーションと会社合併の一部として追加されたアプリケーションで、起こりつつある。なので、メッセージングアプローチは、それを防ぐためのアプリケーションを設計するよりも、問題に対処できるのである。
小さなメッセージを何度も送ることにより、データ共有と同様に、アプリケーションは行動的に(behaviorally)協調することができる。
もし、いったん保険支払い要求を受け取ると、あるプロセスが起動される必要がるあるなら、単一の支払い要求が来たとき、それはすぐにメッセージを送ることによりなすことが出来る。
ただちに情報は要求され、応答がなされる。
そういった協調がRemote Procedure Invocation(50)と同じくらい早くはないとはいえ、呼び出し元は、そのメッセージが処理され応答が帰ってくる間、停止する必要は無い。
そして、メッセージングは、多くの人が考えるほどは遅くは無い。多くのメッセージングソリューションは、毎秒数千もの株価市況と株取引が渡されるメッセージングシステムを用いる金融サービス業界に端を発している。
この本ではメッセージングについて述べている。なので、企業アプリケーション統合に、メッセージングは汎用的な最も良いアプローチであることを支障なく仮定できる。
しかしながら、あなたは、まったく問題が無いと仮定すべきではない。
メッセージングでの、そのメッセージの高頻度は、File Transfer(43)をいらいらさせる多くの不整合問題を減少させる。しかし、すべての問題が無くなるわけではない。
まだ、システムがピッタリ同時にアップロードしないという、いくつかの遅延(lag)問題がある。
非同期設計は、ソフトウェアの人々が考えている多くの方法ではない。そして、その結果として、多くの異なるルールとテクニックがその場にある。
メッセージングコンテキストは、X Windowsのような非同期アプリケーション環境におけるプログラミングより、これを少し簡単にさせる。しかし、非同期方式はまた、学ぶのに時間がかかる(learning curve)。
テストとデバッグは、この環境ではやはり難しい。
メッセージを転送する能力は、Remote Procedure Invocation(50)でやるより、アプリケーションを互いから、より祖結合にすることができるという良い利点を持っている。
しかし、この独立性は、インテグレーターは、しばしば、すべて一緒にひっつけるためのこんがらがった糊コードを書くことにおいまくられる、ということを意味する。
いちど、システムインテグレーションにメッセージングを使うと決めたならば、新たな考慮すべき課題と、採用することが出来る実践することが数多くある。
送信元と受信先をつなぐMessage Channel(60)を通して、Messageを送ることにより、送信元は受信先にデータを送信する。
- どうやって、データをどこに送るのかを知ればよいのか？
もし、送信元がデータの送り先を知らないならば、それは、Message Router(78)を送ることが出来る。それは、正しい受信先へデータを導いてくれる。
- データフォーマットに何を使えばよいのか、どのようにして知るのか？
もし、送信元と受信先がデータフォーマットについて合意できないならば、その送信元はそのデータをMessage Translator(85)に振り分けることが出来る。それは、そのデータを受信先のフォーマットに変換して、受信先にそのデータを転送する。
- もし、あなたがアプリケーション開発者なら、どのようにあなたのアプリケーションをメッセージングシステムに接続するのか？
メッセージングを使いたいとあるアプリケーションは、実際の送信と受信を実行するMessage Endpoints(95)を実装する。
