EIP / Messaging Bridge

Messaging Bridge（メッセージングブリッジ） †

一言要約 †

別々の実装のシステムを共存させるには、間を取り持つブリッジを使えばいいよ。

Context †

アプリケーション間の通信にMessagingを使っている。 でも、いろんな種類のメッセージングシステムが使われていて「あれ？あのアプリとの通信に使うメッセージングシステムってどれだっけ？」てなことになりがち。

Problem †

複数のメッセージングシステムがあるときに、あるメッセージングシステム上にあるメッセージが別のシステム上でも見えるようにするには？

Force †

企業システムによくある問題が、複数のメッセージングシステムを使っているということだ。それぞれ別のメッセージング製品で標準化していたふたつの企業が合併したとか、レガシーシステムで使っているメッセージングシステムと最近のJ2EEアプリや.NETアプリで使っているものとが違うとか、あるいはB2Bクライアントがいろんなオークションシステムに入札したい場合とか。あるいは超大規模な企業で、メッセージングシステムのインスタンスがひとつだけではさばききれないので複数のインスタンスを抱えているとか。

こういうのを統合したいという場合もよくあるはずだ。

「JMSみたいな標準化されたAPIを使えば済む話じゃないの？」違うよ。ぜんぜん違うよ。

確かにJMSを使えば、どんなメッセージングシステムでもクライアント側からは同じように扱える。でも、ただそれだけ。別々のメッセージングシステムの間のやりとりをしてくれるわけじゃない。ここで言う統合とは、お互いのメッセージが相互利用できる状態を指す。異なるベンダーの製品どうしが相互利用できることはめったにない。たいていは、同じベンダーどうしの組み合わせにしか対応していない。

社内の複数のメッセージングシステムに対して、アプリケーションごとにそれぞれ専用のクライアントを実装するという選択肢もある。でも、メッセージング層が複雑になってしまい、さらに冗長になる。もし新たなメッセージングシステムを社内に導入することになったらどうする？全部のアプリケーション用を改修して新たなメッセージングシステムに対応させないといけなくなってしまう。それが嫌なら、アプリケーションごとに「自分はこのメッセージングシステムを使う」と決めてそれ以外を無視してしまうこともできる。この場合、アプリケーションはシンプルになるけれども社内のデータの多くにアクセスできないことになってしまう。

Solution †

Messaging Bridgeを使い、複数のメッセージングシステムをつないでシステム間でメッセージをレプリケートする。

Messaging Bridgeは複数のChannel Adapterをまとめたもの。あるチャネル群から別のチャネル群へのマップとして機能し、システム間でのメッセージフォーマットの変換を行う。

自社向けのMessaging Bridgeを自前で実装する場合もあるだろう。ブリッジというのはMessage Endpointの特別な例で、両方のメッセージングシステムのクライアントとなる。あるメッセージングシステムのチャネルにメッセージが配送されると、ブリッジがそのメッセージをconsumeしてもう一方のメッセージングシステムの対応するチャネルに同じ内容のメッセージを送る。

自社のメッセージングシステム用に、他のベンダーのシステムとの橋渡しをできるような拡張を用意しているベンダーも多い。自分で作らなくても、そういったソリューションを導入するという手もある。

もう一方の「メッセージングシステム」が単なるHTTPのようなシンプルなプロトコルである場合は、Channel Adapterパターンを使えばいい。

Messaging Bridgeが必要となるのは、メッセージングシステムの実装がそれぞれプロプライエタリな手法を使ってメッセージを表現したり転送したりしているからだ。ウェブサービスの場合はこのあたりが標準化されているので、別々の会社が作ったメッセージングシステムを複数インストールしても、その間のやりとりはウェブサービスの標準に基づいて行える。WS-ReliabilityやWS-ReliableMessaging?に関しては第14章「Concluding Remarks」で議論する。

Examples †

Stock Trading †

証券会社ではあるメッセージングシステムを使っており、各地の支社のアプリケーションがそれを使っている。一方、銀行でも別のメッセージングシステムを使っており、各支店のアプリケーションがそれを使っている。この証券会社と銀行が合併して、銀行口座と投資サービスを扱うひとつの会社になったとしよう。さて、合併後の新会社ではどっちのメッセージングシステムをつかうべきだろうか？どちらを選ぶにしても、新会社のアプリケーションの半数を改修する必要がある。その代わりにMessaging Bridgeを導入すればいい。これで、バンキングアプリケーションと証券取引アプリケーションが連携して預金口座から証券取引口座への送金ができるようになる。

MSMQ Bridges †

MSMQではコネクタサーバーを使ったアーキテクチャを定義している。これを使えば、コネクタアプリケーションが他の(MSMQ以外の)メッセージングシステムを使ってメッセージを送受信できる。コネクタサーバーを使うMSMQアプリケーションは、MSMQ上での操作と同じように他のメッセージングシステム上でも操作できるようになる[Dickman]。

Microsoft’のHost Integration Server製品にはMSMQ-MQSeries Bridgeサービスが含まれており、これら二つのメッセージングシステムを共存させることができる。MSMQアプリケーションがMQSeriesのチャネルを使ってメッセージを送ったり、あるいはその逆をしたり。まるで一つのメッセージングシステムであるかのように扱えるというわけだ。

MSMQ-MQSeries BridgeのライセンサーであるEnvoy TechnologiesはEnvoy Connectという関連製品も出している。これは、MSMQやBizTalk? serverを非Windowsプラットフォームのメッセージングサーバーと接続するための製品だ。特にJ2EEプラットフォームを主眼としており、企業内でJ2EEと.NETのメッセージング環境を共存させられるようになる。

SonicMQ Bridges †

Sonic SoftwareのSonicMQにはSonicMQ Bridgeという製品があり、IBM MQSeriesやTIBCO TIB/RendezvousそしてJMSに対応している。これを使えば、Sonicチャネルのメッセージを他のメッセージングシステムのチャネルにも送信できるようになる。

担当者のつぶやき †

WS-ReliabilityやWS-ReliableMessaging?に関しては、最近出た「サービスデザインパターン」とかいう本でも扱われているらしい

みんなの突っ込み †