本文へジャンプ

WebSphere Developer Domain > WebSphere Application Server > 

WebLogicサーバーおよびアプリケーション構成のWASへのマイグレーション
レベル： 中級者向け
1 2 3



はじめに
サーバー構成のマイグレーション
アプリケーション構成のマイグレーション
config.xmlエレメントのマッピング



Donald Vines, Executive IT Architect, IBM

2007年6月6日, 原文はこちら（US）

この記事では、WebLogicアプリケーションおよびサーバー構成をIBM® WebSphere® Application Serverにマイグレーションする方法を説明します。また、ご使用のアプリケーションをWebSphere Application Server上で実行するために適切にマップする必要のあるWebLogic独自の拡張について説明します。よくある問題に対する解決策を記載していますので、マイグレーションで発生する問題を最小限に抑えることができます。


はじめに

この記事の目的は、読者がJava™ 2 Platform, Enterprise Edition（J2EE）アプリケーションをBEA WebLogic ServerからIBM WebSphere Application Serverプラットフォームにマイグレーションできるようにすることです。

WebLogicのマイグレーション（開発環境、実動ランタイム、アプリケーション・コードのマイグレーションを含む）の計画は、developerWorksのその他の記事（『参考文献』を参照）で説明されています。この記事は、J2EEアプリケーションに存在する以下の2種類の構成のマイグレーションに特に焦点を当てており、『参考文献』をはじめとする、その他の記事を補足する内容となっています。

  • サーバー構成（アプリケーション・ファイルの外部にあり、移行元の環境のドメイン構成に含まれる設定を指します）。サーバー構成をマイグレーションするには、WebLogic固有のリソース（JMS接続ファクトリー、JMSキュー、JMSトピック、JDBCデータ・ソース、JavaMailセッションなど）を、対応するWebSphere Application Serverにマップします。

  • アプリケーション構成（エンタープライズ・アーカイブ（EAR）ファイルのアプリケーション・ディレクトリー構造に含まれる設定を指します）。アプリケーション構成をマイグレーションするには、WebLogic固有のデプロイメント記述子を、対応するWebSphere Application Serverにマップします。

この記事で説明する情報は、J2EE 1.3（およびそれ以降の）アプリケーションをWebLogic Server 7.0および8.1からWebSphere Application Server V6.xに直接マイグレーションする場合に適用されます。また、この記事で説明する情報の大部分は、より古いバージョンのWebLogic Serverからアプリケーションをマイグレーションする場合にも適用されます。


上に戻る

サーバー構成のマイグレーション

基本的にサーバー構成のマイグレーションは、アプリケーション・ファイルの外部にあるがWebLogic Serverのドメイン構成内に含まれる設定をWebSphere Application Serverに移動することを意味します。これらの設定には、JMS接続ファクトリーおよび宛先、JDBCデータ・ソース、J2EEセキュリティー設定、メール・セッションなどが含まれます。

構成をマイグレーションするには、マイグレーションが必要な設定を理解する必要があります。しかし、これらの設定に関する文書も、（サーバー構成の作成時に使用された可能性のある）スクリプトも一切参照できない場合がかなりあります。その場合は、各ドメインのWebLogic管理コンソールにログインして設定を探し、WebSphere Application Server環境で作成する必要のある設定を特定する必要があります。

しかし、WebLogic管理コンソールにアクセスできない（またはアクセスが許可されない）場合は、どうすればよいのでしょうか。

いずれの場合であっても、WebLogicサーバーの構成情報を最も効率的に収集する方法は、WebLogicドメイン構成ファイルconfig.xmlとWebLogic起動スクリプトを検査することです。通常、WebLogic管理者は、これらのファイルのコピーをユーザーに提供します。なぜなら、これらのファイルを参照しても、実行中のどのシステムにも影響が及ばないからです。

  • WebLogic config.xmlファイルは、WebLogic管理コンソールがすべてのリソース定義を保管する場所です。これらのリソースを正しくマップしないと、通常はアプリケーションが失敗します。

  • 多くの場合、管理者は、カスタム起動スクリプトを作成して、そのスクリプトにシステム・プロパティー、JVM引数、およびクラスを追加します。これらの設定をマイグレーションしないと、新しい環境のアプリケーションのパフォーマンスとスケーラビリティーに悪影響が及ぶ場合があります。config.xmlファイルと管理コンソールのどちらを参照するかにかかわらず、起動スクリプトは、確認しておくのがよいでしょう。

