ORACLE JAPAN Server Release 6.1

 
  |  

  WebLogic Server ホーム   |     JMS プログラマーズ ガイド   |   前へ   |   次へ   |   目次   |   索引   |   PDF 版

WebLogic JMS アプリケーションの移行

 

以降の節では、WebLogic JMS アプリケーションを移行する方法について説明します。

 

既存の機能の変更点

JavaSoft JMS 仕様バージョン 1.0.2 および JMS API - Errata に従って既存の機能が変更されました。移行手順を開始する前に、次の表で変更点を確認してください。

次の表に、WebLogic Server バージョン 5.1 の既存の機能の変更点を示します。また、その結果としてコードを変更する必要がある場合は、そのコードも併せて示します。バージョン 1.0.2 の変更履歴に関する情報については、JavaSoft JMS 仕様バージョン 1.0.2 の第 11 章「Change History」を参照してください。

表6-1 5.1 と 6.0 の既存の機能の変更点

カテゴリ

説明

コードの変更点

接続ファクトリ

2 つのデフォルト接続ファクトリは非推奨になっている。該当するファクトリの JNDI 名は次のとおり。

  • javax.jms.QueueConnectionFactory

  • javax.jms.TopicConnectionFactory

下位互換性のために、これら 2 つの接続ファクトリの JNDI 名はこのリリースでも定義されており、サポート対象。


WebLogic JMS 6.x では、1 つのデフォルト接続ファクトリが定義されている。このファクトリは JNDI 名 weblogic.jms.ConnectionFactory を使用してルックアップ可能。Administration Console を使用すれば、ユーザ定義の接続ファクトリを指定することもできる。

注意: デフォルトの接続ファクトリを使用する場合は、接続ファクトリがデプロイされる可能性のある WebLogic Server を限定できない。特定の WebLogic Server を対象にする場合は、新しい接続ファクトリを作成し、適切な WebLogic Server の対象を指定する。

新しいデフォルトまたはユーザ定義の接続ファクトリ クラスを使用するために、非推奨のクラスを使用している既存のコードを変更することが望ましい。

例として、デフォルトのキュー接続ファクトリを使用して次の定数を指定した場合を示す。

public final static String JMS_FACTORY="javax.jms.QueueConnectionFactory"

この場合、新しいユーザ定義の接続ファクトリを使用するためには定数を次のように変更する。

public final static String JMS_FACTORY="weblogic.jms.QueueConnectionFactory"

旧バージョンとの下位互換性を保つためには、接続ファクトリのコンフィグレーション時に [メッセージの短縮を許可] チェック ボックスおよび [ユーザ トランザクションを有効化] チェック ボックスをオンにする必要がある。

接続ファクトリの定義の詳細については、Administration Console オンライン ヘルプの「JMS 接続ファクトリ」を参照。

特定の WebLogic Server でデフォルト接続ファクトリをインスタンス化するには、WebLogic Server のコンフィグレーション時に [デフォルト JMS 接続ファクトリを有効化] チェックボックスをオンにする。

変更不要。コンフィグレーションで必要とされる。詳細については、Administration Console オンライン ヘルプの「JMS サーバ」を参照。

接続

接続を閉じると、未処理の同期呼び出しと非同期リスナの処理が完了するまで呼び出しがブロックされる。

変更不要。

セッション

セッションを閉じると、未処理の同期呼び出しおよび非同期リスナの処理が完了するまで、呼び出しがブロックされる。

変更不要。

メッセージ コンシューマ

1 つのセッションで 1 つのトピックに対して複数のトピック サブスクライバが定義されている場合、各コンシューマはメッセージのコピーを受信する。

変更不要。

メッセージ コンシューマをクローズすると、メソッド呼び出しが完了し、未処理の同期アプリケーションがすべてキャンセルされるまで、呼び出しはブロックされる。

変更不要。

JMS 仕様に準拠するために、接続ファクトリのコンフィグレーション時に [メッセージの短縮を許可] チェック ボックスをオンにしない限り、アプリケーションは、onMessage() メソッド内で close() メソッドが呼び出されても応答しない。確認応答モードが AUTO_ACKNOWLEDGE の場合、現在のメッセージはまだ自動的に確認応答される。

