| Oracle® Fusion Middleware Java EEアップグレード・ガイド 11g リリース1（11.1.1） B55925-03 |
|
 戻る |
 次へ |
Java EEアプリケーションをOracle WebLogic ServerおよびOracle Fusion Middleware 11g にアップグレードすると、そのアプリケーションによって公開されている外部インタフェースに影響する場合があります。その結果、そのインタフェースに依存しているクライアント・アプリケーションが影響を受ける場合があります。
次の項では、アップグレードがアプリケーション・クライアントに及ぼす影響、およびそれに起因するクライアントの問題に対処する際のガイドラインについて説明します。
アプリケーションをWebLogic Serverにアップグレードする場合、HTTPセッション・ステートのレプリケーション・モデルがOracle WebLogic ServerとOC4Jで異なるために、JSPクライアントおよびサーブレット・クライアントが影響を受ける場合があります。
OC4Jクラスタの場合はHTTPセッション・ステートのインメモリーの複製コピー数に制限はありませんが、Oracle WebLogic ServerのインメモリーHTTPセッション・ステートのレプリケーションは、OC4Jクラスタとは異なり、プライマリとセカンダリの2コピー・モデルのみをサポートしています。
ほとんどの場合は、このような違いがJSPクライアントおよびサーブレット・クライアントに影響することはありませんが、特殊なケースでHTTPセッション・ステートの3つ以上のコピーがアプリケーションのクライアントから使用可能なことがそのアプリケーションの明示的な前提となっている場合は、Oracle Coherenceの使用を検討してください。
詳細は、Oracle Technology Network（OTN）のOracle Coherenceに関する情報を参照してください。
次の項では、アップグレードするアプリケーションのクライアントがOC4J Java Naming and Directory Interface（JNDI）プロバイダを使用する場合の考慮事項について説明します。
アップグレードするアプリケーションのクライアントの中でOC4J Java Naming and Directory Interface（JNDI）プロバイダを使用してアプリケーションのインタフェースやリソースをルックアップするものがある場合は、かわりにOracle WebLogic Server JNDIプロバイダを使用するようにそのクライアントを変更する必要があります。
アプリケーションのJNDI初期コンテキスト作成コードは、次のようにして変更できます。
クライアント・コードでOC4J JNDI URLが使用されているインスタンスをすべて特定します。
一般に、OC4J URLの構成フォーマットは次のとおりです。
prefix://host:RMI_or_OPMN_request_port:oc4j_instance/application-name
たとえば、OC4Jインスタンスの名前がoc4j1、デプロイされているアプリケーション名がmyapplicationであれば、Oracle Application Server 10g インストールのURLは、次のようになります。
opmn:ormi://127.0.0.1:6003:oc4j1/myapplication
Oracle Process Management and Notificationインフラストラクチャを使用する完全なOracle Application Serverインストールの場合、接頭辞はopmn:ormiのように指定できます。スタンドアロンのOC4Jインストールを使用する場合は、単にormi:と指定できます。
t3プロトコルを使用して、ターゲットのWebLogic Serverドメインの管理サーバーを指すようにプロバイダのURLを変更します。
たとえば、次のようにします。
t3://127.0.0.1:7001
ターゲットのOracle WebLogic Serverドメイン内でセキュリティ資格証明が有効であることを確認します。
初期コンテキスト・ファクトリをOracle WebLogic ServerのWLInitialContextFactoryクラスに変更します。
このクラスは、クライアント・アプリケーションのクラスローダーから使用できるようにする必要もありますが、その処理にはOracle WebLogic Serverクライアントjarファイルを使用します。クライアントjarファイル（wlfullclient.jar）は、WebLogic JarBuilderツールを使用して作成します。
詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverスタンドアロン・クライアントのプログラミング』の次の項を参照してください。
"WebLogicフルクライアントに関する項
"WebLogic JarBuilderツールの使用に関する項
クライアント自体がOC4Jサーバー・インスタンス内で実行されている場合は、サーバーのserver.xmlに記述されたenvironment-naming-url-factory-enabled属性をtrueに設定し、同じOC4Jインスタンスで複数のJNDIプロバイダを使用できるようにすることが必要な場合もあります。
OC4JとOracle WebLogic Server JNDIのプロバイダの重要な相違点で、クライアント・アプリケーションに影響する可能性があるものとしては、JNDIネームスペースのスコープもあげられます。
OC4J JNDIオブジェクトには、明示的なアプリケーション・スコープを設定できます。したがって、OC4J JNDIクライアントがルックアップを実行するときは、特定のOC4Jサーバー・インスタンスを識別してターゲット・アプリケーションの名前を含めるURLを使用することができます。
一方、Oracle WebLogic Server JNDIオブジェクトのネームスペースは常にグローバルです。したがって、ルックアップを実行するOracle WebLogic Server JNDIクライアントの場合、ターゲット・アプリケーションを明示的に識別するURLは指定できません。
このため、WebLogic Serverにアップグレードするときは、その作業の一環として、同じWebLogic ServerドメインにデプロイされるすべてのJNDIリソースについて、そのリソースがどのアプリケーションに所属するかにかかわらず、JNDI名が一意であることを確認する必要があります。必要であれば、ターゲット・オブジェクトの一意なJNDI名を使用するようにJNDIクライアントを変更してください。
アプリケーションをOracle WebLogic Serverにアップグレードしたときに、EJBクライアント・アプリケーションに影響する可能性がある次の2つの場合があります。詳細は、次の項を参照してください。
このカテゴリのEJBクライアントは、スタンドアロンであるか、OC4Jサーバーにデプロイされています。
このカテゴリのEJBクライアントの場合は、Oracle WebLogic Server JNDIプロバイダを使用するようにクライアントを変更する必要があります（6.2.1項「Oracle WebLogic Server JNDIプロバイダを使用するためのクライアントの変更」の説明を参照）。
WebLogic Server JNDIプロバイダを使用すると、クライアント・アプリケーションがWebLogic Server EJBクライアント・スタブを取得することになり、その結果、クライアント・アプリケーションに対して次のような影響が発生する可能性があります。
RMIプロトコル: クライアント・アプリケーションは、OC4J RMI転送プロトコル（ORMI）ではなく、いずれかのOracle WebLogic Server RMI転送プロトコルを使用する必要があります。
WebLogic RMIのデフォルトの転送プロトコルはOracle WebLogic Server T3プロトコルですが、IIOPも使用できます。
ロード・バランシング: OC4Jでは、クライアントEJBリクエストは、Context.lookup()を起動するたびに、InitialContext JNDIオブジェクトを介して（ランダムまたはスティッキーに）OC4Jクラスタ全体でロード・バランシングされるように構成できます。
Oracle WebLogic Serverの場合、EJBクライアント・リクエストのロード・バランシングはリモートEJBクライアント・スタブによって自動的に処理されます。このスタブのロード・バランシング動作は、weblogic-ejb-jar.xmlデプロイメント・ディスクリプタで構成し、InitialContextの作成時またはEJBメソッドの起動時に実行するように設定できます。
ここで述べる考慮事項は、スタンドアロンのクライアントおよび現在OC4Jサーバー・インスタンス内で実行中のクライアントの両方に適用されます。また、WebLogic Serverインスタンス内で実行するようにアップグレードされるクライアントにも適用されます。
スタンドアロン・アプリケーションとしてデプロイされていないEJBクライアントで、引き続きOC4Jサーバー・インスタンス内で実行し、アップグレードされたWebLogic Server EJBアプリケーションに対してリモート起動を行うクライアントの場合は、アップグレードの影響として次の2つの点も追加して考慮する必要があります。
まず、アプリケーションのセキュリティ・コンテキストは、自動的に伝播されません。このセキュリティ伝播が必要な場合は、WebLogic Server JNDI初期コンテキストの作成時に既存のセキュリティ・コンテキストの資格証明を明示的に使用するように、クライアントを変更する必要があります。
次に、リモートEJBを起動するコンテキスト内でのJTAトランザクションの伝播およびXAのリカバリができなくなります。必要な場合は、クライアント・アプリケーション自体のアップグレードが必要になります。
アップグレードするアプリケーションが、OC4Jサーバー内で引き続き実行するEJBコンポーネントへのリモート・クライアントのように動作することがあります。このカテゴリのクライアントは、oc4jclient.jarファイルにあるOC4J RMIInitialContextFactory JNDI初期コンテキスト・ファクトリを使用するように変更する必要があります。
oc4jclient.jarファイルは、アプリケーションのOracle WebLogic Serverクラスローダーから使用できることが必要です。詳細は、5.3.4項「Oracle WebLogic Server上での共有ライブラリおよびクラスロードの使用」を参照してください。
セキュリティ・コンテキストを伝播するには、ターゲットOC4Jサーバー・インスタンスをOracle WebLogic Server SSLクライアントとして構成する必要があります。また、リモートEJBを起動するコンテキスト内でのJTAトランザクションの伝播およびXAのリカバリはできなくなります。これらの機能が必要な場合は、ターゲットのEJBアプリケーションをアップグレードする必要があります。
まず、この項に記載した情報は、メッセージドリブンBean（MDB）以外のJMSクライアントに関する情報であることに注意してください。MDBは、通常はJMSプロバイダのリソースと緊密に結合しているため、常にそのリソースとともにアップグレードする必要があります。MDBアプリケーションのアップグレード時には、WebLogic Server MDBに特有な機能と動作を考慮してください。次の項では、Oracle WebLogic ServerへのアプリケーションのアップグレードがJMSクライアントに影響する可能性がある2つの場合について説明します。
この場合は、JMSプロバイダおよびその関連リソース（宛先、コネクション・ファクトリなど）がOracle WebLogic Serverにアップグレードされます。アップグレードするクライアント・アプリケーションと、そのままOC4Jサーバー内で実行する既存のOC4Jクライアント・アプリケーションの両方を変更する必要があります。
具体的には、WebLogic Server JNDIプロバイダを使用するようにクライアント・アプリケーションを変更する必要があります（6.2.1項「Oracle WebLogic Server JNDIプロバイダを使用するためのクライアントの変更」の説明を参照）。
Oracle WebLogic Server JNDIプロバイダを使用するようにクライアントを変更すると、クライアント・アプリケーションはOracle WebLogic Server JMSプロバイダからJMSリソースを取得します。その場合は、クライアント・アプリケーションに影響を与えることがあるため、次の点を考慮してください。
メッセージの順序付け: Oracle WebLogic Serverには、OC4J JMSプロバイダと同様に、メッセージを厳密な順序で処理することを保証する機能があります。さらに、WebLogic Server JMSの順序単位機能は、追加のメッセージ順序処理機能に対応しています。詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSのプログラミング』のメッセージ順序単位の使用に関する項を参照してください。
接続プーリング: Oracle WebLogic Server JMSプロバイダには、OC4J JMSプロバイダとは異なり、スタンドアロン・クライアントに対するプーリング機能がありません。この機能が必要な場合は、スタンドアロン・クライアントを変更し、JMSリソースを明示的に再利用することで、この機能を実装する必要があります。
ネットワーク接続: WebLogic Server JMSプロバイダを使用するクライアントは、クライアント仮想マシン当たり1つのネットワーク接続を使用します（使用されるJMS接続オブジェクトの数には関係しません）。この動作は、JMS接続オブジェクトごとに別々のネットワーク接続を関連付けるOC4J JMSプロバイダとは若干異なります。
スタンドアロン・アプリケーションでないJMSクライアントで、OC4Jサーバー・インスタンス内での実行を続けながらWebLogic Server環境内のJMSリソースを使用するクライアントは、OC4J Oracle Enterprise Messaging Server JMSコネクタ機能を使用する必要があります。
この場合は、JMSプロバイダがOC4Jインフラストラクチャ内にそのまま残っており、Oracle WebLogic Serverにアップグレードするクライアント・アプリケーションは調整が必要です。このタイプのクライアント・アプリケーションは、WebLogic ServerにデプロイされたJMSクライアントがOC4J JMSリソースにアクセスできるようにするために、OC4J JMSリソースをリモートJMSプロバイダとして扱い、Oracle WebLogic Serverの外部サーバー機能を使用する必要があります。
詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSの構成と管理』のサード・パーティのJMSプロバイダにアクセスするための外部サーバー・リソースの構成に関する項を参照してください。