この情報を収集したら、開発者と管理者に必ずその内容を確認してもらいます。これは、以下のためです。

  • 収集した情報に、最新かつ正確な設定が含まれていることを確認するため。
  • 除去できる不要なコードがないかどうかを識別するため。

また、参照しているWebLogicサーバー構成が正しいものであることも必ず確認します。開発時、J2EEアプリケーションは、さまざまなランタイム環境（開発、テスト、QAなど）にインストールされている可能性があり、各環境の構成設定は、それぞれ若干異なる場合があります。したがって、使用するWebLogicサーバー構成が、目的に合った正しい構成であることを必ず確認してください。同様に、アプリケーションは各開発ステージでインストールするので、対応する環境ごとに適切なサーバー構成をマップします。

マイグレーションが必要な特定のランタイム構成設定がある場合、次のステップは、それを抽出して、WebSphere Application Server管理コンソールにその情報を組み込むことです。これは手動のプロセスですが、作成すべき設定が分かれば、設定を作成するのは難しくありません。WebSphere Application Server管理コンソールを使用してこれらのプロパティーを設定すれば、XMLファイルを変更したり、スクリプトを作成したりする必要はありません。お望みの場合は、データ・ソースの作成やJ2EEアプリケーション・セキュリティーの有効化など、一般的なタスクの実行を支援するガイド付きアクティビティーを使用することもできます。作業が完了すると、サーバー構成、特に実稼働環境のサーバー構成を自動的に作成するスクリプト（US）を作成できます。

図1は、WebLogicからWebSphere Application Serverへのサーバーのマイグレーションを説明しています。示されている設定は、サーバーの構成設定だけではありません。このようなマイグレーション時に見られる設定の大部分が示されています。その他にある設定は、セキュリティーやメール・セッションに関連するものです。ただし、通常は、図に示されているリソースを処理できれば、サーバーのマイグレーションを正常に進めることができます。



図1 サーバー構成のマイグレーション


上に戻る

アプリケーション構成のマイグレーション

基本的にアプリケーション構成のマイグレーションは、WebLogic固有のデプロイメント記述子に含まれる設定をWebSphere Application Serverに移動することを意味します。これらの設定には、グローバルJNDI名前空間へのEJBコンポーネントのマッピング、パフォーマンス関連の各種設定（プール・サイズ、トランザクションの分離レベル、EBJ照会言語の拡張など）が含まれます。デプロイメント記述子は、J2EEアプリケーションに必要な実行環境を記述するものであり、一般的には、以下のような2つのバリエーションがあります。

  • 業界標準のデプロイメント記述子（図2）は、移植可能な記述子であり、通常は変更は不要です。ただし、WebLogicとWebSphere Application Serverの間には、説明に値する相違点がいくつかあります。例えば、IBMの標準のデプロイメント記述子では、標準の記述子の情報とベンダー固有の記述子の情報を相関させるときにIDが使用されます。これに対して、WebLogicでは、相関を行うときにejb-nameが使用されます。したがって、WebLogicデプロイメント記述子をマイグレーションしてIBM固有の記述子を作成するときは、それらの記述子に適切なIDを追加する必要があります。これらのIDは、IBM Rational® Application Developerなどのアセンブリー・ツールを使用して自動的に作成させます。これらのIDの作成を自分で試みて、失敗した場合は、解決が難しいエラーが発生します。

    この記事では、Webサービスのデプロイメント記述子については触れません。これらのマッピングについては、以降の記事で説明します。



    図2 業界標準のデプロイメント記述子


  • ベンダー固有のデプロイメント記述子（図3）は、マイグレーションする必要があります。図3は、WebLogic固有のデプロイメント記述子と、それに対応するWebSphere固有のデプロイメント記述子を示しています。




    図3 ベンダー固有のデプロイメント記述子


    IBMは、以下のような、WebLogicデプロイメント記述子をWebSphere Application Serverにマイグレーションするためのツールを多数用意しています。

    • Xdocletタグ
    • WebSphere Rapid Deploymentタグ
    • Application Server Toolkit（デプロイメント記述子エディター）
    • IBM J2EE Competitive Migrator Plug-in for Rational Application Developer V6

    これらのツールで行えること、これらのツールをいつどのように使用するのか、ヘルプが得られる場所などについては、「Migrating Applications from WebLogic, JBoss and Tomcat to WebSphere V6（US）」を参照してください。これらのツールについて理解し、適切に使用することは重要です。これらのツールは、ベンダー固有のデプロイメント記述子の拡張の一部をマップしますが、そのすべてをマップするわけではありません。したがって、デプロイメント記述子を検査し、その中にある拡張のマップ方法を理解することは依然として重要です。こうしたことを理解した上でApplication Server Toolkitなどのアセンブリー・ツールを使用すると、非常に効率的に作業を行えます。