変更不要。コンフィグレーションで必要とされる。詳細については、Administration Console オンライン ヘルプの「JMS 接続ファクトリ」を参照。

メッセージ ヘッダ フィールド

JMSMessageID ヘッダ フィールドの形式は変更されている。

JMSMessageID で既存のメッセージにアクセスする場合は、以下の weblogic.jms.extensions.JMSHelper メソッドのいずれかを実行して、JMSMessageID の形式を WebLogic JMS 5.1 以前から JMS 6.x に変換しなければならない場合がある。

5.1 以前の JMSMessageID の形式を 6.x に変換する場合には、以下を実行する。

public void oldJMSMessageIDToNew(
   String id,
   long timeStamp
) throws JMSException

6.1 の JMSMessageID の形式を 6.1 以前に変換する場合には、以下を実行する。

public void newJMSMessageIDToOld(
  String id,
  long timeStamp
) throws JMSException

送り先

createQueue() メソッドと createTopic() メソッドでは、送り先が動的には作成されず、ベンダ固有の送り先名で既に存在する送り先への参照が作成されるのみ。

createQueue() または createTopic() を使用しているコードの一部を変更し、createPermanentQueueAsync() および createPermanentTopicAsync() という JMSHelper クラス メソッドをそれぞれ使用して動的に送り先を作成する。

例として、動的にキューを作成するために次のメソッドを使用する場合を示す。

queue=qsession.createQueue(queueName);

キューを動的に作成するには、 JMSHelper クラス メソッドの使い方のサンプル findQueue() メソッドで説明されているようにコードを変更する。

JMSHelper クラスの詳細については、 送り先の動的作成を参照。

一時的な送り先を作成する場合は、一時的なテンプレートを指定する必要がある。

変更不要。コンフィグレーションで必要とされる。詳細については、Administration Console オンライン ヘルプの「JMS テンプレート」を参照。

その一時的な送り先のメッセージ コンシューマを作成するには、接続のオーナであることが必要。

一時的な送り先にメッセージ コンシューマを作成する場合は、自分が接続のオーナであることを確認する。

恒久サブスクライバ

恒久サブスクライバ用に JDBC テーブルを手動で作成する必要はない。自動的に作成される。

変更不要。

恒久サブスクライバは必要な数だけ作成可能。

変更不要。

client ID をプログラムで定義する場合は、接続を作成した直後に定義する必要がある。それ以外の場合、例外が送出され、その接続では他の JMS 呼び出しができなくなる。

setClientID() メソッドが、接続作成の直後に発行されるようにする。詳細については、 クライアント ID の定義を参照。

セッション プール

セッション プール ファクトリ、セッション プール、参照される接続ファクトリ、参照される送り先、関連する接続コンシューマは、すべて同じ JMS サーバを対象にする必要がある。

全オブジェクトが同じ JMS サーバを対象としていることを確認すること。

WebLogic JMS バージョン 5.1 の Javadoc の一部として提供されていた SessionPoolManager インタフェースと ConnectionConsumerManager インタフェースはシステム インタフェースであり、クライアント アプリケーションでは使用しないため、バージョン 6.0 および 6.1 の Javadoc では削除されている。

使用している場合は、これらのオブジェクトへの参照をクライアント アプリケーションから削除すること。

トランザクション

JMS と EJB のデータベース呼び出しを同じトランザクション内で組み合わせて使用するには、2 フェーズ コミット（2PC）が必要である。WebLogic Server の以前のリリースでは、同じデータベース接続プールを使用すれば、この 2 つを組み合わせて使用することができた。

変更不要。

受信キュー メッセージを回復またはロールバックすると、キューにある全コンシューマに対してそのメッセージが使用可能になる。WebLogic Server の以前のリリースでは、ロールバックされたメッセージは、そのメッセージをロールバックしたセッションでのみ（そのセッションが終了するまで）使用可能だった。

変更不要。

次の表に、WebLogic Server バージョン 6.0 の既存の機能の変更点を示します。また、その結果としてコードを変更する必要がある場合は、そのコードも併せて示します。バージョン 1.0.2 の変更履歴に関する情報については、JavaSoft JMS 仕様バージョン 1.0.2 の第 11 章「Change History」を参照してください。

