BEA ホーム | 製品 | dev2dev | support | askBEA
 ドキュメントのダウンロード   サイト マップ   Glossary 
検索
e-docs > WebLogic Server > WebLogic JMS プログラマーズ ガイド > WebLogic JMS アプリケーションの移植

WebLogic JMS プログラマーズ ガイド

 Previous Next Contents Index PDF で侮ｦ  

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

以下の節では、新しいバージョンの WebLogic Server に WebLogic JMS アプリケーションを移植する方法について説明します。

 

既存の機能の変更点

Sun Microsystem の JMS 仕様に従って既存の機能が変更されました。移植手順を開始する前に、次の表で変更点を確認してください。

5.1 と 6.0 の既存の機能の変更点

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

カテゴリ

説明

コードの変更点

接続ファクトリ

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

  • javax.jms.QueueConnectionFactory

  • javax.jms.TopicConnectionFactory

下位互換性を維持するため、これら 2 つの接続ファクトリの JNDI 名は現在でも定義およびサポートされている。


WebLogic JMS 6.x 以降では、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 テーブルを手動で作成する必要はない。自動的に作成される。

変更不要。

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

変更不要。

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

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

セッション プール

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

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

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

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

トランザクション

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

変更不要。

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

変更不要。

6.0 と 6.1 の既存の機能の変更点

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

カテゴリ

説明

コードの変更点

接続ファクトリ

Administration Console の [確認応答ポリシー] 属性の新しいデフォルト値 [All] は、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 のこのリリースでは、Sun Microsystem の JMS 仕様をサポートしています。既存の 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 に移植する前に、処理が非アクティブになっている必要があります。

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

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

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

    最初の 2 つの接続ファクトリは非推奨になっていますが、下位互換性のためにこのリリースでも定義されており、使用できます。新しいデフォルト接続ファクトリの詳細については、5.1 と 6.0 の既存の機能の変更点の表を参照してください。

    JMS の管理者は、コンフィグレーションの変換結果を見直して、アプリケーションのニーズが満たされているかどうかを確認する必要があります。この場合、バージョン 5.1 と同様に、JMS 属性はすべて単一のノードにマップされます。

    注意: バージョン 6.0 以降では、JMS キューはコンフィグレーション時に定義され、データベース テーブル内には保存されません。メッセージ データと恒久サブスクリプションは、2 つの JDBC テーブルまたはファイル システムのディレクトリに格納されます。

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

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

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

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

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

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

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

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

  6. 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 に移植する前に、処理が非アクティブになっている必要があります。

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

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

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

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

6.x アプリケーションの 7.0 への移植手順

すべての WebLogic JMS 6.x アプリケーションがバージョン 7.0 でサポートされています。ただし、可用性の高い新しい JMS 機能をアプリケーションで利用したい場合は、既存の物理的な送り先（キューおよびトピック）を単一の分散送り先の一部として構成する必要があります。

JMS 分散送り先の使用方法の詳細については、『WebLogic JMS プログラマーズ ガイド』の「分散送り先の使用」を参照してください。

 

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 Next