上に戻る

config.xmlエレメントのマッピング

このセクションでは、以下のサーバー構成エレメントをWebLogicからWebSphere Application Serverにマップする方法を説明します。

  1. JMSConnectionFactory
  2. JMSFileStore
  3. JMSServer
  4. ForeignJMSServer
  5. JDBCConnectionPoolおよびJDBCDataSource

各エレメントについて詳しくは、「WebLogic Server Configuration Reference」を参照してください。

  1. JMSConnectionFactory

    JMSConnectionFactoryエレメントは、接続ファクトリー・オブジェクトを作成し、それをJNDI名前空間にバインドします。このアプリケーションのconfig.xmlファイルには、3つの接続ファクトリーが構成されており、それぞれでXAが有効になっています。

    
<JMSConnectionFactory 
      JNDIName="jms/Operations"
      Name="Operations" Targets="myserver" 
      XAConnectionFactoryEnabled="true"
/>

<JMSConnectionFactory 
      JNDIName="jms/Mailing"
      Name="Mailing" Targets="myserver" 
      XAConnectionFactoryEnabled="true"
/>

<JMSConnectionFactory 
      JNDIName="jms/Administration"
      Name="Administration" Targets="myserver" 
      XAConnectionFactoryEnabled="true"
/>

    この構成をWebSphere Application Serverにマップするには、通常、前掲のJMS接続ファクトリー（US）をWebSphereデフォルト・メッセージング・プロバイダーに作成します。その他の注意事項をいくつか以下に示します。

    • WebSphere Application Server内にこれらのJMS接続ファクトリーを構成するときは、正しいJNDINameを使用します。JNDI名が正しくないと、アプリケーションは、接続ファクトリーを見つけることができなくなります。

    • メッセージ駆動型Bean（MDB）がトランザクションであるかどうかを確認します。なぜなら、トランザクション属性に「NotSupported」が指定された非トランザクションMDBに対してXAを無効にすると、パフォーマンスが向上する場合があるからです。非トランザクションMDBは、XAトランザクションには参加できません。また、非トランザクションMDBには、XAが有効の接続ファクトリーは不要です。一方、MDBのトランザクション属性に「Required」が指定されている場合は、XAをそのconnection-factory-jndi-nameに対して有効にする必要があります。

    • WebSphere Application Serverに接続ファクトリーを作成する場合、XAは、デフォルトで有効になります。

  2. JMSFileStore

    JMSFileStoreエレメントは、（キューの）永続メッセージと（トピックの）永続サブスクライバーをファイル・システム・ディレクトリーに保管する、ディスク・ベースのJMSファイル・ストアを定義します。以下のコード片は、単一のJMSファイル・ストアの定義を示しています。

    
<JMSFileStore 
      Directory="/log//weblogic/wl-myserver/rmfilestore"
      Name="FileStoreMailing" SynchronousWritePolicy="Cache-Flush"