表6-2 6.0 と 6.1 の既存の機能の変更点

カテゴリ

説明

コードの変更点

接続ファクトリ

Administration Console の [確認応答ポリシー] 属性の新しいデフォルト値 [All] は、JavaSoft JMS 仕様の変更に従った回避策。この新しいデフォルト設定は、JMS の旧バージョンからの変更を表す。旧バージョンでは、内部で [Previous] がデフォルトとなっており、Administration Console のオプションとしては表示されていなかった。

接続ファクトリのメッセージの確認応答ポリシーとしては、非トランザクション セッションに CLIENT_ACKNOWLEDGE モードを使用する実装にのみ、[確認応答ポリシー] 属性が適用される。

  • [All] − どのメッセージが確認応答メソッドを呼び出すかにかかわらず、指定したセッションで受信したすべてのメッセージを確認応答する。

  • [Previous] − 指定したセッションで受信したすべてのメッセージを確認応答する。ただし、確認応答メソッドを呼び出したメッセージを最後に、確認応答を中止する。

メッセージの確認応答モードの詳細については、 非トランザクション セッションを参照。

注意: メッセージ駆動型 Bean（MDB）で使用される接続ファクトリでは、[確認応答ポリシー] フィールドを常に [Previous] に設定する。デフォルト MDB 接続ファクトリでは既に設定されているが、外部の接続ファクトリでは設定されていない可能性がある。

確認応答メソッドを呼び出すメッセージ以前の受信メッセージを確認応答する場合は、Administration Console の [JMS 接続ファクトリ] タブで、デフォルトの [確認応答ポリシー] 設定を [All] から [Previous] に変更する。

送り先

WLS バージョン 6.0 では、ソフトウェアで大文字と小文字を区別しなかったが、JMS マニュアルは、JMSDestinationMBean の StoreEnabled 属性の default、true、および false の値を正しく指定している。しかし、バージョン 6.1 では、StoreEnabled 設定にはすべて小文字が必要になる。

変更不要。コンフィグレーションで必要とされる。詳細については、Administration Console オンライン ヘルプの「JMS テンプレート」を参照。

セッション プール

WebLogic Server 6.0 SP2 以降の QueueConnection クラスおよび TopicConnection クラスでは、createConnectionConsumer メソッドの MaxMessages 引数は、サーバに保持されるメッセージの量に応じた特定の値を必要とする。

したがって、MaxMessages は以下のように解析される。

-1 - デフォルト値と同じ 10。

>0 - 正の整数は変換を必要としない。

0 - JMSException を生成する無効な値。

<-1 - JMSException を生成する無効な値。

createConnectionConsumer メソッドでは、MaxMessages 引数の値が -1（デフォルト）または正の整数に設定されるようにする。

 

既存のアプリケーションの移行

WebLogic Server 6.1 では、JavaSoft JMS 仕様バージョン 1.0.2 および最新の JMS API - Errata がサポートされています。既存の JMS アプリケーションを使用するには、WebLogic Server のバージョンを確認してから、この節で説明されている適切な移行手順を実行する必要があります。

始める前に

移行手順を開始する前に、以下のリストをチェックして、現在の WebServer JMS のバージョンで移行がサポートされているかどうか、およびそのバージョンに特殊な移行ルールが適用されているかどうかを確認する必要があります。

4.5 および 5.1 アプリケーションのバージョン 6.x への移行手順

WebLogic JMS 6.x アプリケーションを使用するには、その前に WebLogic Server バージョン 4.5 および 5.1 のコンフィグレーション データとメッセージ データを次の手順で移行する必要があります。

  1. 以降手順を開始する前に、WebLogic Server の旧バージョンを正しくシャットダウンします。

