Comments
Description
Transcript
第３章 MQ Telem e try
第３章 MQ Telemetry
1
Smarter Planet実現のための新たなメッセージング・ニーズ
Smarter Planet実現のための新たなメッセージング・ニーズ
IBMは交通や環境、エネルギー、医療といった地球規模の多様な課題を解決するための
コーポレート・ビジョンとして 「Smarter Planet」を提唱
Smarter Planet実現のためには、多様/大量のセンサー・デバイスからネットワーク経由で
データを収集するためのインフラが必要
不確実・低帯域幅N/W上で大量のデバイスと、メッセージング・バックボーンとを相互接続する
ためのテクノロジーが求められる
Smarter Planet環境の特徴とデータ収集に対する要件
特徴
要件
大量のデータを多数のデバイスから収集
・中間集約拠点の設置（マルチホップ転送）
・軽量プロトコルの使用
・宛先を意識しない通信モデル
不確実・低帯域幅N/Wからの接続
・通信エラーへの対処
デバイスの遠隔制御
・デバイス、サーバー間の相互通信
2
MQ Telemetry
デバイスでの利用を想定した、軽量なパブリッシュ/サブスクライブ処理を実現
MQが以前から提供しているパブリッシュ/サブスクライブ機能とは異なり、
転送データの軽量化に特化した仕組みを提供
様々な機器上のデバイスとWMQメッセージ基盤を連携可能
デバイス
キュー・マネージャー
MQTT
クライアント
MQTTプロトコル
MQTT
サーバー
オープン・プロトコルMQTT（MQ Telemetry Transport）を通信プロトコルに使用
MQTT V3.1に準拠
ネットワーク･プロトコルは、TCP/IP（IPv4/IPv6）、SSLをサポート
WMQ V7.0.1.2 から、MQの標準機能として提供
以前は、WebSphere Message Brokerでサポート（SCADAノード）
機能をMQに移管し、WMB
V7ではサポート終了
MQTTのサーバー機能とクライアント用のライブラリ（C、Java）を提供
Telemetryデーモンの提供
MQTTクライアントとサーバーの間で、ゲートウェイとして機能する組み込みコンポーネント
3
MQTT (MQ Telemetry Transport)
仕様が公開されたオープンなパブリッシュ/サブスクライブ型通信プロトコル
http://mqtt.org/
仕様は上記URLから入手可
最新のバージョンはV3.1
TCP/IPが前提
シンプル・軽量で開発容易性を備えたプロトコル
クライアント･サーバー間で送受信されるパケットは最小化されたフォーマット
–ビット単位でフォーマットを規定
–パケットの固定ヘッダー部分は、2バイトのみ
低帯域ネットワーク、信頼性の低い小型デバイスなど、リソースに制約のある環境で
稼働するアプリケーションとの通信を想定
クライアント接続の予期しない切断に対し、「遺言（Last
Will and Testament）」機能を提供
クライアント切断時、サーバー側でのパブリケーションの保持
メッセージ送信の信頼性に応じて、3つのサービス品質（QoS : Quality of Service）を規定
QoS
=0
QoS = 1
QoS = 2
：メッセージは1回のみ送信される（送信先の届くかは保証しない）
：メッセージは最低1回は送信先に送られる
：メッセージは必ず正確に1回送信先に送られる
4
MQ Telemetry適用イメージ
MQTTクライアントを実装したデバイスからMQにMQTTプロトコルで接続
通信が不安定な環境でも信頼性を保ったメッセージ連携が可能
組み込みデバイスとの双方向通信が可能
デバイスからのデータ収集、デバイスへの管理コマンドの送信・データ一斉配信など
Pub/Subの仕組みにより宛先アプリケーションの数や、宛先を意識しない
Telemetryデーモンにより、メッセージの集約やフィルタリングが可能
メッセージの集約・転送
MQTTクライアント
Telemetryデーモン
エンタープライズ・システム
MQTTクライアント
MQTTプロトコル
Pub/Subによる
メッセージを送受信
MQTTクライアント
WMQ
Telemetry
デバイス、MQ間をMQTTで接続
5
（補足）Publish / Subscribe型メッセージ通信モデル
Publish / Subscribe型
送信プログラムと受信プラグラムがトピックを介して１対Nで通信するモデル
送信側（パブリッシャー）が受信側（サブスクライバー）を意識せずにデータ送受信を行う
サブスクライバーは受信したいトピックにサブスクライブ（購読）登録を行う
パブリッシャーは、送信したいデータをトピックに対してパブリッシュ（送信）する
両者の間には必ずPub/Subブローカーが介在し、データの管理、配信を行う
購読の登録(トピックA)
トピックA
パブリッシャー
パブリッシャー
送信
Pub/Sub
ブローカー
管理情報/データを保持
・サブスクライブ登録情報
・パブリッシュ・データ など
トピックA
サブスクライバー
配信
トピックA
サブスクライバー
（参考）Point-to-Point（PTP）型
送信プログラムと受信プログラムがキューを介して1対1で通信するモデル
プログラムＡ
プログラムＡ
プログラムＢ
プログラムＢ
6
（補足） Pub/Sub の構成要素
トピック
情報提供者 (パブリッシャー)と情報受信者(サブスクライバー)を連携する、共通の”話題”
パブリケーション
パブリッシャーとサブスクライバーがやり取りするメッセージ
パブリッシャ－が 発信(送信) したパブリケーションを、ブローカーが 受信・配信 し、それをサブス
クライバーが 受信
パブリッシャー
パブリッシャーは、トピックを宛先として情報を配信
サブスクライバー
パブリケーションを受信するために、購読要求(サブスクリプション)を登録する
サブスクリプション
サブスクライバーがパブリケーションを受信するために登録する情報
ブローカー
パブリケーションの受信/配信と、パブリッシャー、サブスクライバーの管理を行う
7
（補足）トピック
トピック
トピックAの
サブスクリプション登録
パブリッシャーとサブスクライバーを紐付ける共通の話題
階層構造に構成することができる
パブリッシャー
トピックA
サブスクライバー
Pub/Sub
ブローカー
トピック・ツリー
トピックを階層構造で表記したもの
トピック・ツリーの各セグメントをノードという
トピックAに関する
情報を発信
トピック・ストリング
トピックAに関する
情報を受信
トピック・ツリー
スラッシュを階層の区切り文字としてノードを表現する文字列
スラッシュで区切られた文字列の単位がノード
パブリッシャーがパブリケーションを発信する宛先
サブスクライバーがパブリケーションを受信するために指定するもの
トピック・ストリング (例：“result” のノードのトピック・ストリング)
/men
/olympic/london/judo/women/result
/result
/olympic
/london
/judo
/women
/beijing
/tennis
/men
/women
/result
ノード
8
MQ Telemetry の構成コンポーネント
MQ Telemetryは以下のコンポーネントから構成される
MQ キューマネージャー
Telemetry サービス
（MQTTサーバー）
Telemetry チャネル
Telemetry チャネル
Telemetryチャネル
MQTT
クライアント
Telemetry
デーモン
MQTT
クライアント
MQTT
クライアント
9
MQ Telemetry の構成コンポーネント
Telemetryサービス
MQTTのサーバー機能を提供するコンポーネント
MQのサービスとして稼働（Javaプロセス）
MQサービス名は“SYSTEM.MQXR.SERVICE”
（固定）
キューマネージャーに１つのみ構成可能
Telemetryチャネル
MQTTクライアントからの接続を受け付け、通信を行うコンポーネント
Telemetryチャネルのプロパティで使用するポートを指定
複数のチャネルを構成可能
クライアントをグループ化し、異なった設定のチャネルを使い分けることが可能
チャネル毎にJAASやSSLのセキュリティ設定が可能
MQTTクライアント
MQ TelemetryのAPIを使用して、Telemetryチャネルに接続し、Pub/Sub通信を実施
JavaとCで実装可能
Java
SE／Java ME 用の MQTT v3 クライアント・ライブラリー、C 用 MQTT v3 ライブラリーを提供
10
MQ Telemetry の構成コンポーネント
Telemetryデーモン（拡張MQTTクライアント、C実装）
MQTTクライアントとサーバーの間で、ゲートウェイとして機能するコンポーネント
複数クライアントからの接続を集約してMQTTサーバーに接続
–MQTTサーバー側の接続負荷を軽減
Telemetryデーモン同士で接続し、階層的な構成を取ることも可能
メッセージのストア・アンド・フォワード
–一時的にメッセージをメモリーに保管し、ネットワークの瞬断に対応
Pub/Subネットワーク内のメッセージをフィルタリング
トピックベースのフィルタリング
11
MQ Telemetry と MQ との関係
MQ Telemetry サービスは、MQのPub/Subアプリケーションとして稼動
MQTTクライアントとMQ Pub/Sub アプリケーションは相互通信可能
① MQTT クライアントからのサブスクライブ登録は
Telemetry サービスによって、
MQ Pub/Sub ブローカーに登録される
② MQTT クライアントからパブリッシュした
メッセージは該当トピックを
サブスクライブしているMQ Pub/Sub
アプリケーションにも送信される
③ MQ Pub/Subアプリケーションからパブリッシュしたメッセー
ジは該当トピックをサブスクライブしているMQTTクライアン
トに送信される
④ MQアプリケーションから直接MQTTクライアントにメッ
セージを送信することが可能
MQアプリはMQTTクライアントのクライアントIDを指定して
送信（クライアントIDはMQTTクライアントが接続時に指
定するユニークなID）
※MQTTクライアントからMQアプリへの直接メッセージ送
信は不可
12
MQ Pub/Sub
アプリ
③
MQ キューマネージャー
MQ Pub/Sub ブローカー
トピック
サブスクリプション
Telemetry サービス
Telemetry チャネル
①
②
MQTT
クライアント
MQ
アプリ
④
構成／管理
MQ Telemetryの構成、管理はMQ Explorerから実施
MQ Telemetryを導入すると、MQ Explorerに以下のMQ Telemetry項目が追加される
13
構成／管理
初期構成は、「サンプル構成の定義」ウィザードから実施
※初期構成は、製品提供の下記スクリプト、もしくは手動でも構成できる
<MQ導入Dir>/mqxr/samples/SampleMQM.bat(or SampleMQM.sh)
14
構成／管理
「サンプル構成の定義」ウィザードを実行すると以下のコンポーネントが作成される
Telemetryサービス「SYSTEM.MQXR.SERVICE」（固定名）
Telemetryチャネル「PlainText」
–初期構成後、ユーザーは任意の名前で複数のTelemetryチャネルを構成可
15
構成／管理
MQTTクライアント・ユーティリティを利用してパブリッシュ、サブスクライブのテストが可能
接続の実施
サブスクライブ
の実行
パブリッシュの
実行
16
構成／管理(UNIX）
UNIX環境での手動での構成手順
Telemetry 伝送キューの作成
echo "DEFINE QLOCAL('SYSTEM.MQTT.TRANSMIT.QUEUE') USAGE(XMITQ) MAXDEPTH(100000)" | runmqsc qMgr
デフォルト伝送キューを設定
echo "ALTER QMGR DEFXMITQ('SYSTEM.MQTT.TRANSMIT.QUEUE')" | runmqsc qMgr
MQTTクライアントがMQメッセージを受信するための設定
デフォルト伝送キューを変更しない場合は、MQを受信するクライアントごとにリモート・キュー定義を追加す
る必要がある
MQTT クライアント用ユーザーIDの作成
パブリッシュ、サブスクライブ、およびMQTT
クライアントへのパブリケーション送信の権限
Telemetryサービスをインストール
<導入ディレクトリ>/mqxr/samples
のinstallMQXRService_unix.mqsc を実行
cat installMQXRService_unix.mqsc | runmqsc qMgr
サービスを開始
echo "START SERVICE(SYSTEM.MQXR.SERVICE)" | runmqsc qMgr
Telemetryチャネルを構成
echo "define channel(MQTTCHL) chltype(MQTT) port(1883) MCAUSER(userid)" | runmqsc qMgr
17
MQTT クライアントの開発
MQ Telemetry が提供する Java および C のクライアント･ライブラリーを利用
WebSphere MQ Telemetry Software Development Toolkit (SDK)にて提供
簡単な動詞（verbs）のセットのみで実装可能
connect
/ publish / subscribe / disconnect ....
10数行程度の短いコードで実装できる
18
コード･イメージ（Java、パブリッシャーの例）
・・・MQTT用のパッケージ
import com.ibm.micro.client.mqttv3.*;
public class MqttPubSync {
public static void main(String[] args) {
try {
MqttClient client = new MqttClient("tcp://localhost:1883", “PubClient001");
・・・クライアントの作成
MqttConnectOptions conOptions = new MqttConnectOptions();
conOptions.setCleanSession(false);
client.connect();
・・・接続オプションの設定
・・・クリーン･セッション設定
・・・接続の実施
MqttTopic topic = client.getTopic("/MQTT/Examples");
MqttMessage message = new MqttMessage("Hello World!".getBytes());
message.setQos(1);
・・・トピックの作成
・・・メッセージの作成
・・・QoSの設定
MqttDeliveryToken token = topic.publish(message);
token.waitForCompletion(10000);
・・・パブリッシュの実施
・・・確認応答待ち
client.disconnect();
} catch (Exception e) {
e.printStackTrace();
}
・・・接続の切断
}
}
※上記は簡略化したコード･イメージであり、稼動を保証するものではありません。
19
コード･イメージ（C言語、パブリッシャーの例）
・・・MQTT用のヘッダー
#include "MQTTClient.h"
int main(int argc, char* argv[])
{
MQTTClient client;
MQTTClient_connectOptions conn_opts;
MQTTClient_message pubmsg;
MQTTClient_deliveryToken token;
int rc;
char *PAYLOAD = "Hello World!";
・・・ローカル変数の定義
MQTTClient_create(&client, "tcp://localhost:1883", "PubClient001",
MQTTCLIENT_PERSISTENCE_NONE, NULL);
memset(&conn_opts, '¥0', sizeof(conn_opts));
conn_opts.cleansession = 1;
rc = MQTTClient_connect(client, &conn_opts);
if (rc != MQTTCLIENT_SUCCESS) {
printf("Failed to connect, return code %d¥n", rc);
exit(-1);
}
pubmsg.payload = PAYLOAD;
pubmsg.payloadlen = strlen(PAYLOAD);
pubmsg.qos = 1;
MQTTClient_publishMessage(client, "/MQTT/Examples", &pubmsg, &token);
rc = MQTTClient_waitForCompletion(client, token, 10000L);
MQTTClient_disconnect(client, 10000);
MQTTClient_destroy(&client);
}
※上記は簡略化したコード･イメージであり、稼動を保証するものではありません。
20
・・・クライアントの作成
・・・接続オプションの設定
・・・クリーン･セッション設定
・・・接続の実施
・・・メッセージの設定
・・・QoSの設定
・・・パブリッシュの実施
・・・確認応答待ち
・・・接続の切断
・・・クライアント終了
（メモリ開放）
MQTTのメッセージ保証
MQTTにおけるメッセージ保証の仕組み
MQTTクライアント（パブリッシャー）から送信されたメッセージが他のMQTTクライアント（サブスク
ライバー）に到達するまでの間のメッセージ保証について、MQTTでは以下の仕組みを用意
サービス品質（QoS : Quality of Service）
MQTTクライアントとMQTTサービス間のメッセージ転送の信頼性について、3つのレベルを用意
QoS = 0 / 1 / 2
QoSが高いほど、より確実に、より正確にメッセージを転送
ただし、転送負荷は高くなり、パフォーマンスは低くなる
セッション管理
MQTTクライアントのセッション情報を保持することで、クライアント障害やN/W障害が起きた場
合でも再接続後に処理を再開することが可能
QoS=1/2の場合、障害時に未完了の転送を再接続後に再開できる
サブスクライバー障害時に届いていたパブリケーションを再接続後に受信できる
21
サービス品質（QoS）
MQTTプロトコルでは3種類のサービス品質（QoS:Quality of Service）を規定
MQTTクライアントとMQTTサービス間のメッセージ（パブリケーションおよびサブスクライブ登録）
のサービス品質
サブスクライブ登録
MQTT
クライアント
パブリケーション
MQTT
サーバー
パブリケーション
MQTT
クライアント
QoS
QoS
QoS = 0
メッセージは1回のみ送信される
–送達確認を行わないため、転送途中で障害が発生するとメッセージ消失の可能性がある
最も高速な転送モード
QoS = 1
メッセージは最低1回は送信先に送られる
–送達確認を行うため、1回は必ず送信先に到達する
–受信側で複数回メッセージを処理する可能性がある
QoS = 2
メッセージは必ず正確に1回送信先に送られる
–送達確認と重複送信確認を行うことで、メッセージは1回だけ確実に送信先に到達する
最も負荷の高い転送モード
22
サービス品質（QoS）
サブスクライブ登録の要求メッセージは常にQoS=1で送信される
パブリッシュ時のQoSより高いQoSでサブスクライバーはメッセージを受信することはできない
サブスクライバーがQoS=2を指定していても、パブリッシャーからQoS=1でパブリッシュされたメッセージは、
サブスクライバーへもQoS=1で転送される
キューマネージャー内に（一時的に）格納されるパブリケーション･メッセージ（※）の永続性は
QoSに依存
※リテイン･パブリケーション時のリテイン･キューやサブスクライバー･キューに格納されるメッセージ
QoS=0の場合、ノン･パーシステント･メッセージ
QoS=1/2の場合、パーシステント･メッセージ
23
（補足） QoS=0 の処理フロー
QoS=0 では、送信処理のみ実施（送達確認は行わない）
MQTTアプリケーションのパブリッシュによって、MQTTクライアントから1回だけパブリケーションが送信される
MQTTサービスはパブリケーションを受信するとサブスクライバーにパブリッシュ
MQTTアプリケーションのパブリッシュ実行からMQTTサービスのパブリッシュまでの間に障害が発生すると
メッセージは消失する可能性がある
MQTTアプリ
MQTT
クライアント
MQTT
サービス
キューマネージャー
パブリッシュ実行
パブリケーション送信
サブスクライバーにパブリッシュ
24
（補足） QoS=1 の処理フロー
QoS=1 では、送達確認を実施
MQTTアプリケーションからパブリッシュが実行されると、MQTTクライアントはパブリケーションをローカルに保
管し、パブリケーションを送信
MQTTサービスはパブリケーションを受信するとサブスクライバーにパブリッシュし、確認応答を返信
確認応答を受け取ると、保管しているパブリケーションを破棄
MQTTアプリ
MQTT
クライアント
MQTT
サービス
キューマネージャー
パブリッシュ実行
パブリケーション送信
サブスクライバーにパブリッシュ
メッセージの保管
確認応答の返信
メッセージの破棄
25
（補足） QoS=2 の処理フロー
QoS=2 では、送達確認と重複チェックを実施
MQTTサービスはパブリケーションを受信すると、サブスクライバーにパブリッシュ
さらにパブリケーションのメッセージIDを保管し、パブリケーション受信応答をMQTTクライアントに返信
MQTTクライアントはパブリケーション受信応答を受け取るとパブリケーション破棄指示を送信
MQTTサービスは保管していたメッセージIDを破棄し、パブリッシュ完了応答を返信
MQTTクライアントは応答を受信すると保管していたメッセージを破棄
MQTTアプリ
MQTT
クライアント
MQTT
サービス
キューマネージャー
パブリッシュ実行
パブリケーション送信
サブスクライバーにパブリッシュ
メッセージの保管
UOW
パブリケーション受信応答
ID
メッセージID の保管
パブリケーション破棄指示
パブリッシュ完了応答
メッセージID の破棄
メッセージの破棄
26
メッセージIDを保管して
おくことで再送メッセー
ジを受信したときにサ
ブスクライバーへのパ
ブリッシュが完了して
いるかチェックする
セッション管理（ステートフル／ステートレス）
MQTTサービスでは、MQTTクライアントのセッション情報を保持することが可能
クライアントごとにサブスクリプションや未完了パブリケーションなどのセッション情報を保持
クライアントIDとアドレスでクライアントを識別
クライアントは接続時にセッション情報を保持するか指定（クリーン・セッション属性の指定）
クリーン・セッション属性＝false
クリーン・セッション属性＝true
（デフォルト）
⇒セッション情報を保持する（ステートフル）
⇒セッション情報を保持しない（ステートレス）
ステートフル・クライアントの場合
接続中に登録したサブスクリプションは、接続が（意図せず）切断した後も保持される
継続サブスクリプションとして登録
切断している間も当クライアントに対するパブリケーションは保管され、
再接続時にクライアントにパブリッシュされる
切断前に未完了だったパブリケーション（QoS=1/2）は再接続後に完了
ステートレス・クライアントの場合
（前回ステートフルで接続していた場合に）保管されているセッション情報は、接続時に破棄
接続中に登録したサブスクリプションは、接続が切断されると破棄
27
「遺言」パブリケーション
MQTTクライアントが予期せずに終了した場合に、「遺言」を残すことができる
MQTTクライアントは接続時に「遺言」パブリケーションを登録
接続オプションにトピック、QoS、ペイロードを指定
リテイン（保存）パブリケーションの指定も可
conOptions.setWill(MqttTopic lastWillTopic, byte [] lastWillPayload, int lastWillQos,boolean lastWillRetained);
Telemetryサービスはクライアント接続の予期しない切断を検知すると、
登録されている「遺言」パブリケーションをパブリッシュ
クライアントからdisconnectメソッドが発行されずに接続が切断された場合に実施
利用例
MQTTクライアントのステータス情報の通知（保管）
MQTTクライアントは接続後、および（正常）切断前にそれぞれ使用可／使用不可（正常）を示すリテイ
ン･パブリケーションをパブリッシュ
「遺言」パブリケーションには、使用不可（異常）を示すリテイン･パブリケーションを登録しておく
※リテイン･キューに送信（保管）されるメッセージをパーシステントにするため、各パブリケーションのQoSは１
もしくは2に設定しておく
該当トピックにサブスクライブしたアプリケーションは、常に、3つのうちのいづれかのパブリケーションを受信す
ることができる
（リテイン･パブリケーションは同一トピックに対して最新のパブリケーションのみが保管される）
28
（参考） MQTTのセキュリティ
MQTTの通信はVPNを使用してMQTT装置とサーバー間でセキュアな通信を実現可能
IPSecなどVPNネットワークで認証や暗号化を実現し、トラステッド・ネットワークを確立
その他、SSLやJAASなどのセキュリティー・メカニズムを使用したセキュアな通信もサポート
通信の暗号化、認証、認可
ただし端末ごとの認証や認可は困難なため、考慮が必要
認証と認可
認可はMQのOAM機能を使用して実施
膨大な装置にそれぞれセキュリティープロファイルを設定するのは非現実的
ユーザーをグループ化し、共通IDを使用する
認証はSSLやJAASを使用
認証と許可のユーザーは異なってもよい
SSLとJAAS
SSLでのセキュリティ設定
装置と遠隔測定チャネル間の通信の暗号化
サーバー認証
（正しいサーバーに装置が接続しているか）
（クライアント装置がサーバーに接続することを許可されているか）
クライアント認証
JAASでのセキュリティ設定
パスワードを使用したクライアントの認証
LDAPとともに使用することで、シングル・サインオン・ディレクトリーを使用したパスワード検査が可能
29
（参考） MQTT パフォーマンス例
LinuxでのMulti-Publisher / Multi-Subscriberのパフォーマンステスト結果
QoS0で秒1877件、QoS1で秒1235件、QoS2で秒1088件とQoSレベルがあがるほど、
パフォーマンスは劣化
同時接続数が増えればCPU使用率も上がり、QoS0の場合、同時接続数1000で71%程
度、10万接続で92%程度まであがる。
[ Linux Multi-Publisher, Multi-Subscriber graph ]
測定環境
Red Hat Enterprise Linux V5.5 64-bit
Processor: 3.66GHz Intel Xeron
Architecture: 2 dual core CPU (4way SMP)
RAM: 4Gb
Network: 1Gbit Ethernet Adapter
[出典] MP0A: WebSphere MQ Telemetry V7.0.1 - Performance Evaluation
http://www-01.ibm.com/support/docview.wss?rs=171&uid=swg24027711&loc=en_US&cs=utf-8&lang=en
30
（参考） MQTT パフォーマンス例
WindowsでのMulti-Publisher / Multi-Subscriberのパフォーマンステスト結果
Windowsは同時接続50000までをテスト
QoS0で秒3157件、QoS1で秒2035件、QoS2で秒1819件とQoSレベルがあがるほど、
パフォーマンスは劣化
接続数が増えるほど、メッセージの処理件数は下がり、CPU使用率は100%に近づく
測定環境
[ Windows Multi-Publisher, Multi-Subscriber graph ]
Windows Server 2008
Processor: 3.66GHz Intel Xeron
Architecture: 2 dual core CPU (4way SMP)
RAM: 4Gb
Network: 1Gbit Ethernet Adapter
31
参考資料
MQTT.org
http://mqtt.org/
MQTTの仕様や各種クライアント・サーバーの実装など、様々な情報にアクセス可能
WMQ Information Center - WebSphere MQ Telemetry
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r1/topic/com.ibm.mq.doc/tt00000_.htm
System Requirements for WebSphere MQ V7.1 Telemetry
http://www-01.ibm.com/support/docview.wss?uid=swg27023057
developerWorks
さらに拡がるMQの世界 - WebSphere MQ Telemetry のご紹介
http://www.ibm.com/developerworks/jp/websphere/library/wmq/mq_world_ws/
WebSphere MQ V7 アップデート・ワークショップ 2章（WMQ Pub/Sub）など参照
http://www.ibm.com/developerworks/jp/websphere/category/wmq/
WebSphere MQ SupportPacs
http://www-01.ibm.com/support/docview.wss?rs=171&uid=swg27007198&wv=1
MP0A（パフォーマンスレポート）、IA93（MQTT Cクライアント）など参照
32