/>

    この構成をWebSphere Application Serverにマップするには、最初にWebSphere Application Server V6.0デフォルト・メッセージングがJMSファイル・ストアをサポートしていないことを知る必要があります。このファイル・ストアはバージョン6.1の拡張機能ですが、バージョン6.0を使用している場合は、メッセージング・エンジンにJDBCデータ・ソースを定義する必要があります。

  3. JMSServer

    JMSServerエレメントは、そのJMS宛先（JMSQueueまたはJMSTopicエレメント）への接続およびメッセージを管理するJMSサーバーを定義します。config.xmlファイルからの以下のコード片には、3つのJMSサーバーが示されています。これらの各サーバーには、JMS宛先が2つ含まれています（ここでは、JMSキューを使用しています）。


<JMSServer Name="JMSServerOperations" Targets="myserver">
      <JMSQueue CreationTime="1149493675734"
            JNDIName="jms/Queue/EntryOperations" 
            Name="EntryOperations"/>
      <JMSQueue CreationTime="1161679692974"
            JNDIName="jms/Queue/ExitOperations" 
            Name="ExitOperations"/>
</JMSServer>

<JMSServer Name="JMSServerMailing" Store="FileStoreMailing" Targets="myserver">
      <JMSQueue CreationTime="1161682828610"
            JNDIName="jms/Queue/RequestEntryMailing" 
            Name="RequestEntryMailing"/>
<JMSQueue CreationTime="1161682915323"
      JNDIName="jms/Queue/RequestMailing" 
      Name="RequestMailing"/>
</JMSServer>

<JMSServer Name="JMSServerAdministration" Targets="myserver">
      <JMSQueue CreationTime="1161683412185"
            JNDIName="jms/Queue/EntryAdministration" 
            Name="EntryAdministration"/>
      <JMSQueue CreationTime="1161683429724"
            JNDIName="jms/Queue/ExitAdministration" 
            Name="ExitAdministration"/>
</JMSServer>

このWebLogic構成では、ファイル・ストアを使用するJMSサーバーは1つ（JMSServerMailing）だけです。他の2つのサーバーはJMSストアを指定していません。そのため、これらのJMSサーバーのキューは、永続メッセージをサポートしません。

宛先のデリバリー・モード（PERSISTENTまたはNON_PERSISTENT）をアプリケーションが明示的に設定していない場合は、WebLogic config.xmlファイルによって、メッセージが永続的であるかどうかが指定されます。したがって、ファイル・ストアの指定があるJMSサーバーは、その宛先に対して永続デリバリー・モードを使用します。ファイル・ストアの指定がないJMSサーバーは、非永続デリバリー・モードを使用します。

この構成をWebSphere Application Serverにマップする場合、JMSServerMailing JMSサーバーに定義されている2つの宛先に対しては永続メッセージングを使用し、その他のすべての宛先には非永続デリバリー・モードを使用します。繰り返しますが、WebSphere Application Server内でこれらのJMSキューを構成するときは、必ず、正しいJNDINameを使用してください。JNDI名が正しくない場合、クライアント・アプリケーションは、JMS宛先を見つけることができなくなります。

  1. ForeignJMSServer

    ForeignJMSServerエレメントは、WebLogic JMSサーバーの外部にあるJNDIプロバイダーを定義します。このエレメントは、ForeignJMSConnectionFactoryおよびForeignJMSDestinationエレメントの親エレメントです。これらのエレメントが提供する情報を使用すると、WebLogic ServerはリモートJNDIプロバイダーにアクセスできるようになり、その結果、クライアントは、ローカルJNDI名を使用してリモート接続ファクトリーと宛先オブジェクトを参照できるようになります。これは、WebSphere MQを JMSプロバイダーとして使用するときによく見られます。config.xmlファイルからの以下のコード片には、1つの外部JMSサーバー、1つの外部JMS接続ファクトリー、および2つの外部JMS宛先が示されています。

    