警告: メッセージの処理中に WebLogic Server の旧バージョンを突然停止すると、移行の際に問題が発生することがあります。旧バージョンのサーバをシャットダウンし、WebLogic Server バージョン 6.x に移行する前に、処理が非アクティブになっている必要があります。

  1. 『WebLogic Server インストール ガイド』で説明されているとおりに、WebLogic Server 環境をアップグレードします。

  2. コンフィグレーション変換機能を使用してコンフィグレーション情報を移行します。

    コンフィグレーションの移行時に、以下のデフォルト キュー接続ファクトリおよびデフォルト トピック接続ファクトリが有効になります。

  3. 既存の JDBC データベース ストアの自動移行作業を準備します。

    1. 既存の JDBC データベースのバックアップを作成します。

    2. 移行されたコンフィグレーション情報（手順 2 を参照）に、既存の JDBC データベース ストアと全く同じ属性を持つ JDBC データベース ストアがあること、また、そのストアを使用する新しい JMS サーバで、既存の JMS サーバと同じ送り先とその送り先の属性が定義されていることを確認します。

    3. 新しい JDBC データベース ストアが既にある場合、中身が空であることを確認します。

      新しい JDBC データベース ストアが必要に応じて自動移行中に作成されます。

    4. JDBC データベース ストアで必要な量の 2 倍のディスク スペースがシステムにあることを確認します。

      移行中には、既存のデータベース情報と新しいデータベース情報がディスク上に併存するため、2 倍のディスク スペースが必要になります。移行が完了したら、 JDBC データベース ストアの削除の説明に従って古い JDBC データベース ストアを削除できます。

  4. 必要に応じて既存のコードを更新し、 5.1 と 6.0 の既存の機能の変更点で説明されている機能の変更点を反映させます。

  5. WebLogic Server を起動すると、既存の JDBC データベース ストアが自動的に移行されます。

    注意: 何らかの理由で自動移行が失敗した場合、自動移行は次に WebLogic Server が起動したときに再試行されます。

6.0 アプリケーションの 6.1 への移行手順

WebLogic JMS 6.x アプリケーションを使用するには、その前に WebLogic Server バージョン 6.0 のコンフィグレーション データとメッセージ データを次の手順で移行する必要があります。

  1. バージョン 6.0 での接続ファクトリのコンフィグレーションを確認します。6.1 の新しいデフォルト接続ファクトリを呼び出すプログラムを修正して、以下の接続ファクトリのいずれかがロードされるようにする必要がある場合があります。

  2. 移行手順を開始する前に、バージョン 6.0 の WebLogic Server を正しくシャットダウンします。

警告: メッセージの処理中に WebLogic Server の旧バージョンを突然停止すると、移行の際に問題が発生することがあります。旧バージョンのサーバをシャットダウンし、WebLogic Server バージョン 6.x に移行する前に、処理が非アクティブになっている必要があります。

  1. 『WebLogic Server インストール ガイド』で説明されているとおりに、WebLogic Server 環境をアップグレードします。

  2. 必要に応じて既存のコードを更新し、 6.0 と 6.1 の既存の機能の変更点で説明されている機能の変更点を反映させます。

警告: バージョン 6.1 の WebLogic Server を起動する前に、バージョン 6.0 のストアをバックアップします。これは、バージョン 6.0 のサーバでは 6.1 のストアを使用できないためです。使用すると、データが破損するおそれがあります。

  1. バージョン 6.1 の WebLogic Server を起動します。6.1 サーバでは、6.0 ストアがそのまま使用されます。

 

JDBC データベース ストアの削除

移行が完了したら、 JDBC データベース ユーティリティの説明に従って、utils.Schema ユーティリティで古い JDBC データベース テーブルを削除する必要があります。

移行中に、ローカル作業ディレクトリで DDL ファイルが生成および保存されます。DDL ファイルには、drop_<jmsServerName>_oldtables.ddl という名前が付けられます。<jmsServerName> は JMS サーバ名を示します。JDBC データベース ストアを削除するには、utils.Schema ユーティリティでこの DDL ファイルを引数として指定します。

たとえば、MyJMSServer という JMS サーバから古い JDBC データベース ストアを削除するには、次のコマンドを実行します。

java utils.Schema jdbc:weblogic:oracle weblogic.jdbc.oci.Driver -s server -u 
user1 -p foobar -verbose drop_MyJMSServer_oldtables.ddl

utils.Schema ユーティリティの詳細については、 JDBC データベース ユーティリティを参照してください。

 

back to top previous page next page