メッセージ指向ミドルウェア
メッセージ指向ミドルウェア（メッセージしこうミドルウェア、英: Message-oriented middleware、MOM）とは、アプリケーションソフトウェア間のデータ通信ソフトウェアであり、一般に非同期メッセージパッシングに基づいたものを指す。
多くのメッセージ指向ミドルウェアはメッセージキューシステムに基づくが、他にもブロードキャスト型のメッセージシステムやマルチキャスト型のメッセージシステムに基づくものもある。
起源
編集ミドルウェアという概念が登場したのは比較的遅い。1980年代に古いシステムと新しいアプリケーションをどう接続するかという問題の解決策として登場した。それはまた、分散コンピューティングを助長することになった。すなわち、コンピュータネットワーク上で複数のアプリケーションを接続して、全体として大きなアプリケーションを形成するようになったのである。
寓話的解説
編集大手の銀行の場合を例として考えると、ミドルウェアがビジネスの要求としていかに成長してきたかがわかる。銀行は1960年代から、顧客に関する全ての情報を大規模なメインフレームに格納していた。このメインフレームは何度かの更新を経て、今も現役で使われ続けている。その後、パーソナルコンピュータ (PC) ベースの独立したアプリケーションで顧客にメインフレームには不可能な新たなサービスを提供するようになると、メインフレームの有用性は減少していった。理想としては、PCベースのアプリケーションとメインフレームのアプリケーションが接続され、メインフレームとPCがデータを共有するのが望ましい。メインフレームのデータにアクセスできれば、次の2つの利点が生じる。
- 新たなフロントエンドとしてのPCアプリケーションは、古くて使いにくいメインフレーム端末を置換できる。
- PCベースのシステムは、メインフレームのデータを従来のシステムでは不可能だった新たな方法で活用できる。
1980年代末まで、これらアプリケーションを相互に接続する容易な方法は存在しなかった。開発者はいくつかの問題に直面した。
- ソフトウェア開発者は、2つのシステムを接続するに当たって、送信側から送られてきたデータを受信側で扱える形式に変換するためのソフトウェア「アダプタ」を開発しなければならない（双方向通信なら双方のシステムにアダプタが必要）。
- 一方のシステムの処理速度がもう一方のシステムを制限する。例えば、メインフレームが遅ければ、PCベースのアプリケーションはメインフレームが追いつくまで待つ必要があり、結果としてPCのアプリケーションの速度が低下する。
- 通信プログラマは、メインフレームのネットワークとPCのネットワークのプロトコルが異なる場合、ゲートウェイシステムを実装する必要がある。このゲートウェイはパケットの中身を変換して双方のシステム間で通信ができるようにする。
このような問題によってアプリケーションの統合は困難となっていた。また、個々のシステムで状況が異なるため、このような統合は個々のシステム毎に設計が必要である。異機種上のアプリケーション間の連結には、オリジナルのシステム開発以上のコスト（場合によっては10倍）がかかった。
複数のアプリケーションの中間に位置して、それらの間の「配管」をする新たな独立したソフトウェアが必要なのは明らかだった。そのようなソフトウェアは、異なるプラットフォーム、異なるプログラミング言語、各種通信プロトコル、様々なハードウェアを扱える必要があった。すなわち、基盤となるインフラストラクチャーの複雑さを切り離すことで、開発者が個々のアプリケーションの機能開発に注力できるようになる。
1980年代末までにミドルウェアがこれら問題への対策として登場した。初期のミドルウェアはサポートするプラットフォームや言語が限られており、有用性は限定的だった。しかし時間とともにミドルウェア製品は複数のプラットフォーム、言語、プロトコルをサポートするようになり、高度化していった。
異機種混合のネットワーク環境で各システムを連結するというミドルウェアの能力は、この技術の利点のほんの一例に過ぎない。2006年現在、ミドルウェアは相互接続可能な既存アプリケーションを増やし、強化する新たな機能を提供している。
利点
編集メッセージベースの通信プロトコルの利点は、メッセージを送達する過程で保管したり、ルーティングし、変換することが可能な点にある。
格納
編集多くのメッセージ指向ミドルウェアは、転送されるメッセージのバックアップを保持することで永続性を提供する。すなわち、送信側と受信側は同時にネットワークに接続されている必要はない。これは、ネットワークの品質が低いとか、ユーザーが不定期に接続してくる場合とか、接続に時間制限がある場合など、接続が断続的な場合に特に便利である。また、受信側で問題が生じてアプリケーションが停止してしまっても、送信側はそれに影響されることなく送信を続け、メッセージを格納しておいて、後で受信側アプリケーションが再開したときに処理が行われる。
ルーティング
編集メッセージ指向ミドルウェアの重要な利点として、ミドルウェア層自身でメッセージのルーティングが可能な点が挙げられる。これを推し進めると、ミドルウェアで1つのメッセージを複数の受信者に配布することもできる（マルチキャスト）。
変換
編集メッセージ指向ミドルウェアでは、受信側が受け取るメッセージは送信側が送ったメッセージそのものである必要はない。知的なシステムでは、送信側や受信側の要求に応じてメッセージの変換が可能である。ルーティングやブロードキャスト/マルチキャストと組み合わせると、あるアプリケーションがメッセージを自身の形式で送り出し、複数の受信アプリケーションがそれぞれ固有の形式に変換されたメッセージを受け取ることも可能である。最近のメッセージ指向ミドルウェアは洗練されたメッセージ変換ツールを持っており、プログラマがGUIによるドラッグ・アンド・ドロップ操作で変換規則を指定できるようになっている。
欠点
編集メッセージ指向ミドルウェアの主な欠点は、アーキテクチャ上、外部コンポーネントであるメッセージ転送エージェントを必要とするという点に根ざしている。一般に、新たなコンポーネントを加えると、システムの性能が低下し、信頼性も低下する。さらに、システム全体として見たときに保守が難しくなり、コストもかかるようになる。
それに加えて、アプリケーション間通信は本質的に同期的であり、送信側は処理を進める前に応答を待つようになっているのが普通である。メッセージベースの通信は本質的に非同期であり、不一致が生じている。このため、多くのメッセージ指向ミドルウェアは、要求をグループ化して1つの擬似同期的トランザクションとして応答する機能を持っている。
標準規格の欠如
編集メッセージ指向ミドルウェアには標準と呼べる規格が存在しないため、問題が生じている。主要ベンダーはそれぞれ独自に実装しており、独自のAPIや管理ツールを持っている。
Jakarta EEプログラミング環境では JMS (Java Message Service) という標準APIを提供しており、多くのベンダーが採用している。マイクロソフトの MSMQ は JMS をサポートしていないが、サードパーティーがそのような製品を提供している。
傾向
編集Advanced Message Queuing Protocol (AMQP) は、メッセージ指向ミドルウェアの相互運用性を確保することを意図したものである。このプロトコルは非常に柔軟で、P2P型メッセージング、出版/購読型メッセージング、あるいはそれらを組み合わせたものなどを定義しており、非常に強力であることから、この分野の標準となる可能性がある。この領域での標準となるべく策定されたものとして、XMPPとStreaming Text Oriented Messaging Protocolがある。