<ForeignJMSServer ConnectionURL="file:/var/mqm/qmgrs"
      InitialContextFactory="com.sun.jndi.fscontext.RefFSContextFactory"
      JNDIProperties="" Name="JMSServerMailingMq" Targets="myserver">
      <ForeignJMSConnectionFactory
            LocalJNDIName="jms/MailingMq"
            Name="MailingMq" 
            RemoteJNDIName="MYSERVER"/>
      <ForeignJMSDestination
            LocalJNDIName="jms/Queue/RequestMailingMq"
            Name="RequestMailingMq" 
            RemoteJNDIName="J2EE_MVS_OFF_IN"/>
      <ForeignJMSDestination
            LocalJNDIName="jms/Queue/RespuestaMailingMq"
            Name="RespuestaMailingMq" 
            RemoteJNDIName="J2EE_MVS_OFF_OU"/>
</ForeignJMSServer>

    この構成の外部JMSサーバー、接続ファクトリー、および宛先は、WebSphere MQ JMSプロバイダーにマップされます。LocalJNDINameとRemoteJNDINameを正しく構成することが重要です。

  2. JDBCConnectionPoolおよびJDBCDataSource

    JDBCConnectionPoolおよびJDBCTxDataSourceエレメントは、JDBCリソースの構成を定義します。config.xmlファイルからの以下のコード片には、単一の接続プールおよびデータ・ソースの構成が示されています。

    
<JDBCConnectionPool DriverName="oracle.jdbc.driver.OracleDriver"
                    Name="MyJDBCConnectionPool"
                    PasswordEncrypted="{3DES}B2Bl+tp70Eh3D1pT53/anw=="
                    Properties="user=wles" Targets="myserver"
                     URL="jdbc:oracle:thin:@localhost:1521:ASI"
                     InitialCapacity="25" MaxCapacity="125"
                     TestTableName="SQL SELECT 1 FROM DUAL"/>
  <JDBCTxDataSource JNDIName="jdbc/MyDataSource"
                    Name="MyJDBCDataSourceName"
                    PoolName="MyJDBCConnectionPool"
                     Targets="myserver"/>

    このコードでは、

    • JDBCConnectionPoolエレメントによって、データ・ソースに対してgetConnectionを呼び出したときにプールから戻される接続のプロパティーが定義されています。

    • JDBCTxDataSourceエレメントによって、トランザクション対応JDBCデータ・ソースが定義されています。また、データ・ソースをバインドするJNDI名とこのデータ・ソースに関連付けられる接続プールが指定されています。

    接続プールとデータ・ソース（US）をWebSphere Application Serverにマップするには、JDBCプロバイダー、JDBCデータ・ソース、およびJCA認証データ・エントリーを構成します。最も重要なエレメントは、JNDIName、DriverName、URL、PasswordEncrypted、および Propertiesです。（パスワードは config.xmlファイル内で暗号化されているので、データベース管理者から入手する必要があります。）

    TestTableName属性をマップするには、SQLストリングの事前テストと呼ばれるWebSphereプロパティーを使用します。このプロパティーでは、各JDBC接続をテストするようにSQL文を設定できます。また、接続再試行の間隔も設定できます。

    <InitialCapacity>および<MaxCapacity>エレメントに基づいてプール・サイズを構成する必要もあります。デフォルトでは、WebSphere Application Server接続プールには、最小で1個、最大で10個の接続が含まれます。WebLogic接続プールは、25個の接続で開始するように構成されているため、WebSphereプール・サイズを構成する必要があります。これを行うには、以下のステップを実行します。

    1. WebSphere Application Server管理コンソールを開き、「リソース」=>「JDBCプロバイダー」を選択します。
    2. プロバイダーの名前を選択します。
    3. 「追加プロパティー」の下で「データ・ソース」エントリーを選択します。
    4. データ・ソース名をクリックします。
    5. 「接続プールのプロパティー」を選択します。
    6. 最小接続数のフィールドと最大接続数のフィールドを使用して、プール・サイズを構成します。

JDBCリソースを構成する際に使用できるWebLogic固有の属性は他にもいくつかありますが、最も頻繁に使用されるのは、上記の属性です。


上に戻る

次頁へ
レベルマークについて

このページで紹介されている情報はレベル別にカテゴライズされています。

： 上級者向け
： 中級者向け
： 初級者向け
： 入門者向け