Comments
Transcript
Hints & Tips トピック 2004/06/14 プーリング機能
＜MQ-WAS連携-第５章＞
Hints & Tips
2004/06/14
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
トピック
プーリング機能
プーリング概要
プーリングの属性
適切なプーリング使用方法
JMSオブジェクトの管理方法
ネーミングサービス概要
Lookup方法
ネーミングサービスへの登録方法
有効範囲の選択
Message Driven Bean (MDB)
MDB概要
メッセージの順序制御
トランザクション・スコープ
ポイズン・メッセージへの対処
Extended Message Service (EMS)
EMS概要
送信側Bean
遅延応答の処理
受信側Bean
メッセージ・ポート
データ・マッピング
2
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
プーリング機能
3
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
プーリング機能
＜Note＞
この章では、プーリング機能に関する以下の項目について説明します。
プーリング概要
プーリングの属性
適切なプーリング使用方法
4
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
プーリング概要
プーリング機能とは
コネクションを再利用して接続・切断の負荷を軽減
MQとWASにおけるプーリング機能の違い
MQのプーリング ・・・ MQとのコネクション自体
WASのプーリング ・・・ コネクションが結び付けられたJMSオブジェクト
WASのプール
コネクション・プール
QueueConnection
オブジェクトを再利用
コネクション・ファクトリーごとに1つのコネクション・プール
セッション・プール
QueueSession
オブジェクトを再利用
コネクションごとに1つのセッション・プール
Session
JMS
クライアント
Session
Connection
Queue
Session
Connection
Queue Manager
Session
Connection
MDB
Session
Session
Connection
Session
5
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
プーリング概要
＜Note＞
プーリング機能とは、一度使用されたコネクションを再利用し、接続・切断の負荷を軽減することでパフォーマン
ス向上を図るための機能です。不特定多数がアクセスしてくるWebアプリケーションにおいては、非常に有効な
機能であるといえます。
WebSphere MQ（以下、MQ）が提供するJMS実装クラスでは、以前から独自のコネクション・プーリング機能
を提供していましたが、WebSphere Application Server（以下、WAS）が提供するプーリング機能は、その
プーリング機能とは仕組みや設定方法が異なります。
MQが提供するプーリング機能では、WASとMQの間で使用されるコネクション自体をプーリングし、再利用
します。
WASが提供するプーリング機能では、WASとMQの間で使用されるコネクションが結び付けられたJMSオ
ブジェクトをプーリングし、再利用します。結果的にコネクション自体がプーリングされるようになっています。
WASが提供するプールとしては、「コネクション・プール」と「セッション・プール」の2種類があり、それぞれプール内
に保持するJMSオブジェクトが異なります。
コネクション・プールは、QueueConnectionFactoryオブジェクトごとに用意され、そのオブジェクトから作成
されるQueueConnectionオブジェクトをプーリングします。
セッション・プールは、QueueConnectionオブジェクトごとに用意され、そのオブジェクトから作成される
QueueSessionオブジェクトをプーリングします。
6
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
プーリングの属性
コネクション・プール と セッション・プール の属性
最大接続数 （デフォルト 10）
プールに作成することのできるコネクションの最大数
最小接続数 （デフォルト 1）
常に維持する必要があるコネクションの最小数
接続タイムアウト （デフォルト 180秒）
コネクション要求がタイムアウトになる間隔
リープ時間 （デフォルト 180秒）
プール保守スレッドの実行間隔
未使用タイムアウト （デフォルト 1800秒）
未使用のコネクションがプール保守スレッドによって破棄される間隔
経過タイムアウト （デフォルト 0）
アクティブで未使用なコネクションがプール保守スレッドによって破棄される間隔
Servlet / EJB
接続
接続タイムアウト
経過タイムアウト
最大接続数
Connection
Connection
未使用タイムアウト
Connection
Connection
最小接続数
Connection
Connection
7
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
プーリングの属性
＜Note＞
コネクション・プールとセッション・プールはそれぞれ接続に関する属性を持っており、それらはWASの管理コンソー
ルの「リソース」＞「JMSプロバイダーの種類」＞「キュー接続ファクトリー」＞「接続ファクトリー名」＞「接続プール」
から設定することができます。属性の種類については、以下の通りです。
「最大接続数」は、プール内に作成することのできるコネクションの最大数を設定します。デフォルト値は10で
す。コネクション数がこの数値に到達すると、新規のコネクション要求は待機状態となります。
「最小接続数」は、プール内に常に維持しておく必要があるコネクションの最小数を設定します。デフォルト
値は1です。コネクション数がこの数値に到達するまでは、プール保守スレッドによってコネクションが破棄され
ることはありません。ただし、「経過タイムアウト」を設定した場合、この数値に到達していなくても有効期限切
れのコネクションは破棄されます。
「接続タイムアウト」は、コネクション要求がタイムアウトになり、ConnectionWaitTimeoutExceptionがス
ローされる間隔を設定します。デフォルト値は180秒です。これが0に設定されている場合、コネクションが割り
振られるまで待機を続けます。
「リープ時間」は、プール保守スレッドが実行される間隔を設定します。デフォルト値は180秒です。これが0に
設定されている場合、プール保守スレッドは使用不可になります。この数値が短いほど「未使用タイムアウ
ト」や「経過タイムアウト」で設定した値の精度は高まりますが、プール保守スレッドの実行回数が増えるとい
うことはパフォーマンス低下につながります。
「未使用タイムアウト」は、未使用のコネクションがプール保守スレッドによって破棄される間隔を設定します。
デフォルト値は1800秒です。未使用のコネクション数が「最小接続数」で設定した値よりも多い場合にのみ、
未使用のコネクションは破棄されます。
「経過タイムアウト」は、アクティブかつ未使用で、時間の経過したコネクションがプール保守スレッドによって破
棄される間隔を設定します。デフォルト値は0（無制限）です。これが0に設定されている場合、アクティブなコ
ネクションを無制限にプールに残しておくことができます。
8
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
適切なプーリング使用方法
コネクション・プール と セッション・プール の関係
WAS-MQ間の実接続数
両プールを最大まで使い切った場合
（コネクション・プールの最大接続数） X （セッション・プールの最大接続数）
オブジェクトとプールの関係
別のConnectionオブジェクトから作成されたSessionオブジェクトは別のプールにプーリング→再利用不可
スレッドとオブジェクトの関係
JMS: 2.8 Multithreading
Connectionオブジェクトは複数スレッドから共有可能
Sessionオブジェクトはスレッドごとの作成が必要
JMSオブジェクト
Destination
ConnectionFactory
Connection
Session
MessageProducer
MessageConsumer
複数スレッドからの
同時使用サポート
YES
YES
YES
NO
NO
NO
考え方
Connectionオブジェクトはアプリケーション内でできるだけ再利用、Sessionオブジェクトで調整
プール数をおさえ、Sessionオブジェクトを効率的に使用する
チューニングポイントはセッションプールに絞る
クローズ処理忘れの可能性を最小にする
9
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
適切なプーリング使用方法
＜Note＞
コネクション・プールとセッション・プールはそれぞれ保持するオブジェクトが異なりますので、アプリケーションのコーディ
ングに応じて適切に使い分けなければなりません。
QueueConnectionオブジェクトを各スレッドで作成している場合、WAS-MQ間の最大実接続数は、（コネ
クション・プールの最大接続数）X（セッション・プールの最大接続数）で算出することができます。
別のQueueConnectionオブジェクトから作成されたQueueSessionオブジェクトは別のプールにプーリング
されて再利用されるため、自由に使いまわすことができません。
仕様上、QueueConnectionオブジェクトは複数スレッドから共有することができますが、QueueSessionオ
ブジェクトはスレッドごとに作成する必要があります。
2種類のプールを使用するにあたって、QueueConnectionオブジェクトはアプリケーション内でできるだけ再利用
して使いまわし、QueueSessionオブジェクトの数で調整する、という考え方があります。
オブジェクトのプール数をおさえることで、QueueSessionオブジェクトを効率的に使用します。
コネクション・プールおよびその属性は使用されないので、チューニングポイントをセッション・プールに絞ります。
オブジェクトのクローズ処理忘れの可能性を最小にします。
10
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
JMSオブジェクトの管理方法
11
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
JMSオブジェクトの管理方法
＜Note＞
この章では、JMSオブジェクトの管理方法に関する以下の項目について説明します。
ネーミングサービス概要
Lookup方法
ネーミングサービスへの登録方法
有効範囲の選択
12
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
ネーミングサービス概要
ネーミングサービスとは
ネーミングサービス
名前をキーとしてオブジェクトを検索するためのサービス
ネームスペース
オブジェクトが階層的に格納されている空間
バインド
名前とオブジェクトを関連づけること
Lookup
名前から関連づけられたオブジェクトを検索すること
JMSオブジェクト
キュー・コネクション・ファクトリー
キュー・マネージャー名、接続タイプ、ホスト名、チャネル名、ポート番号など
キュー宛先
キュー名など
13
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
ネーミングサービス概要
＜Note＞
WAS上のアプリケーションからMQに接続するにはJMSオブジェクトが使用され、そのJMSオブジェクトを取得する
には、ネーミングサービスが使用されます。
ネーミングサービスとは、オブジェクトと名前を関連付け、その名前をキーとしてオブジェクトを検索するための
サービスです。ネーミングサービスに対してある特定の名前を指定すると、その名前に対応するオブジェクトを
取得することができます。
ネームスペースとは、ネーミングサービスにおいてオブジェクトが格納されている空間のことです。ネーミングサー
ビスから検索されるオブジェクトはネームスペースに階層的に格納されています。
バインドとは、名前とオブジェクトを関連付けることです。「<名前>と<オブジェクト>をバインドする」といった言
い方をします。
Lookupとは、名前から関連付けられたオブジェクトを検索することです。「<名前>から<オブジェクト>を
Lookupする」といった言い方をします。
MQに接続するために、アプリケーションはネーミングサービスからJMSオブジェクトを取得します。JMSオブジェクト
には、キュー・コネクション・ファクトリーとキュー宛先があります。
キュー・コネクション・ファクトリー（QueueConnectionFactory）には、接続先のキュー・マネージャー名、接
続タイプ、ホスト名、チャネル名、ポート番号などといった接続に必要な接続先情報が定義されます。
キュー宛先（Queue）には、キュー名などといったメッセージの送信/受信に必要な宛先情報が定義されます。
14
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
Lookup方法
「参照」の使用
Lookupするオブジェクトの名前の先頭に「java:comp/env/」コンテキストを付けるのが原則
デプロイ時に実際のJNDI名にバインド
×悪いアプリケーション・コード (直接JNDI名を記述するとポータビリティーが低下)
queue
queue == (Queue)
(Queue) ctx.lookup(“jms/SampleQ");
ctx.lookup(“jms/SampleQ");
ネーミングサービス
◎良いアプリケーション・コード
キュー宛先
queue
queue == (Queue)
(Queue) ctx.lookup("java:comp/env/jms/Sample");
ctx.lookup("java:comp/env/jms/Sample");
JNDI名: jms/SampleQ
“SampleQ”
デプロイメントディスクリプター
<リソース参照>
ディプロイメントディスクリプターでリソース参照「jms/Sample」を作成し、
これを実際のJNDI名「jms/SampleQ」にバインドする
15
jms/Smaple → jms/SampleQ
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
Lookup方法
＜Note＞
J2EEにおけるネーミングサービスの意義はポータビリティーの向上であり、アプリケーションコードから外部リソースへ
のJava Naming and Directory Interface（以下、JNDI）による統一されたアクセス環境を提供しています。オ
ブジェクトをLookupする際は、アプリケーションに直接JNDI名を記述するのではなく「参照」を使用します。
JNDIクライアントにおいてLookupする際は、Lookupするオブジェクトの名前の記述フォーマットとして
[java:comp/env]コンテキストを先頭につけた形とすることが原則であり、J2EEとして良い作法であるといわ
れています。lookup()の中にJNDI名のみを直接記述することでオブジェクトを取得することもできますが、そ
れはソースコードの中に特定の環境情報が記述されてしまうことになり、ポータビリティーが低下します。
アプリケーションのデプロイ時に、そのアプリケーションのディプロイメント・ディスクリプターでリソース参照を作成
します。リソース参照を作成することにより、ソースコードの中に記述した名前を実際のオブジェクトのJNDI名
にバインドすることができます。
このような「参照」を使用することにより、ある環境で稼動しているアプリケーションを別の環境で稼動させたい場
合に、ソースコードを編集する必要がなくなります。
16
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
ネーミングサービスへの登録方法
JMSプロバイダーの定義
有効範囲の選択
「セル」、「ノード」、「サーバー」
キュー・コネクション・ファクトリーの定義
キュー・マネージャー名、接続タイプ、ホスト名、チャネル名、ポート番号など
キュー宛先の定義
キュー名など
新規作成
17
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
ネーミングサービスへの登録方法
＜Note＞
MQへ接続する際に必要となる接続先情報などは、WASのJMSプロバイダーとして定義します。このJMSプロバ
イダーでキュー・コネクション・ファクトリーやキュー宛先などの情報を定義することで、これらの情報はネーミングサー
ビスに登録されます。JMSプロバイダーは、WASの管理コンソールを使用して定義することができます。
JMSプロバイダーの有効範囲を選択します。ND構成の場合、「セル」、「ノード」、「サーバー」の中から1つを
選択します。
キュー・コネクション・ファクトリーを定義します。ここでは、接続先情報として、キュー・マネージャー名、接続タ
イプ、ホスト名、チャネル名、ポート番号などを定義します。
キュー宛先を定義します。ここでは、宛先情報として、キュー名などを定義します。
18
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
有効範囲の選択
ネームスペースとオブジェクトの関係
物理ノード(ホスト名: cipher)
論理ノード
(ノード名: cipherNode)
node
agent
プロセス名
論理ノード
(ノード名: cipherManager)
server1
server2
dmgr
SampleQ
SampleQ
SampleQ
JMSプロバイダーの有効範囲
セルレベル
ノードレベル(cipherManager)
SampleQ
ノードレベル (cipherNode)
SampleQ
サーバーレベル (server1)
SampleQ
SampleQ
有効範囲を選択する際の考え方
基本的に、リソースは使用するアプリケーションが稼動するプロセスのネームスペースに登録
属性の設定範囲によって有効範囲を選択
（全てのクラスタメンバの属性が同じであれば、有効範囲は「セル」を選択）
19
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
有効範囲の選択
＜Note＞
JMSプロバイダーを定義する際、有効範囲を「セル」、「ノード」、「サーバー」のいずれかで指定する必要がありま
す。WASは各プロセスごとにネームスペースを持っており、どのプロセスに対してJMSオブジェクトを定義するか、と
いった選択を有効範囲で指定することになります。
デプロイメント・マネージャーは、同じ物理ノードにあっても他のプロセスとは別論理ノード扱いになりますので、注
意が必要です。
有効範囲を選択する際の考え方としては、以下のものが挙げられます。
基本的に、リソース（この場合はJMSプロバイダー）は使用するアプリケーションが稼動するプロセスのネームス
ペースに登録します。例えば、あるJMSプロバイダーを使用するアプリケーションがserver1で稼動する場合、
そのJMSプロバイダーの有効範囲としては「サーバー」を選択し、「server1」というプロセスのネームスペースに
登録します。
セルやノード、サーバーごとに属性を変えたいときは、有効範囲としてそれぞれのレベルを選択します。例えば、
あるJMSプロバイダーを使用するアプリケーションが分散している複数のクラスタメンバで稼動する場合、全て
のクラスタメンバで属性を同じ値に設定するのであれば有効範囲として「セル」を選択し、全てのクラスタメン
バで属性を異なった値に設定するのであれば「サーバー」を選択します。
20
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
Message Driven Bean (MDB)
21
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
Message Driven Bean (MDB)
＜Note＞
この章では、MDBに関する以下の項目について説明します。
MDB概要
メッセージの順序制御
トランザクション・スコープ
ポイズン・メッセージへの対処
22
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
MDB概要
EJB2.0で決められた新しいタイプのEJB
非同期実行メカニズムを実現
メッセージ到着時にコンテナーによって呼び出されるEJB
EJBクライアントから呼び出すことはできない
Homeインターフェース、Remoteインターフェースがない
JMS宛先（キュー）にメッセージが到着するとEJBコンテナーがonMessage()を起動
ビジネスロジックはonMessage()に記述
1メッセージで1インスタンスのみ起動
並列にメッセージ受信およびビジネスロジックの実行が可能
EJBｺﾝﾃﾅ
ﾒｯｾｰｼﾞ送信
JMSｸﾗｲｱﾝﾄ
Destination
MQｱﾌﾟﾘｹｰｼｮﾝ
ﾒｯｾｰｼﾞ･ｵﾌﾞｼﾞｪｸﾄ
MDB
MDB
作成/検索
EJBHome
EJBｸﾗｲｱﾝﾄ
EJBObject
Session
Entity
ﾒｿｯﾄﾞ呼び出し
23
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
MDB概要
＜Note＞
EJB2.0では、SessionBeanやEntityBeanに加えて、新しいタイプのEnterprise Bean としてMessage
Driven Bean （以下、MDB）が新たに定義されました。
JMSメッセージ到着の際、EJBコンテナーによって自動的に呼び出される非同期のMessageConsumer
です。 SessionBeanやEntityBeanのようなHomeインターフェースやRemoteインターフェースはなく、EJB
クライアントから呼び出すことはできません。
MDBは、javax.Message.Listenerインターフェースとjavax.ejb.MessageDrivenBeanインターフェース
を実装しています。
MDBにはonMessage()メソッドがあり、JMS宛先（キュー）にJMSメッセージが到着すると、EJBコンテナーに
よって自動的にonMessage()メソッドが実行されます。
onMessage()メソッドの中にビジネスロジックを書き加えることができ、受信したメッセージ内容をMessage
オブジェクトとして参照することができます。
MDBは1メッセージ到着ごとに1インスタンスのみ起動されますが、リスナー・ポートの設定を変更するだけで
並列に複数のメッセージを受信することができます。つまり、並列に複数のインスタンスを起動して並列にビ
ジネスロジックを実行することができるということです。
24
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
メッセージの順序制御 [1/4]
メッセージ処理時の順序性を保証したい場合は、サーバー側の処理はシングル・スレッ
ドになる部分を持たなければならない
MQGET(1)
MQGET(1)
MQGET(2)
(1)終了
MQGET(3)
MQGET(2)
(2)終了
(2)終了
(1)終了
(3)終了
MQGET(3)
(3)終了
処理の終了順序が(1)→(2)→(3)となるとは限らない
1つのスレッドで処理すれば順序が保持できる
25
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
メッセージの順序制御 [1/4]
＜Note＞
キューに入ってくるJMSメッセージは、デフォルトではFIFOで取り出されます。取り出す処理がマルチスレッドで行
われた場合、メッセージを取り出した後の処理が終了してから次のメッセージが取り出されるとは限らないため、処
理の順序性を保つことができません。したがって、メッセージ処理時の順序性を保証したい場合は、メッセージの
取り出しから処理が終了するまでの一連作業をシングルスレッドで行う必要があります。
26
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
メッセージの順序制御 [2/4]
メッセージ処理時の順序性を保つことは可能
同一のキューから1つのアプリケーションで受信していれば、メッセージの順序を保ったまま受信
することができる
アプリケーションがメッセージをロールバックしても、再度そのメッセージから受信することができる
アプリケーション・サーバー
Webｺﾝﾃﾅー
Servlet
JMSクライアント
A
MQ
B
ロールバック
B
C
27
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
メッセージの順序制御 [2/4]
＜Note＞
JMSクライアントを使用した場合、メッセージ処理時の順序性を保つことは可能です。
キューに入ってくるメッセージは、デフォルトではFIFOで取り出されます。したがって、ある特定のキューの中の
メッセージを1つのアプリケーションで受信している場合、ある1つのメッセージに関する処理が終了してから次
のメッセージを取り出すことになるので、メッセージの順序性を保つことができます。
何らかの原因で障害が発生してアプリケーションがメッセージをロールバックした場合でも、そのロールバック処
理が終了してから、再度そのメッセージから受信することができるので、メッセージの順序性を保つことができま
す。
28
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
メッセージの順序制御 [3/4]
メッセージ処理時の順序性を保つことは困難
MDBを並列稼動 → 処理の順序性を保証することはできない
A
JMS
クライアント
A
B
C
リスナー・
ポート
MDB
B
C
MDB
MDB
MDBを単一稼動 → 処理の順序性を保つことは困難
正常であれば順序性を保つことはできる
メッセージを取得するリスナー・ポートとメッセージを処理するMDBとは別スレッドで動いている
メッセージ処理中のエラーによってロールバックされたメッセージが次に処理されるとは限らない
A
JMS
クライアント
A
A
B
C
リスナー・
ポート
ロールバック
B
C
MDB
A
29
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
メッセージの順序制御 [3/4]
＜Note＞
MDBを使用した場合、メッセージ処理時の順序性を保つことは困難です。
MDBの1インスタンスは、必ず1つのスレッドにより実行されます。したがって、MDBのビジネスロジック記述部
分であるonMessage()メソッド内の処理であれば、順序性を保つことは可能と考えられます。しかし、MDB
を並列稼動させている場合は、各MDBインスタンスは並列に処理を行うため、メッセージ受信後はどのイン
スタンスが先に処理を終了するのか分からない状態になります。したがって、メッセージ処理の順序性を保証
することはできないということになります。
また、MDBを単一稼動させている場合（最大スレッド・プール数を1に設定している場合）でも、正常であれ
ば順序性を保つことは可能ですが、メッセージ処理中の何らかのエラーが発生してロールバックすると追い越
しが発生してしまいます。メッセージを取得するリスナー・ポートとメッセージを処理するMDBとは別スレッドで
動いているため、エラーが発生したとしてもリスナー・ポートは既に次のメッセージを認識しているので、ロール
バックされたメッセージが次に取り出されるとは限りません。したがって、メッセージ処理の順序性を保証するこ
とはできないということになります。
30
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
メッセージの順序制御 [4/4]
MDBでメッセージ処理時の順序性を保証したい場合はWASのパラメータを設定
non.asf.receive.timeout
アプリケーション・サーバー単位で設定
設定した場合は順序性を保証
ロールバック時にメッセージを自動的に退避する機能が使用不可
31
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
メッセージの順序制御 [4/4]
＜Note＞
メッセージが正常に処理されているときはメッセージの到着順序どおりに処理されます。しかし、メッセージ処理中
にエラーが発生してロールバックすると追い越しが発生し、ロールバックされたメッセージの処理は後方に回されて
しまいます。このようなロールバック時のメッセージ順序の狂いを防ぐために、「non.asf.receive.timeout」パラメー
タの設定が必要です。パラメータ「non.asf.receive.timeout」を設定することにより、エラーが発生しても再度
ロールバックされたメッセージから受信することができ、メッセージ処理の順序性を保つことができます。
ただし、「non.asf.receive.timeout」を設定したときは、ロールバック時にそのメッセージを自動的に退避する機
能が使用できません。そのため、ユーザー・コーディングで退避するような仕組みを作ることが必要になります。また、
順序性を保つためには、念のため、キューの属性をDEFSOPT(EXCL)と設定し、同時に1アプリケーションしか
読み込みを目的としてキューをOPENできないように排他制御をかけておくと安心です。
また、「non.asf.receive.timeout」はアプリケーション・サーバー単位での設定となるため、メッセージの順序性を
保証したいアプリケーションとそうではないアプリケーションをアプリケーション・サーバーごとに分ける、などといった考
慮が必要です。
「non.asf.receive.timeout」に設定する値の指針は、以下の通りです。
トランザクション・タイムアウトになるとメッセージの再処理が必要となってしまいますので、「non.asf.receive.timeout」はトラン
ザクション・タイムアウトよりも低い値を設定します。
onMessage()メソッド内の処理にかかる時間分は確保しておく必要があります。
（例）
トランザクション・タイムアウトが120000ミリ秒（120秒）で、onMessage()メソッド内の処理にかかる時間が最大で10000ミリ秒
（10秒）である場合、「non.asf.receive.timeout」は110000（120000-10000=110000）ミリ秒（110秒）未満に設定します。
32
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
MDBのトランザクション・スコープ [1/2]
UOWの分け方によって、障害時のメッセージの行方やサーバー側の対応が異なる
ここでは、以下の3つの処理に分けて考える
・受信処理
受信処理 ・・・・・ EJBコンテナーによるメッセージ受信処理（MDB起動のトリガー）
・リソース更新処理
リソース更新処理 ・・・・・ ビジネスロジック内のDB更新などの処理 [パターン1]
パターン1]
・送信処理
送信処理 ・・・・・ ビジネスロジック内のメッセージ送信処理
サーバー
ＵＯＷ
GET
MDB
Update
[パターン
パターン1]
パターン 3つの処理を全てを1つのUOWに入れる
PUT
1つでも処理が異常終了した場合は全ての処理がロールバック
ロールバックした時の要求メッセージはキューに戻る
サーバーは「ポイズン・メッセージ」に対応しておく必要がある
[パターン2]
パターン2] サーバー
EJBコンテナーの2フェーズ・コミットが行われるのでパフォーマンス悪化
GET
MDB
ＵＯＷ
Update
[パターン
パターン2]
パターン リソース更新処理と送信処理を1つのUOWに入れる
PUT
要求メッセージはサーバーから受信されるとキューから消去
ロールバックしたときの要求メッセージはキューに戻らない
応答メッセージはビジネス・ロジックが失敗したら送信されない
[パターン3]
パターン3] サーバー
GET
[パターン
パターン3]
パターン 3つの処理全てをUOWに入れない
トランザクション管理が行われない
参照系処理のようにリソースへの更新を行わない場合に適用
33
MDB
Update
PUT
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
MDBのトランザクション・スコープ [1/2]
＜Note＞
サーバー・アプリケーションの処理をどのようにUOWに入れるかで、障害時のメッセージの挙動やサーバー・アプリ
ケーションの対応が異なってきます。
ここでは、MDBを起動するトリガーとなるEJBコンテナーによるメッセージ受信処理、ビジネスロジックすなわち
onMessage()メソッド内に記述されているリソース更新処理とメッセージ送信処理の3つに分けて考えます。
3つの処理全てを1つのUOWに入れる場合、要求メッセージの受信からビジネスロジック、応答メッセージの
受信までが同一のUOW内で処理されます。1つでも処理が異常終了した場合は、全ての処理がロール
バックされ、要求メッセージもキューに戻ります。ロールバックされたメッセージは再度処理され、場合によっては
「ポイズン・メッセージ」（P.39参照）になる可能性もありますので、サーバー側では「ポイズン・メッセージ」に対
する対応を取っておく必要があります。また、EJBコンテナーにトランザクション管理を任せますので、コミット処
理にはDBとメッセージング・システム間の2フェーズ・コミット・プロトコルが実施される場合にパフォーマンスが悪
化することも考慮しなければなりません。
リソース更新処理と送信処理を1つのUOWに入れる場合、これらの処理結果に依存せずに要求メッセージ
の受信が行われます。要求メッセージはサーバーから受信されると同時にキューから消去され、後続のビジネ
スロジックが失敗したとしてもキューにメッセージが戻されることはありません。応答メッセージは、ビジネスロジッ
クが成功した場合はクライアントへ送信されますが、失敗した場合は送信されません。
3つの処理全てをUOWに入れない、すなわちトランザクション管理しない場合、サーバーの全ての処理を他
の処理に依存せずに行います。参照系の処理のように、リソースへの更新を行わず、ビジネスロジックをトラン
ザクション管理しなくてもよい場合に適用されます。
34
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
MDBのトランザクション・スコープ [2/2]
受信処理をonMessage()メソッド内の処理と同じUOWに入れるかどうかを設定可能
トランザクション・タイプ
コンテナー管理トランザクション（CMT）
・・・ コンテナーがトランザクションを管理する
ビーン管理トランザクション（BMT） ・・・ コンテナーがトランザクションを管理しない
onMessageメソッドのトランザクション属性
Required
・・・ コンテナーの受信処理をonMessageメソッド内の処理と同じUOWに入れる
・・・ コンテナーの受信処理もonMessageメソッド内の処理もトランザクションを管理
NotSupported
しない
各パターンにおけるトランザクション設定
トランザクション・タイプ
トランザクション属性
パターン1
CMT
Required
パターン2
BMT
―
パターン3
CMT
NotSupported
35
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
MDBのトランザクション・スコープ [2/2]
＜Note＞
EJBコンテナーによって行われる受信処理をonMessage()メソッド内の処理と同じUOWに入れるかどうかは、
MDBの2つの属性で設定することができます。
トランザクション・タイプには、コンテナー管理トランザクション（以下、CMT）とビーン管理トランザクション（以下、BMT）の2種類
があります。CMTに設定した場合はEJBコンテナーがトランザクション管理を行い、BMTに設定した場合はEJBコンテナーはト
ランザクション管理を行わず、ユーザーがコーディングによってトランザクション管理を行います。
onMessage()メソッドに設定できるトランザクション属性は、EJBの仕様により、RequiredとNotSupportedの2つだけと決めら
れています。Requiredに設定した場合は、EJBコンテナーの受信処理をonMessage()メソッド内の処理と同じUOWに入れ
ることができます。NotSupportedに設定した場合は、EJBコンテナーの受信処理もonMessage()メソッド内の処理もトランザ
クション管理しません。
前ページの3つのパターンを実現するためには、それぞれ表のようなトランザクション設定を行う必要があります。
トランザクション・タイプをCMTとし、onMessage()メソッドのトランザクション属性をRequiredと設定すると、EJBコンテナーによ
るメッセージ受信処理をonMessage()メソッド内の処理と同じUOWに入れることができます。この場合、トランザクションは
EJBコンテナーによって管理されるため、トランザクションの開始や終了（コミットやロールバック）もコンテナーが内部的に行います。
[パターン1]を採用する場合はこの設定を行います。
トランザクション・タイプがBMTの場合は、EJBコンテナーのメッセージ受信処理はトランザクション管理されず、onMessage()メ
ソッド内の処理と同じUOWに入れることはできませんが、onMessage()メソッド内の処理はユーザーによるコーディングでトラン
ザクション管理させることができます。[パターン2]を採用する場合はこの設定を行います。
トランザクション・タイプがCMTでも、onMessage()メソッドのトランザクション属性がNotSupportedの場合は、EJBコンテナー
のメッセージ受信処理に対してもonMessage()メソッド内の処理に対してもトランザクション管理は行われません。[パターン3]
を採用する場合はこの設定を行います。
36
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
（参考）パーシステント属性による違い
グローバルトランザクションではない（CMTでNotSupportedあるいはBMT）場合、受信
メッセージのパーシステント属性によってEJBコンテナーの処理の仕組みが異なる
パーシステント・メッセージを受信する場合
MQのローカル・トランザクションの同期点付きで処理
同期点はonMessageメソッドが正常に終了しても例外が発生してもコミット
onMessageメソッド処理中のプロセス障害などにより、後続の処理が行われない場合はロールバック
ノン・パーシステント・メッセージを受信する場合
同期点なしで処理
後続の処理で障害が発生してもロールバックされない
コンテナーが受信したタイミングでメッセージはキューから削除
GET時にメッセージはキューから削除
メッセージ受信
メッセージ受信
onMessage()
onMessage()
障害発生
メッセージはキューに
ロールバックされる
障害発生
メッセージは消失する
WMQのローカル・トランザクション
【ノン・パーシステントの場合】
【パーシステントの場合】
37
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
（参考）パーシステント属性による違い
＜Note＞
グローバルトランザクションではない場合、すなわちトランザクション・タイプがCMTでトランザクション属性が
NotSupportedの場合か、トランザクション・タイプがBMTの場合、WASの実装するMDBでMQをプロバイダーと
して選択したときには、受信メッセージのパーシステント属性によってEJBコンテナーが行う受信処理の内部的な
仕組みが異なります。これは、EJBコンテナーがメッセージ受信時に内部的に発行しているMQGET（メッセージ
受信用のMQインターフェース）には、同期点オプションとしてMQGMO_SYNCPOINT_IF_PERSISTENTが
セットされているからです。
パーシステント・メッセージを受信する場合は、MQのローカル・トランザクションの同期点付きで処理されます。
この同期点は、onMessage()メソッドが正常に終了しても例外が発生して終了しても、コミットされます。た
だし、onMessage()メソッド内の処理の途中でプロセス障害が発生し、後続の処理が行われないような場
合は、コミットは発行されず、受信したメッセージはロールバックされることになります。
ノン・パーシステント・メッセージを受信する場合は、同期点なしで処理されます。したがって、後続の処理で
障害が発生してもメッセージがロールバックされるということはありません。また、EJBコンテナーが受信したタイ
ミングで、メッセージはキューから削除されます。
38
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
ポイズン・メッセージへの対処 [1/4]
ロールバックのループ現象
不正なメッセージを処理→エラー発生→ロールバック→再度処理→エラー発生→ロールバック
何回処理を試みてもロールバック
ロールバックのループ
キュー・マネージャー
EJBコンテナー
エラー発生
MDB
ポイズン・メッセージ
何度もロールバックされているメッセージ
後続のメッセージ処理の妨げとなる
MDBを使用した環境におけるポイズン・メッセージへの対処方法
MQの設定でエラー・キューに退避させる方法
ユーザー・ロジックでロールバック回数を判断し、エラー・キューに退避させる方法
特定回数リトライを実行し、リスナーを停止させる方法
39
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
ポイズン・メッセージへの対処 [1/4]
＜Note＞
メッセージング・システムにおいて、メッセージの内容が不正などの理由で何回処理を繰り返してもエラーになって
しまい、ロールバック処理がループしてしまう場合があります。
このような何度もロールバックを繰り返し、後続のメッセージ処理の妨げになるようなメッセージを「ポイズン・メッ
セージ」といいます。
通常、メッセージング・システムで行われるこのようなポイズン・メッセージに対する対処を、MDBを使用した環境
で実現する方法として、以下の3つが考えられます。
MQの設定でエラー・キューに退避させる方法です。
ユーザー・ロジックでロールバック回数を判断し、エラー・キューに退避させる方法です。
特定回数リトライを実行し、リスナーを停止させる方法です。
40
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
ポイズン・メッセージへの対処 [2/4]
MQのキュー属性設定により、ポイズン・メッセージをエラー・キューに退避
キューの属性
・・・ 退避させるキューの名前を設定
BOTHRESH ・・・ ロールバックの閾値を設定
BOQNAME
「BOTHRESH」で指定した回数ロールバックした場合、WASが「BOQNAME」で指定したエ
ラー・キューにメッセージを退避
BOQNAME(BACKOUT.QUEUE)
キュー・マネージャー
ロールバックのループ
EJBコンテナー
BOTHRESH(5)
MDB
エラー・キューに退避
BACKOUT.QUEUE
特徴
キューの属性を設定するだけなので実装は容易
エラー・キューにPUTできない、かつ、伝送不能キュー設定がされていない場合
ノン・パーシステント属性メッセージは、キューへのPUTが失敗した時点で消失
パーシステント属性メッセージは、キューへのPUTが失敗するとExceptionを出力して退避処理をリトライ
WASの設定でApplication Server Facility (ASF)機能を停止している場合は使用不可
リスナー・ポートの「最大試行回数」が「BOTHRESH」よりも小さい場合は、エラー・キューに退
避する前にリスナーが停止
41
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
ポイズン・メッセージへの対処 [2/4]
＜Note＞
WAS V5 では、MQのキューの属性を設定することで、ポイズン・メッセージが発生した場合に自動でエラー・
キューに退避させるように制御することができます。
MQのキューには「BOQNAME」と「BOTHRESH」という属性値があり、それぞれ「BOQNAME」には退避
させるキューの名前を、「BOTHRESH」にはロールバックのしきい値を設定することができます。MDBと関連
付けられているリスナー・ポートが待ち受けているキューに対してこれらの属性を設定することで、メッセージが
「BOTHRESH」で指定した回数ロールバックした場合に、WASが「BOQNAME」で指定したエラー・キュー
にメッセージを退避します。
この方法を採用した場合の特徴として、以下のものが挙げられます。
この方法は、キューの属性を設定するだけで退避処理を行うので、実装方法としては簡単です。
キュー溢れの発生や、MQの設定でエラー・キューに対するPUTが禁止されていたなど、何らかの理由でエ
ラー・キューにPUTすることができない状態の場合、キュー・マネージャーに対して伝送不能キューの設定がな
されている場合は、不正メッセージは伝送不能キューにリキューされますが、この設定がなされていない場合
は、扱うメッセージの永続性によっても変わってきますが、メッセージが消失したり、さらなる障害を引き起こす
場合があります。永続性を保証しないノン・パーシステント属性のメッセージを使用している場合は、エラー・
キューへのPUTが失敗した時点で消失してしまいます。逆に、永続性を保証するパーシステント属性のメッ
セージを使用している場合は、エラー・キューへのPUTが失敗するとJMSExceptionを出力して、退避処理
をリトライすることになります。
このMQの設定による退避方法は、Application Server Facility（ASF）の機能を利用して実行していま
す。そのため、WASの設定でASFの機能を停止させている場合は、この方法を使用することができませんの
で、後述のユーザー・ロジックでエラー・キューに退避させるように作りこむ必要があります。
リスナー・ポートの「最大試行回数」パラメータの設定値が「BOTHRESH」属性の値よりも小さい場合は、
キューの属性を設定していたとしても、不正メッセージをエラー・キューに退避する前にリスナーが停止してしま
うので注意が必要です。
42
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
ポイズン・メッセージへの対処 [3/4]
ユーザー・ロジックにより、ポイズン・メッセージをエラー・キューに退避
JMSヘッダとJMSプロパティ
JMSRedelivered
(JMSヘッダ) ・・・ メッセージが再配信中であるかどうかを示すboolean値
public void onMessage(javax.jms.Message msg) {
//JMSRedelivered フィールドがtrue なら退避処理を実行
if(msg.getJMSRedelivered() == true){
//退避キューにメッセージを送信
}
}
JMSXDeliveryCount
(JMSプロパティ)・・・ メッセージの送信回数を示すint値 （正常時は1）
public void onMessage(javax.jms.Message msg) {
//3 回目のGET で退避キューに再送
if(msg.getIntProperty("JMSXDeliveryCount") > 2){
//退避キューにメッセージを送信
}
}
特徴
コーディングを行うので実装に手間がかかる
「JMSRedelivered」によりループを事前に防止
「JMSXDeliveryCount」によりロールバック回数を判断しながらエラー・キューにメッセージを退避
エラー・キューに退避させる前にメッセージに対する参照/編集可能
43
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
ポイズン・メッセージへの対処 [3/4]
＜Note＞
ユーザー・ロジックでロールバック回数をチェックし、退避キューにPUTさせるように作りこむことができます。
JMSメッセージには、過去にそのメッセージがロールバックしたかを判断するための材料として、JMSヘッダの
「JMSRedelivered」とJMSプロパティの「JMSXDeliveryCount」の2つの値を持っています。
「JMSRedelivered」フィールドには、メッセージが再配信中であるかどうかを示すboolean値が含まれていま
す。メッセージが何らかの理由によりロールバックされた場合には、このフィールドに”true”が設定されます。
「JMSXDeliveryCount」プロパティには、メッセージの送信回数がint属性でセットされています。正常であれ
ばこのプロパティ値には”1”がセットされていますが、メッセージがロールバックされた場合には、このプロパティ値
がカウントアップされていきます。
この方法を採用した場合の特徴として、以下のものが挙げられます。
コーディングで作りこむことになりますので、実装に手間がかかります。
「JMSRedelivered」フィールドをチェックすることで、そのメッセージが過去にロールバックされたことがあるかど
うかを判断することができますので、ロールバック処理がループしてしまうことを事前に防ぐことが可能です。
「JMSXDeliveryCount」プロパティをチェックすることによって、ロールバックした回数を判断しながらエラー・
キューに退避させるような処理が可能となります。
MQのキューの設定で不正メッセージを対処する方法は、MDBがキューの属性値を判断して退避処理を
行うので、ユーザーでロジックを作成する必要がありませんが、退避させるメッセージに対して編集することがで
きません。例えば処理がエラーになった理由やエラーが発生した時刻を付加するなど、エラー・キューに退避さ
せる前にメッセージに対して編集を行ったり参照したりすることができます。
44
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
ポイズン・メッセージへの対処 [4/4]
WASの設定により、ポイズン・メッセージが発生した場合にリスナーを停止
WASの管理コンソール
サーバー名]>[メッセージ・リスナー・サービス]>[リスナー・ポート］
[サーバー]>[アプリケーション・サーバー]>[
「最大試行回数」で設定した回数分リトライを繰り返し、以下のエラーを出力してMDBは停止
[03/07/03 17:22:53:453 JST] 29cfdb90 ServerSession W WMSG0036E: MDB TestMDB、JMSDestination
jms/QUEUE1 に対する最大メッセージ・デリバリー再試行数 5 に達しました。MDBListener は停止されます。
特徴
WASのパラメーターを設定するだけなので実装は容易
MDB自体が停止してしまうので後続の処理がある場合は処理不可能
「最大試行回数」とMQのキュー属性「BOTHRESH」との関係には注意が必要
45
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
ポイズン・メッセージへの対処 [4/4]
＜Note＞
WASのリスナー・ポートの設定により、ポイズン・メッセージが発生した場合にMDBを停止することができます。
WASの管理コンソールから、「サーバー」＞「アプリケーション・サーバー」＞「<サーバー名>」を選択し、追加
プロパティーの「リスナー・ポート」を選択すると、WASに定義されているリスナー・ポートの一覧が表示されま
すので、対象のMDBと関連付けられているリスナー・ポートを選択します。選択したリスナー・ポートの一般プ
ロパティーに「最大試行回数」というプロパティーがあります。この「最大試行回数」パラメータを設定することで、
不正メッセージが発生した場合には、パラメータに設定したる回数分リトライを繰り返し、エラーを出力して
MDBは停止します。
この方法を採用した場合の特徴として、以下のものが挙げられます。
WASのパラメータを設定するだけなので、容易に実装することができます。
MDB自体を停止させてしまうことになるので、後続の処理がある場合、それらは処理されなくなります。
「最大試行回数」の設定値とMQのキュー属性「BOTHRESH」の設定値との関係には注意が必要です。
46
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
Extended Message Service (EMS)
47
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
Extended Message Service (EMS)
＜Note＞
この章では、EMSに関する以下の項目について説明します。
EMS概要
送信側Bean
遅延応答の処理
受信側Bean
メッセージ・ポート
データ・マッピング
48
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
EMS概要
WAS Enterprise V5でサポートするIBM独自の機能
メッセージ送受信の機能をサーバサイドのコンポーネントとして提供
送信側Bean(SenderBean)
メッセージの送信と応答の受信を行う
応答の待ち方が選択できる（同期応答、据え置き応答、応答なし）
受信側Bean（ReceiverBean）
メッセージの受信と応答の送信を行う
2種類の受信側Beanが利用可能
MDBベースの受信側Bean
アプリケーションから呼び出しが可能な受信側Bean（Stateless Session Bean）
応答の送信方法が選択できる（同期応答、非同期応答、応答なし）
Bean開発者にわかりやすいプログラミング・モデル
JMS管理オブジェクトやJMSメッセージの構造を意識する必要がない
論理的なメッセージ・ポートに対して送受信
JMSメッセージとJavaオブジェクト間のマッピング
49
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
EMS概要
＜Note＞
Extended Messaging Service(EMS)は、WAS Enterprise V5でサポートするIBM独自の機能です。
EMSによって提供されるメッセージ送受信の形態には以下があります。
メッセージの送信
応答なしのリクエストの送信
同期応答を受信するリクエストの送信
据え置き応答を受信するリクエストの送信
メッセージの受信
キューにメッセージが到着したことをトリガーとしてメッセージを受信
アプリケーションからの呼び出しでメッセージを受信
応答の送信
EMSを使用することで、以下のメリットを受けることが出来ます。
EMSによってメッセージング部分が管理されるため、JMSの使用法が隠蔽されます。EMSは入力ポートや
出力ポート、リスナー・ポートといった、論理的なコンポーネントを通してメッセージを送受信しますので、開発
者はメッセージングを意識する必要がありません。
EMSが提供するデータ・マッピング機能によって、メソッドの引数とJMSメッセージ間の相互変換を行います。
EMSを使用するアプリケーションはEJBクライアントからEJBを呼び出すのと同様のイメージで、呼び出すこと
が出来ます。
50
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
送信側Bean [1/3]
Stateless Session Beanをベースに生成される
メッセージの送信と応答の受信を行う
応答の待ち方を選択できる
応答なし
同期応答あり
据え置き応答あり
応答の待ち時間の設定が可能
出力ポートを使用してメッセージを送受信
メッセージの属性や送信先/応答先などの定義を出力ポートにパッケージ
WAS管理コンソールにて設定
データのマッピング機能を提供
メソッド引数を元に、送信側BeanがJMSメッセージを作成
遅延応答の処理
応答メッセージが受信できなかった場合の処理を制御
51
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
送信側Bean [1/3]
＜Note＞
送信側BeanはStateless Session Beanベースに生成され、アプリケーションは送信側Beanのメソッドをコール
することで、メッセージの送信を要求します。
送信側Beanは、与えられた引数からJMSメッセージを作成し、出力ポート（※１）で定義されたJMS宛先に対
して送信します。
送信側Beanは、送信したメッセージに対する応答の待ち方を選択できます。
応答なし
アプリケーションはメッセージを送信するために、送信側Beanのメソッドを呼び出します。送信側Bean
を呼び出したアプリケーションは、送信メッセージに対する応答を受信しません。このモードはPtoPと
Pub/Subの両方で使用できます。
同期応答あり
アプリケーションはメッセージを送信して、同期応答を受信するために送信側Beanのメソッドを呼び出
します。送信側Beanはメッセージを送信し、応答を受信すると呼び出し元のアプリケーションに応答
メッセージを戻します。このモードはPtoPでのみ使用できます。
据え置き応答あり
アプリケーションがメッセージを送信して、据え置き応答を受信するために送信側Beanを呼び出します。
送信側Beanはメッセージを送信し、応答を待つことなく呼び出し元のアプリケーションにCorrelatorを
渡して制御を戻します。アプリケーションはCorrelatorを引数として受信を要求することで、送信メッ
セージに対する応答メッセージを受信することが出来ます。このモードはPtoPでのみ使用できます。
応答メッセージが何かしらの理由で遅れて送信側Beanが受信できない場合は、遅延応答処理を登録すること
で、処理させることが出来ます。
※１：出力ポートはメッセージの属性や送受信の宛先を定義した論理的なコンポーネントです。
詳細は後述の「メッセージ・ポート」の項参照
52
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
送信側Bean [2/3]
応答なし
Business Logic
EJB
①送信要求
送信側
Bean
②メッセージ送信
出力ポート
1. アプリケーションが送信側Beanの送信メソッドを呼び出す
2. 送信側BeanがJMSメッセージを作成し、出力ポート宛に送信
同期応答あり
②メッセージ送信
①送信要求
Business Logic
EJB
送信側
Bean
④応答受信
出力ポート
EMS
Runtime
③メッセージ受信
1.
2.
3.
4.
アプリケーションが送信側Beanの送信メソッドを呼び出す
送信側BeanがJMSメッセージを作成して出力ポート宛に送信し、応答を待つ
応答メッセージを受信する
アプリケーションに応答が返される
53
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
送信側Bean [2/3]
＜Note＞
<Blank Page>
54
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
送信側Bean [3/3]
据え置き応答あり
①送信要求
③Correlator
Business Logic
④受信要求(with Correlator)
EJB
⑥応答受信
②メッセージ送信
送信側
Bean
出力ポート
EMS
Runtime
⑤メッセージ受信
1.
2.
3.
4.
アプリケーションが送信側Beanの送信メソッドを呼び出す
送信側BeanがJMSメッセージを作成し、出力ポート宛に送信
送信側BeanからアプリケーションにCorrelatorが戻される
アプリケーションがCorrelatorに対応するメッセージの受信を要求する
5. 応答メッセージを受信する
6. アプリケーションに応答が返される
55
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
送信側Bean [3/3]
＜Note＞
<Blank Page>
56
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
遅延応答の処理
遅延応答が発生するケース
据え置き応答ありでメッセージを送信した場合
応答を受信する前に送信側Beanが終了した場合に発生
同期応答ありでメッセージを送信した場合
応答を受信する前に送信側Beanがタイムアウト・エラーになった場合に発生
応答メッセージが遅延した場合の対策を提供
事前に指定したMDBが遅延応答メッセージを処理
アプリケーションから遅延応答処理を登録することで処理させる
据え置き応答の場合、アプリケーションが明示的に遅延応答を登録して処理
同期応答の場合、システムが自動的に遅延応答を登録し処理
①送信要求
Business Logic
EJB
③Correlator
④遅延応答登録
(with Correlator)
②メッセージ送信
送信側
Bean
出力ポート
⑥遅延応答を処理
MDB
リスナー・ポート
57
⑤応答メッセージ送信
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
遅延応答の処理
＜Note＞
送信側Beanが応答を受信する時、なにかしらの理由で応答が遅れてしまった場合にはアプリケーションは応答
メッセージを受信することができません。EMSではそのような遅延した応答メッセージを、処理する仕組みを提供
しています。
遅延応答が発生した場合、アプリケーションはEMSに遅延処理の登録を行うことで、メッセージが到着した際に
MDBにそのメッセージの処理をさせることが出来ます。このMDBは遅延処理用に事前に登録しておく必要があり
ます。
遅延応答が発生するケースには、以下が考えられます。
据え置き応答ありでメッセージを送信した場合
アプリケーションからの受信要求に対して応答メッセージを受信できなかった場合に発生します。この場
合、アプリケーションはEMSに対して、遅延応答の処理の依頼を登録することができます。（アプリケー
ションから明示的に登録をする必要があります。）
同期応答ありでメッセージを送信した場合
応答を受信する前にアプリケーションがタイムアウト・エラーになった場合に発生します。タイムアウト・エ
ラーが起こると、アプリケーションはそのメッセージに対する応答は受信することができません。この時点で
EMSは遅延応答処理の対象として、自動的に登録します。
58
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
受信側Bean [1/3]
MDBベースとStateless Session Beanベースの2種類の受信側Bean
MDBベースの受信側Bean（以降「受信側Bean」）
JMS宛先にメッセージが到着したのをトリガーに起動する
Statless Session Beanベースの受信側Bean（以降「アプリケーション呼び出し可能受信
側Bean」）
アプリケーションからの呼び出しで起動する
受信側Bean
メッセージがJMS宛先に到着するとonMessage(Message)メソッドが起動される
受信側Beanから他のEJBを呼び出す
データのマッピング機能を使用することができる
受信メッセージを解析してEJBに引数を渡す
応答の送信の有無を選択できる
応答なし/同期応答あり
アプリケーション呼び出し可能受信側Bean
入力ポートを使用してメッセージを受送信
データのマッピング機能を使用することが出来る
非同期応答の送信の有無を選択できる
応答なし/非同期応答あり
59
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
受信側Bean [1/3]
＜Note＞
メッセージの受信要求には受信側Beanを使用します。受信側BeanにはMDBベース（以降「受信側Bean」）と
Stateless Session Beanベース（以降「アプリケーション呼び出し可能受信側Bean」）の2種類があります。
受信側Beanはリスナーに登録してあるJMS宛先にメッセージが到着することで起動されます。受信側Beanは
JMSメッセージを受け取ると、JMSメッセージもしくはメッセージから抽出したパラメータのいずれかを渡して別のメ
ソッドを呼び出すことができます。
受信側Beanは受信したメッセージに対する応答の送信方法を選択することが出来ます。
応答なし
アプリケーションはメッセージを受信し、応答を返さないケースです。
同期応答あり
アプリケーションはメッセージを受信し、同期応答を送信するケースです。受信側Beanはメッセージを
受信すると、同じBean内、もしくは別のEJBのメソッドを起動します。メソッドから戻りを受け取ると、リ
クエストメッセージに設定されている応答の宛先へ送信します。
アプリケーション呼び出し可能受信側 Beanは、ユーザーアプリケーションからの受信要求によって起動されます。
アプリケーション呼び出し可能受信側Beanは受信したメッセージに対する応答の送信を選択できます。
応答なし
アプリケーションはメッセージを受信し、応答を返さないケースです。
非同期応答あり
アプリケーションはメッセージを受信し、応答を非同期に送信するケースです。アプリケーション呼び出し
可能受信側Beanは、アプリケーションからの受信要求により起動され、メッセージとCorrelatorを呼び
出し元へ戻します。アプリケーションはCorrelatorを引数として送信を要求することで、受信メッセージに
対する応答メッセージを送信することが出来ます。
60
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
受信側Bean [2/3]
受信側Bean：応答なし
②EJBの呼び出し
①onMessage(msg)
受信側
Bean
リスナーポート
Business Logic
EJB
1. キュー宛先にメッセージが送信され、リスナー・ポートによって受信側Beanが起動される
2. 受信側Beanがアプリケーションを起動する
受信側Bean：同期応答あり
①onMessage(msg)
リスナーポート
②EJBの呼び出し
受信側
Bean
Business Logic
EJB
③応答送信
1. キュー宛先にメッセージが送信され、リスナー・ポートによって受信側Beanが起動される
2. 受信側Beanがアプリケーションを起動し、処理結果を待つ
3. 受信側Beanが処理結果を送信する
61
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
受信側Bean [2/3]
＜Note＞
<Blank Page>
62
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
受信側Bean [3/3]
アプリケーション呼び出し可能受信側Bean
EMS
Runtime
①受信要求
②メッセージ受信
受信側
Bean
③メッセージ&Correlator受信 Business Logic
EJB
④応答送信(with Correlator)
入力ポート
⑤応答メッセージ送信
1.
2.
3.
4.
5.
アプリケーションが受信側Beanの受信メソッドを呼び出す
受信側Beanが入力ポートを使用してメッセージを受信
受信側BeanからアプリケーションにメッセージとCorrelatorが戻される
アプリケーションから受信側Beanの送信メソッドを呼び出す
受信側Beanは応答メッセージとCorrelatorを入力ポートを送信する
63
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
受信側Bean [3/3]
＜Note＞
<Blank Page>
64
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
メッセージ・ポート
メッセージを送受信する宛先やメッセージの属性を定義したコンポーネント
EMSはメッセージ・ポートに対して送受信する
入力ポート
メッセージを受信するための宛先とコネクション・ファクトリーを指定
応答メッセージを送信するための宛先とコネクション・ファクトリーを指定
アプリケーション呼び出し可能受信側Beanで使用
出力ポート
メッセージを送信する宛先とコネクション・ファクトリーを指定
応答メッセージを受信するための宛先とコネクション・ファクトリーを指定
送信側Beanで使用
リスナー・ポート
メッセージを受信する宛先とコネクション・ファクトリーを指定
MDBベースの受信側Beanで使用
JNDIネームスペース
キュー・マネージャー
コネクション・ファクトリー
EMS
メッセージ・ポート
キュー宛先
キュー
キュー宛先
キュー
65
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
メッセージ・ポート
＜Note＞
<Blank Page>
66
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
データ・マッピング
メソッドの引数とJMSメッセージ間の変換を行う機能
送信時：メソッド引数からJMSメッセージを作成する
受信時：JMSメッセージからメソッド引数に変換する
アプリケーションでJMSメッセージを意識する必要が無い
EJBクライアントからEJBを呼び出す場合と同様のイメージで呼び出せる
データ・マッピングを使用しない場合は、JMSメッセージを意識した作りが必要
EMS作成時にウィザードでマッピングの有無や構造を定義する
メソッド・シグニチャーの指定で定義
マッピング構造はメッセージ・フォーマットIDによって識別される
Business Logic EJB
送信側Beanが引数を元にJMSメッセージを作成
：
//送信側Beanの呼び出し
送信側
Bean
sendWithResponse(param1,param2,param3
param1,param2,param3);
param1,param2,param3
：
JMSメッセージ
JMSヘッダー
param1
param2
param3
受信側
Bean
抽出した引数でアプリケーションを起動
受信側BeanがJMSメッセージから引数を抽出
67
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
データ・マッピング
＜Note＞
EMSではJMSメッセージとメソッドの引数間の相互変換を行うデータ・マッピングの機能を提供しています。デー
タ・マッピングを使用することで、開発者はJMSメッセージの構造を意識する必要がなくなります。
データ・マッピングを使用すると、受信側Beanから呼び出されるアプリケーションのメソッドは、JMSメッセージの内
容を引き数の形で受け取ります。EMSは、JMSメッセージを解析して、メソッド引き数へマッピングを行っています。
同様に、データ・マッピングを使用してメッセージを送信する場合には、アプリケーションは引き数を使用して送信
側Bean のメソッドを呼び出します。EMSは、受け取った引き数をJMSメッセージへパックし、送信します。開発
者はEJBクライアントがEJBのメソッドを呼び出すのと同様のイメージでメッセージング処理を行うことができます。
データ・マッピングを使用しない場合は、受信側Beanのターゲット・メソッドはJMSメッセージを受信します。同様
に、アプリケーションがメッセージを送信するには、JMS メッセージを使用して送信側 Bean のメソッドを呼び出し
ます。従って、データ・マッピングを使用しない場合、開発者はJMSメッセージを意識したアプリケーションを作成し
なければなりません。
データ・マッピングはEMSの作成時にウィザードで有無や構造を、メソッド・シグニチャーを指定することで定義しま
す。マッピングの構造はメッセージ・フォーマットIDのよって識別されます。実際の送受信の際には、このフォーマット
IDはJMSメッセージのJMSTypeヘッダーにセットされます。
68
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
≪参考資料≫
「WMQ Javaインターフェース（Base & JMS）ワークショップ」資料
MQ Javaインターフェース
MQ Javaデザインのポイント
MQ Javaシステム構成
MQ Javaパフォーマンス
「WebSphere基幹システム構築ワークショップ」資料
メッセージング
「WebSphere最新動向ワークショップ2003.12」資料
ネーミング・サービス
WebSphere Application Server V5.1 InfoCenter
http://publib.boulder.ibm.com/infocenter/ws51help/index.jsp
ISE WebSphere最新テクノロジー検証
最終回 「Message Driven Beanによる並列処理と順序処理」
http://www-6.ibm.com/jp/software/websphere/developer/wv5/ise/index.html
69
Copyright ISE Co,.Ltd
＜MQ-WAS連携-第５章＞
＜Note＞
<END>
70
Copyright ISE Co,.Ltd