EIP
Chapter 4 : メッセージチャネル (Messaging Channels) †
導入 (Introduction) †
第３章「メッセージングシステム」で、 Message Channels(60) について議論してきた。
２つのアプリケーションがデータを交換したいとき、その２つにつながっているチャネルを通じてデータを送ることで、それを行っている。
そのデータを送っているアプリケーションは、どのアプリケーションがそのデータを受け取るのかし習いかもしれない。
しかしながら、データを送っている特定のチャネルを選択することにより、そのチャネル上のそのデータを探しているものが何かということを探せるので、その送り手は受け手を知ることになる。
この方法により、共有データを生み出しているアプリケーションは、それを消費したい受け手とコミュニケーションする方法を持つ。
メッセージチャネルのテーマ (Message Channel Themes) †
Message Channel(60) を使用することを決めることは、単純なことである。もし、あるアプリケーションが送りたいデータ、もしくは、受け取りたいデータを持っているなら、とあるチャネルを使用しなければならなくなる。
困難なのは、あなたのアプリケーションがどのチャネルを必要としているかを知ることと、それらを何のために使用するかを知ることである。
チャネルの固定集合 (Fixed set of channels) -- この章で議論するひとつのトピックは、 Message Channels(60)の集合を、とあるアプリケーションを静的になりがちにすることを可能にすることである。
とあるアプリケーションを設計するときに、開発者は、他のアプリケーションとそのデータを共有するために、どんなタイプのデータをどこに置くかを知らなければならない。同様に、他のアプリケーションからやってくる特定のタイプのデータを探す場所を知らなければならない。
それらの通信経路は、実行時に動的に作ったり発見したりすることは出来ない。それらは設計時に合意される必要があり、その結果、そのアプリケーションは、そのデータがやってくる場所を知り、また、そのデータが出て行く場所を知る。
(多くのチャネルが静的に定義される必要があるのは本当なのだが、例外もあり、動的チャネルが実用的で使えるものである場合もある。
ひとつの例外は Request-Reply(154) 内での応答チャネルである。
その要求者は、応答者が知らない新しいチャネルを作ったり得たりすることが出来き、また、要求メッセージの Return Address(159) としてそれを明記することが出来る。
応答者はその結果それを使うことが出来る。
他の例外は、階層的なチャネルをサポートするメッセージシステムの実装です。
ある受信者は、その階層の親を購読(subscribe)することが出来て、またその結果、ある送信者は、受信者が知らないある新しい子チャネルを出版(publish)することができる。
その購読者(subscriber)はそのメッセージを受け取り続ける。
これらの相対的に普通でない場合にも関わらず、通常、チャネルは配置するまえに定義され、また、アプリケーションは知られたチャネルの集合の周辺で設計される。
チャネルの集合を決定する (Determining the set of channels) -- 関連する事柄は、どんなMessage Channel(60)を入手可能にするのかを決定するのは誰であるか、ということである。それは、メッセージングシステムだろうか、アプリケーションだろうか。
言い換えると、そのメッセージングシステムは特定のチャネルを定義し、それらとさせるためのアプリケーション要求するのか。
もしくは、アプリケーションがどんなチャネル必要なのか決定し、それらを提供するためのメッセージングシステムを要求するのか。
単純な回答はない。必要なチャネルの集合を設計することは反復的である。
まず始めに、アプリケーションは、メッセージングシステムが提供する必要があるのはどんなチャネルかを決定する。
それに続くアプリケーションは、入手可能なチャネルの周辺でそれらの通信を設計してみようとする。しかし、それが実用的でない場合、それらは追加チャネルを追加することを要求する。
アプリケーションの集合が既に特定のチャネルの集合を使用していて、また、新しいアプリケーションが加わりたいとき、かれらはまた、既存のチャネルの集合を使用する。
既存のアプリケーションが新機能を追加するとき、新たなチャネルを要求するかも知れない。
単方向チャネル (Unidirectional channels) -- 他のよくある混乱の元は、 Message Channel(60)は単方向なのか双方向なのかということである。技術的には、それはどちらでもない。
チャネルはむしろ、いくつかのアプリケーションがデータを追加し、他のアプリケーションはデータを取り出す、バケツに似ている。
(協調的なやり方で多数のコンピュータにまたがって分散しているバケツではあるが。)
しかし、そのデータはひとつのアプリケーションから他に伝わっていくメッセージの中にあるため、それはチャネルの方向を与え、それを単方向にさせる。
もし、チャネルが双方向だったらならば、あるアプリケーションは、同じチャネルからメッセージを送ったりメッセージを受け取ったりの両方を行うことになる。技術的には可能であったとしても、それはあまり意味が無い。なぜなら、そのアプリケーションは、他のアプリケーションに送るつもりでも、自分自身のメッセージを消費し続けがちになるからである。
なので、すべての実用的な目的のため、チャネルは単方向である。
結果として、２つのアプリケーションが両方向の会話をするためには、それぞれの方向をもつ、２つのチャネルが必要である。(次の章の Request-Reply[154] を参照すること)
メッセージチャネルの決定事項 †
いまや、我々は Message Channel(60) はなんであるかを理解したのだから、それを使うのに関与する決定事項を考えることにしましょう。
一対一か一対多か (one-to-one or one-to-main) -- アプリケーションがデータの一部を共有するとき、ただひとつのほかのアプリケーションと共有したいですか？それとも、興味を持っているどんなアプリケーションとも今日したいですか？
単一のアプリケーションにデータを送るため、Point-to-Point Channel(103)を使いましょう。
これは、そのチャネルへ送ったデータのすべての断片が必ず同じ受信者に行くことを保障しない。なぜなら、そのチャネルは複数の受信者を持っているかも知れないからである。
それは、しかしながら、データのどんなひとつの断片もアプリケーションの中のひとつだけに届くことを保障する。
もし、すべての受信アプリケーションがそのデータを受信できるようにしたいなら、 Publish-Subscribe Channel(106)を使うべきだ。
この方法でデータの段ポンを送るとき、そのチャネルは効果的にそれぞれの受信者にデータをコピーする。
どんなタイプのデータか (what type of data) -- どんなコンピューターのどんなデータも型(取り決められた意味で、知られた形式や予期された構造)といったものに適合しなければならない。
さもなくば、すべてのデータは一連のバイトでしかないし、それはどんな意味をも持つことは決してない。
メッセージシステムはいつもと同じ方法でうまく動作する。つまり、その受信者はデータの構造を理解できるように、そのメッセージの中身を何かの型に適合させなければならない。
Datatype Channel(111) は、チャネルのすべてのデータは、同じ型のデータにならなければならないという発想に基づいている。
これが、メッセージングシステムが多くのチャネルを必要としている主な理由である。
もし、そのデータがどんな型のデータデータになりうるなら、そのメッセージシステムは２つのどんなアプリケーション間でも、ひとつのチャネルだけが必要である。
無効で廃れたメッセージ (invalid and dead messages) -- メッセージシステムはメッセージが正しく届けられることを保障できるが、受信者がそれで何をするのかを知ることを保障することは出来ない。
その受信者は、データの型と意味について、期待をしている。
それが、そういった期待と合致しないようなメッセージを受信するとき、それらはなにかをするには不十分である。
受信者が出来るしかしながら、事は、その未知のメッセージを特別に指定された Invalid Message Channel(60) に置く事だけである。チャネルをモニターしているあるユーティリティが、そのメッセージを拾って、それで何をするのかを見つけ出す。
多くのメッセージングシステムは、Dead Letter Channel(119) という同様の元から持つ特性を持っている。メッセージにとっては、成功裏に送られるが、最終的に、成功裏に届けられない。
重ねて、システム管理ユーティリティは Dead Letter Channel(119) をモニターしなければならなず、届けることが出来なかったそのメッセージでやることを決めなければならない。
障害対策 (Crash Proof) -- もし、メッセージシステムに障害が発生するか、保守のために停止されるとき、そのメッセージに何が起こるだろうか。
それがバックアップされ動作している時、そのメッセージはまだそのチャネルの中にあるだろうか。
デフォルトでは、NOである。チャネルはそれらのメッセージをメモリに保存している。
しかしながら、 Guaranteed Delivery(122) はチャネルを永続的にさせる。つまり、それらのメッセージをディスクに保存する。
これは、性能を犠牲にするが、メッセージングの信頼性をより高める。メッセージングシステム自身の信頼性が低いときでさえ。
メッセージを受け付けないクライアント (non-messaging client) -- もし、あるアプリケーションがメッセージングシステムに接続できず、でもまだ、メッセージングに参加したいとしたらどうなるだろうか。通常、運が無かったかも知れないが、もし、メッセージングシステムがそのアプリケーションに何とかして(そのユーザーインターフェースや、そのビジネスサービスAPIや、そのデータベースや、TCP/IPやHTTPといったネットワーク接続を通して)接続できるならば、メッセージングシステムの Channel Adapter(127) が使用されうる。
これにより、そのアプリケーションを変更なしで、また、たぶん、そのアプリケーションとして同じマシンじょうで動作しているメッセージングクライアントを必要とせずに、そのアプリケーションへのチャネル(もしくは、チャネルの集合)に接続できる。
時々、その「メッセージを受け付けないクライアント」は、本当に、とあるメッセージングクライアントだが、異なるメッセージングシステムのためのものでしかなかったりする。
そういった場合は、両方のメッセージングシステム上のクライアントであるアプリケーションは、効率的にひとつの混成メッセージングシステムに接続している両者間の Messaging Bridge(133) を構築できる。
通信のバックボーン (communcation backbone) -- メッセージングシステムに接続している企業アプリケーションはますます増え、メッセージングを通してそれらの機能が使用可能になっているので、そのメッセージングシステムは、企業内の機能共有のためのなんでもやさんという中央集権型のものになってくる。
とある新しいアプリケーションは、単に、要求する機能をを使用するためのチャネルがどれかを知り、その結果を受け取るのがどれかを知るだけでよい。
メッセージングシステムそのものは、本質的にバックボーン Message Bus(137) になり、それは、すべての企業の多様で常に変化しているアプリケーションと機能への接続を提供する。
最初からそのために明確に設計することにより、より早く簡単に、この統合天国(integration nirvana)を実現することが出来る。
ご覧のように、アプリケーションがメッセージを送ることが出来るように、Messaging(53) 用にアプリケーションをセットアップすることは、より多くアプリケーションをメッセージングシステムに接続することを伴う。
そのメッセージは、送信するための Message Channels(60) を持たなければならない。
単純にいくつかのチャネルに置く(slapping)ことでは、なにも仕事をなさない。
それらは、目的を持って設計されなければならない。つまり、共有されているデータ型に基づいてなければならず、ある程度のアプリケーションがデータを使用可能にしていなければならず、ある程度のアプリケーションがデータを受け取っていなければならない。
この章では、それらのチャネルの設計を論じる決定について説明している。
そのパターンの説明を助けるために、それぞれには空想の単純な証券取引領域のサンプルがある。
それらの例はどれも実際の取引システムの実装に基づくために用いるべきではない。それらは、パターンをどのように使うことが出来るのかを示すちょっとした特定の例を提供するに過ぎない。
