ナビゲーションをスキップ

eDocs ホーム > BEA WebLogic Server 8.1 ドキュメント > WebLogic JMS プログラマーズ ガイド > WebLogic JMS アプリケーションの移植

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

  前 次 前/次ボタンと目次ボタンとの区切り線 目次  

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

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

 

既存の機能の変更点

Sun Microsystems の 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 以降では、1 つの接続ファクトリ (デフォルトでは weblogic.jms.ConnectionFactory) が定義されている。

Administration Console を使用すれば、ユーザ定義の接続ファクトリを指定することもできる。

注意 : デフォルトの接続ファクトリを使用する場合は、接続ファクトリがデプロイされる可能性のある WebLogic Server を限定できない。ただし、WebLogic Server 単位でデフォルトの接続ファクトリの有効/無効を切り替えることができる。特定の WebLogic Server またはクラスタに接続ファクトリをデプロイするには、新しい接続ファクトリを作成し、適切な対象の WebLogic Server を指定する。

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

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

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

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

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

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

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

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

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

接続

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

変更不要。

セッション

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

変更不要。

メッセージ コンシューマ

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

変更不要。

メッセージ コンシューマをクローズするとき、コンシューマが非同期コンシューマである場合は、未処理の onMessage() メソッド呼び出しが完了するまで、呼び出しはブロックされる。

変更不要。

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);

キューを動的に作成するには、「JMS ヘルパーを使用したアプリケーションの管理」のサンプル findQueue() メソッドで説明されているようにコードを変更する。

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

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

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

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

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

恒久サブスクライバ

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

変更不要。

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

変更不要。

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

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

セッション プール

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

変更不要。コンフィグレーションで必要とされる。全オブジェクトが同じ JMS サーバを対象としていることを確認すること。詳細については、Administration Console オンライン ヘルプの「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 Microsystems の 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 Microsystems の JMS 仕様をサポートしています。既存の JMS アプリケーションを使用するには、WebLogic Server のバージョンを確認してから、この節で説明されている適切な移植手順を実行する必要があります。

始める前に

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

バージョン 5.1 アプリケーションのバージョン 8.1 への移植手順

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

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

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

  2. 『インストール ガイド』で説明されているとおりに、WebLogic Server 環境をアップグレードします。
  3. 「コンフィグレーション変換機能」を使用してコンフィグレーション情報を移植します。

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

    最初の 2 つの接続ファクトリは非推奨になっていますが、下位互換性のためにこのリリースでも定義されており、使用できます。新しいデフォルト接続ファクトリの詳細については、「ConnectionFactory オブジェクト」を参照してください。

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

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

  4. 既存の JDBC データベース ストアの自動移植作業を準備します。
    1. 既存の JDBC データベースのバックアップを作成します。
    2. 移植されたコンフィグレーション情報 (手順 2 を参照) に、既存の JDBC データベース ストアと全く同じ属性を持つ JDBC データベース ストアがあること、また、そのストアを使用する新しい JMS サーバで、既存の JMS サーバと同じ送り先とその送り先の属性が定義されていることを確認します。
    3. 新しい JDBC データベース ストアがすでにある場合、中身が空であることを確認します。

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

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

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

  5. 必要に応じて既存のコードを更新し、「5.1 と 6.0 の既存の機能の変更点」で説明されている機能の変更点を反映させます。
  6. WebLogic Server を起動すると、既存の JDBC データベース ストアが自動的に移行されます。

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

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 データベース ユーティリティ」を参照してください。

バージョン 6.0 アプリケーションのバージョン 8.1 への移植手順

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

  1. バージョン 6.0 での接続ファクトリのコンフィグレーションを確認します。バージョン 8.1 のデフォルト接続ファクトリを呼び出すプログラムを修正して、以下の接続ファクトリのいずれかがロードされるようにする必要がある場合があります。
  2. 移植手順を開始する前に、バージョン 6.0 の WebLogic Server を正しくシャットダウンします。

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

  3. 『インストール ガイド』で説明されているとおりに、WebLogic Server 環境をアップグレードします。
  4. 必要に応じて既存のコードを更新し、「5.1 と 6.0 の既存の機能の変更点」で説明されている機能の変更点を反映させます。

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

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

バージョン 6.1 または 7.0 アプリケーションのバージョン 8.1 への移植手順

すべての WebLogic JMS 6.1 および 7.0 のアプリケーションがバージョン 8.1 でサポートされています。ただし、高可用性 JMS の分散送り先機能をアプリケーションで利用する場合は、既存の物理的な送り先 (キューおよびトピック) を、単一の分散送り先セットの一部としてコンフィグレーションする必要があります。

JMS 分散送り先の使用方法については、「分散送り先の使用」を参照してください。

 

フッタのナビゲーションのスキップ  ページの先頭 前 次