アプリケーションは、サポートされているトランスポート・プロトコルの 1 つを介してブローカーにメッセージを送信したり、ブローカーからメッセージを受信したりして、ブローカーのサービスを使用できます。その方法は、プロトコルそのもの、使用するプログラミング・インターフェース、および採用している通信モデルに応じて異なります。
WebSphere® Event Broker は、次の 2 つのエンド・ユーザー・アプリケーション通信モデルをサポートしています。
単一アプリケーションは、それが適切であれば、2 つのスタイルを混合することができます。 混合のシナリオでは、このアプリケーションに対するメッセージを処理するメッセージ・フローには、1 つ以上の入力ノードの他に、最低 1 つの出力ノード、および最低 1 つのパブリケーション・ノードが含まれています。
アプリケーションにコーディングできるプログラミング・インターフェースについては、アプリケーション・プログラミング・インターフェースで説明します。
Point-to-Point アプリケーションは、要求/応答またはクライアント/サーバー・モデルを使用するか、または 1 つのメッセージを配布リスト を使用して 複数のターゲット・アプリケーションにブロードキャストします。その他のアプリケーションは、片方向の send-and-forget または データグラム・トラフィックを送信します。それらは既知のパートナーと、情報を交換します。 それぞれのアプリケーションは、通信相手となる 1 つ以上のアプリケーションの ID を認識しています。 応答不要送信メッセージと要求/応答メッセージの両方を処理するよう、メッセージ・フローを作成ならびに構成し、これをブローカーにデプロイすることができます。
本文と以下の図に、応答不要送信と要求/応答モデルを示します。 図は、アプリケーションが WebSphere MQ Enterprise Transport プロトコルを使用することを前提としています。 プロトコルが変わってもモデルは同一ですが、メッセージの送信または受信の経路となるリソースは WebSphere MQ キューにはなりません。
応答不要送信モデルの場合、アプリケーションはメッセージを送信しますが、応答を期待しません。 最初のアプリケーションがメッセージを送信したことを受けて、もう一方のアプリケーションは随意でメッセージを受信できます。 図では、送信側がブローカーでメッセージ・フローの入力キューにメッセージを書き込みます (1)。 メッセージ・フローからの出力は受信側のキューに書き込まれ (2)、受信側はここから出力を取得します (3)。
要求/応答メッセージングの場合、受信側は、要求メッセージを受け取ると、応答を送信側に送り返します。 要求メッセージは、応答不要送信メッセージの説明と同様に処理されます。 応答については、以下の 2 つの可能性があります。
以下の図では、送信側がブローカーでメッセージ・フローの入力キューにメッセージを書き込みます (1)。 メッセージ・フローからの出力は受信側のキューに書き込まれ (2)、受信側はここから出力を取得できます (3)。 受信側は直接に送信側の ReplyToQ に応答を送信します (4)。 送信側はここから応答を取得できます (5)。
この応答メッセージ・フローの出力を、送信側の ReplyToQ に送らなければなりません。 名前が固定されているなら問題ありませんが、固定されていない場合は、何らかの方法でこのキューを応答メッセージと関連付けることが必要です。
例えば、メッセージ記述子の中の関連する詳細を MQRFH2 ヘッダー内のフォルダーにコピーし、メッセージと一緒に送信することができます。
以下の図では、送信側がブローカーで最初のメッセージ・フローの入力キューにメッセージを書き込みます (1)。 メッセージ・フローからの出力は受信側のキューに書き込まれ (2)、受信側はここから出力を取得できます (3)。 受信側は、ブローカーで、応答を 2 番目のメッセージ・フローの入力キューに送信します (4)。 応答に処理を加えた後、ブローカーは送信側の ReplyToQ に応答を送信します (5)。 送信側はここから応答を取得できます (6)。 (この場合、2 番目のメッセージ・フローの出力ノードは、送信側の ReplyToQ を知っていなければなりません。)
point-to-point モデルを使用して作成した既存アプリケーションは、サポートされるプロトコルのうちの 1 つを使用してブローカーと通信する場合には、WebSphere Event Broker 環境で未変更のままで実行することができます。
パブリッシュ/サブスクライブ・アプリケーション通信モデルには、パブリッシャーというアプリケーションと、サブスクライバーというアプリケーションが含まれます。 パブリッシャーは、特定のトピックをパブリッシュすることにより、メッセージを使用可能にします。 サブスクライバーは、トピックをサブスクライブすることにより、メッセージを受信します。 個々のアプリケーションは、パブリッシャーにもサブスクライバーにもなることができます。
1 つのパブリッシャーがパブリッシュするメッセージを受け取るサブスクライバーの数は、制限されていません。 また、サブスクライバーは、同じまたは異なるトピック上で、任意の数のパブリッシャーからメッセージを受け取ることもできます。
以下の図の場合、パブリッシャーは Publish または Delete Publication メッセージをブローカーに送信できます。ブローカーは、一致するサブスクリプションのあるサブスクライバーに Publish メッセージを転送します。 サブスクライバーは、Register Subscriber、Deregister Subscriber、または Request Update メッセージをブローカーに送信します。 ブローカーから、オプションの応答メッセージがパブリッシャーとサブスクライバーに送信されます。
MQI または AMI を使用するなどして パブリッシュ/サブスクライブ・モデルに作成された既存のエンド・ユーザー・アプリケーションがある場合、おそらくそれらのアプリケーションを変更しないで WebSphere Event Broker ブローカー・ドメインに統合できます。
さらに、これらのアプリケーションを変更したり新規のアプリケーションを作成して、特にサブスクライバーのために洗練されたパブリッシュ/サブスクライブ処理を活用できます。
パブリッシュ/サブスクライブ・モデル、および WebSphere Event Broker が提供する処理については、関連リンクを通して使用可能な以降のトピックで詳細に説明します。