1 つのキュー・マネージャーに基づくアーキテクチャー

1 つのキュー・マネージャーで複数のローカル・アプリケーションがサービスにアクセスするアーキテクチャー

1 つのキュー・マネージャーに基づく最初のアーキテクチャーは、サービスにアクセスするアプリケーションとサービスを提供するアプリケーションを同じシステムで実行するというものです。 IBM MQ キュー・マネージャーは、サービスを要求するアプリケーションとサービスを提供するアプリケーションとの間の非同期相互通信を提供します。 この場合は、いずれかのアプリケーションが長期にわたってオフラインになっても、アプリケーション間の通信を継続できます。

1 つのキュー・マネージャーで複数のリモート・アプリケーションがクライアントとしてサービスにアクセスするアーキテクチャー

1 つのキュー・マネージャーに基づく 2 番目のアーキテクチャーは、サービスを提供するアプリケーションからアプリケーションをリモート実行するというものです。 つまり、サービスが存在するシステムとは異なるシステムでリモート・アプリケーションを実行します。 それらのアプリケーションは、クライアントとして 1 つのキュー・マネージャーに接続します。 この場合は、1 つのキュー・マネージャーで複数のシステムにサービスに対するアクセスを提供することになります。

このアーキテクチャーの場合は、アプリケーションの操作のためにネットワーク接続を有効にしておく必要がある、という制約があります。 ネットワーク接続を経由したアプリケーションとキュー・マネージャーの対話は、同期モードになります。

1 つのキュー・マネージャーでパブリッシュ/サブスクライブを構成するアーキテクチャー

1 つのキュー・マネージャーを使用するさらに別のアーキテクチャーは、パブリッシュ/サブスクライブ構成を使用するというものです。 パブリッシュ/サブスクライブ・メッセージングでは、情報のプロバイダーとコンシューマーを分離できます。 これまでに取り上げたアーキテクチャーの Point-to-Point スタイルのメッセージングとは、この点が異なります。前述のアーキテクチャーでは、アプリケーションにおいて、ターゲット・アプリケーション (メッセージの書き込み先のキュー名など) についての情報が必要になります。 IBM MQ パブリッシュ/サブスクライブを使用すると、送信側アプリケーションは、情報のサブジェクトに基づいて、指定されたトピックを持つメッセージをパブリッシュします。 IBM MQ は、サブスクリプションを介してそのサブジェクトへのインタレストを登録したアプリケーションへのメッセージの配布を処理します。 受信側のアプリケーションも、メッセージを受信するために、そのソースについて何かの情報を知っておく必要はありません。 詳しくは、『パブリッシュ/サブスクライブ・メッセージング』および『単一キュー・マネージャーのパブリッシュ/サブスクライブ構成の例』を参照してください。