レベル: 初級 豊村 明彦, WebSphereテクニカル・セールス, IBM
2007年 04月 21日
更新 2009年 03月 25日 ご好評の記事、「MQ虎の巻」の久々の改訂版(V7対応）です。今回は第2回「WebSphere MQの特長と主な機能（後編）」を改訂いたしました。
1 MQシステムの構成要素
これから、WebSphere MQを構成する主な要素についての詳しい説明を行ないます。説明対象として取り上げた構成要素は、アプリケーション間で受け渡すデータであるメッセージ、およびMQを使用する際に管理対象となるMQオブジェクトです。下記が2.2以降で順次説明を行う構成要素になります。
- メッセージ
- MQオブジェクト
- キューマネージャー
- キュー
- チャネル
- プロセス定義
- 名前リスト
- リスナー・オブジェクト
- サービス・オブジェクト (WebSphere MQ for z/OS を除く)
- 管理トピック・オブジェクト
- 認証情報オブジェクト
図1 MQオブジェクト
【MQオブジェクト】
「MQオブジェクト」には以下の種類があります。v6からは、チャネル、リスナー、サービスがMQオブジェクトとして扱われるようになりました。MQオブジェクトになることで、これらのリソースは、メディア・リカバリーやAMによるセキュリティー保護の対象となりました。
- キューマネージャー
- キュー
- チャネル
- プロセス定義
- 名前リスト
- リスナー
- 認証情報オブジェクト
- 管理トピック・オブジェクト
- サービス (WebSphere MQ for z/OS を除く)
- キュー共用グループ (WebSphere MQ for z/OS® のみ)
- ストレージ・クラス (WebSphere MQ for z/OS のみ)
これらのうち、キュー共用グループとストレージグループに関しては特定のプラットフォームに固有な話題なので、今回の説明の対象外としています。MQオブジェクトはキューマネージャーによって管理されます。MQオブジェクトの作成、属性の変更、削除は各種管理コマンドを用いて行うことができます。
MQINQ/MQSETといったMQIを使用してオブジェクトを制御する事も可能です。ただし、チャネルに対する照会・操作はMQIではできません。
MQIによって各オブジェクトにアクセスする時には、MQOPENの際にオブジェクト記述子（MQOD:MQ
Object Descriptor）を用いて特定のオブジェクトを指定します。オブジェクト記述子とは特定のMQオブジェクトを識別するためのデータ構造体で、オブジェクトの名前とオブジェクトタイプが含まれています。
2 メッセージ
図2 メッセージの構成
はじめにメッセージについての説明を行います。
MQにおいてメッセージとは、キューを介してプログラム（プロセス）間で渡されるデータのことを指します。メッセージはMQオブジェクトではありませんが、キューマネージャーをはじめとしたMQオブジェクトによって管理されシステム間で転送されます。
MQのメッセージは下記のような構成になっており、必ずメッセージ・ヘッダーが先頭に付加されます。
【メッセージ・ヘッダー】
MQでは、メッセージ・ヘッダーとしてメッセージ記述子（MQMD）を持っています。
主な内容として、以下のようなものがあります。
- メッセージタイプ
- メッセージID、相関ID
- Reply-Toキュー名
- メッセージの永続性
- メッセージの優先順位
- コンテキスト（発行元の情報）
【ユーザーデータ】
任意のデータです。MQは基本的にユーザーデータの内容には関知しませんので、アプリケーション用のユーザーヘッダーの付加や解釈などは通信を行うアプリケーション間のロジックで対応する必要があります。
ユーザーデータが全て文字列の場合は、パラメーターの指定のみで文字コード変換を行うことができます。ユーザーデータにバイナリーデータが混合しているような場合にはEXITを作成して文字コード変換を行う事ができます。
図3 メッセージのタイプ
【メッセージのタイプ】
メッセージのタイプには、以下のようなものがあります。
-
データグラム： リプライを必要としない一方向のメッセージです。
-
リクエスト： リプライを必要とするメッセージです。通常ReplyToQ、ReplyToQMgrフィールドにリプライメッセージの宛先を指定します。
-
リプライ： リクエストに対する応答メッセージです。通常、相関IDにてリクエストとリプライのメッセージを関連付けます。
-
レポート： MQの機能で、例外情報などの通知メッセージを送信可能です。
3 キューマネージャー
キューマネージャーは、キューイング・サービスをアプリケーションに提供し、キューマネージャーに属しているキューおよびその他のMQオブジェクトを管理します。1つのシステム上で複数のキューマネージャーを使用することもできます。
キューマネージャーの役割には以下のようなものがあります。
- アプリケーションが発行したMQIを受け取り、メッセージを正しいキューに書き込むなどの処理を行います。
書き込みに失敗した場合には、アプリケーションに通知され、該当の理由コードが戻されます。
- 書き込みに失敗した場合には、アプリケーションに通知され、該当の理由コードが戻されます。
- 受け取ったコマンドに応じてオブジェクトの属性を変更します。
- 該当の条件が満たされたときに、トリガー・イベントなどの特殊イベントを生成します。
- オブジェクトに対する権限のチェックを行います。
- アプリケーションがオブジェクトにアクセスする前に、必要なレベルの許可を持っているかどうかチェックします。
- 検査はオープンされるオブジェクトの名前に対して行われます。
注意点を以下に挙げます。
- MQIによるキューマネージャーの属性変更は行えません。MQSCコマンド、PCFコマンドなどを使用します。
- キューマネージャー作成時に設定する属性には変更不可なものもあります（ログタイプ設定等）。
- メッセージをキューマネージャーに書き込むことはできません。メッセージは必ずキューに書き込まれます。
主な属性には以下のようなものがあります。
- CCSID（文字コード）
- 最大メッセージ長
- デフォルト・デッドレターキュー名
- デフォルト・トランスミッションキュー名
デッドレターキュー、トランスミッションキューについては後述します。
図4 “ローカル”と“リモート”について
【“ローカル”と“リモート”について】
今後、ローカルおよびリモートの表現が出てきたときには、以下の意味で用いることとします。
- アプリケーションが接続されているキューマネージャーは、そのアプリケーションに対してローカル・キューマネージャーであるといいます。また、ローカル・キューマネージャーが属するシステムをローカル・システムと呼びます。
- リモート・キューマネージャーとは、ローカル・キューマネージャー以外の任意のキューマネージャーのことです。リモート・キューマネージャーは、ネットワーク内のリモート・マシン上にある場合と、ローカル・キューマネージャーと同じマシン上にある場合があります。また、リモート・キューマネージャーが存在するシステムのことをリモート・システムと呼びます。
4 キュー
キューとは、アプリケーションからのメッセージを保持するための仕組みです。
アプリケーションは、そのキューを所有するキューマネージャーに接続してMQIコールを発行し、キューに対するメッセージの読み書きを行います。
キューには、メッセージを実際に格納することのできるローカルキュー、実体のないリモートキュー、別名キュー、モデルキューといった種類があります。
以下、順にこれらのキューに関する説明を行います。
【ローカルキュー】
アプリケーションが接続されているキューマネージャーに属するキューです。それぞれのキューが1つのキューマネージャーに属しているという意味では、すべてのキューがローカルキューであり、特定のキューマネージャーにとっては、それに属しているキューがローカルキューです。
主な属性は以下のようになります。
- 最大メッセージ数
- 現行メッセージ数
- 最大メッセージ長
- GETの可否
- PUTの可否
- デフォルトの優先順位
- デフォルトのメッセージ永続性
図5 リモートキューの使用例
【リモートキュー定義】
リモートキュー定義は、他のキューマネージャーに属するキューを指し示すものです。
リモートキュー定義が指し示している宛先のキューは宛先となるリモートキューマネージャー上で実在しなければなりません。さもなくば、デッドレターキューへメッセージが書き込まれたり、チャネルが停止する原因になります。
リモートキュー定義には宛先のキューマネージャー名、宛先のキュー名、トランスミッションキュー名等を指定することが可能であり、これらの情報をもとにローカル・キューマネージャーは、メッセージを正しい宛先に送信することができます。
別のキューマネージャー上のキューにメッセージを送信するには、あらかじめトランスミッションキューと宛先のキューマネージャーとの間のチャネルを定義しておく必要があります。ただし複数のキューマネージャーをクラスターとしてグループ化している環境では、その必要はありません。
上の図にリモートキューの使用例を示します。
図6 別名キュー
【別名キュー】
アプリケーションは、別名キューを用いて間接的にキューを参照することによりあるキューへアクセスすることができます。別名キュー名がMQI呼び出しで使用されると、その名前は実行時にローカルキューまたはリモートキューの名前として解釈されます。
これにより、アプリケーションを変更しなくても、単に別名キュー定義を変更するだけで、アプリケーションが使用するキューを変更することができます。別名キューは、キューではありませんが、他のキューへのアクセスに使用できるオブジェクトです。
図7 モデルキュー
【モデルキュー】
モデルキューの説明のため、動的キューと合わせた説明を行います。
モデルキューは、動的キュー作成のテンプレートとして使用されます。動的キューは、キュー名（モデルキューの名前）を指定したMQOPEN要求をアプリケーションが出す時に、キューマネージャーによって作成されます。このようにして作成された動的キューはローカルキューであり、その属性は、モデルキュー定義から継承されます。動的キュー名は、アプリケーションで指定する方法と、キューマネージャーが生成した名前をアプリケーションに渡す方法があります。
動的キューには以下の二種類があります。
-
一時キュー： アプリケーションやキュー管理プログラムが再始動すると消滅します。
-
永続キュー： アプリケーションやキュー管理プログラムが再始動しても存続します。
モデルキューによる動的キューの作成は、以下のような場面でよく用いられます。
- 一時的にキューを利用したい場合（Reply-Toキューなど）
- 個々の処理に専用のキューを割り当てたい場合
5 特殊な目的をもつローカルキュー
MQでは、一部のローカルキューを特定の目的のために使用します。以下、そのようなキューのうち主なものについての説明を行います。
図8 トランスミッションキューの使用例
【トランスミッションキュー】
トランスミッションキューは、リモート・キューマネージャー宛てのメッセージを一時的に保管する転送用のキューです。
ローカル・キューマネージャーがメッセージを直接送信する各リモート・キューマネージャーごとに、少なくとも1つのトランスミッションキューを定義する必要があります。通常は宛先キューマネージャー名と同一名にします。
上の図にトランスミッションキューの使用例を示します。
図9 イニシエーションキュー
拡大図
【イニシエーションキュー】
トリガリング機能を使用する際に、キューマネージャーによってトリガー・メッセージが書き出されるキューです。
キューマネージャーは、トリガー・イベントが発生すると、イニシエーションキューにトリガー・メッセージを書き込みます。トリガー・イベントは、例えばキュー内のメッセージの数が一定以上になったときに発生するように設定できます。
このトリガー・メッセージは、イニシエーションキューを監視する特殊アプリケーションであるトリガー・モニターによって取り出されます。次にトリガー・モニターは、トリガー・メッセージに指定されているアプリケーション・プログラムを始動します。
キューマネージャーでこのトリガー操作を使用する場合は、少なくとも1つのイニシエーションキューを、そのキューマネージャー用に定義する必要があります。
【デッドレターキュー】
キューマネージャーやMCAなどから配布不可能なメッセージが書き出されるキューです。送達不能キューなどとも呼ばれます。
デッドレターキューは、正しい宛先キューに書き込むことができないメッセージを保管します。たとえば、宛先キューが満杯である場合などに用いられます。
キューマネージャー接続においては、キューマネージャーごとに1つのデッドレターキューを定義することを推奨します。デッドレターキューの定義がない場合、宛先キューが満杯等の理由でMCAがメッセージを書き込むことができないと該当メッセージはトランスミッションキューに残ったままとなり、チャネルが停止してしまいます。クライアント接続では、デッドレターキューは使用しないのが一般的です。
【システムコマンドキュー】
システムコマンドキューはMQの管理コマンドを受け付けるためのキューです。管理コマンドをメッセージとしてこのキューにMQPUTする事により、キューマネージャーにコマンドを実行させる事ができます。コマンドの形式にはPCF（Programmable
Command Format）、MQSC（MQSeries Commands）およびCL（Control Language）コマンドの3種類があり、どの形式のコマンドを受け付ける事が可能かは、キューマネージャーが稼働しているプラットフォームに依存します。MQSeries
for VSE/ESAではシステムコマンドキューはサポートされていません。
WebSphere MQ for z/OSでは、このキューはSYSTEM.COMMAND.INPUT.QUEUEという名前で、受け付けられるコマンド形式はMQSCコマンドです。他のプラットフォームでは、SYSTEM.ADMIN.COMMAND.QUEUE
という名前で、受け付けられるコマンドはプラットフォームによって異なります。
【システムデフォルトキュー】
システムデフォルトキューは、キューのパラメーターのデフォルト値を持ちます。新しいキューを作成すると、キューマネージャーは該当のシステムデフォルトキューからパラメーター値をコピーします。
6 チャネル
チャネルとは、あるキューマネージャーと別のキューマネージャー（あるいはMQクライアントとサーバ側のキューマネージャー）を結ぶ通信パスを提供するオブジェクトのことであり、分散メッセージ・キューイングで使用されます。チャネルは、通信プロトコルをアプリケーションから隠蔽する役割を果たします。
以下にメッセージチャネル（キューマネージャー間接続の場合）およびMQIチャネル（MQクライアント接続の場合）についての説明を行います。
図10 メッセージチャネルを用いたメッセージの流れは
【メッセージチャネル】
あるキューマネージャーと別のキューマネージャーを結ぶ通信パスを提供するオブジェクトです。キューマネージャーは同一のプラットフォーム上に存在する場合もあれば、異なるプラットフォーム上に存在する場合もあります。
メッセージチャネルの特徴は以下のようになります。
- 1対1のチャネル定義を行います。
- 一つのチャネルを作成するためには、送信側と受信側それぞれで定義する必要があります。
- チャネルは単一方向のメッセージ転送を提供します。
- よって、データの送受信を行うには二対の定義が必要となります。
- MCA（Message Channel Agent）と呼ばれるプロセスが両側で稼働し、チャネルの制御を行います。
- リモート・システムのチャネルはリスナーにより開始されます。
- リスナーとは、ローカル・システム側からのチャネル接続要求をlistenするプログラムです。
- リスナーは接続要求を受信すると、その側でのチャネルを始動します。
メッセージチャネルを用いたメッセージの流れは左図のようになります。
【MQIチャネル】
MQIチャネルは、サーバーマシン上にあるキューマネージャーにMQクライアントを接続し、MQCONNまたはMQCONNX呼び出しの実行時に確立されます。
メッセージチャネルと異なり両方向の転送を提供するチャネルであり、MQIの呼び出しおよび応答だけを転送するのに使用されます（メッセージ・データが入ったMQPUT呼び出しを含む）。
サーバー側のチャネルをサーバー接続チャネル、クライアント側のチャネルをクライアント接続チャネルと呼びます。
7 プロセス定義
プロセス定義は、キューマネージャー上のトリガー・イベントに応答して開始されるアプリケーションを定義するものです。
プロセス定義の主な属性として、以下のようなものがあります。
- アプリケーションID
- アプリケーション・タイプ
- アプリケーション特有のデータ
- 環境情報
図11 プロセス定義
拡大図
トリガー設定済みのローカルキューがトリガリングの条件を満たすと、キューマネージャーがプロセス定義を参照しトリガー・メッセージ（MQTM）をイニシエーションキューに書き出します。そして、トリガーモニターと呼ばれる監視プログラムがトリガー・メッセージにセットされた情報をもとにアプリケーションを起動します。
8 名前リスト
図12 名前リスト
名前リストは他種のMQオブジェクト名のリストを提供します。アプリケーションで複数の宛先に対しメッセージを送出する時などに使用します。
名前リストを使用した場合の利点は、アクセスするオブジェクトのリストをアプリケーションとは別に管理できるということです。従って、名前リストの更新時に名前リストを使用しているアプリケーションを停止する必要はありません。また、あるアプリケーションで障害が起こった場合でも名前リストには影響はなく、他のアプリケーションは引き続きその名前リストを照会（MQINQ）して使用できます。
また、キューマネージャーやクラスターキューが複数のクラスターに属する場合にも、名前リストを使用して複数のクラスター名を指定します。この使用法を特にクラスター名前リストと呼びます。
9 リスナー、サービス、管理トピック、認証情報
【リスナー・オブジェクト】
リスナーは、他のキュー・マネージャーまたはクライアント・アプリケーションからネットワーク要求を受け取るプロセスで、関連付けられたチャネルを始動します。リスナー・プロセスは、runmqlsr制御コマンドを使用して開始できます。また、リスナー・オブジェクトの属性を定義することにより、次の操作を実行できます。
- リスナー・プロセスを構成する。
- キュー・マネージャーが開始および停止したときに、リスナー・プロセスも自動的に開始および停止させるかどうかを指定する。
【サービス・オブジェクト (WebSphere MQ for z/OS を除く)】
サービス・オブジェクトは、キュー・マネージャーが開始または停止したときに実行するプログラムを定義するオブジェクトです。プログラムは、次の2つのタイプのサービス･オブジェクトに分類されます。
サーバー・サービス・オブジェクト
サーバーは、SERVTYPEパラメーターがSERVERに指定されているサービス・オブジェクトです。サーバー・サービス・オブジェクトは、指定したキュー・マネージャーの開始時に実行されるプログラムの定義ですが、同時に実行できるサーバー・プロセスは1つです。サーバー･サービス･オブジェクトは、実行中の状況をMQSCコマンド"DISPLAY SVSTATUS"を使用してモニターできます。 コマンド・サービス・オブジェクト
コマンドは、SERVTYPEパラメーターがCOMMANDに指定されているサービス・オブジェクトです。コマンド・サービス・オブジェクトは、指定されたキュー・マネージャーが開始または停止したときに実行されるプログラムの定義であり、複数のインスタンスを並行して実行できます。コマンド・サービス・オブジェクトは、プログラムが実行されるとキュー・マネージャーがプログラムをモニターしなくなる点で、サーバー・サービス・オブジェクトと異なっています。つまり、MQSCコマンドを使用して状況をモニターすることはできません。
【管理トピック・オブジェクト】
トピックとは、パブリッシュ/サブスクライブ・メッセージでパブリッシュされる情報のサブジェクトを記述する文字ストリングのことです。その中で、管理トピック・オブジェクト とは、デフォルト以外の特定の属性をトピック に割り当てるための WebSphere MQ オブジェクトです。
下図は、上位トピック「Sport」を個々のスポーツに対応する個々のトピックに分割し、トピック・ツリーとして視覚化した図です。このツリーを作成するには管理トピック･オブジェクトは不要です。
下図は、トピック･ツリーの中の「Sport/Soccer」トピックに管理トピック・オブジェクト"FOOTBALL.EUROPEAN"を関連付けたイメージです。
ここで、管理トピック･オブジェクトの属性を変更するには、次のようなコマンドを使用します。
ALTER TOPIC(FOOTBALL.EUROPEAN) DURSUB(NO) |
下位のトピックは、管理トピック･オブジェクトの属性を引き継ぐので、開発者は管理トピック･オブジェクトより上のトピック属性を知る必要がありません。この機能を使用すれば、トピック・ツリーの一部分をアプリケーション開発者から隠蔽することができます。
【認証情報オブジェクト】
キュー・マネージャー認証情報オブジェクトは、WebSphere® MQ の Secure Sockets Layer (SSL) セキュリティー・サポートの一部です。このオブジェクトには、LDAP サーバーを使用したCRL(Certification Revocation List:証明書取り消しリスト)の検査に必要な定義を保持しています。
参考文献
著者について  | | | 豊村 明彦, IBM |
記事の評価
| 
