IBM MessageSightを 利用したシステム設計のポイント IBM MessageSight テクニカル・セミナー
by user
Comments
Transcript
IBM MessageSightを 利用したシステム設計のポイント IBM MessageSight テクニカル・セミナー
IBM MessageSight
テクニカル・セミナー
IBM MessageSightを
利用したシステム設計のポイント
日本アイ・ビー・エム株式会社
© 2014 IBM Corporation
Disclaimer
当資料は、資料内で説明されている製品の仕様を保証するものではありません。
資料の内容には正確を期するよう注意しておりますが、製品の新しいリリース、修正などによっ
て動作／仕様が変わる可能性があるのでご注意下さい。
2
© 2014 IBM Corporation
目次
MQTT、IBM
MessageSight概要
MQTTおよびMessageSightの概要をご紹介
MessageSight利用シナリオ
適用できる業界やビジネスエリア、ビジネスにおけるPub/Subの活用などをご紹介
MessageSightを利用したシステム設計のポイント
システム・パターンとトポロジー
トピック設計、パブリッシャー/サブスクライバー
MessageSightのオブジェクト、セキュリティ
システム設計例
3
ユースケースに沿った設計の例をご紹介
© 2014 IBM Corporation
Part3「MessageSightを有効利用したシステム設計」の構成
システムグランドデザイン
要件整理
設計パターンの整理
トポロジー設計
論理設計
トピック/ペイロード設計
パブリッシャー設計
サブスクライバー設計
外部連携設計
物理設計
MessageSightオブジェクト定義設計
ユーザ/グループ定義設計
クライアント設計
外部連携設計
4
© 2014 IBM Corporation
システムグランドデザイン
ここでは、Pub/Subシステムの全体構想をまとめる
5
© 2014 IBM Corporation
システムグランドデザインの流れ
システムグランドデザイン
要件整理
設計パターンの整理
トポロジー設計
論理設計
トピック/ペイロード設計
パブリッシャー設計
サブスクライバー設計
1. 要件整理（確認）
外部連携設計
物理設計
MessageSightオブジェクト定義設計
ユーザ/グループ定義設計
クライアント設計
外部連携設計
機能要件についてヒアリング
論理設計、物理設計時の判断材料としても利用
•
2. 設計パターンの整理
業務アプリケーションの視点でパターン化
複数パターンの組み合わせもある
• データの視点でパターン化
• Pub/Subモデルへの適用
•
3. トポロジー設計
Pub/Sub コンポーネントの整理とプロトコル選択
• 外部システム連携方式の決定
•
6
© 2014 IBM Corporation
要件整理
システムグランドデザイン
要件確認（整理）
設計パターンの整理
トポロジー設計
論理設計
トピック/ペイロード設計
パブリッシャー設計
サブスクライバー設計
外部連携設計
ヒアリング項目にしたがって、要件を整理
物理設計
MessageSightオブジェクト定義設計
ユーザ/グループ定義設計
クライアント設計
外部連携設計
分類
ヒアリング内容
ヒアリング・ポイント
パターン
業務パターン
Fan-out / Fan-in / Any-to-Any / Point-to-Point
データパターン
1 ： N / 1 ：1 （特定配信宛先の数）
要求/応答型の有無
接続
データ
セキュリ
ティ
7
同時接続数
最大で同時にMQTTクライアントが何台接続するか
外部連携の有無
APサーバー / ESB / DB / MQ など
接続状況の把握
接続の切断をすばやく検知したいか
データ量
時間当たりのメッセージ数
データ長
Pub/Subの場合はペイロード（データ） + トピック長 を考慮
受信データの鮮度
受信側が接続後のデータのみ受信 / 切断中のデータもすべて
受信 / 切断中の最新データのみ受信
送達保障
データのロストを許容 / 必ず送信（重複許容） /必ず1回送信
接続状況の把握
接続の切断をすばやく検知したいか
ユーザー認証
ユーザーID（パスワード認証） / SSL証明書の利用
認可
データの認可設定が必要か
通信の暗号化
SSL
© 2014 IBM Corporation
要件整理
システムグランドデザイン
業務アプリケーション視点でパターン化
設計パターンの整理
トポロジー設計
論理設計
トピック/ペイロード設計
パブリッシャー設計
サブスクライバー設計
外部連携設計
業務の視点から情報の送信/受信を4パターンに分類する
物理設計
MessageSightオブジェクト定義設計
ユーザ/グループ定義設計
クライアント設計
①
業務によっては複数パターンの組み合わせになるケースもある
多数への情報配信
②
送信者
送信者は、多数の受信者に一括して情報を送りたい
受信者の数は変動する（会員、社員など）
例） 株価配信、スポーツ結果の配信、イベント情報配信、渋滞情報の配信
Fan-in（N ：1）
受信者
N：1
多数からの情報集信
8
1：N
Fan-out （1 ： N）
外部連携設計
受信者は、多数の送信者から情報を受け取りたい
送信者はある程度決まっている
例） メーターやセンサーからのデータ収集、アンケートの収集
送信者
受信者
© 2014 IBM Corporation
業務アプリケーション視点でパターン化
③
不特定多数への集配信
④
送信者は、一定数の受信者に情報を送りたい
情報の送信者と受信者が不特定多数で変動する
例） グループチャット、フォーラム
送信者
Point-to-Point （1 ： 1）
送信者は受信者を特定して情報を送りたい
例） 通知、メーターの制御メッセージの送信
その他の分類
一方向型
要求/応答型
受信者
1：1
特定配信
N：N
Any-to-Any （N ：N）
送信者
受信者
一方向型
9
要求/応答型
一方向型の組み合わせ
© 2014 IBM Corporation
データの視点でパターン化
データの送受信の観点から、4つの業務パターンは2つに集約できる
【Fan-out】
マルチキャスト型（1 ：N）
複数宛先に同じデータを送信する
【Any-to Any】
Fan-out が
複数ある業務
データ
［1 ： N ］
D
データ
D
D
D
送信者
受信者
D
ユニキャスト型（1 ：1 ）
D
10
【Point-to-Point】
特定宛先に１つのデータを送信する
データ
送信者
データ
受信者
【Fan-in】
Point-to-Pointが
複数ある業務
［1 ： 1］
D
送信者
受信者
送信者
受信者
© 2014 IBM Corporation
Pub/Subモデルへの適用
業務パターンをPub/Subモデルへ適用する
パブリッシャー（送信者）、サブスクライバー（受信者）、Pub/Subブローカー（仲
介）、トピックを整理
トポロジー設計、トピック設計、セキュリティ設計につなげる
Pub/Subモデル① --- 1 ： N （Fan-out / Any-to-Any）
パブリッシャーは1つのトピックに対してペイロード（データ）を送るだけ
ブローカーが複数のサブスクライバーへの配信を行う
サブスクライバーは、トピックをサブスクライブするだけ
【Any-to-Any】
【Fan-out】
トピック
S
S
P
BRK
S
S
パブリッシャー
ブローカー
サブスクライバー
P
P
P
S
S
BRK
S
S
P
パブリッシャー
11
トピック
ブローカー
サブスクライバー
© 2014 IBM Corporation
Pub/Subモデルへの適用
Pub/Subモデル② --- 1 ： 1 （Point-to-Point / Fan-in）
パブリッシャーは宛先毎に異なるトピックで配信
サブスクライバーは、自分専用のトピックをサブスクライブする
他人のトピックにサブスクライブ/パブリッシュできないようなセキュリティ設定が必要
【Point-to-Point】
【Fan-in】
トピック
P
S
P
S
P
BRK
S
S
パブリッシャー
12
ブローカー
サブスクライバー
P
トピック
BRK
S
P
パブリッシャー
ブローカー
サブスクライバー
© 2014 IBM Corporation
トポロジー決定のための検討項目
要件整理
システムグランドデザイン
設計パターンの整理
トポロジー設計
論理設計
トピック/ペイロード設計
パブリッシャー設計
サブスクライバー設計
Pub/Sub コンポーネントの整理
外部連携設計
測定デバイス、スマートフォン（iOS,Android）、ブラウザー、アプリケーション ・・・
IBM MessageSight ：新規でMQTT環境を構築する場合（大規模接続が可能）
WebSphere MQ
：MQ導入済環境で接続台数が少ない場合
バックエンドシステムとの連携方法を決める
APサーバー連携 ：JMS / MQTTで新規アプリケーションを作成する
MQ連携 ：MessageSightでMQTT⇔MQ変換を実施する
MQTTクライアントが
提供されている言語
ESB連携 ：ESB経由で既存アプリケーション変更なしに連携する
DB連携 ：リアルタイムのデータ分析、蓄積したデータを後で分析する
プロトコルの選択
• C言語、Java、JavaScript
• .NET、Perl、PHP、Python
（IBMサポート外）
MQTT、JMS（Pub/Sub）、MQ
13
クライアント設計
外部システム連携方式の決定
ユーザ/グループ定義設計
ブローカー
MessageSightオブジェクト定義設計
サブスクライバー / パブリッシャー
外部連携設計
物理設計
アプリケーション開発言語が決まるため、開発要員のスキルも考慮が必要
通信ヘッダのオーバーヘッドが、NWを流れるデータ量に影響
© 2014 IBM Corporation
トポロジーパターン
MessageSight をブローカーに採用する場合の構成パターン
MQTTアプリケーション同士の連携
クライアント ⇔ MessageSight ⇔ バックエンドシステム
クライアント
アプリ
サーバー
アプリ
MQTT
MQTT
クライアント
アプリ
パブリッシャー / サブスクライバーのプロトコルはMQTT
14
MQTT
クライアント ⇔ MessageSight ⇔クライアント
クライアント
アプリ
MQTT
新規にMQTTアプリケーションを作成する
MessageSight との接続情報はアプリケーション内で指定
MessageSight 上に接続設定が必要
© 2014 IBM Corporation
トポロジーパターン
APサーバーとの連携
クライアント ⇔ MessageSight ⇔ バックエンドシステム(APサーバー)
JMS
クライアント
アプリ
MQTT
MQTT
WAS
サーバー
アプリ
DB
アプリケーション視点： プロトコルはMQTT, JMS
Webアプリケーションの場合、MQTTで作成すればクライアント側と開発言語が統一できる
JMSでは、MessageSight がJMSプロバイダーになる
インフラ視点（JMS）
15
Fan-in（データ収集）の場合は、MDBにてサブスクライブして待ち受けることが容易にできる
APサーバー側でMessageSight をJMSプロバイダーとして設定
MessageSight 上にJMSプロトコル利用を設定（MessageHub）
© 2014 IBM Corporation
トポロジーパターン
MQとの連携
クライアント ⇔ MessageSight ⇔ バックエンドシステム(MQ)
クライアント
アプリ
MQ
サーバー
アプリ
MessageSight がMQクライアントとして、MQサーバーに接続
MQアプリケーションは、P2P、Pub/Sub どちらのMQIも利用可能
P2P:MQPUT/MQGET、PubSub:MQPUB/MQSUB/MQGET
インフラ視点（MQ）
MessageSight 上にMQコネクションを設定
MessageSightでMQTT⇔MQ 変換のためのマッピング・ルールを設定
16
MQ
アプリケーション視点： プロトコルはMQ
MQTT
MessageSight上でプロトコル変換
MQサーバー側でMessageSight 接続を設定（サーバー接続チャネル）
© 2014 IBM Corporation
トポロジーパターン
ESBとの連携
クライアント ⇔ MessageSight ⇔ バックエンドシステム(IIB)
SOAP/HTTP
JMS
クライアント
アプリ
MQTT
MQ
既存システム
（Webサービス）
IIB
メッセージフロー
外部システム
DB
アプリケーション視点： プロトコルはJMS、MQ
17
ESB(IIB)を経由することで、既存アプリケーションは追加・変更なしに連携できる
IIB提供の入出力ノード（部品）を利用して、容易にデータを送受信可能
JMS
： MessageSight がJMSプロバイダーになる
MQ
： MessageSight がMQクライアントとして、MQサーバーに接続
インフラ視点
JMS
MQ
： IIB側にMessageSight が提供するJMS Classファイルを導入
： IIB側にMessageSight をJMSプロバイダーとして設定
： MessageSight 上にJMSプロトコル利用を設定（MessageHub）
： MessageSight 上にMQコネクションを設定
： MessageSightでMQTT⇔MQ 変換用のマッピング・ルールを設定
MQサーバー側でMessageSight 接続を設定（サーバー接続チャネル）
© 2014 IBM Corporation
トポロジーパターン
ストリームデータ処理（InfoSphere Streams）との連携
クライアント → MessageSight → バックエンドシステム(Streams)
クライアント
アプリ
MQTT
MQTT
Streams
サーバー
アプリ
DB
ストリームデータ処理により、リアルタイムなデータ分析と予測が可能
大量のパブリッシュ・データを複合イベントとして処理
プロトコルはMQTT
18
データを抽出、結合して、必要なデータのみをバックエンドシステムに連携
時系列データの平均値、最大値の計算など
SPL（Streams Processing Language）言語
Streams のMQTTアダプタを利用
© 2014 IBM Corporation
可用性構成（参考）
トポロジー構成が決まったら、可用性構成を検討する
MessageSight のHigh Availability構成
Primary と Standby のペアにより構成
Primary がメッセージを処理
Standby は Primaryと同一の構成
データの複製は同期的に行われる
メッセージと構成情報をメモリー上で高速に同期（RoCE）注
Primary
Memory Replication
Standby
注）RoCE （RDMA over Converged Ethernet）： ロスレスのEthernet規格拡張
RDMA（Remote Direct Memory Access）：CPUの干渉なしに直接メモリアクセス
19
© 2014 IBM Corporation
論理設計
ここでは、MQTTとしての設計を行う
20
© 2014 IBM Corporation
論理設計
システムグランドデザイン
要件整理
設計パターンの整理
トポロジー設計
論理設計
トピック/ペイロード設計
パブリッシャー設計
サブスクライバー設計
外部連携設計
１．トピック/ペイロード設計
物理設計
MessageSightオブジェクト定義設計
ユーザ/グループ定義設計
クライアント設計
外部連携設計
•
•
送受信されるペイロードの設計
トピック構造の設計
２．パブリッシャー設計
•
Pub/Sub連携における送信アプリケーションの設計
３．サブスクライバー設計
•
Pub/Sub連携における受信アプリケーションの設計
４．外部連携設計
•
21
バックエンドシステム連携の設計
© 2014 IBM Corporation
トピック/ペイロード設計における基本事項
システムグランドデザイン
要件整理
設計パターンの整理
トポロジー設計
論理設計
トピック/ペイロード設計
パブリッシャー設計
サブスクライバー設計
外部連携設計
物理設計
MessageSightオブジェクト定義設計
ユーザ/グループ定義設計
送受信情報
クライアント設計
外部連携設計
トピック・ストリング ・・・・・ パブリッシュ/サブスクライブされる情報を識別する文字列
ペイロード（メッセージ） ・・・・ データそのもの。バイナリー・データとして扱われる
パブリッシャー
Pub/Subブローカーに対して、トピック・ストリングを指定して、メッセージをパブリッシュ
サブスクライバー
Pub/Subブローカーに対して、トピック・ストリングを指定してサブスクライブ
Pub/Subブローカーから、トピック・ストリングとペイロードを受信
サブスクライブ
XXX/YYY/#
トピック
トピック・ストリング
ペイロード
BRK
S
サブスクライバー
ペイロード：Hello!!
トピック：XXX/YYY/ZZZ
ブローカー
サブスクライバーの受信情報
22
© 2014 IBM Corporation
トピック/ペイロード設計
トピック・ストリングの目的
送受信するペイロードを分類する
サブスクライバーが欲しい情報を的確に指定できるようにする
トピックの設計指針
送受信する”データ構造”を考え、何をトピックにするかを決定する
サブスクライバーが欲しい情報だけを入手できる構造
分類目的では必要最小限が妥当
トピック設計による影響
構造が大雑把だと
構造が細かいと
欲しい情報が複数のトピックにまたがり、複数のサブスクライブをする必要がある
階層が多いと
23
欲しい情報だけでなく、不要な情報も送られ、受信側で選別する必要が出てくる
トピック・ストリングとして流れるデータ量が多くなる
トピック指定がわかりにくくなる
© 2014 IBM Corporation
トピック/ペイロード設計
パターン別の設計ポイント
パターン
パターン小分類
設計ポイント
1:1
Point-to-Point
受け取るべきサブスクライバー以外が受け取らない仕組みが必要
・サブスクライバー単位のトピック
Fan-in
パブリッシャーが誰かを知る必要がある場合はその仕組みが必要
・パブリッシャー単位のトピック
・ペイロードにパブリッシャー情報を付加
すべてのメッセージを１つのサブスクライバーが受け取るか
・負荷分散方式の検討
Fan-out
最も多くのサブスクライバーがサブスクライブしたい情報の塊は何か
・トピック・ストリングの構造
Any-to-Any
複数のパブリッシャーのペイロードの種類
必要なメッセージを入手できるトピック・ストリングの粒度
1:N
リクエスト＆リプライ
24
リプライのリクエストへの紐付けはどうするか
・リクエストに識別子が必要
・リクエスト識別子単位のリプライ用トピック
・ペイロードにリクエスト識別子を含める
リプライが誰からのものか知る必要がある場合はその仕組みが必要
© 2014 IBM Corporation
トピック/ペイロード設計
トピックおよびペイロードを設計する手順の流れを示す
将来の構造修正を最小化するための検討である
メッセージを選択する
条件項目を決める
ペイロードを決める
1
•
送るペイロードに含めるデータ
とその構造を決定する
•
5
整合性を確認し、必要が
あれば見直す
•
トピック・ストリングの
構造を決定する
•
25
2
トピック・ストリングを構成する
各項目の順序を決定する
4
サブスクライバーの視点で、受け
取るデータを絞り込むための条
件を決める
決まったトピック・ストリングを
もとにペイロードを見直す
3
拡張性を考慮して
項目を追加する
•
後々追加される要件も考慮し、
変更が最小限になるようあらかじ
め追加項目を検討する
© 2014 IBM Corporation
トピック/ペイロード設計の流れ
1
STEP1 ペイロードを決める
ペイロードに含める要素を決める
パブリッシャー、サブスクライバー間で連携したい情報を列挙
文字もバイナリも可能
１つのペイロードに入れるか、別のペイロードにするか検討
組み合わせ（セットになる）要素は、１つのペイロードに収める
２つのトピックのデータに組み合わせであることを明示できない
独立の要素が、独立のタイミングで発生する場合には、別々のペイロードとする
A1
P
A2
A3
A4
B2
B1
S
どのAとどのBがセ
ットなんだ？
A情報とB情報を送るよ
P
26
A0-B1 A1-B1
A2-B1 A3-B1
A3-B2
A4-B2
S
どのタイミングで
変わったんだ？
© 2014 IBM Corporation
トピック/ペイロード設計の流れ
送信者情報は必要か
１つのトピックに複数のパブリッシャーがパブリッシュする場合（Fan-inパターン）
トピックストリングに依存
他のメッセージとの紐付け情報は必要か
リクエストに対するリプライの場合など
日付、時刻、場所などの情報は必要か
送信データが時刻依存である場合、トピック・ストリングに時刻情報がなければ必要
接続オプションによっては、即時に受け取るとは限らない
だれから送信されたか
知りたい・・・
S
P
cust001
P
cust002
P
cust003
P
cust004
response
自分が送ったリクエスト“req001”に対して、
クライアント“cust001”からの応答だな！
27
1
STEP1 ペイロードを決める（つづき）
送信者、時刻、リクエストIDのある例
<message>
<sender>cust001</sender>
<requestid>req0001</publisher>
<date>2014/04/09</date>
<time>11:11:11</time>
<response>150</response>
</message>
© 2014 IBM Corporation
トピック/ペイロード設計の流れ
1
STEP1 ペイロードを決める（つづき）
構造を決める
XML、CSV、固定長データなど
要因１：アプリケーションの要件
要因２：MQTTデバイス要件
既存アプリケーション、連携アプリケーション
処理能力、通信帯域、電力消費量
要因１と要因２のバランスが取れない場合は、連携ミドルウェア等で変換
SOAPは送らないんだ
が・・・・
SOAPならそのまま受
け取れるんだが・・・・
JMS
クライアント
アプリ
MQTT
Pub/Sub
ブローカー
MQ
SOAP/HTTP
既存システム
（Webサービス）
IIB
メッセージフロー
外部システム
私がSOAPに変換
しましょう
28
DB
© 2014 IBM Corporation
トピック/ペイロード設計の流れ
2
STEP2 メッセージを選択する条件項目を決める
サブスクライバーが必要なメッセージのみを受信できるように条件項目を選択
条件項目が細か過ぎると、複数のサブスクライブを発行しなければならない
条件項目が粗すぎると、欲しいデータ以外のデータも受け取ることになる
サブスクライバーが受け取った後、必要なデータを選別する必要が発生する
必要ないデータのために通信量が増える
中央区に関するデータがほしい
P
箱崎
箱崎
箱崎
XXX
XX
XX
中央区に関するデータ
をそろえるためには・・・
箱崎、XXXを条件に指定
P
P
中央区
中央区
東京都の各地に関す
るデータを送信
29
港区
中央区
新宿区
渋谷区
中央区
中央区
中央区
S
中央区
中央区
箱崎
XXX
S
S
中央区
港区
選別
渋谷区
目黒区 新宿区
中央区
中央区
中央区
中央区だけ
ほしい
© 2014 IBM Corporation
トピック/ペイロード設計の流れ
2
STEP2 メッセージを選択する条件項目を決める（つづき）
サブスクライブできる人を特定したい場合は、トピックに条件項目を追加する
（例）スポーツ大会での選手と事務局との連絡/通知アプリケーション
P
S
001
S
002
S
101
S
102
S
renraku
P
S
S
・個々の選手への連絡を選手番号宛にパブリッシュ
・特定の選手への配信ができない
パブリッシャーを特定したい場合、トピックまたはペイロードにパブリッシャー情報を含める
P
S
ペイロードに
パブリッシャー
情報
001
P
002
P
P
101
P
P
102
P
P
renraku
・選手側からの通知に利用する場合は、
ペイロードに選手情報を含めることで可能
30
S
S
自分自身の
トピックに対し
てパブリッシュ
・選手は自分専用のトピックに通知をパブリッシュする
ことで、事務局側はだれからの通知か認識できる
© 2014 IBM Corporation
トピック/ペイロード設計の流れ
3
STEP3 拡張性を考慮して項目を追加する
ルート要素は、１つである必要はない
後々追加する処理も想定して、分離できるようにトピック項目を追加
今は１種類だが、将来は複数になる場所がキーポイント
東京オリンピック以外の
開催でも利用しよう
tennis
001
31
tokyo
tennis
100m
100m
men
women
men
men
women
men
result
result
result
result
result
result
002
101
102
002
001
002
101
102
002
© 2014 IBM Corporation
トピック/ペイロード設計の流れ
STEP4 トピック・ストリングの構造を作成する
決まった条件項目（トピック項目）を並べて順序を決定
完全はない。より多くの場合によい結果を生むように決定
サブスクライバーがまとめてサブスクライブすると想定される項目を上位にする
マルチレベル・ワイルドカード(#)のほうが、単一レベル・ワイルドカード(+)より効率がよい
テニスの結果が知りたい
tennis/#
tennis
001
男子の結果が知りたい
men/#
どっちが主流か・・・・
men
100m
wemen
men
women
men
tennis
100m
tennis
result
result
result
result
result
result
002
101
102
男子の結果が知りたい
+/men/#
32
4
002
001
002
101
102
002
テニスの結果が知りたい
+/tennis/#
© 2014 IBM Corporation
トピック/ペイロード設計の流れ
STEP4 トピック・ストリングの構造を作成する（つづき）
同じレベルの項目は、トピック・ストリング上も同じレベルになるようにする
1度のサブスクライブで要求できるように
でも、男子の項目を入れれば、
例えば、”すもう”には男子しかな
いので・・・・
tennis
001
sumou
tennis
sumou
men
women
result
men
women
men
result
result
002
result
result
result
002
101
102
男子の結果が知りたい
+/men/#
では、すもうはもれてしまう
33
4
001
+/men/#
Sumou/#
の２回のサブスクライブ
002
101
102
002
+/men/#
の１回のサブスクライブで
可能
© 2014 IBM Corporation
トピック/ペイロード設計の流れ
5
STEP5 トピック・ストリングとペイロードの整合性を確認し、必要があれば見直す
トピック・ストリングの設計の結果、ペイロードに影響が出ていれば修正
ペイロードの情報の一部が、トピック・ストリングの項目として出た場合
この部分をどうするか
トピック・ストリング
ペイロード
サブスクライバーの受信情報
34
基本的に、重複を取り除く （情報量の観点から重複は無駄）
但し、問題検知のため１項目程度、冗長にしておく（重ねる）のが理想
ペイロードを修正したあと、そのペイロードでトピック・ストリングに影響がないか確認
© 2014 IBM Corporation
システムグランドデザイン
パブリッシャー設計
要件整理
設計パターンの整理
トポロジー設計
論理設計
トピック/ペイロード設計
パブリッシャー設計
サブスクライバー設計
要件から設計要素にマッピングする
外部連携設計
物理設計
MessageSightオブジェクト定義設計
ユーザ/グループ定義設計
クライアント設計
外部連携設計
35
検討内容
設計内容
ブローカーの宛先はどこか？冗長構成にするか
宛先制御方法
自分を一意に指定する名前は何か
クライアントID
パブリッシュする宛先はどこか
トピック・ストリング
接続完了までどれくらい待てるか
接続タイムアウト値
接続の切断をすばやく検知したいか
KeepAlive値
ユーザー認証を行うか
ユーザー名、パスワード
送信する情報は見られたらまずいか
SSLの利用
接続が切れたとき何か通知したいか
遺言メッセージを使用
メッセージの保証はどうするか
QoSの値
後からサブスクライブしたクライアントにも、
最新のメッセージを送りたいか
リテイン・メッセージの使用
© 2014 IBM Corporation
パブリッシャー設計
① 後からサブスクライブしたクライアントにも、直近のメッセージを送るか
送る場合
“リテイン”を指定する
パブリッシャー
ブローカー サブスクライバー
メッセージA
•
•
サブスクライバーがそのトピックをサブスクライブすると、必ず１
度メッセージを受け取る
状態を保持するトピックへのパブリッシュに有効
送らない場合
サブスクライブ
メッセージA
メッセージB
“リテイン”を指定せず
パブリッシャー
•
•
•
36
メッセージB
メッセージがパブリッシュされたトピックに、その時接続している
サブスクライバーだけが受け取る
サブスクライバーがそのトピックをサブスクライブすると、その後
にパブリッシュされたメッセージを受け取る
過去の情報には意味がないトピックへのパブリッシュに有効
ブローカー サブスクライバー
メッセージA
サブスクライブ
メッセージB
メッセージB
© 2014 IBM Corporation
パブリッシャー設計
② メッセージの保証をどうするか
届かない場合があっても許容できる場合
•
•
１度だけ送信する。届かない場合もありうる。届かない場合も検知できない
効率を良くしたい場合や、送信しなおして遅れて届いても無意味または後の送信メッセージで補完できる場
合に有効
届かないことは許容できないが、２度届くことは許容できる場合
•
•
•
QoS=0
必ず１回は届ける。複数回届くこともありうる。届かない場合はエラーとして検知する
サブスクライバーが重複受信を想定する必要がある
効率は良くしたいが、メッセージが欠けることは許されない場合に有効
届かないことも、２度届くことも許容できない場合
•
•
QoS=1
QoS=2
必ずちょうど１回届ける。複数回届くこともはなく、届かない場合はエラーとして検知する
かなり効率が落ちることを想定する必要がある
（送達保証のため、送り側と受け側の間を２往復の通信が発生する）
37
© 2014 IBM Corporation
パブリッシャー設計
② メッセージの保証をどうするか（つづき）
パブリッシャーでは、さらに以下の点を考慮し、QoSを何にするか決定する
メッセージは、どのような情報か（状態なのか差分なのか）
QoSの指定は、メッセージ単位である
指定するQoSの指定は、パブリッシャー・サーバー間の指定であり、サブスクライバー
にこのQoSで届くとは限らない
サブスクライバーが受け取るメッセージのQoSは、サブスクライバーが指定
但し、パブリッシャーが指定したQoSより大きくなることはない
サブスクライブ（QoS=2）
パブリッシュ（QoS=1）
BRK
P
S
受信メッセージ（QoS=1）
サブスクライブ（QoS=0）
パブリッシュ（QoS=1）
P
BRK
S
受信メッセージ（QoS=0）
38
© 2014 IBM Corporation
システムグランドデザイン
サブスクライバー設計
要件整理
設計パターンの整理
トポロジー設計
論理設計
トピック/ペイロード設計
パブリッシャー設計
サブスクライバー設計
要件から設計要素にマッピングする
外部連携設計
物理設計
MessageSightオブジェクト定義設計
ユーザ/グループ定義設計
クライアント設計
外部連携設計
39
検討内容
適用内容
ブローカーの宛先は？冗長構成にするか
宛先制御方法
自分を一意に指定する名前は何か
クライアントID
サブスクライブする宛先はどこか？複数あるか
ワイルドカードで指定できるか
トピックストリング
接続完了までどれくらい待てるか
接続タイムアウト値
接続の切断をすばやく検知したいか
KeepAlive値
ユーザー認証を行うか
ユーザー名、パスワード
受信する情報は見られたらまずいか
SSLの利用
接続が切れたとき何か通知したいか
遺言メッセージを使用
メッセージの保証はどうするか
QoSの値
切断している最中にパブリッシュされたメッセージも、再接続後
に受け取りたいか
デュラブル・サブスクリプション
© 2014 IBM Corporation
サブスクライバー設計
① 接続が切れている間のメッセージをどうするか
パブリッシャー
再接続時に受け取りたい場合
ブローカー サブスクライバー
メッセージA
サブスクライブ
メッセージA
デュラブル・サブスクリプション
•
•
•
（永続サブスクリプション）
ノン・デュラブル・サブスクリプション
•
•
切断
接続
接続が切れても、サブスクライブは保持される方法
１度サブスクライブしたトピックへのメッセージは、切断中も保持
されていて、再接続時に受け取ることができる
遅れても、すべてのメッセージを受け取りたい場合に有効
接続がきれている間のメッセージはいらない場合
•
メッセージB
メッセージC
メッセージB
メッセージC
パブリッシャー
ブローカー サブスクライバー
メッセージA
（非永続サブスクリプション）
接続が切れると、サブスクライブ自体も消去される方法
切断中にパブリッシュされたメッセージは受け取ることができない
遅れて受け取っても意味がない場合に有効
サブスクライブ
メッセージA
メッセージB
切断
接続
メッセージC
サブスクライブ
メッセージC
（注意）デュラブル・サブスクリプションの指定は“サブスクリプション”単位ではなく、“接続”単位なので、１つ
の接続中の複数サブスクリプションの設定を異なるものにはできない
再接続時に、再度デュラブル・サブスクリプションを指定しない場合、保持していたメッセージは破棄される
40
© 2014 IBM Corporation
サブスクライバー設計
② メッセージの保証をどうするか
サブスクライバーでも、パブリッシャーと同様にQoS決定
届かない場合があっても許容できる場合
届かないことは許容できないが、２度届くことは許容できる場合
届かないことも、２度届くことも許容できない場合
QoS=0
QoS=1
QoS=2
但し、サブスクライバーの場合、以下の点を考慮
•
•
QoSの指定は、サブスクライブ単位である
指定するQoSの指定は、ブローカー、サブスクライバー間の指定であり、サブスクライバーにこの
QoSで届くとは限らない
サブスクライバーが受け取るメッセージのQoS
41
パブリッシャーが
指定するQoS
サブスクライバーが指定するQoS
QoS=0
QoS=1
QoS=2
QoS=0
QoS=0
QoS=0
QoS=0
QoS=1
QoS=0
QoS=1
QoS=1
QoS=2
QoS=0
QoS=1
QoS=2
© 2014 IBM Corporation
サブスクライバー設計
③ 全体構造
サブスクライブ
（トピックA）
複数のサブスクライブが必要になる場合
１つのトピック・ストリングで必要なサブスクライブができな
い場合
デュラブル・サブスクリプションなど接続単位の設定は、
複数のサブスクリプションすべてに適用されることを留意
BRK
サブスクライブ
（トピックB）
複数の接続が必要になる場合
サブスクライブ毎に設定を変えたい場合（デュラブル・サ
ブスクリプションなど）
クライアントIDは異なるものにする必要がある
サブスクライブ
（トピックA）
負荷分散が必要になる場合
42
S
S
BRK
サブスクライブ
（トピックB）
S
１つのサブスクライバーですべてのメッセージの処理がで
きない場合
共用サブスクリプション、MQコネクティビティを利用
（外部連携を参照）
© 2014 IBM Corporation
要件整理
システムグランドデザイン
外部システム連携設計
設計パターンの整理
トポロジー設計
論理設計
トピック/ペイロード設計
パブリッシャー設計
サブスクライバー設計
連携方向
外部連携設計
物理設計
MessageSightオブジェクト定義設計
ユーザ/グループ定義設計
•
•
クライアント設計
Pub/Subブローカーからバックエンドシステムへ（Fan-in）
バックエンドシステムからPub/Subブローカーへ（Fan-out）
外部連携設計
連携方式
Fan-outの場合、1toN （ Pub/Subブローカーまでは1to1）
Fan-inの場合、複数の方式が可能
1to1 ・・・・・・・・・ １つのバックエンドシステムが受け取り処理する
1toN ・・・・・・・・・ 複数のバックエンドシステムが同時に受け取り、それぞ
れの処理をする。後から追加することも容易
負荷分散 ・・・・・ 複数のバックエンドシステムのうち１つだけが受け取り処
理する（1to1）
P
P
P
P
P
43
P
P
BRK
1:1
S
P
BRK
S
S
P
P
P
P
1:N
S
BRK
S
負荷分散
© 2014 IBM Corporation
物理設計
ここでは、MessageSightへの実装を考慮した設計を行う
44
© 2014 IBM Corporation
物理設計
要件整理
システムグランドデザイン
設計パターンの整理
トポロジー設計
論理設計
トピック/ペイロード設計
パブリッシャー設計
サブスクライバー設計
１．MessageSightオブジェクト定義設計
外部連携設計
物理設計
MessageSightオブジェクト定義設計
ユーザ/グループ定義設計
•
•
クライアント設計
MessageSightへのアクセス方法の定義設計
MessageHub内のEndpointと各ポリシーの構成でのアクセス制御設計
外部連携設計
２．ユーザ/グループ定義設計
•
•
認証・認可の元データとなるユーザー/グループの定義設計
LDAPまたは、MessageSightローカルの定義設計
３．クライアント設計
•
クライアントとなるパブリッシャーまたはサブスクライバー・アプリケーションの設計
４．外部連携設計
•
バックエンドシステムとのメッセージ連携の設計
その他
•
•
45
通信経路設計（SSL,証明書等）
運用・監視設計
© 2014 IBM Corporation
システムグランドデザイン
MessageSightオブジェクト
要件整理
設計パターンの整理
トポロジー設計
論理設計
トピック/ペイロード設計
パブリッシャー設計
サブスクライバー設計
外部連携設計
MessageSightに定義するオブジェクトの包含関係
物理設計
MessageSightオブジェクト定義設計
ユーザ/グループ定義設計
クライアント設計
外部連携設計
MessageSight
MessageHub
Endpoint
(NIC,Port)
Messaging
Messaging
Policy
Messaging
Policy
Policy
46
Endpoint
(NIC,Port)
接続
Connection
Policy
Connection
Policy
Endpoint
(NIC,Port)
接続
Messa
ging
Policy
Conne
ction
Policy
© 2014 IBM Corporation
MessageSightオブジェクト設計
4つのオブジェクトの設定方法
オブジェクト
設定方法
MessageHub
・定義体の入れ物。アプリケーション単位に作成がお勧め
・EndPointはそのMessageHub内のどのPolicyも利用可
（Endpointは他のMessageHubのPolicyは参照不可）
・MessageHubをまたがってトピックはアクセスされる
Endpoint
・NIC（IPアドレス）およびポート毎の定義体
（どのNICのどのポートからのリクエストを受け付けるかを指定）
・１つのMessageHub内に複数定義可能
MessagingPolicy
・誰が、どの宛先（トピック/キュー）に、どうアクセスできるかを指定
・宛先は、トピック/キューの別、その名称（ワイルドカード可）を指定
ConnectionPolicy
・誰が接続できるかを指定
設計順序
MessageHub
47
Endpoint
Connection
Policy
Messaging
Policy
© 2014 IBM Corporation
MessageSightオブジェクト定義
各オブジェクトの定期項目と定義内容
オブジェクト
定義項目
MessageHub
名前
任意名称
ConnectionPolicy
名前
任意名称
クライアント制限
MessagingPolicy
IP address、ClientId、UserId、
GroupId、CertificateName、
Protocol（JMS/MQTT)
定義内容
有無とその値
名前
任意名称
宛先タイプ
Topic/Queue/Globalshared Subscription
認可
Publish、Subscribe、Send、
Receive、Browse、Control
有無
非接続クライアント通
知
有無
宛先
認可文字列
最大メッセージ数
数値
クライアント制限
48
サブ定義項目
IP adress、ClientId、UserId、
GroupId、CertificateName、
Protocol（JMS/MQTT)
有無とその値
© 2014 IBM Corporation
MessageSightオブジェクト定義
各オブジェクトの定期項目と定義内容
オブジェクト
定義項目
サブ定義項目
EndPoint
名前
任意名称
有効フラグ
有効無効
ポート
受付ポート番号
IPアドレス
受付IPアドレス（ALL選択可）
プロトコル
JMS、MQTT
定義内容
有無
最大メッセージサイズ
数値
SecurityPolicy
定義済みセキュリティポリシーから選択
ConnectionPolicy
定義済みセキュリティポリシーから選択
MessagingPolicy
定義済みセキュリティポリシーから選択
定義順序は下図の順が効率がよい
MessageHub
49
Connection
Policy
Messaging
Policy
Endpoint
© 2014 IBM Corporation
MessageSightオブジェクト定義
MessagingPolicyでのトピック指定
ワイルドカード “*” を使った指定が可能
３つの変数を使用可能
${UserID}
${ClinetID}
${CommonName} （SSL証明書使用時）
item
【例】ユーザー毎にトピックを用意する場合、トピックにUserId
を含めることで、認可定義が容易
• item/tracking/tp${UserID}
tracking
tpuser1
tpuser2
tpuser3
tpuser4
•
UserId：user1さんは、item/tracking/tpuser1にアクセス可能
ClientIdとUserId
ClientId ・・・・・ 接続を区別するためのId。１つのUserIdで複数のClientId可
クライアント全体でユニークである必要がある
クライアントが任意に設定できるので、認可には不向き
UserId ・・・・・・ 認証・認可に使用するユーザー識別のId
50
© 2014 IBM Corporation
要件整理
システムグランドデザイン
ユーザー/グループ設計
設計パターンの整理
トポロジー設計
論理設計
トピック/ペイロード設計
パブリッシャー設計
サブスクライバー設計
外部連携設計
物理設計
MessageSightオブジェクト定義設計
ユーザ/グループ定義設計
ユーザーIDで認証を行う場合に必要
外部連携設計
通信経路でSSLを行う場合でも、サーバー認証のみ行い、クライアント認証は
ユーザーID/パスワードで行うことが多い
MessageSightオブジェクトで、ユーザーIDまたはグループIDで認可を行うこと
が可能
オブジェクト
定義項目
定義内容
ユーザー
ユーザーID
任意ID
グループ・メンバーシップ
グループ定義から選択
パスワード
任意文字列
グループID
任意ID
グループ・メンバーシップ
グループ定義から選択 （階層化が可能）
グループ
51
クライアント設計
© 2014 IBM Corporation
システムグランドデザイン
パブリッシャー設計
要件整理
設計パターンの整理
トポロジー設計
論理設計
トピック/ペイロード設計
パブリッシャー設計
パブリッシャーの処理の流れ
サブスクライバー設計
外部連携設計
物理設計
MessageSightオブジェクト定義設計
ユーザ/グループ定義設計
クライアント設計
外部連携設計
接続
トピック指定
•
MQTTサーバー（Pub/Subブローカー）に、
各種オプションを指定して接続
•
メッセージを送りたいトピックを指定
複数のトピックを指定することも可能
•
•
メッセージ
送信
•
•
メッセージをトピックに対して送信
そのトピックに複数のメッセージを送ることも可能
別のトピックに対して別または同じメッセージを送ることも可
能（繰り返し）
凡例
繰り返し範囲
52
© 2014 IBM Corporation
パブリッシャー設計
パブリッシャーに対する要件に合わせた設計
検討内容
適用内容
適用先
宛先制御方法
URL（address:port）
接続
クライアントID
ClientId
接続
トピックストリング
Topic
トピック
接続タイムアウト値
ConnectionTimeout
接続
KeepAlive値
KeepAliveInterval
接続
ユーザー名、パスワード
UserName
UserPassword
接続
SSLの利用
SSLproperty
接続
遺言メッセージを使用
Will指定
接続
QoSの値
QoS指定
メッセージ
リテインメッセージ
Retained指定
メッセージ
53
© 2014 IBM Corporation
【参考】パブリッシャー設計 ～ コード・イメージ
package com.ibm.mq.id;
import org.eclipse.paho.client.mqttv3.*;
public class PubAsync {
public static void main(String[] args) {
try {
MqttClient client = new MqttClient("tcp://192.168.11.11:16102”, "clientId001");
MqttTopic topic = client.getTopic(“test");
MqttMessage message = new MqttMessage("Hello World“.getBytes());
message.setQos(1);
message.setRetained(true);
リテイン・パブリケーション
CallBack callback = new CallBack("clientId001");
client.setCallback(callback);
MqttConnectOptions option = new MqttConnectOptions();
option.setKeepAliveInterval(60);
option.setConnectionTimeout(10000);
option.setUserName(“username”);
option.setPassword(“password”.toCharArray());
client.connect(option);
MqttDeliveryToken token = topic.publish(message);
if (client.isConnected()) client.disconnect(10000);
} catch (Exception e) {
e.printStackTrace();
}
接続先を指定
トピックを指定
ペイロードをを指定
メッセージ・オプションを指定
接続オプションを指定
接続
パブリッシュ
接続を解除
}
}
54
© 2014 IBM Corporation
【参考】パブリッシャー設計 ～ コード・イメージ
コールバック用クラス（CallBack.java）
package com.ibm.mq.id;
import org.eclipse.paho.client.mqttv3.MqttClient;
public class CallBack implements MqttCallback {
private String instanceData = "";
コールバックの定義
public CallBack(String instance) {
instanceData = instance;
}
public void messageArrived(MqttTopic topic, MqttMessage message) {
メッセージ受信時の処理
// メッセージ受信時の処理。メッセージを受信してそのハンドリング
}
public void connectionLost(Throwable cause) {
接続が切れた時の処理
// コネクションが切れたときの処理（再接続など）
}
public void deliveryComplete(MqttDeliveryToken token) {
パブリッシュが完了した時の処理
// メッセージのパブリッシュが完了した時の処理
}
}
55
© 2014 IBM Corporation
サブスクライバー設計
サブスクライバーの処理の流れ
接続
トピック指定
サブスクライブ
メッセージ
受信
•
MQTTサーバー（Pub/Subブローカー）に、
各種オプションを指定して接続
•
•
メッセージを受け取りたいトピックを指定
複数のトピックを指定することも可能
ワイルドカードを使ってトピックを指定することも可能
•
トピックに対してサブスクライブを送信
•
メッセージ（ペイロード）と、そのメッセージがパブリッシュされた
トピックストリングを受信
アンサブスクライブするまで受信（繰り返し）
•
•
凡例
繰り返し範囲
56
© 2014 IBM Corporation
サブスクライバー設計
サブスクライバーに対する要件に合わせた設計
検討内容
適用内容
適用先
宛先制御方法
URL（address:port）
接続
クライアントID
ClientId
接続
トピックストリング
Topic
サブスクライブ
接続タイムアウト値
ConnectionTimeout
接続
KeepAlive値
KeepAliveInterval
接続
ユーザー名、パスワード
UserName
UserPassword
接続
SSLの利用
SSLproperty
接続
遺言メッセージを使用
Will指定
接続
QoSの値
QoS指定
サブスクライブ
デュラブル・サブスクリプション
CleanSession指定
接続
57
© 2014 IBM Corporation
【参考】サブスクライバー設計 ～ コード・イメージ
package com.ibm.mq.id;
import org.eclipse.paho.client.mqttv3.MqttClient;
public class SubAsync {
public static void main(String[] args) {
try {
MqttClient client = new MqttClient("tcp://192.168.11.11:16102", "clientId001");
CallBack callback = new CallBack("clientId001");
client.setCallback(callback);
MqttConnectOptions option = new MqttConnectOptions();
option.setCleanSession(false);
option.setKeepAliveInterval(60);
デュラブル・サブスクリプション
option.setConnectionTimeout(10000);
option.setUserName(“username”);
option.setPassword(“password”.toCharArray());
client.connect(option);
client.subscribe(“test”, 1);
Thread.sleep(30000);
client.disconnect();
} catch (Exception e) {
e.printStackTrace();
}
接続先を指定
非同期呼び出しプログラム設定
接続オプションを指定
接続
サブスクライブ
（トピック、QoSの指定）
接続を解除
}
58 }
© 2014 IBM Corporation
外部システム連携設計
システムグランドデザイン
要件整理
設計パターンの整理
トポロジー設計
論理設計
トピック/ペイロード設計
パブリッシャー設計
プロトコル別の設計
サブスクライバー設計
外部連携設計
物理設計
MessageSightオブジェクト定義設計
ユーザ/グループ定義設計
MQTT
クライアント設計
外部連携設計
クライアントがMQTTの場合と同様に構成
JMS(Pub/Sub)
MessageSightオブジェクト（エンドポイント、コネクション・ポリシー、メッセージング・
ポリシー）で、JMSを受け付けるよう設定
メッセージング・ポリシーで、操作（バブリッシュ、サブスクライブなど）の認可を設定
JMSアプリケーションでは、トピックを指定して、MessageSightに対してパブリッシュ
またはサブスクライブを実行
MQ
MessageSightのMQコネクティビティを設定
59
サブスクライバー
キュー Putter
パブリッシャー
キュー Getter
キューマネージャー・コネクションで、キューマネージャーを指定
デスティネーション・マッピング・ルールで、どこからどこに転送するかを指定
MQアプリケーションでは、通常のMQアプリケーションと同様に、キューに対して操作
© 2014 IBM Corporation
外部システム連携設計
負荷分散方式の設計
Fan-inパターンで、サブスクライバーであるサーバー側で負荷分散したい場合の連携方式
複数のサブスクライバーの１つがメッセージを受けとることの目的
負荷分散として機能させる（サブスクライバー側の意図）
Fan-in型のパターンで、サブスクライバーであるサーバー側の処理が１つではまかないきれない場
合など
メッセージ割り当てとして機能させる（パブリッシャー側の意図）
複数のサブスクライバー宛にパブリッシュするが、そのうちの１つに受け取ってもらいたい場合など
S
方法1の場合
パブリッシュ（リクエスト）
P
サブスクライブ
S
BRK
今、処理可能
リクエスト
席をはずすので、処理できない
から、サブスクライブしないよ
S
今、処理可能
負荷分散実現方法
方法１．JMS2.0による共用サブスクリプション
方法２．MQコネクティビティ
60
© 2014 IBM Corporation
外部システム連携設計（JMS）
JMS連携
JMS：J2EEにおける標準メッセージング・インターフェース
ポイント・ツー・ポイント、パブリッシュ/ サブスクライブ型をサポート
MQTTとの相違点
QoS(MQTT)とパーシステンシー(JMS)
共用サブスクリプション（JMS2.0のみ）
JMSからMQTTに送信した場合、
パーシステンシーがQoSに変換される
MQTTからJMSに送信した場合、
QoSがパーシステンシーに変換される
（パブリッシャーがJMS、サブスクライバーがMQTT）
（パブリッシャーがMQTT、サブスクライバーがJMS）
JMS ＼ MQTT
QoS=0
QoS=1
QoS=2
MQTT
JMS
NON-PERSISTENT
0
1
1
QoS=0
NON-PERSISTENT
PERSISTENT
0
1
2
QoS=1
PERSISTENT
QoS=2
PERSISTENT
（検証環境での確認結果）
61
© 2014 IBM Corporation
外部システム連携設計（JMS）
JMS連携の定義項目と定義内容
オブジェクト
定義項目
定義内容
コネクション
名前
任意名称
コネクション名
IPアドレスとポート番号
トピック名
トピック名
リテイン・メッセージ
指定の有無
デュラブル・サブスクリプション
指定の有無
JNDI
コンテキストファクトリー
コネクションファクトリー
プロバイダーURL
プロバイダー・ユーザーID
プロバイダー・パスワード
メッセージ
メッセージ型
TextMessage、ObjectMessage、
MapMessage、BytesMessage、
StreamMessage
パーシステンシー
パーシステント/ ノンパーシステント
ペイロード
送信する情報
※別途、JMS接続の認可設定がMessageSightに必要
62
© 2014 IBM Corporation
【参考】JMSパブリッシャー設計 ～ コード・イメージ
パブリッシュ用クラス (JMSPublish.java)
package com.ibm.mq.jms;
import javax.jms.*;
import com.ibm.ima.jms.*;
public class JMSPublish {
public static void main(String[] args) {
try {
ConnectionFactory connectionFactory =
ImaJmsFactory.createConnectionFactory(“tcp”,
“192.168.111.20, 16100”, “clientId001”);
Connection connection = connectionFactory.createConnection();
Session session = connection.createSession(false,
Session.DUPS_OK_ACKNOWLEDGE);
Destination dest = session.createTopic(“test/hoge/”);
MessageProducer producer = session.createProducer(dest);
producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);
TextMessage tmsg = session.createTextMessage(“hello World!”);
producer.send(tmsg);
connection.close();
} catch (JMSException e) {
//例外処理
} finally {
//クローズ処理
}
}
63
接続先を指定
接続の確立
セッションの確立
トピックを指定
送信オプションを指定
ペイロードをを指定
パブリッシュ
接続を切断
© 2014 IBM Corporation
【参考】JMSサブスクライバー設計 ～ コード・イメージ - 同期型
サブスクライブ用クラス (JMSSubscribe.java)
package com.ibm.mq.jms;
import javax.jms.*;
import com.ibm.ima.jms.ImaJmsFactory;
public class JMSSubscribe {
public static void main(String[] args) {
try {
ConnectionFactory connectionFactory=
ImaJmsFactory.createConnectionFactory(“tcp”,
“192.168.111.20”, 16100, “clientId001”);
Connection connection = connectionFactory.createConnection();
Session = connection.createSession(false,
Session.DUPS_OK_ACKNOWLEDGE);
Destination dest = session.createTopic(test/hoge/);
MessageConsumer consumer = session.createConsumer(dest);
connection.start();
Message msg = consumer.receive(10000);
//受信処理
} catch (Exception e) {
//例外処理
} finally {
//クローズ処理
}
}
}
64
接続先を指定
接続の確立
セッションの確立
トピックを指定
サブスクライブ
メッセージを受信
接続の切断
© 2014 IBM Corporation
【参考】JMSサブスクライバー設計 ～ コード・イメージ - 非同期型
サブスクライブ用クラス (AsyncJMSSubscribe.java)
package com.ibm.mq.jms;
import javax.jms.*;
import com.ibm.ima.jms.ImaJmsFactory;
public class AsyncJMSSubscribe implements MessageListener {
public static void main(String[] args) {
try {
ConnectionFactory connectionFactory =ImaJmsFactory
.createConnectionFactory(“tcp”, “192.168.111.20”,16100, “clientId001”);
Connection connection = connectionFactory.createConnection();
Session session=connection.createSession
(false,Session.DUPS_OK_ACKNOWLEDGE);
Destination dest = session.createTopic(“test/hoge/”);
MessageConsumer consumer = session.createConsumer(dest);
AsyncJMSSubscribe asyncReceiver = new AsyncJMSSubscribe();
consumer.setMessageListener(asyncReceiver);
connection.start();
for (int i = 0; i < 10; i++){
//メッセージの待ち受け処理
}
} catch (Exception e) {
//例外処理
}
}
@Override
public void onMessage(Message msg) {
//メッセージ受信処理
}
}
65
接続先を指定
接続の確立
セッション・オプションを指定
トピックを指定
サブスクライブ
接続の切断
メッセージ受信
© 2014 IBM Corporation
外部システム連携(JMS)
負荷分散方式： 共有サブスクリプション
JMS2.0からの新機能
共用サブスクリプションの種類
１つのコネクションを共用してサブスクリプションを共用（クライアントIDは１つ）
複数のスレッドでメッセージの処理を分散したい場合
複数のコネクションでサブスクリプションを共用（クライアントIDは複数）
複数のシステムでメッセージの処理を分散したい場合
JMSアプリケーションでは
共有サブスクリプションのためのメソッドを利用
負荷分散の対象から外す場合、サブスクリプションをアン・サブスクライブ
MessageSight
Message1
Publisher
JMS Subscriber
S
JMS Subscriber
S
JMS Subscriber
Message1
P
Message2
66
Topic
S
Message2
© 2014 IBM Corporation
【参考】サブスクライバーの分類
MessageSightでのサブスクライバーの種類
67
検討内容
特徴
プロトコル
（非共有）ノンデュラブル・
サブスクリプション
・通常のサブスクリプション
MQTT
JMS
（非共有）デュラブル・
サブスクリプション
・通常のデュラブル・サブスクリプション
MQTT
JMS
プライベート共有ノンデュラブル・
サブスクリプション
・１つのコネクションを共用した同一のサブスクリプション
・クライアントIDは１つ
JMS2.0のみ
プライベート共有デュラブル・
サブスクリプション
・１つのコネクションを共用した同一のデュラブル・サブス
クリプション
・クライアントIDは１つ
JMS2.0のみ
グローバル共有ノンデュラブル・
サブスクリプション
・複数のコネクション間での同一のサブスクリプション
・クライアントIDは個別
JMS2.0のみ
グローバル共有デュラブル・
サブスクリプション
・複数のコネクション間での同一のデュラブル・サブスクリ
プション
・クライアントIDは個別
JMS2.0のみ
© 2014 IBM Corporation
外部システム連携設計（MQ）
MQ連携（MQコネクティビティ）
外部のWebSphere MQのキューマネージャーとの間でメッセージの連携が可能
MessageSihgtのデスティネーション・マッピング・ルールで指定
既存のMQを利用したシステムとの連携を容易に実現できる
向きは２方向
MQ
MessageSight
または
MQ
MessageSight
（注意）
MessageSight内のトピックとキュー
の間のマッピングはできない
変換パターンは７種類
Topic
Topic subtree
Queue
68
Topic
Topic subtree
Queue
© 2014 IBM Corporation
外部システム連携設計（MQ）
MQ連携の定期項目と定義内容
オブジェクト
定義項目
名前
キューマネー
ジャー・コネクション キューマネージャー
任意名称
接続先キューマネージャー名
コネクション名
IPアドレスとポート番号
チャネル名
チャネル名（SVRCONN）
SSL Cipher Spec
SSL用Ciper Specification （最大32文字)
デスティネーション・ 名前
マッピング・ルール
ルールタイプ
69
定義内容
任意名称
14種類のルールタイプから選択
ソース
送信元トピックまたはキュー
宛先
送信先トピックまたはキュー
最大メッセージ数
数値
リテイン・メッセージ
有無
有効化
有無
キューマネージャー・コネクション名
定義済みキューマネージャー・コネクションから
選択（複数可）
© 2014 IBM Corporation
外部システム連携設計（MQ）
MQ連携を負荷分散に利用
キューマネージャー・コネクションを複数作成
デスティネーション・マッピング・ルールで、複数のキューマネージャー・コネクションを指定
各キューマネージャーには、同一名のキューが必要
各キューには分散配信される
デスティネーション・マッピング・ルー
ルで、トピックからキューに変換
各キューマネージャーには、
同一のキューが必要
キューマネージャー毎に、キューマ
ネージャー・コネクションを
MessageSightに定義
MessageSight
Message1
Publisher
QMR1
Queue1
QMR2
Queue1
QMR3
Message1
P
Message2
70
Topic
Queue1
Message2
© 2014 IBM Corporation
まとめ
設計の鍵
どういうパターン、トポロジーにするか
どんなペイロードにするか
どういうトピック構造にするか
アプリケーションでどんなオプションを使うか
MQTT
MQTT/Websocket
Enterprise Applications
MessageHUB
User&Group
MQ
MQTT
Client
Applications
MessageSight
DMZ
71
JMS Java SE
Client
Destination Mapping Rule
（MQコネクティビティ）
Services
WebGUI／CLI（SSH）
© 2014 IBM Corporation
© Copyright IBM Corporation 2014. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind,
express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have
the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM
software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities
referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature
availability in any way. IBM, the IBM logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other
company, product, or service names may be trademarks or service marks of others.
72
© 2014 IBM Corporation