メッセージ指向ミドルウェア (MOM)

ビジネス、制度、およびテクノロジは絶えず変化しているため、そこで使用されるソフトウェアシステムには、このような変化に順応できる能力が要求されます。ビジネスで、合併、サービスの追加、または使用可能なサービスの拡張を行ったあとで、情報システムを作り直すだけの余裕はほとんど残っていません。この最も重要な時点でこそ、新しいコンポーネントの統合または既存のコンポーネントの拡張を、できるだけ効率的に行う必要があります。異種コンポーネントを最も簡単に統合する方法は、同種の要素として作り直すことではなく、異種であっても相互に通信できるようにする層を用意することです。ミドルウェアと呼ばれるこの層によって、個別に開発され、異なるネットワークプラットフォームで稼働するソフトウェアコンポーネント (アプリケーション、エンタープライズ Java Bean、サーブレットなどのコンポーネント) が、相互に対話できるようになります。この対話が可能になった時点から、ネットワークはコンピュータとして機能できます。

図 1–1 に示すように、ミドルウェアは、概念上、アプリケーション層とプラットフォーム層 (オペレーティングシステムと基礎となるネットワークサービス) の間に位置します。

図 1–1 ミドルウェア

異なるネットワークノードに分散したアプリケーションはアプリケーションインタフェースを使用して通信し、ほかのアプリケーションをホストしているオペレーティング環境の詳細を意識する必要も、これらのアプリケーションに接続するサービスを使用する必要もありません。さらに、相互接続したアプリケーションによるこの新しい仮想的なシステムは、管理インタフェースを備えることにより、信頼性と安全性を確保します。そのパフォーマンスは測定および調整可能であり、機能を損ねずにシステムを拡張できます。

ミドルウェアは、次のカテゴリに分類できます。

• リモートプロシージャー呼び出し (RPC) ベースのミドルウェア。あるアプリケーション内のプロシージャーが、ローカルでの呼び出しであるかのように、リモートのアプリケーション内のプロシージャーを呼び出せるようにします。このミドルウェアにはリンクメカニズムが実装されており、リモートプロシージャーを検索して、呼び出し側から透過的にこれらのプロシージャーを利用できるようにしています。従来、この種のミドルウェアは、プロシージャーベースのプログラムを扱っていましたが、現在、オブジェクトベースのコンポーネントにも対応しています。

• オブジェクトリクエストブローカ (ORB) ベースのミドルウェア。アプリケーションのオブジェクトを、異種ネットワーク間で分散し共有できるようにします。

• メッセージ指向ミドルウェア (MOM) ベースのミドルウェア。分散型アプリケーションが、メッセージの送受信によって、データの通信および交換を行えるようにします。

これらのすべてのモデルで、あるソフトウェアコンポーネントが別のコンポーネントの動作にネットワークを介して影響を及ぼすことができます。RPC ベースと ORB ベースのミドルウェアが、密結合コンポーネントのシステムを作成する一方、MOM ベースのシステムが、疎結合コンポーネントに対応しているという点で、これらには違いがあります。RPC ベースまたは ORB ベースのシステムでは、あるプロシージャーが別のプロシージャーを呼び出すと、呼び出されたプロシージャーが返されるまで、別の処理を行えなくなります。前述のように、これらのモデルでは、ミドルウェアは部分的にスーパーリンカーとして機能し、呼び出されたプロシージャーをネットワーク上で検索し、ネットワークサービスを使用して、関数やメソッドのパラメータをプロシージャーに渡し、結果を返します。

MOM ベースのシステムは、図 1–2 に示すように、メッセージの非同期的交換を通じて、通信を行えるようにします。

図 1–2 MOM ベースのシステム

メッセージ指向ミドルウェアは、メッセージングプロバイダを利用して、メッセージング操作を仲介します。MOM システムの基本要素は、クライアント、メッセージ、および MOM プロバイダです。MOM プロバイダには API と管理ツールが含まれます。MOM プロバイダは、メッセージのルーティングおよび配信に使用されるアーキテクチャーとして、集中メッセージサーバーを使用したものと、ルーティングおよび配信機能を各クライアントマシンに分散したものを使用します。この 2 つの方式を併用した MOM 製品もあります。

MOM システムを使用した場合、クライアントは API 呼び出しを作成して、プロバイダが管理する送信先にメッセージを送信します。この呼び出しによって、プロバイダのサービスが呼び出され、メッセージのルーティングと配信を行います。クライアントはメッセージを送ったあと、受信側クライアントがメッセージを取得するまでメッセージがプロバイダに保持されるため、他の作業を続行することができます。メッセージベースのモデルとプロバイダの仲介とを組み合わせることにより、疎結合コンポーネントのシステムを作成できます。このようなシステムは、個々のコンポーネントまたはコネクションに障害が生じた場合でも確実に機能を続行でき、停止時間がありません。

