(MOM)ビジネス、制度、およびテクノロジは絶えず変化しているため、そこで使用されるソフトウェアシステムには、このような変化に順応できる能力が要求されます。ビジネスで、合併、サービスの追加、または使用可能なサービスの拡張を行ったあとで、情報システムを作り直すだけの余裕はほとんど残っていません。この最も重要な時点でこそ、新しいコンポーネントの統合または既存のコンポーネントの拡張を、できるだけ効率的に行う必要があります。異種コンポーネントを最も簡単に統合する方法は、同種の要素として作り直すことではなく、異種であっても相互に通信できるようにする層を用意することです。相互に対話できるようになります。この対話が可能になった時点から、ネットワークはコンピュータとして機能できます。ミドルウェア異なるネットワークノードに分散したアプリケーションはアプリケーションインタフェースを使用して通信し、ほかのアプリケーションをホストしているオペレーティング環境の詳細を意識する必要も、これらのアプリケーションに接続するサービスを使用する必要もありません。相互接続したアプリケーションによるこの新しい仮想的なシステムは、管理インタフェースを備えることにより、信頼性と安全性を確保します。そのパフォーマンスは測定および調整可能であり、機能を損ねずにシステムを拡張できます。ミドルウェアは、次のカテゴリに分類できます。ベースのミドルウェア。あるアプリケーション内のプロシージャーが、ローカルでの呼び出しであるかのように、リモートのアプリケーション内のプロシージャーを呼び出せるようにします。このミドルウェアにはリンクメカニズムが実装されており、リモートプロシージャーを検索して、呼び出し側から透過的にこれらのプロシージャーを利用できるようにしています。従来、この種のミドルウェアは、プロシージャーベースのプログラムを扱っていましたが、現在、オブジェクトベースのコンポーネントにも対応しています。ベースのミドルウェア。アプリケーションのオブジェクトを、異種ネットワーク間で分散し共有できるようにします。ベースのミドルウェア。分散型アプリケーションが、メッセージの送受信によって、データの通信および交換を行えるようにします。これらのすべてのモデルで、あるソフトウェアコンポーネントが別のコンポーネントの動作にネットワークを介して影響を及ぼすことができます。ベースのシステムが、疎結合コンポーネントに対応しているという点で、これらには違いがあります。ベースのシステムでは、あるプロシージャーが別のプロシージャーを呼び出すと、呼び出されたプロシージャーが返されるまで、別の処理を行えなくなります。前述のように、これらのモデルでは、ミドルウェアは部分的にスーパーリンカーとして機能し、呼び出されたプロシージャーをネットワーク上で検索し、ネットワークサービスを使用して、関数やメソッドのパラメータをプロシージャーに渡し、結果を返します。示すように、メッセージの非同期的交換を通じて、通信を行えるようにします。ベースのシステムメッセージ指向ミドルウェアは、メッセージングプロバイダを利用して、メッセージング操作を仲介します。管理ツールが含まれます。プロバイダは、メッセージのルーティングおよび配信に使用されるアーキテクチャーとして、集中メッセージサーバーを使用したものと、ルーティングおよび配信機能を各クライアントマシンに分散したものを使用します。呼び出しを作成して、プロバイダが管理する送信先にメッセージを送信します。この呼び出しによって、プロバイダのサービスが呼び出され、メッセージのルーティングと配信を行います。クライアントはメッセージを送ったあと、受信側クライアントがメッセージを取得するまでメッセージがプロバイダに保持されるため、他の作業を続行することができます。メッセージベースのモデルとプロバイダの仲介とを組み合わせることにより、疎結合コンポーネントのシステムを作成できます。このようなシステムは、個々のコンポーネントまたはコネクションに障害が生じた場合でも確実に機能を続行でき、停止時間がありません。メッセージングプロバイダにクライアント間のメッセージングを仲介させた場合、管理インタフェースを追加することによって、パフォーマンスの監視と調整を行えるという別のメリットが得られます。システムを実装するコードと管理者に委ねられます。これまで、メッセージ指向ミドルウェアを使用した分散コンポーネントの接続によるメリットについて述べてきました。デメリットもあります。そのひとつは、疎結合自体から生じるものです。システムでは、呼び出し側の関数は、呼び出された関数が実行中のタスクを終了するまで戻りません。非同期システムでは、呼び出し側のクライアントは、この作業の処理に必要なリソースが欠乏し、呼び出されたコンポーネントに障害が発生するまで、受信側に負荷をかけ続けることがあります。システムでは不要な作業になります。それぞれのシステムのメリットとデメリットを理解することが重要です。それぞれのシステムは、異なるタスクに適しています。種類のシステムを組み合わせる必要が生じることもあります。ベースのシステム間の通信を可能にしている様子を示しています。図の左側は、パフォーマンスの改善のために、クライアント、サーバー、およびデータストアのコンポーネントを別々のネットワークノードに分散しているアプリケーションを示しています。これは、割引航空券予約システムです。エンドユーザーがこのサービスの利用料を支払うことにより、このサービスが指定された行先と時間に対して利用可能な最低運賃を見つけます。データストアは、登録ユーザーに関する情報と、このプログラムに参加している航空会社に関する情報を格納しています。社の料金をユーザーに提示します。ベースのシステムが示されています。図の右側は、割引システムに接続している航空会社の数だけ複製されます。サーバーコンポーネントは、エンドユーザーが入力したデータに応じて情報を更新します。サービスを利用して、割引予約システムから情報の要求を受け取り、座席および価格情報を返します。社の割引航空券を購入することにした場合、このシステムのサーバーコンポーネントは、データストア内の情報を更新してから、請求者に対してチケットを発券するか、チケットを発券するように割引サービスへメッセージを送信します。システムとの相違点がいくつか示されています。分散コンポーネントの結合方法における相違点については、すでに述べました。システムでは、クライアントが、メッセージングによってのみ相互運用可能な異種ソフトウェアコンポーネントであるという点も異なります。有標製品として実装されるということから生じます。使用している企業を合併すると、どうなるでしょうか。この問題を解決するために、標準的なメッセージングインタフェースが必要になります。両方にこのインタフェースが実装されていれば、一方のシステムで稼働するように開発されたアプリケーションは、もう一方のシステムでも稼働できます。このようなインタフェースは、習得が容易であると同時に、高度なメッセージングアプリケーションをサポートできるだけの十分な機能を備えているべきです。仕様は、まさしくこのことを目的としています。製品の共通要素を取り入れ、異種の受け入れと今後の成長に対応するために、この標準がどのように開発されたかについて説明します。affiliates。