|
|
以下の節では、WebLogic JMS の付加価値機能を使用して JMS アプリケーションをプログラム的に管理する方法について説明します。
以下の節では、ロールバックまたは回復したメッセージを管理する方法について説明します。
一時的または外部的な要因でアプリケーションがメッセージを正しく処理できない場合に、メッセージの再配信を遅延させることができます。これによって、アプリケーションは、現時点では処理できない「有害な」メッセージを一時的に受信できないようにすることができます。メッセージがロールバックまたは回復される場合、再配信遅延は、メッセージが止められてから再配信が試行されるまでの間隔です。
JMS でメッセージをすぐに再配信すると、エラーの原因が解決されず、アプリケーションはメッセージを処理できないままの場合があります。ただし、アプリケーションが再配信遅延用にコンフィグレーションされている場合、メッセージがロールバックまたは回復されると、メッセージは再配信の遅延が過ぎるまで止められます。遅延の期間を過ぎた時点でメッセージを再配信できるようになります。
セッションによって消費された結果、ロールバックまたは回復したすべてのメッセージは、ロールバックまたは回復時にそのセッションの再配信遅延を受信します。単一のユーザ トランザクションの一部として複数のセッションで消費されたメッセージは、個々のメッセージを消費したセッションの機能として異なる再配信遅延を受信します。意識的か、または失敗の結果、クライアントによる確認応答またはコミットされていないメッセージには、再配信遅延が割り当てられません。
セッションは、作成時に接続ファクトリから再配信遅延を継承します。接続ファクトリの RedeliveryDelay 属性は、Administration Console でコンフィグレーションします。
詳細については、Administration Console オンライン ヘルプの「接続ファクトリのコンフィグレーション」を参照してください。
セッションを作成するアプリケーションは、javax.jms.Session インタフェースに対する WebLogic 固有の拡張を使用して接続ファクトリ設定をオーバーライドできます。セッション属性は動的なので、いつでも変更できます。セッションの再配信遅延を変更すると、メッセージが非恒久トピックを使用するセッション内にある場合を除いて、変更後にそのセッションで消費およびロールバック (または回復) されるすべてのメッセージに影響します。
| 注意 : | セッションで非恒久トピックを使用している場合、setRedeliveryDelay メソッドは適用されません。その結果、非恒久トピック コンシューマを使用してワークフローを駆動している場合に予期しない動作が発生することがあります。 |
セッションに対して再配信遅延を設定するメソッドは、javax.jms.Session インタフェースの拡張である weblogic.jms.extensions.WLSession インタフェースを介して提供されます。セッションの再配信遅延を定義するには、以下のメソッドを使用します。
public void setRedeliveryDelay(
long redeliveryDelay
) throws JMSException;
public long getRedeliveryDelay(
) throws JMSException;
WLSession クラスの詳細については、weblogic.jms.extensions.WLSession の Javadoc を参照してください。
再配信遅延がセッションで設定されているかどうかに関係なく、メッセージがロールバックまたは回復される送り先で再配信遅延の設定をオーバーライドできます。メッセージの再配信に割り当てられた再配信遅延のオーバーライドは、メッセージがロールバックまたは回復されるときに有効になります。
送り先の RedeliveryDelayOverride 属性は、Administration Console でコンフィグレーションします。詳細については、以下を参照してください。
WebLogic JMS によるアプリケーションへのメッセージ再配信の試行回数に制限を設けることができます。送り先へのメッセージの再配信の失敗が指定した回数に達すると、そのメッセージ送り先に関連付けられたエラー送り先にメッセージをリダイレクトできます。再配信の制限がコンフィグレーションされていて、エラー送り先がコンフィグレーションされていない場合、永続メッセージまたは非永続メッセージは再配信の制限に達すると削除されます。
代わりに、メッセージ プロデューサの set メソッドを使用して、再配信の制限値を動的に設定できます (「メッセージ プロデューサ属性の設定」を参照)。
送り先によるコンシューマへのメッセージ再配信の試行が指定した再配信制限に達すると、送り先はメッセージを配信不能にします。RedeliveryLimit 属性は、送り先で設定され、Administration Console でコンフィグレーションできます。この設定は、メッセージのプロデューサ側で設定された再配信制限をオーバーライドします。詳細については、以下を参照してください。
配信されなかったメッセージのエラー送り先が JMS サーバにコンフィグレーションされている場合は、送り先に配信できないと判断されたメッセージが指定したエラー送り先にリダイレクトされます。エラー送り先はトピックまたはキューのいずれかですが、定義されている送り先と同じ JMS サーバにコンフィグレーションする必要があります。エラー送り先がコンフィグレーションされていない場合、配信されなかったメッセージは削除されます。
ErrorDestination 属性は、Administration Console を使用して、スタンドアロンの送り先および共通分散送り先にコンフィグレーションします。詳細については、以下を参照してください。
| 注意 : | 再配信の順序付けを使用しているアプリケーションは、メッセージ順序単位を使用するようにアップグレードすることをお勧めします。「メッセージ順序単位の使用」を参照してください。 |
JMS 仕様により、特定のプロデューサからコンシューマに最初に配信されるすべてのメッセージは、生成された順序でコンシューマに到着することが確保されています。WebLogic JMS はこの要件を満たすだけでなく、さらに「メッセージの再配信の順序付け」機能を提供しています。この機能は、再配信メッセージについても正しい順序を保証します。
この保証を提供するために、WebLogic JMS では特定の制約を課す必要があります。制約は次のとおりです。
| 注意 : | MDB (メッセージ駆動型 Bean) については、コンシューマ数は、ある特定の MDB 用にデプロイされた MDB インスタンス数の関数です。インスタンス数の初期値および最大値は 1 に設定する必要があります。そうでない場合、再配信メッセージに関する順序付けは保証できません。 |
WebLogic メッセージング ブリッジまたは MDB を使用する非同期コンシューマや JMS アプリケーションでは、メッセージ パイプラインのサイズを 1 に設定する必要があります。パイプラインのサイズは、受信側アプリケーションが使用する JMS 接続ファクトリの [最大メッセージ数] 属性を使用して設定します。1 より大きい値は、再配信メッセージの前に追加の送信中メッセージがある可能性を示します。MDB アプリケーションでは、アプリケーションに固有の JMS 接続ファクトリを定義し、その接続ファクトリの [最大メッセージ数] 属性の値を 1 に設定する必要があります。さらに、MDB アプリケーションの EJB 記述子で接続ファクトリを参照する必要があります。
EJB のプログラミングの詳細については、『WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「メッセージ駆動型 EJB」を参照してください。
順序付き再配信機能を実装した JMS アプリケーションには、JTA トランザクション (具体的には MDB および WebLogic メッセージング ブリッジ) を使用する非同期コンシューマのパフォーマンス低下が伴います。原因は送信中メッセージ数が強制的に 1 に削減されることであり、そのためメッセージは集約されずにクライアントに送信されます。
WebLogic JMS には、アクティブなメッセージ有効期限ポリシーが用意されています。このポリシーでは、期限切れメッセージの検索方法と処理方法を設定できます。この機能では、単純に期限切れメッセージを破棄するか、期限切れメッセージを破棄してそれをログに記録するか、または期限切れメッセージをローカル JMS サーバのエラー送り先に転送することによって期限切れメッセージが即座に消去できます。
アプリケーションへのメッセージ配信を、将来の指定した時間にスケジューリングできます。短い期間 (秒や分など) の後でメッセージを配信することも、長い期間をおいた後で配信 (数時間単位でバッチ処理する場合など) することもできます。その配信時間になって配信されるまでメッセージは表示されないため、将来の特定の時間に作業をスケジューリングできます。
メッセージが送信されるのは 1 回だけで、繰り返し送信されることはありません。メッセージが繰り返し送信されるようにするには、受信したスケジューリング済みのメッセージを元の送信先に戻す必要があります。一度のみというセマンティクスを保証するため、受信、送信、およびこれらに関連する作業は同じトランザクションのもとで行われます。
個々のプロデューサに対する配信時間の設定および取得のサポートは、javax.jms.MessageProducer インタフェースの拡張である weblogic.jms.extensions.WLMessageProducer インタフェースを介して提供されます。個々のプロデューサに対して配信時間を定義するには、以下のメソッドを使用します。
public void setTimeToDeliver(
long timeToDeliver
) throws JMSException;
public long getTimeToDeliver(
) throws JMSException;
WLMessageProducer クラスの詳細については、weblogic.jms.extensions.WLMessageProducer の Javadoc を参照してください。
DeliveryTime は、メッセージを配信するのに最も早い絶対時間を定義できる JMS メッセージ ヘッダです。つまり、メッセージはメッセージング システムによって保持され、その時間になるまでどのコンシューマにも配信されません。
DeliveryTime は、JMS ヘッダ フィールドとして送り先でのメッセージのソート、またはメッセージの選択に使用できます。データ型変換の目的で、配信時間は長整数として保存されます。
| 注意 : | メッセージの配信時間の値を設定しても、このフィールドには影響しません。これは、メッセージが送信またはパブリッシュされるたびに、JMS がこの値をプロデューサの値でオーバーライドするためです。ここで説明するメッセージ配信時間の方法は、プロデューサによって設定される他の JMS メッセージ フィールド (配信モード、優先度、配信時間、存続時間、再配信遅延、再配信制限など) と似ています。特に、これらのフィールドの設定は JMS プロバイダ (WebLogic JMS を含む) 用に予約されます。 |
個々のメッセージに対する配信時間の設定および取得のサポートは、javax.jms.Message インタフェースの拡張である weblogic.jms.extensions.WLMessage インタフェースを介して提供されます。メッセージの配信時間を定義するには、以下のメソッドを使用します。
public void setJMSDeliveryTime(
long deliveryTime
) throws JMSException;
public long getJMSDeliveryTime(
) throws JMSException;
WLMessage クラスの詳細については、weblogic.jms.extensions.WLMessage の Javadoc を参照してください。
作成されたプロデューサは、接続の作成に使用する接続ファクトリ (プロデューサもそこに含まれます) から TimeToDeliver 属性 (ミリ秒) を継承します。配信時間がプロデューサで設定されているかどうかに関係なく、メッセージが送信またはパブリッシュされる送り先で配信時間の設定をオーバーライドできます。管理者は、相対形式またはスケジューリング済み文字列形式のいずれかで送り先に対する TimeToDeliverOverride 属性を設定できます。
指定した存続時間の値 (JMSExpiration) が指定した配信時間と同じかそれより少ない場合、メッセージの配信は成功します。ただし、メッセージは通知されずに期限切れになります。
相対 TimeToDeliverOverride は、整数で指定した文字列で、Administration Console でコンフィグレーション可能です。
スケジューリング済み TimeToDeliverOverride は weblogic.jms.extensions.Schedule クラスを使用しても指定できます。このクラスでは、スケジュールを取得し、次回のメッセージ配信時間を返すメソッドが提供されています。
cron に似た文字列がスケジュールの定義に使用されます。書式は、次の BNF 構文で定義されます。
schedule := millisecond second minute hour dayOfMonth month
dayOfWeek
second フィールドを指定するための BNF 構文は次のとおりです。
second := * | secondList
secondList := secondItem [, secondList]
secondItem := secondValue | secondRange
SecondRange := secondValue - secondValue
ミリ秒、分、時、日、月、曜日に対する同様の BNF 文を 2 番目の構文から取得できます。各フィールドの値は、以下の範囲の正の整数で指定します。
milliSecondValue := 0-999
milliSecondValue := 0-999
secondValue := 0-59
minuteValue := 0-59
hourValue := 0-23
dayOfMonthValue := 1-31
monthValue := 1-12
dayOfWeekValue := 1-7
| 注意 : | これらの値は、monthValue を除いて、java.util.Calendar クラスで使用するのと同じ範囲です。monthValue の java.util.Calendar の範囲は、1-12 ではなく 0-11 です。 |
この構文を使用すると、2 つの時間の間のすべての時間を示す値の範囲で各フィールドを表すことができます。たとえば、dayOfWeek フィールドの 2-6 は、月曜から金曜まで (双方の曜日を含む) を示します。また、カンマ区切りのリストで各フィールドを指定することもできます。たとえば、分フィールドの 0,15,30,45 は、1 時間内の 15 分おきの値を示します。さらに、個々の値と値の範囲の組み合わせで各フィールドを定義することもできます。たとえば、時フィールドの 9-17,0 は、午前 9 時と午後 5 時の間と深夜 12 時を示します。
dayOfWeek の値 1 は日曜日。l、つまり last (大文字と小文字の区別はない) は、そのフィールドで使用できる値で最も大きな値を示す。 | 注意 : | このクラスの静的メソッドのいずれか 1 つに対するメソッド パラメータとして Calendar が指定されない場合、使用されるカレンダーは、デフォルトの java.util.TimeZone およびデフォルトの java.util.Locale がある java.util.GregorianCalendar です。 |
weblogic.jms.extensions.schedule クラスには、反復時間式に一致する次のスケジュール時間を返すメソッドがあります。この式は、TimeToDeliverOverride と同じ構文を使用します。ミリ秒で返される時間は、相対でも絶対でもかまいません。
WLSession クラスの詳細については、weblogic.jms.extensions.Schedule の Javadoc を参照してください。
次のメソッドを使用すると、指定した時間の後の次のスケジュール時間を定義できます。
public static Calendar nextScheduledTime(
String schedule,
Calendar calendar
) throws ParseException {
次のメソッドを使用すると、現在の時間の後の次のスケジュール時間を定義できます。
public static Calendar nextScheduledTime(
String schedule,
) throws ParseException {
次のメソッドを使用すると、指定した時間の後の次のスケジュール時間を絶対ミリ秒で定義できます。
public static long nextScheduledTimeInMillis(
String schedule,
long timeInMillis
) throws ParseException
次のメソッドを使用すると、指定した時間の後の次のスケジュール時間を相対ミリ秒で定義できます。
public static long nextScheduledTimeInMillisRelative(
String schedule,
long timeInMillis
) throws ParseException {
次のメソッドを使用すると、現在の時間の後の次のスケジュール時間を相対ミリ秒で定義できます。
public static long nextScheduledTimeInMillisRelative(
String schedule
) throws ParseException {
例外リスナは、接続に問題が発生するとアプリケーションに非同期的に通知します。このメカニズムは、通知されない限り接続がメッセージの消費を待ち続ける場合に役立ちます。
| 注意 : | 例外リスナの目的は、接続によって送出されたすべての例外をモニタすることではなく、本来なら配信されない例外を配信することです。 |
接続に対する例外リスナを定義するには、次の Connection メソッドを使用します。
public void setExceptionListener(
ExceptionListener listener
) throws JMSException
接続に対する ExceptionListener オブジェクトを指定しなければなりません。
JMS プロバイダは、接続の問題を発見すると、次の ExceptionListener メソッドを使用して例外リスナ (定義されている場合) に通知します。
public void onException(
JMSException exception
)
JMS プロバイダは、このメソッドを呼び出すときに、問題を説明する例外を指定します。
接続に対する例外リスナにアクセスするには、次の Connection メソッドを使用します。
public ExceptionListener getExceptionListener(
) throws JMSException
特定の接続に関連付けられているメタデータにアクセスするには、次の Connection メソッドを使用します。
public ConnectionMetaData getMetaData(
) throws JMSException
このメソッドは、JMS メタデータへのアクセスに使用する ConnectionMetaData オブジェクトを返します。次の表に、JMS メタデータのタイプと、それらにアクセスするために使用できる get メソッドを示します。
ConnectionMetaData クラスの詳細については、javax.jms.ConnectionMetaData の Javadoc を参照してください。
メッセージの流れを制御するために、以下の start() メソッドと stop() メソッドをそれぞれ使用して、接続を一時的に開始および停止できます。
start() メソッドと stop() メソッドの詳細は以下のとおりです。
public void start(
) throws JMSException
public void stop(
) throws JMSException
新しく作成された接続は停止しています。接続が開始されるまで、メッセージは受信されません。一般に、他の JMS オブジェクトは、「JMS アプリケーションの設定」で説明するとおり、接続が開始される前からメッセージを処理するよう設定されます。メッセージは、停止している接続上に作成することはできますが、停止している接続に届けることはできません。
接続が開始されていれば、stop() メソッドを使用して接続を停止できます。このメソッドは、次の手順を実行します。
一般に、JMS プロバイダは接続を作成するときに大量のリソースを割り当てます。接続が使用されなくなったら、その接続をクローズしてリソースを解放する必要があります。接続をクローズするには、次のメソッドを使用します。
public void close(
) throws JMSException
このメソッドは、次の手順を実行して系統的にシャットダウンを行います。
接続をクローズすると、関連付けられているすべてのオブジェクトがクローズされます。受信メッセージの acknowledge() メソッドを除いて、接続で作成または受信されたメッセージ オブジェクトは引き続き使用できます。クローズされた接続をクローズしても影響はありません。
| 注意 : | クローズされた接続のセッションから受信したメッセージを確認応答しようとすると、IllegalStateException が送出されます。 |
例外リスナは、セッションに問題が発生すると、クライアントに非同期的に通知します。これは、通知されない限りセッションがメッセージの消費を待ち続ける場合に役立ちます。
| 注意 : | 例外リスナの目的は、セッションによって送出されたすべての例外をモニタすることではなく、本来なら通知されない例外を通知することです。 |
セッションに対する例外リスナを定義するには、次の WLSession メソッドを使用します。
public void setExceptionListener(
ExceptionListener listener
) throws JMSException
セッションに対する ExceptionListener オブジェクトを指定しなければなりません。
JMS プロバイダは、セッションの問題を発見すると、次の ExceptionListener メソッドを使用して例外リスナ (定義されている場合) に通知します。
public void onException(
JMSException exception
)
JMS プロバイダは、このメソッドを呼び出すときに、問題を説明する例外を指定します。
セッションに対する例外リスナにアクセスするには、次の WLSession メソッドを使用します。
public ExceptionListener getExceptionListener(
) throws JMSException
| 注意 : | 1 つのセッションに対して 1 つのスレッドしか存在しないので、例外リスナとメッセージ リスナ (非同期メッセージ配信用に使用される) を同時に実行することはできません。そのため、問題が発生したときにメッセージ リスナが実行されている場合、そのメッセージ リスナが実行を完了するまで例外リスナはブロックされます。メッセージ リスナの詳細については、「メッセージの非同期受信」を参照してください。 |
接続と同じように、JMS プロバイダはセッションを作成するときに大量のリソースを割り当てます。セッションが使用されなくなったら、そのセッションをクローズしてリソースを解放することをお勧めします。セッションをクローズするには、次の Session メソッドを使用します。
public void close(
) throws JMSException
| 注意 : | close() メソッドは、セッション スレッドとは別個のスレッドから呼び出すことができる唯一の Session メソッドです。 |
このメソッドは、次の手順を実行して系統的にシャットダウンを行います。
セッションをクローズすると、関連付けられているすべてのプロデューサとコンシューマもクローズされます。
| 注意 : | onMessage() メソッド呼び出し内で close() メソッドを発行する場合、システム管理者は接続ファクトリをコンフィグレーションするときに [メッセージの短縮を許可] チェック ボックスを選択しなければなりません。 |
送り先の動的作成に関する手順については、以降の節で説明します。
次のいずれかの方法を使用して、JMS 送り先 (キューまたはトピック) を動的に削除できます。
JMS サーバは削除された送り先をリアル タイムに削除します。従って、削除を有効にするために JMS サーバを再デプロイする必要はありません。送り先の動的削除に関する手順については、以降の節で説明します。
送り先の削除を正常に完了するには、次の事前条件が満たされている必要があります。
これらの事前条件のいずれかが満たされていない場合、削除は実行できません。
送り先を削除する場合、以下の動作とセマンティクスが適用されます。
InvalidDestinationException を受け取ります。ConsumerClosedException が生成され、親セッションの ExceptionListener (存在する場合) に配信されます。この例外には「Destination was deleted」と示されます。
コンシューマがクローズされた時点でコンシューマに未処理の receive() 処理がある場合、その処理は取り消され、呼び出し側はメッセージが存在しないことを示す null を受け取ります。アプリケーションで close() 以外の実行を試みると、クローズされたコンシューマの IllegalStateException が発生します。
close() 以外の実行を試みると、クローズされたブラウザの IllegalStateException が発生します。ブラウザのクローズにより、ブラウザに関連付けられたすべての列挙値が暗黙的にクローズされます。hasMoreElements() の呼び出しで true の値が返され、以降に nextElement() を呼び出していない場合は、列挙により次の要素を列挙できることが保証されます。その結果、詳細が生成されます。クローズ前の最後の呼び出しが hasMoreElements() を呼び出し、返された値が true であった場合は、以下の動作が適用されます。nextElement() の最初の呼び出しではメッセージが返される。nextElement() の呼び出しでは NoSuchElementException が送出される。nextElement() の呼び出し前に hasMoreElements() を呼び出すと、true が返る。nextElement() の最初の呼び出し前に hasMoreElements() を呼び出すと、false が返る。
ある特定の列挙値が一度も呼び出されていないか、クローズ前の最後の呼び出しが nextElement() を呼び出した場合、またはクローズ前の最後の呼び出しが hasMoreElements() を呼び出し、返された値が false であった場合には、以下の動作が適用されます。
hasMoreElements() の呼び出しでは false が返される。nextElement() の呼び出しでは NoSuchElementException が送出される。ResourceAllocationException を受け取ります。
永続メッセージがある送り先が、削除されてからすぐに再作成され、そのとき JMS サーバが動作中でなかった場合、JMS サーバは送り先のバージョン番号 (コンフィグレーション ファイル config.xml の CreationTime フィールドを使用) と永続メッセージ内の送り先バージョン番号を比較します。この場合、古い送り先に残っている永続メッセージのバージョン番号は、config.xml ファイルにある再作成された送り先のバージョン番号よりも古い番号になります。JMS サーバが再起動すると、残っている永続メッセージは破棄されます。
ただし、永続メッセージのバージョン番号が、再作成された送り先の config.xml にあるバージョン番号よりも新しい場合は、送り先が削除されてから (JMS サーバが動作中でない状態で) 再作成されたときにシステム クロックがロールバックされたか、異なる config.xml が使用されています。この場合、JMS サーバの起動が失敗します。永続メッセージを保存するために、永続メッセージ内のバージョン番号に一致するバージョン番号 (CreationTime フィールド) を config.xml に設定できます。または、config.xml のバージョン番号を、永続メッセージ内のバージョン番号よりも新しい番号に変更できます。このようにすると、JMS サーバは再起動時にメッセージを削除できます。
削除した送り先およびホストする JMS サーバに関する統計は、メッセージが物理的に削除されたときに更新されます。ただし、別の処理の結果が出るまで削除が遅れるメッセージもあります。このようなメッセージには、トランザクションで送受信されるメッセージや、クライアントが受信する確認応答されていない非トランザクション メッセージが含まれます。
一時的な送り先を使用することで、サーバ定義の送り先のコンフィグレーションと作成に伴うシステム管理のオーバーヘッドを発生させずに、必要に応じてアプリケーションで送り先を作成できます。
JMS アプリケーションでは、JMSReplyTo ヘッダ フィールドを使用して、リクエストに応答を返すことができます。送信側アプリケーションでは、オプションとして、メッセージの JMSReplyTo ヘッダ フィールドをその一時的な送り先の名前に設定することで、使用している一時的な送り先を別のアプリケーションに対して公開できます。
一時的な送り先は、「一時的な送り先の削除」の説明のとおりに delete() メソッドを使用して削除されない限り、現在の接続が継続している間だけ存在します。
サーバが再起動すると、メッセージは使用できなくなるので、すべての PERSISTENT メッセージは自動的に NON_PERSISTENT メッセージになります。そのため、一時的な送り先は、再起動によるデータの消失が許されないビジネス ロジックには適していません。
| 注意 : | 一時的な送り先は、JMS サーバの [一時的な送り先をホスト |
以降の節では、一時的なキュー (PTP) または一時的なトピック (Pub/Sub) の作成方法について説明します。
次の QueueSession メソッドを使用して、一時的なキューを作成できます。
public TemporaryQueue createTemporaryQueue(
) throws JMSException
たとえば、現在の接続が継続している間だけ存在する TemporaryQueue への参照を作成するには、次のメソッド呼び出しを使用します。
QueueSender = Session.createTemporaryQueue();
次の TopicSession メソッドを使用して、一時的なトピックを作成できます。
public TemporaryTopic createTemporaryTopic(
) throws JMSException
たとえば、現在の接続が継続している間だけ存在する一時的なトピックへの参照を作成するには、次のメソッド呼び出しを使用します。
TopicPublisher = Session.createTemporaryTopic();
一時的な送り先の使用が終了したら、次の TemporaryQueue メソッドまたは TemporaryTopic メソッドを使用して送り先を削除し、関連リソースを解放できます。
public void delete(
) throws JMSException
WebLogic JMS では、恒久サブスクリプションおよび非恒久サブスクリプションがサポートされています。
恒久サブスクリプションの場合、WebLogic JMS では、メッセージはサブスクライバに配信されるか、または期限切れになるまで永続ファイルまたはデータベースに格納されます。この場合、メッセージの配信時にサブスクライバがアクティブな状態でなくてもかまいません。サブスクライバを表す Java オブジェクトが存在していれば、サブスクライバはアクティブであるとみなされます。恒久サブスクリプションは、Pub/Sub メッセージングのみでサポートされています。
| 注意 : | 恒久サブスクリプションは、分散トピックに対しては作成できません。ただし、分散トピックのメンバーに対して恒久サブスクリプションを作成することはできます。こうすると、他のトピック メンバーは、恒久サブスクリプションを持つメンバーにメッセージを転送します。分散トピックの使用方法については、「分散送り先の使用」を参照してください。 |
非恒久サブスクリプションの場合、WebLogic JMS では、メッセージはアクティブ セッションを持つアプリケーションにのみ配信されます。アプリケーションがリスンしていない間にトピックへ送信されたメッセージは、二度とそのアプリケーションに配信されません。つまり、非恒久サブスクリプションは、そのサブスクライバ オブジェクトが存在している間だけ存続します。デフォルトでは、サブスクライバは非恒久です。
メッセージがサブスクライバに配信されるか、または期限切れになるまで WebLogic JMS がそのメッセージを保持できるようにするためには、永続ファイルまたはデータベース ストアをコンフィグレーションして JMS サーバに割り当てる必要があります。
恒久サブスクリプションをサポートするには、接続に対してクライアント ID を定義する必要があります。
| 注意 : | JMS クライアント ID は、WebLogic セキュリティ レルムでのユーザ認証で使用される WebLogic Server ユーザ名とは必ずしも一致しません。JMS アプリケーションに適合していれば、JMS クライアント ID を WebLogic Server ユーザ名に設定することは当然可能です。 |
クライアント ID は、以下の 2 つの方法で設定できます。
public void setClientID(
String clientID
) throws JMSException
ユニークなクライアント ID を指定する必要があります。この代替方法を使用する場合は、デフォルトの接続ファクトリを使用すると (アプリケーションに適合している場合)、コンフィグレーション情報を変更する必要がありません。ただし、恒久サブスクリプションに対応しているアプリケーションの場合は、トピック接続を作成したらすぐに setClientID() を呼び出すようにする必要があります。
クライアント ID が接続に対してすでに定義されている場合は、IllegalStateException が送出されます。指定したクライアント ID が別の接続に対してすでに定義されている場合は、InvalidClientIDException が送出されます。
| 注意 : | setClientID() メソッドを使用してクライアント ID を指定する場合には、重複したクライアント ID が例外の送出なしに指定されてしまう危険性があります。たとえば、2 つの異なる接続に対して、同じ値を持つクライアント ID が同時に設定されると、競合状態のまま、同じ値が両方の接続に割り当てられる場合があります。このような重複の危険性を回避するには、コンフィグレーション時にクライアント ID を指定します。 |
クライアント ID を表示し、クライアント ID がすでに定義されているかどうかをテストするには、次の Connection メソッドを使用します。
public String getClientID(
) throws JMSException| 注意 : | 恒久サブスクリプションのサポートは、Pub/Sub メッセージング モデル固有の機能なので、クライアント ID はトピック接続でしか使用できません。キュー接続にもクライアント ID がありますが、JMS では使用されません。 |
| 注意 : | 恒久サブスクリプションは、一時的なトピックに対しては作成しないでください。一時的なトピックは、現在の接続が継続している間だけ存在するように設計されているからです。 |
以下の TopicSession メソッドを使用して、恒久サブスクリプション用のサブスクライバを作成できます。
public TopicSubscriber createDurableSubscriber(
Topic topic,
String name
) throws JMSException
public TopicSubscriber createDurableSubscriber(
Topic topic,
String name,
String messageSelector,
boolean noLocal
) throws JMSException
サブスクライバを作成するトピックの名前と恒久サブスクリプションの名前を指定する必要があります。
| 注意 : | 恒久サブスクリプションの名前に含めることのできない文字は、カンマ (,)、等号 (=)、コロン (:)、アスタリスク (*)、パーセント記号 (%)、および疑問符 (?) です。 |
また、メッセージをフィルタ処理するためのメッセージ セレクタ、および noLocal フラグ (この節で後述) を指定することもできます。メッセージ セレクタの詳細については、「メッセージのフィルタ処理」を参照してください。messageSelector を指定しない場合、デフォルトではすべてのメッセージが検索されます。
アプリケーションでは、JMS 接続を使用して同じトピックに対してパブリッシュとサブスクライブの両方を行うことができます。トピック メッセージはすべてのサブスクライバに配信されるので、アプリケーションは自身がパブリッシュしたメッセージを受信する可能性があります。これを防ぐために、JMS アプリケーションは noLocal フラグを true に設定できます。noLocal 値は、デフォルトでは false になっています。
恒久サブスクリプションの name は、クライアント ID ごとにユニークである必要があります。接続に対するクライアント ID の定義については、「クライアント ID の定義」を参照してください。
特定の恒久サブスクリプション用のサブスクライバをいつでも定義できるのは、1 つのセッションだけです。複数のサブスクライバが恒久サブスクリプションにアクセスできますが、同時にはアクセスできません。恒久サブスクリプションはファイルまたはデータベースに格納されます。
問題が発生した JMS 接続については、ベスト プラクティスとして、アプリケーションで JVM ガベージ コレクションを使用してクリーンアップするのではなく、JMS クライアントで常に close() メソッドを呼び出してクリーンアップすることをお勧めします。これは、JMS 自動再接続機能では、問題が発生した JMS 接続への参照が保持されるため、恒久サブスクリプションの ClientID に関しては特に重要です。したがって、常に connection.close() を使用して接続をクリーンアップします。また、接続リソースを確実にクリーンアップするため、finally ブロックを使用することも検討してください。このようにしない場合、接続を使用可能な状態に維持するためにシステム リソースが割り当てられてしまいます。
次のコードの抜粋では、close() および finally を JMS クライアントで使用して問題が発生した接続リソースをクリーンアップする例を示しています。
JMSConnection con = null;
try {
con = cf.createConnection();
con.setClientID("Fred");
// Do some I/O stuff;
}
finally {
if (con != null) con.close();
}
JMS 自動再接続機能の詳細については、「JMS クライアントの自動フェイルオーバ」を参照してください。
恒久サブスクリプションを削除するには、次の TopicSession メソッドを使用します。
public void unsubscribe(
String name
) throws JMSException
削除する恒久サブスクリプションの名前を指定する必要があリます。
以下の条件のいずれかに当てはまる場合は、恒久サブスクリプションを削除できません。
| 注意 : | Administration Console を使用して恒久サブスクリプションを削除することもできます。恒久サブスクリプションの管理については、「恒久サブスクリプションの管理」を参照してください。 |
恒久サブスクリプションを変更するには、以下の手順を実行します。
この手順は省略可能です。この手順が明示的に実行されない場合は、次の手順で恒久サブスクリプションが再作成されるときに暗黙的に削除が行われます。
noLocal のいずれかには異なる値を指定します。| 注意 : | 恒久サブスクリプションを再作成する場合には、重複した名前を持つ恒久サブスクリプションを作成しないよう注意してください。たとえば、使用できない JMS サーバから恒久サブスクリプションを削除しようとすると、削除は失敗します。続いて、別の JMS サーバで同じ名前の恒久サブスクリプションを作成すると、最初の JMS サーバが使用可能になったときに予期しない結果が生じることがあります。元の恒久サブスクリプションが削除されていないため、最初の JMS サーバが再び使用可能になると、重複した名前の 2 つの恒久サブスクリプションが存在することになります。 |
Administration Console またはパブリックな実行時 API を使用して、恒久トピック サブスクライバをモニタおよび管理できます。恒久サブスクライバ上のすべてのメッセージを表示、参照したり、ほとんどのメッセージを操作したりすることもできます。こうした管理機能には、メッセージの参照 (ソート目的)、メッセージの操作 (移動、削除など)、メッセージのインポートとエクスポートなどがあります。詳細については、『WebLogic JMS のコンフィグレーションと管理』の「JMS メッセージの管理」を参照してください。
WebLogic JMS には、メッセージの識別および転送を定義できる一連の標準ヘッダ フィールドが用意されています。さらに、プロパティ フィールドを使用すると、標準セットを拡張した、アプリケーション固有のヘッダ フィールドをメッセージ内に含めることができます。メッセージ ヘッダ フィールドおよびメッセージ プロパティ フィールドを使用して、通信しているプロセス間で情報をやり取りできます。
データをメッセージ本文ではなくプロパティ フィールドに含める主要な理由は、メッセージ セレクタを使用したメッセージのフィルタ処理をサポートするためです。XML メッセージ拡張機能以外では、メッセージ セレクタからメッセージ本文のデータにアクセスすることはできません。たとえば、プロパティ フィールドを使用して、あるメッセージに高い優先度を割り当てると仮定します。その場合、このプロパティ フィールドにアクセスし、至急の優先度が指定されたメッセージだけを選択するメッセージ セレクタを含むメッセージ コンシューマを作成できます。セレクタの詳細については、「メッセージのフィルタ処理」を参照してください。
JMS メッセージには、常にメッセージと共に送信されるヘッダ フィールドの標準セットが含まれます。これらはメッセージを受信するメッセージ コンシューマで利用でき、また、一部のフィールドはメッセージを送信するメッセージ プロデューサで設定できます。メッセージを受信したら、ヘッダ フィールドの値は変更できます。
ヘッダ フィールドの値を変更 (オーバーライド) する際は、メッセージ フィールドが JMS サブシステムによって上書きされる場合があることを考慮に入れる必要があります。たとえば、プロデューサで優先順位を設定するとメッセージの優先順位に影響しますが、send() メソッドに提供された値はプロデューサの設定をオーバーライドします。同様に、送り先で設定した値は、プロデューサによって設定された値や、send() メソッドに提供された値をオーバーライドします。ヘッダ フィールドの値を検証するには、send() メソッドの後にメッセージに対してクエリを実行するしかありません。
標準メッセージ ヘッダ フィールドの詳細については、「メッセージ ヘッダ フィールド」を参照してください。
次の表に、Message クラスの set メソッドと get メソッドを、サポートされているデータ型ごとに示します。
| 注意 : | set() メソッドを使用して設定されたヘッダ フィールド値は、send() メソッドによってオーバーライドされる場合もあります (次表参照)。 |
|
||||
|
WL_HOME\samples\server\examples\src\examples\jms\sender ディレクトリ (WL_HOME は WebLogic Platform のインストール先の最上位ディレクトリ) に収められている WebLogic Server 付属の examples.jms.sender.SenderServlet の例では、送信するメッセージのヘッダ フィールドを設定する方法、および送信後にメッセージのヘッダ フィールドを表示する方法を示します。
たとえば、send() メソッドの後に置く次のコードは、WebLogic JMS によってメッセージに割り当てられたメッセージ ID を表示します。
System.out.println("Sent message " +
msg.getJMSMessageID() + " to " +
msg.getJMSDestination());
プロパティ フィールドを設定するには、適切な set メソッドを呼び出して、プロパティ名と値を指定します。プロパティ フィールドを参照するには、適切な get メソッドを呼び出して、プロパティ名を指定します。
送信側アプリケーションはメッセージにプロパティを設定でき、受信側アプリケーションはそのプロパティを表示できます。受信側アプリケーションがプロパティを変更するには、まず次の clearProperties() メソッドを使用してプロパティを消去する必要があります。
public void clearProperties(
) throws JMSException
このメソッドは、メッセージ ヘッダ フィールドおよびメッセージ本文は消去しません。
| 注意 : | JMS 用に JMSX というプロパティ名のプレフィックスが予約されています。接続メタデータには、JMSX プロパティのリストが含まれています。getJMSXPropertyNames() メソッドを使用して、列挙リストとして、このリストにアクセスできます。詳細については、「接続メタデータへのアクセス」を参照してください。 |
| 注意 : | プロバイダ固有のプロパティ用に JMS_ というプロパティ名のプレフィックスが予約されています。このプレフィックスは標準の JMS メッセージングでは使用できません。 |
プロパティ フィールドは、boolean、byte、double、float、int、long、short、string の各データ型のいずれかに設定できます。次の表に、Message クラスの set メソッドと get メソッドを、サポートされているデータ型ごとに示します。
上記の表で説明した set メソッドおよび get メソッド以外にも、setObjectProperty() メソッドおよび getObjectProperty() メソッドを使用して、プロパティのデータ型の具体的なプリミティブ値を使用できます。具体的な値が使用されている場合、プロパティのデータ型はコンパイル時ではなく、実行時に決定されます。有効なオブジェクトのデータ型は、boolean、byte、double、float、int、long、short、および string です。
次の Message メソッドを使用して、すべてのプロパティ フィールド名にアクセスできます。
public Enumeration getPropertyNames(
) throws JMSException
このメソッドは、すべてのプロパティ フィールド名を列挙して返します。その後、プロパティ フィールドのデータ型に基づいて、上記の表で説明されている適切な get メソッドにプロパティ フィールド名を渡すことで、各プロパティ フィールドの値を取り出すことができます。
次の表は、メッセージ プロパティの変換表です。この表から、読み込み可能なデータ型を、書き込まれたデータ型に基づいて識別できます。
次の Message メソッドを使用して、プロパティの値が設定されているかどうかをテストできます。
public boolean propertyExists(
String name
) throws JMSException
プロパティ名を指定すると、メソッドはそのプロパティが存在するかどうかを示すブール値を返します。
たとえば、次のコードは、2 種類の String プロパティと 1 種類の int プロパティを設定します。
msg.setStringProperty("User", user);
msg.setStringProperty("Category", category);
msg.setIntProperty("Rating", rating);
メッセージ プロパティ フィールドの詳細については、「メッセージ プロパティ フィールド」または javax.jms.Message の Javadoc を参照してください。
| 注意 : | 参照できるのは、キューのメッセージ ヘッダ フィールドおよびメッセージ プロパティ フィールドだけです。トピックのメッセージ ヘッダ フィールドおよびメッセージ プロパティ フィールドは参照できません。 |
以下の QueueSession メソッドを使用して、キューにあるメッセージのヘッダ フィールドおよびプロパティ フィールドを参照できます。
public QueueBrowser createBrowser(
Queue queue
) throws JMSException
public QueueBrowser createBrowser(
Queue queue,
String messageSelector
) throws JMSException
参照するキューを指定する必要があります。また、参照するメッセージをフィルタ処理するメッセージ セレクタを指定することもできます。メッセージ セレクタの詳細については、「メッセージのフィルタ処理」を参照してください。
キューを定義すると、以下の QueueBrowser メソッドを使用して、キュー ブラウザに関連付けられたキュー名およびメッセージ セレクタにアクセスできるようになります。
public Queue getQueue(
) throws JMSException
public String getMessageSelector(
) throws JMSException
さらに、次の QueueBrowser メソッドを使用して、メッセージを参照するための列挙値にアクセスできます。
public Enumeration getEnumeration(
) throws JMSException
WL_HOME\samples\server\examples\src\examples\jms\queue ディレクトリ (WL_HOME は WebLogic Platform のインストール先の最上位ディレクトリ) にある WebLogic Server 付属の examples.jms.queue.QueueBrowser サンプルは、受信メッセージのヘッダ フィールドへのアクセス方法を示したものです。
たとえば、次の QueueBrowser の例からの引用コードでは、QueueBrowser オブジェクトを作成します。
qbrowser = qsession.createBrowser(queue);
次のコードは、QueueBrowser サンプルで定義されている displayQueue() メソッドからの引用です。この例では、QueueBrowser オブジェクトを使用して、キューのメッセージをスキャンする場合に使用される列挙値を取得します。
public void displayQueue(
) throws JMSException
{
Enumeration e = qbrowser.getEnumeration();
Message m = null;
if (! e.hasMoreElements()) {
System.out.println("There are no messages on this queue.");
} else {
System.out.println("Queued JMS Messages: ");
while (e.hasMoreElements()) {
m = (Message) e.nextElement();
System.out.println("Message ID " + m.getJMSMessageID() +
" delivered " + new Date(m.getJMSTimestamp())
" to " + m.getJMSDestination());
}
}
キュー ブラウザが使用されていない場合は、キュー ブラウザをクローズしてリソースを解放する必要があります。詳細については、「オブジェクト リソースの解放」を参照してください。
QueueBrowser クラスの詳細については、javax.jms.QueueBrowser の Javadoc を参照してください。
多くの場合、アプリケーションでは、配信されるすべてのメッセージが通知される必要はありません。メッセージ セレクタを使用すると、不要なメッセージをフィルタ処理できるので、ネットワーク トラフィックへの影響が最小限になり、パフォーマンスが向上します。
メッセージ セレクタはメッセージの内容 (本文) を参照することができないため、情報の一部をメッセージ プロパティ フィールドに複製することもできます (XML メッセージの場合を除く)。
キュー レシーバまたはトピック サブスクライバの作成時に、それぞれ QueueSession.createReceiver() メソッドまたは TopicSession.createSubscriber() メソッドの引数としてセレクタを指定します。キュー レシーバおよびトピック サブスクライバの作成については、「手順 5 : セッションと送り先を使用してメッセージ プロデューサとメッセージ コンシューマを作成する」を参照してください。
以降の節では、SQL 文と XML セレクタ メソッドを使用してメッセージ セレクタを定義する方法、およびメッセージ セレクタを更新する方法について説明します。ヘッダ フィールドおよびプロパティ フィールドの設定の詳細については、それぞれ「メッセージ ヘッダ フィールドおよびメッセージ プロパティ フィールドの設定と参照」、「メッセージ プロパティ フィールドの設定」を参照してください。
メッセージ セレクタはブール式であり、SQL の select 文の where 句と似た構文を持つ文字列です。
salary > 64000 and dept in ('eng','qa')(product like 'WebLogic%' or product like '%T3')
and version > 3.0
hireyear between 1990 and 1992
or fireyear is not null
fireyear - hireyear > 4
次の例では、キュー レシーバの作成時に、優先度が 6 未満のメッセージをフィルタで除外するセレクタを設定する方法を示します。
String selector = "JMSPriority >= 6";
qsession.createReceiver(queue, selector);
次の例では、トピック サブスクライバの作成時に、同様のセレクタを設定する方法を示します。
String selector = "JMSPriority >= 6";
qsession.createSubscriber(topic, selector);
メッセージ セレクタ構文の詳細については、javax.jms.Message の Javadoc を参照してください。
XML メッセージ タイプの場合、メッセージ セレクタの定義には、前節で説明した SQL セレクタ式だけでなく、次のメソッドを使用することもできます。
String JMS_BEA_SELECT(String type, String expression)
JMS_BEA_SELECT は、WebLogic JMS SQL 構文の組み込み関数です。構文タイプと XPath 式を指定します。構文タイプは、xpath (XML Path Language) に設定する必要があります。XML Path Language は、XML Path Language (XPath) のドキュメントで定義されており、XML Path Language の Web サイト http://www.w3.org/TR/xpath で入手できます。
| 注意 : | XML メッセージの構文には十分注意してください。不正な XML メッセージ (終了タグの欠落など) はどの XML セレクタとも一致しません。 |
<order>
<item>
<id>007</id>
<name>Hand-held Power Drill</name>
<description>Compact, assorted colors.</description>
<price>$34.99</price>
</item>
<item>
<id>123</id>
<name>Mitre Saw</name>
<description>Three blades sizes.</description>
<price>$69.99</price>
</item>
<item>
<id>66</id>
<name>Socket Wrench Set</name>
<description>Set of 10.</description>
<price>$19.99</price>
</item>
</order>
次の例では、上記の引用にある 2 番目の項目の名前を取り出す方法を示します。メソッド呼び出しは、Mitre Saw という文字列を返します。
String sel = "JMS_BEA_SELECT(`xpath', `/order/item[2]/name/text()') = `Mitre Saw'";
二重引用符と単一引用符、およびスペースの使い方に注意してください。xpath、XML タブ、および文字列値が単一引用符で囲まれていることに注意してください。
次の例では、上記の引用にある 3 番目の項目の ID を取り出す方法を示します。メソッド呼び出しは、66 という文字列を返します。
String sel = "JMS_BEA_SELECT(`xpath', `/order/item[3]/id/text()') = `66'";
次の MessageConsumer メソッドを使用して、メッセージ セレクタを表示できます。
public String getMessageSelector(
) throws JMSException
このメソッドは、現在定義されているメッセージ セレクタ、またはメッセージ セレクタが定義されていない場合は null のいずれかを返します。
アプリケーションの一部のクラスでは、WebLogic JMS でトピック サブスクライバのメッセージ セレクタにインデックスを付けることで最適化できます。通常、それらのアプリケーションはサブスクライバ数が多く、各サブスクライバにユニークな識別子 (ユーザ名など) が設定されています。また、単独のサブスクライバまたはサブスクライバのリストへメッセージを迅速に送信できる必要があります。一般的な例としては、各サブスクライバが異なるユーザに対応し、各メッセージに 1 つまたは複数の対象ユーザのリストが含まれるインスタント メッセージング アプリケーションがあります。
最適化されたサブスクライバのメッセージ セレクタをアクティブ化するには、サブスクライバはセレクタに以下の構文を使用する必要があります。
"identifierIS NOT NULL"
identifier は、あらかじめ定義された JMS メッセージ プロパティではない任意の文字列です (たとえば、JMSCorrelationID でも JMSType でもない文字列)。複数のサブスクライバが同じ識別子を共有できます。
WebLogic JMS では、このメッセージ セレクタ構文を、内部サブスクライバ インデックスを構築するためのヒントとして使用します。構文に従っていないメッセージ セレクタ、または追加の OR 句および AND 句を含むメッセージ セレクタも受け付けられますが、最適化はアクティブ化されません。
このメッセージ セレクタ構文を使用してサブスクライバを登録すると、トピックにパブリッシュされるメッセージは、1 つまたは複数の識別子をメッセージのユーザ プロパティに追加することにより、特定のサブスクライバを対象にすることができます。次に例を示します。
// 名前付きサブスクライバを設定する ("wilma" はサブスクライバ名、
// subscriberSession は JMS TopicSession)
// ここで使用しているセレクタ構文により、最適化がアクティブ化されるTopicSubscriber topicSubscriber =
subscriberSession.createSubscriber(
(Topic)context.lookup("IMTopic"),
"Wilma IS NOT NULL",
/* noLocal= */ true);
// サブスクライバ "Fred" および "Wilma" にメッセージを送信する
// publisherSession は JMS TopicSession
// メッセージ セレクタ式 "Wilma IS NOT NULL" または
// "Fred IS NOT NULL" が設定されたサブスクライバがこのメッセージを受け取る
TopicPublisher topicPublisher =
publisherSession.createPublisher(
(Topic)context.lookup("IMTopic");
TextMessage msg =
publisherSession.createTextMessage("Hi there!");
msg.setBooleanProperty("Fred", true);
msg.setBooleanProperty("Wilma", true);
topicPublisher.publish(msg);
| 注意 : |
| 注意 : | 最適化されたメッセージ セレクタとメッセージ構文は、標準の JMS API に基づいています。そのため、この構文を使用したアプリケーションは、最適化されたメッセージ セレクタがない WebLogic JMS のバージョンや、WebLogic JMS 以外の製品でも動作します。ただし、これらのバージョンの場合、この拡張機能を備えたバージョンに比べてパフォーマンスは劣ります。 |
| 注意 : | メッセージ セレクタを最適化しても、MULTICAST_NO_ACKNOWLEDGE 確認応答モードを使用しているアプリケーションには効果がありません。このようなアプリケーションは、メッセージの選択がサーバサイドではなくクライアントサイドで行われるため、拡張の必要性はありません。 |
| 注意 : | このリリースでは、ストリーミングはサポートされていません。サポートされるのは、XML ドキュメントのテキスト表現と DOM 表現のみです。 |
WebLogic Server JMS API では、XML メッセージを送信するためのドキュメント オブジェクト モデル (DOM) のネイティブ サポートも提供されています。
以下の節では、XML メッセージの拡張サポートを提供する WebLogic JMS API の拡張機能について説明します。
String 表現と DOM 表現の間の XML 変換には、以下の WebLogic XML API を使用できます。
XMLMessage のペイロードは、ある XML 表現を使用して設定し、別の表現を使用して取得できます。たとえば、XMLMessage の本文を String 表現を使用して設定し、DOM 表現を使用して取得することも可能です。
string 型を使用して XML メッセージをパブリッシュするには、次の手順に従います。
XML メッセージを DOM 表現を使用して送信すると、String としてメッセージを送信する場合に比べパフォーマンスがかなり向上します。DOM 表現を使用して XML メッセージをパブリッシュするには、次の手順に従います。
  
|