メッセージングプロバイダにクライアント間のメッセージングを仲介させた場合、管理インタフェースを追加することによって、パフォーマンスの監視と調整を行えるという別のメリットが得られます。したがって、クライアントアプリケーションは、メッセージの送信、受信、および処理の問題を除く実質的にすべての問題から解放されます。相互運用性、信頼性、セキュリティー、スケーラビリティー、パフォーマンスなどの問題の解決は、MOM システムを実装するコードと管理者に委ねられます。

これまで、メッセージ指向ミドルウェアを使用した分散コンポーネントの接続によるメリットについて述べてきました。しかし、デメリットもあります。そのひとつは、疎結合自体から生じるものです。RPC システムでは、呼び出し側の関数は、呼び出された関数が実行中のタスクを終了するまで戻りません。非同期システムでは、呼び出し側のクライアントは、この作業の処理に必要なリソースが欠乏し、呼び出されたコンポーネントに障害が発生するまで、受信側に負荷をかけ続けることがあります。もちろん、パフォーマンスの監視とメッセージフローの調整によって、このような状況を最小限にとどめたり、回避したりすることができますが、RPC システムでは不要な作業になります。それぞれのシステムのメリットとデメリットを理解することが重要です。それぞれのシステムは、異なるタスクに適しています。場合によっては、必要とする動作を得るために、2 種類のシステムを組み合わせる必要が生じることもあります。

図 1–3 では、MOM システムが、2 つの RPC ベースのシステム間の通信を可能にしている様子を示しています。図の左側は、パフォーマンスの改善のために、クライアント、サーバー、およびデータストアのコンポーネントを別々のネットワークノードに分散しているアプリケーションを示しています。これは、割引航空券予約システムです。エンドユーザーがこのサービスの利用料を支払うことにより、このサービスが指定された行先と時間に対して利用可能な最低運賃を見つけます。データストアは、登録ユーザーに関する情報と、このプログラムに参加している航空会社に関する情報を格納しています。サーバーのロジックは、ユーザーの要求に基づいて、参加している航空会社の価格を照会し、情報を調べて、最も安い 3 社の料金をユーザーに提示します。図の右側には、参加している航空会社のいずれか 1 社の航空券 / 予約システムを表す、RPC ベースのシステムが示されています。図の右側は、割引システムに接続している航空会社の数だけ複製されます。データストアは、このような航空会社ごとに、利用可能なフライトに関する情報 (座席、フライト時間、価格など) を保存します。サーバーコンポーネントは、エンドユーザーが入力したデータに応じて情報を更新します。航空会社のサーバーも MOM サービスを利用して、割引予約システムから情報の要求を受け取り、座席および価格情報を返します。顧客が PanWorld 社の割引航空券を購入することにした場合、このシステムのサーバーコンポーネントは、データストア内の情報を更新してから、請求者に対してチケットを発券するか、チケットを発券するように割引サービスへメッセージを送信します。

図 1–3 RPC システムと MOM システムとの組み合わせ

この例には、RPC システムと MOM システムとの相違点がいくつか示されています。分散コンポーネントの結合方法における相違点については、すでに述べました。そのほかにも、RPC システムは多くの場合、クライアントがエンドユーザーであるクライアントおよびサーバーコンポーネントの分散と結合に使用されますが、MOM システムでは、クライアントが、メッセージングによってのみ相互運用可能な異種ソフトウェアコンポーネントであるという点も異なります。

MOM システムでのより重要な問題は、MOM が有標製品として実装されるということから生じます。SuperMOM-X に依拠している企業が、SuperMOM-Y を使用している企業を合併すると、どうなるでしょうか。この問題を解決するために、標準的なメッセージングインタフェースが必要になります。SuperMOM-X と SuperMOM-Y の両方にこのインタフェースが実装されていれば、一方のシステムで稼働するように開発されたアプリケーションは、もう一方のシステムでも稼働できます。このようなインタフェースは、習得が容易であると同時に、高度なメッセージングアプリケーションをサポートできるだけの十分な機能を備えているべきです。1998 年に発表された Java Message Service (JMS) 仕様は、まさしくこのことを目的としています。次の節では、JMS の基本機能について説明し、既存の有標 MOM 製品の共通要素を取り入れ、異種の受け入れと今後の成長に対応するために、この標準がどのように開発されたかについて説明します。