イベントチャネル連携サービスを利用することにより、他サーバ(Windowsサーバ、UNIXサーバ、Linuxサーバ、またはグローバルサーバ)上の非同期メッセージ基盤を使用するアプリケーションとの間でサーバ間の非同期通信を実現できます。アプリケーションは、アプリケーションが使用する非同期メッセージ基盤のAPIを利用したメッセージ操作を行うだけで、サーバ間のメッセージの転送を意識することなく、他サーバ上の異なるキューを論理的な一つのキューとして処理することができます。
イベントチャネル連携サービスを利用した、サーバ間の非同期通信のモデルを、図11.2 サーバ間の非同期通信のモデルに示します。
図11.2 サーバ間の非同期通信のモデル
[図の説明]
1) 送信アプリケーションは、当該アプリケーションが使用する非同期メッセージ基盤のAPIを使用してメッセージをキュー(ec1,jq1またはmq1)に送信します。
2) イベントチャネル連携サービスは、送信側のキュー(ec1,jq1またはmq1)に対応する受信側のキュー(ec2,jq2またはmq2)にメッセージを転送します。
3) 受信アプリケーションは、当該アプリケーションが使用する非同期メッセージ基盤のAPIを使用してメッセージをキュー(ec2,jq2またはmq2)から受信します。
イベントチャネル連携サービスでは、メッセージの送信側とメッセージの受信側の非同期メッセージ基盤が同一の場合や異なる場合でもメッセージ通信を行うことができます。
メッセージ通信可能な非同期メッセージ基盤の組み合わせを表11.2 メッセージ通信可能な非同期メッセージ基盤の組み合わせに示します。
送信側の非同期メッセージ基盤 (注1.) | 受信側の非同期メッセージ基盤 (注1.) | |||
|---|---|---|---|---|
ノーティフィケーションサービス | JMS | MQD (注2.) | グローバルサーバのMQD | |
ノーティフィケーションサービス | ○ | ○ | ○ | ○ |
JMS | ○ | ○ | ○ | ○ (注3.) |
MQD (注2.) | ○ | ○ | ○ | ○ |
グローバルサーバのMQD | ○ | ○ (注3.) | ○ | ○ (注4.) |
○: 通信可能
イベントサービスを使用することはできません。
Linux、Windows Server(R) for Itanium-based Systems および Windows Server(R) x64 Editions では使用できません。
通信可能なグローバルサーバのバージョンは以下となります。
［MSP］の場合
－ OS IV/MSP INTERSTAGE/MessageQueueDirector V20L10 D04061 以降
－ OS IV/MSP INTERSTAGE/AIMApplicationDirector V20L10 D04061 以降
－ OS IV/MSP Interstage AIMApplicationDirector V30L10 以降
［XSP］の場合
－ OS IV/XSP INTERSTAGE/MessageQueueDirector V20L10 D04071 以降
－ OS IV/XSP INTERSTAGE/AIMApplicationDirector V20L10 D04071 以降
－ OS IV/XSP Interstage AIMApplicationDirector V30L10 以降
本製品の機能範囲外です。
同一非同期メッセージ基盤間のメッセージ通信
同一非同期メッセージ基盤間のメッセージ通信とは、メッセージを送信するサーバと受信するサーバが使用する非同期メッセージ基盤が同一の場合のメッセージ通信モデルです。同一非同期メッセージ基盤間のメッセージ通信モデルを図11.3 同一非同期メッセージ基盤のメッセージ通信に示します。
図11.3 同一非同期メッセージ基盤のメッセージ通信
異なる非同期メッセージ基盤間のメッセージ通信
異なる非同期メッセージ基盤間のメッセージ通信とは、メッセージを送信するサーバと受信するサーバが使用する非同期メッセージ基盤が異なる場合のメッセージ通信モデルです。異なる非同期メッセージ基盤間のメッセージ通信モデルを図11.4 異なる非同期メッセージ基盤間のメッセージ通信に示します。
図11.4 異なる非同期メッセージ基盤間のメッセージ通信
グローバルサーバとのメッセージ通信
イベントチャネル連携サービスでは、使用する非同期メッセージ基盤により送信キューと受信キューの組み合わせを以下の4つから選択することができます。
1:1型のメッセージ通信
配信型のメッセージ通信
集信型のメッセージ通信
中継型のメッセージ通信
使用する非同期メッセージ基盤によるメッセージ通信可能な送信キューと受信キューの組み合わせを表11.3 メッセージ通信可能な送信キューと受信キューの組み合わせに示します。
送信側の非同期メッセージ基盤 | 受信側の非同期メッセージ基盤 | ||||
|---|---|---|---|---|---|
ノーティフィケーションサービス | JMS | MQD (注1.) | グローバルサーバのMQD | ||
ノーティフィケーションサービス | 1:1型 | ○ | ○ | ○ | ○ |
配信型 | ○ | ○ | ○ | ○ | |
集信型 | ○ | ○ | ○ | ○ | |
中継型 | ○ | ○ | ○ | ○ | |
JMS | 1:1型 | ○ | ○ | ○ | ○ (注2.) |
配信型 | ○ | ○ | ○ | ○ (注2.) | |
集信型 | ○ | ○ | ○ | ○ (注2.) | |
中継型 | ○ | ○ | ○ | ○ (注2.) | |
MQD (注1.) | 1:1型 | ○ | ○ | ○ | ○ |
配信型 | × | × | × | × | |
集信型 | ○ | ○ | ○ | ○ | |
中継型 | ○ | ○ | ○ | ○ | |
グローバルサーバのMQD | 1:1型 | ○ | ○ (注2.) | ○ | － |
配信型 | × | × | × | － | |
集信型 | ○ | ○ (注2.) | ○ | － | |
中継型 | ○ | ○ (注2.) | ○ | － | |
○:通信可能 ×:通信不可能 -:イベントチャネル連携サービスの機能対象外
Linux、Windows Server(R) for Itanium-based Systems および Windows Server(R) x64 Editions では使用できません。
通信可能なグローバルサーバのバージョンは以下となります。
［MSP］の場合
－ OS IV/MSP INTERSTAGE/MessageQueueDirector V20L10 D04061 以降
－ OS IV/MSP INTERSTAGE/AIMApplicationDirector V20L10 D04061 以降
－ OS IV/MSP Interstage AIMApplicationDirector V30L10 以降
［XSP］の場合
－ OS IV/XSP INTERSTAGE/MessageQueueDirector V20L10 D04071 以降
－ OS IV/XSP INTERSTAGE/AIMApplicationDirector V20L10 D04071 以降
－ OS IV/XSP Interstage AIMApplicationDirector V30L10 以降
1:1型のメッセージ通信
1:1型のメッセージ通信は、最も基本的なメッセージ通信の組み合わせであり、送信元と受信先の非同期メッセージ基盤の組み合わせに関わらず使用できます。
メッセージの送信元の非同期メッセージ基盤がノーティフィケーションサービスやJMSの場合は、Point-To-Pointモデルのイベントチャネルを使用することでメッセージの一意性の向上や送信アプリケーションによる異常メッセージ格納時の復旧方法を容易に行うことができます。
また、1:1型のメッセージ通信に限らず配信型および集信型の場合でもメッセージの受信先の非同期メッセージ基盤がノーティフィケーションサービスやJMSの場合は、アプリケーションの運用に合わせて受信キューのメッセージングモデルをPoint-To-PointモデルやMultiCastモデルから選択できます。
なお、MQDのメッセージキューのメッセージングモデルは、Point-To-Pointモデルに相当します。
1:1型の通信関係の指定は、後述のサービス定義により行います。
1:1型のメッセージ通信の一例として、送信側と受信側がノーティフィケーションサービスの場合の通信モデルを図11.6 1:1型のメッセージ通信の通信モデルの例に示します。
図11.6 1:1型のメッセージ通信の通信モデルの例
配信型のメッセージ通信
配信型のメッセージ通信は、特定の送信キューから同一のメッセージを複数の受信キューへ送信する場合に使用するメッセージ通信の組み合わせであり、送信元の非同期メッセージ基盤がノーティフィケーションサービスまたはJMSの場合に使用できます。
受信キューが特定のサーバに集中していても別々のサーバに分散していても、メッセージを配信することができます。
メッセージの送信元のイベントチャネルはMultiCastモデルで作成する必要があり、メッセージは配信先のすべてのサーバへの転送が完了した時点で送信キューから削除されます。
なお、メッセージの受信先の非同期メッセージ基盤は同一でも混在してもかまいません。
配信型の通信関係の指定は、後述のサービス定義により行います。
配信型のメッセージ通信の一例として、送信側がノーティフィケーションサービスで受信側がノーティフィケーションサービスとMQDの場合にメッセージの配信を行う通信モデルを図11.7 配信型のメッセージ通信の通信モデルの例に示します。
図11.7 配信型のメッセージ通信の通信モデルの例
集信型のメッセージ通信
集信型のメッセージ通信は、複数の送信キューから特定の受信キューへメッセージを送信する場合に使用するメッセージ通信の組み合わせであり、送信元と受信先の非同期メッセージ基盤の組み合わせに関わらず使用できます。
送信キューが特定のサーバに集中していても別々のサーバに分散していても、メッセージを集信することができます。
メッセージの送信元の非同期メッセージ基盤がノーティフィケーションサービスやJMSの場合は、Point-To-Pointモデルのイベントチャネルを使用することでメッセージの一意性の向上や送信アプリケーションによる異常メッセージ格納時の復旧方法を容易に行うことができます。
なお、メッセージの送信元の非同期メッセージ基盤は同一でも混在してもかまいません。
集信型の通信関係の指定は、後述のサービス定義により行います。
集信型のメッセージ通信の一例として、送信側がノーティフィケーションサービスとMQDで受信側がノーティフィケーションサービスの場合にメッセージの集信を行う通信モデルを図11.8 集信型のメッセージ通信の通信モデルの例に示します。
図11.8 集信型のメッセージ通信の通信モデルの例
中継型のメッセージ通信
中継型のメッセージ通信は、送信キューから受信キューへメッセージを送信する場合に、送信側のサーバからメッセージを受信側のサーバに直接送信せず、一旦、別のサーバ(中継用のサーバ)を介して行う組み合わせであり、送信元と受信先の非同期メッセージ基盤の組み合わせに関わらず、表11.30 通信可能なメッセージの形式に示す通信可能なメッセージの形式の範囲で使用できます。
送信サーバから受信サーバへのネットワークがセキュリティ等により直接接続されていない場合や、送信サーバから複数の受信サーバにメッセージを送信する場合の通信関係を簡便にするための通信ハブの様な位置づけとして中継型のメッセージ通信を使用します。
本通信形態は、1:1型の通信の応用であり、配信型や集信型の通信と組み合わせて使用することで多様な通信形態を構築することができます。
中継型の通信関係の指定は、受信キューと送信キューの定義を組み合わせることで後述のサービス定義により行います。
中継型のメッセージ通信の一例として、ノーティフィケーションサービスを使用してメッセージの中継を行う通信モデルを図11.9 中継型のメッセージ通信の通信モデルの例に示します。
図11.9 中継型のメッセージ通信の通信モデルの例
中継型のメッセージ通信と配信型のメッセージ通信を組み合わせた通信の一例として、ノーティフィケーションサービスを使用してメッセージの中継と配信を行う通信モデルを、図11.10 中継型と配信型を組み合わせたメッセージ通信の通信モデルの例に示します。
図11.10 中継型と配信型を組み合わせたメッセージ通信の通信モデルの例
イベントチャネル連携サービス特有の用語を以下に説明します。また、イベントチャネル連携サービスが通信相手を識別する方法について用語を用いて説明します。
サーバ間の非同期通信を行う各サーバ上のイベントチャネル連携サービスが動作するMQDを識別する識別子です。本識別子は、イベントチャネル連携サービスで接続するサーバ間で一意な値にします。
メッセージの送信側のイベントチャネル連携サービスでは、メッセージの受信側のイベントチャネル連携サービスの相手MQDサーバ識別子を指定することでメッセージの送信先を特定します。
送信キューは、メッセージを相手サーバに送信するために使用するキューです。
受信キューは、サーバ間でメッセージを受信するために使用するキューです。
送信キューと受信キューの論理的な結合関係です。チャネルコネクションは、以下の契機で自動的に接続されます。
自サーバのイベントチャネル連携サービスおよび相手サーバのイベントチャネル連携サービスを起動した契機
mqdnsgwcommコマンドによりサービスの通信を再開した契機。mqdnsgwcommコマンドの詳細については、“11.7.7 mqdnsgwcomm(サービスの通信を制御する)”を参照してください。
任意のチャネルコネクションを特定するための識別子です。イベントチャネル連携サービスの通信を制御する場合に使用します。
送信チャネル識別子は、MQDシステム内で一意な値にします。
イベントチャネル連携サービスの通信を制御する詳細については、“11.2.9 サービスの通信制御”を参照してください。
イベントチャネル連携サービスの通信概念について、図11.11 イベントチャネル連携サービスの通信概念に示します。
図11.11 イベントチャネル連携サービスの通信概念
送信キューと受信キューの対応関係は、イベントチャネル連携サービスのサービス定義で指定します。詳細については、“11.3.3.1 サービス定義の記述”を参照してください。
サーバ間でメッセージを送信する機能です。イベントチャネル連携サービスのサービス定義で送信キューと受信キューの対応関係を定義することで、送信キューから受信キューへメッセージを送信します。
メッセージの送信の流れを図11.12 メッセージ送信の流れに示します。
図11.12 メッセージ送信の流れ
[図の説明]
1) 送信アプリケーションが、利用する非同期メッセージ基盤のAPIを用いて送信キューにメッセージを格納します。
2) イベントチャネル連携サービスが、サービス定義にしたがって自動的に送信キューから、メッセージを取り出します。
3) イベントチャネル連携サービスが、CORBAサービスを使用して相手サーバのイベントチャネル連携サービス(CORBAサービスのサーバアプリケーションに相当)を呼び出し、メッセージを渡します。
表11.4 メッセージ送信仕様詳細にメッセージ送信仕様の詳細を示します。
項目 | 内容 |
|---|---|
送信可能な最大メッセージ長 | 約2Mバイト(2,088,960バイト) |
相手サーバに送信可能なメッセージの形式 | 相手サーバに送信可能なメッセージの形式は、“11.6 アプリケーションの作成方法”に示すメッセージの形式の範囲で使用してください。送信できない形式のメッセージを送信キューに格納すると、当該送信キューの以降のメッセージは相手サーバへ送信されません。 |
チャネルコネクションを初期化した場合の動作 | 送信側の非同期メッセージ基盤がノーティフィケーションサービスまたはJMSであり、かつ送信キューをMultiCastモデルとして利用する場合、チャネルコネクションを初期化すると、その時点で送信キューに滞留していたメッセージは受信キューに送信されません。チャネルコネクションの初期化はメッセージが滞留していない状態で実行してください。 |
イベントチャネル連携サービスが未起動状態で格納されたメッセージの扱い | イベントチャネル連携サービスが未起動状態で送信キューに格納されたメッセージは、イベントチャネル連携サービスを再起動した際に送信されます。 ただし、送信側の非同期メッセージ基盤がノーティフィケーションサービスまたはJMSであり、かつ送信キューをMultiCastモデルとして利用する場合、イベントチャネル連携サービスを初めて起動するまでに送信キューに格納されたメッセージは送信されません。 |
esmonitorchnlコマンドによる接続情報の回収
非同期メッセージ基盤がノーティフィケーションサービスまたはJMSの場合、通信中に、イベントチャネル連携サービスのサービス定義のCHANNELセクションまたはRCHANNELセクションに記述したキュー名への接続情報を、esmonitorchnlコマンドにより回収しないでください。
キューに滞留したメッセージが消失したり、重複したりする可能性があります。
相手サーバからのメッセージを受信する機能です。相手サーバのサービス定義で、送信キューと受信キューの対応関係を定義します。イベントチャネル連携サービスは、この定義で対応づけられた送信キューからメッセージを受信し、該当の受信キューにメッセージを格納します。
サーバ間のメッセージ受信の流れを図11.13 メッセージ受信の流れに示します。
図11.13 メッセージ受信の流れ
[図の説明]
1) イベントチャネル連携サービスが、CORBAサービスを介して相手サーバからメッセージを受信します。
2) イベントチャネル連携サービスが、送信側のサービス定義で指定した受信キューにメッセージを格納します。
3) 受信アプリケーションが、利用する非同期メッセージ基盤のAPIを用いて受信キューからメッセージを取り出します。
イベントチャネル連携サービスのメッセージ受信機能を使用する場合、以下の点に注意してください。
esmonitorchnlコマンドによる接続情報の回収
非同期メッセージ基盤がノーティフィケーションサービスまたはJMSの場合、通信中に、イベントチャネル連携サービスのサービス定義のCHANNELセクションまたはRCHANNELセクションに記述したキュー名への接続情報を、esmonitorchnlコマンドにより回収しないでください。
キューに滞留したメッセージが消失したり、重複したりする可能性があります。
イベントチャネル連携サービスは、送信サーバが、受信サーバと通信するために受信サーバのオブジェクトリファレンスを以下の二つの方式のどちらかで取得します。
ネーミングサービス方式：
受信サーバを登録したネーミングサービスを指定する方式
IORファイル方式：
受信サーバで出力したIORファイルを指定する方式
Windowsサーバ、UNIXサーバ、Linuxサーバと通信する場合は、ネーミングサービス方式を推奨します。
グローバルサーバと通信する場合は、IORファイル方式を使用してください。ネーミングサーバ方式は使用できません。
ネーミングサービス方式
Windowsサーバ、UNIXサーバ、Linuxサーバと通信を行う場合に使用する方式です。（グローバルサーバとの通信には使用できません。）
サービス定義に指定したURLリストファイルに記述されたネーミングサービスのURLを順次参照し、相手サーバのイベントチャネル連携サービスのオブジェクトリファレンスを取得し、通信できるようにします。
IORファイル方式に比べサーバ移動などのシステム環境変更での運用操作が軽減できます。
ネーミングサービス方式を図11.14 ネーミングサービス方式に示します。
図11.14 ネーミングサービス方式
[図の説明]
1) ユーザが、受信側のサーバで一括登録コマンド(mqdnsgwinit_ns)を実行します。登録コマンドは受信側イベントチャネル連携サービスのオブジェクトリファレンスをネーミングサービスへ登録します。
2) イベントチャネル連携サービスの送信側プロセスが、ユーザが作成した 1)で登録したネーミングサービスのアドレスが記述されているURLリストファイルを取得します。
3) イベントチャネル連携サービスの送信側プロセスが、取得したURLリストからネーミングサービスのURLへ順次検索を行い、受信サーバのオブジェクトリファレンスを取得します。
4) イベントチャネル連携サービスの送信側プロセスが、取得したオブジェクトリファレンスから受信サーバの位置を特定し、メッセージを送信します。
IORファイル方式
グローバルサーバと通信を行う場合に使用する方式です。（Windowsサーバ、UNIXサーバ、Linuxサーバでも使用できますが、Windowsサーバ、UNIXサーバ、Linuxサーバの場合、ネーミングサービス方式を推奨します。）
メッセージの受信先となるグローバルサーバのサーバ間非同期通信機能のオブジェクトリファレンスをIOR化したファイルをメッセージの送信元となるイベントチャネル連携サービスにFTP等により配布し、そのファイルをサービス定義に指定することで相手サーバと通信できるようにします。
IORファイル方式を図11.15 IORファイル方式に示します。
図11.15 IORファイル方式
[図の説明]
1) ユーザが、受信側のサーバで一括登録コマンド(mqdnsgwinit_ior)を実行し、IORファイルを作成します。
2) ユーザが、出力されたIORファイルを送信サーバへ配布します。
3) ユーザが、配布されたIORファイルを送信側のサーバのイベントチャネル連携サービスへ登録します。
4) イベントチャネル連携サービスの送信プロセスが、登録されたIORファイルから受信側のサーバの位置を特定します。
5) イベントチャネル連携サービスの送信プロセスが、送信サーバから受信サーバへメッセージを送信します。
