お客様が developerWorks に初めてサインインすると、プロフィールが作成されます。プロフィールで選択した情報は公開されますが、いつでもその情報を編集できます。お客様の姓名（非表示設定にしていない限り）とディスプレイ・ネームは、投稿するコンテンツと一緒に表示されます。

送信されたすべての情報は安全です。

developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

送信されたすべての情報は安全です。

My developerWorks：

通知：

サイン・アウト

言語を選択する：

WebLogicサーバーおよびアプリケーション構成のWASへのマイグレーション

Donald Vines (dhvines@us.ibm.com), Executive IT Architect, IBM

Donald Vinesは、北米でのWebSphereマイグレーション・プラクティスを担当するIBMのエグゼクティブITアーキテクトです。Donは、全社的で複雑な業務システムのアーキテクチャー、設計、および開発に関して、20年を超える豊富な実装経験を持っています。また、ソフトウェア開発ライフ・サイクルのすべてのフェーズで、ソフトウェア・アーキテクチャーを提供するだけではなく、開発プロセスを定義したり、テクニカル・チームに助言を与えたりしています。以前は、世界最大の業界標準化団体、Object Management Group（OMG）の技術代表者を務め、現在インターネット全体で使用されているInternet Inter-ORB Protocol（IIOP）の考案にも加わりました。Donは、アーキテクチャーと設計、Webサービス、およびJ2EEマイグレーションに関する著名な演説者であり、半導体製造の高度なプロセス制御に関わる米国特許を保有しています。

概要： この記事では、WebLogicアプリケーションおよびサーバー構成をWebSphere Application Serverにマイグレーションする方法を説明します。

タグを付ける!

日付: 2007年 6月 06日
レベル: 中級
この記事の原文: 英語
アクティビティー： 6240 ビュー
お気軽にご意見・ご感想をお寄せください：

また、ご使用のアプリケーションを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にマップする方法を説明します。

JMSConnectionFactory
JMSFileStore
JMSServer
ForeignJMSServer
JDBCConnectionPoolおよびJDBCDataSource

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

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は、デフォルトで有効になります。

JMSFileStore

JMSServerエレメントは、そのJMS宛先（JMSQueueまたはJMSTopicエレメント）への接続およびメッセージを管理するJMSサーバーを定義します。config.xmlファイルからの以下のコード片には、3つのJMSサーバーが示されています。これらの各サーバーには、JMS宛先が2つ含まれています（ここでは、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データ・ソースを定義する必要があります。

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宛先を見つけることができなくなります。

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を正しく構成することが重要です。

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プール・サイズを構成する必要があります。これを行うには、以下のステップを実行します。

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

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

上に戻る

WebLogic起動スクリプトのマッピング

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

JVM引数
システム引数
クラスパス

WebLogic構成エレメントについて詳しくは、『参考文献』

JVM 引数
一般にWebLogicでは、JVM引数をカスタム起動スクリプトに指定します。起動スクリプトは、必ず、環境に応じて正しいものを入手するようにしてください。 Sun™ JVMオプションを使用する例を以下に示します。
-server -Xms1024m -Xmx1024m -verbose:gc -Xloggc:wls-gc.log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:ParallelGCThreads=8 -XX:PermSize=128m -XX:MaxPermSize=128m
WebLogic用に調整されたのと同じJVM上でWebSphere Application Serverを実行するものと想定すると、上記の拡張はこのJVMをWebSphere Application Server用に調整する際の適切な開始点になるはずですが、負荷テストに基づいてこれらを調整することもできます。これらのJVM引数をWebSphere Application Serverに追加するには、以下のステップを実行します。
1. 管理コンソールから「サーバー」=>「アプリケーション・サーバー」=> server_name =>「プロセス定義」=>「Java 仮想マシン」を選択します。
2. 「冗長ガーベッジ・コレクション」にチェック・マークを付けます（これは、オフにすることを忘れないでください）。
3. 「初期ヒープ・サイズ」を1024に設定します。
4. 「最大ヒープ・サイズ」を1024に設定します。
5. 「汎用 JVM 引数」ボックスに先頭の引数として-serverを追加します。次に、他の既存の引数の後に以下の引数を追加します。
  -XX:ParallelGCThreads=8 -XX:PermSize=128m -XX:MaxPermSize=128m -Xloggc:wls-gc.log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps
注意すべき点を以下に示します。
- 冗長ガーベッジ・コレクションを有効にするには、-verbose:gcオプションを使用します。負荷テストの間にガーベッジ・コレクション統計を収集することは重要なことです。しかし、大きなコレクションから小さなコレクションまで、すべてのコレクションがログに記録されるので、最終的なベンチマークを実行する前には、冗長ガーベッジ・コレクションを無効にすることを忘れないでください。
SunのJVMおよびその他のJVMの調整について詳しくは、『Java仮想マシンの調整』を参照してください。
システム引数
WebLogic起動スクリプトに指定された -D 引数は、WebSphere Application Serverにすべてマップする必要があります。システム引数をマップしないと、ほぼ確実にマイグレーションで問題が発生します。システム引数をWebSphere Application Serverにマップするには、以下のステップを実行します。
1. 管理コンソールから「アプリケーション・サーバー」=> server_name =>「プロセス定義」=>「Java 仮想マシン」を選択します。
2. この例では、起動スクリプトに2つの引数が含まれています。一つは、キャッシュを有効にする引数、もう一つは、log4j構成ファイルの場所を指定する引数です。これらの引数は、「汎用JVM引数」ボックスのすべての既存のJVM引数の後に追加する必要があります。
  -Dtangosol.coherence.distributed.localstorage=true -Dlog4j.configuration=file:///myprojects/config/log4j.xml
クラスパス
多くの場合、起動スクリプトのWebLogicクラスパスは変更されています。その理由としては、アプリケーションのエンタープライズ・アーカイブに含まれていないJARを追加するため、またはアプリケーションがロードする構成ファイルを検索するディレクトリーを追加するために使用するJARを追加するためと考えられます。いずれかの状況でこれらをマップするには、以下のステップを実行します。
1. 管理コンソールから「アプリケーション・サーバー」=> server_name =>「プロセス定義」=>「Java 仮想マシン」を選択します。
2. この例では、WebLogic起動スクリプトでディレクトリーがクラスパスに追加されています。したがって、ユーザーは、そのディレクトリーをWebSphere Application Serverクラスパスにも追加します。このフォルダーを「クラスパス」ボックスに追加します。 C:\myprojects
  JARをクラスパスに追加するときには、注意が必要です。この作業は、WebSphere Application Serverディストリビューションに当該JARが既に含まれていないことを確認して初めて行ってください。

上に戻る

weblogic-ejb-jarエレメントのマッピング

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

jndi-name
local-jndi-name
max-beans-in-free-poolおよびinitial-beans-in-free-pool
max-beans-in-cacheおよびidle-timeout-seconds
trans-timeout-seconds
concurrency-strategy
enable-call-by-reference
cache-between-transactions
delay-updates-until-end-of-tx
finders-load-bean
resource-description
resource-env-description

WebLogic構成エレメントについて詳しくは、『参考文献』を参照してください。

jndi-name

jndi-nameエレメントは、グローバルJNDI名前空間のEJBのJNDI名を指定します。EJBのJNDI名をWebSphere Application Serverで設定するには、EJBプロジェクトと正しいEJBを知る必要があります。これらを見つけるには、weblogic-ejb-jarファイルで以下のエレメントを検索します。 <jndi-name> jndi-nameエレメントをWebSphere Application Serverにマップするには、以下のステップを実行します。
1. アセンブリー・ツールを開始して、EJBプロジェクトを開きます。
2. Rational Application Developerを使用している場合は、デプロイメント記述子をダブルクリックします。
3. 該当するEJBコンポーネントをクリックします。
4. 「WebSphere バインディング」セクションが表示されるまで下にスクロールして、そのBeanのJNDI名を入力します。
local-jndi-name

local-jndi-nameエレメントは、グローバルJNDI名前空間におけるBeanのローカル・ホームのJNDI名を定義します。つまり、WebLogicでは、グローバルJNDI名前空間におけるローカル・ホームのJNDI名を指定する方法を提供しています。ただし、これを行うと、リモート・クライアントがグローバルJNDI名前空間のローカル・インターフェースを検索できるようになり、その結果、実行時にエラーが発生する場合があります（これは、ローカル・ホームはクライアントと同じコンテナーに配列する必要があるからです）。ここで、WebSphere側を考える前に、JNDIの背景を検討します。
- J2EEの仕様には、グローバルJNDI名前空間へのEJBのマッピングは明記されていません。これは、ベンダーに任されています。したがって、大部分のベンダーは、ベンダー独自のデプロイメントにエレメントを組み込んで、グローバルJNDI名前空間のリモートEJB JNDI名を指定しています。
- ただし、定義上、ローカル・ホーム・インターフェースは、ローカル・コンテナーでしかアクセスできません。そのため、ベンダーは、それをグローバルJNDI名前空間にバインドする必要はありません。クライアント・モジュールがJNDIを使用してローカル・ホームを検索する可能性がありますが、コンテナーは、それをJNDI名前空間に公開する必要はありません。その代わり、クライアント・モジュールは、EJBへのJNDI参照を定義し、検索の中でjava:comp/envを使用して、ローカル名前空間でそれにアクセスする必要があります。
- 業界では、JNDI名を使用してグローバル名前空間のEJBに直接アクセスするよりも、JNDI参照を使用してローカル名前空間のEJBにアクセスすることが推奨されています。JNDI参照を使用すると、クライアント・モジュールは、グローバルJNDI名前空間の変更の影響を受けなくなります。これは、同じEJBの複数のバージョンをサポートするために必要です。つまり、ソース・コードを一切変更することなく、同じJNDI参照を使用するクライアント・モジュールを新しいバージョンのEJBにバインドすることが可能です。クライアント・モジュールは、別のEJBを指すようにJNDI参照をバインドするだけです。
こうした背景において、local-jndi-nameエレメントをWebSphere Application Serverにマップするには、どうすればよいでしょうか。

最初に理解する必要があるのは、WebSphere Application Serverでは、ローカル・ホームのJNDI名を定義する方法は提供されていないということです。その代わりとしてユーザーは、グローバル名前空間のJNDI名ではなく、ローカル名前空間のJNDI参照を使用してローカルBeanにアクセスする必要があります。

あいにく、一部のWebLogicアプリケーションは、ローカルJNDI名前空間でJNDI参照を使用して間接的にローカル・オブジェクトを参照するのではなく、グローバルJNDI名前空間でJNDI名を使用して直接ローカル・オブジェクトを参照します。したがって、これらのアプリケーションに対して、いくつかのコードの変更が必要になります。 local-jndi-nameエレメントをWebSphere Application Serverにマップする方法はいくつかありますが、それらは、サポートされていないか、または非実用的なものです。ただし、使用できる一つの方法は、ローカルJNDI参照を呼び出し側のモジュールに追加して（これは、ローカル・ホームを検索する標準的な方法です）、すべてのJNDI検索でjava:comp/env接頭部を使用することです。これは、EJBだけではなく、その他のリソース（JMS接続ファクトリーなど）へのアクセスにおいても、業界で認識されているベスト・プラクティスです。したがって、この方法がここで使用すべき解決策になります。
max-beans-in-free-poolおよびinitial-beans-in-free-pool

max-beans-in-free-poolエレメントは、特定のエンティティーBean、ステートレス・セッションBean、またはメッセージ駆動型Beanについて、EJBの空きプールの最大サイズを定義します。各Beanクラスは、このエレメントを使用して、その独自の空きプールのサイズを定義できます。

initial-beans-in-free-poolエレメントは、始動時に特定のBeanクラスの空きプールに追加するBeanインスタンスの最初の数を定義します。空きプールにインスタンスを追加すると、新しいインスタンスを生成することなく最初のBeanの要求を満たすことができるので、初期応答時間が改善されます。

WebLogicでは、アプリケーション内のひとつひとつのBeanが、最大プール・サイズと初期プール・サイズを指定できます。これらのプール・サイズは、Beanクラスごとに大きく異なる場合があります。特定のプール・サイズを確認するには、weblogic-ejb-jar.xmlファイルで、以下のエレメントのいずれかを参照します。

<initial-beans-in-free-pool> <max-beans-in-free-pool>
WebSphere Application ServerでEJBプール・サイズを指定するには、以下の方法でシステム引数をJVMに追加します。
1. 管理コンソールから「アプリケーション・サーバー」=>「サーバー名」=>「プロセス定義」=>「Java 仮想マシン」を選択します。
2. 「汎用JVM引数」ボックスのすべての既存のJVM引数の後にcom.ibm.websphere.ejbcontainer.poolSizeを追加します。RuleEngineEJBという名前のBeanの最小プール・サイズを 1、最大プール・サイズを5に設定する例を以下に示します。
  -Dcom.ibm.websphere.ejbcontainer.poolSize =myapp#RulesEngine.jar#example.RulesEngineEJB=1,5
詳しくは、『EJB コンテナーの調整』を参照してください。

プール・サイズの拡張をマップすることはできますが、アプリケーション・サーバーでの空きプールの扱いについては異なります。
- プールが空の場合、WebLogicは、別のインスタンスを作成しません。新しいBeanの要求は、既存のBeanがプールに戻されるまで待機する必要があります。プール・サイズが適切でない場合は、このポリシーによってデッドロック状況が発生する場合があります。ただし、アクティブ・オブジェクトの数が制御されているので、スケーラビリティーには貢献する場合があります。
- プールが空の場合、WebSphere Application Serverは、（その要求を待機させるのではなく）新しいインスタンスを作成します。要求でその新しいインスタンスが使用された後、プール内のBeanがまだ最大サイズでない場合は、WebSphere Application Serverによって、Beanがプールに戻されます。（WebSphere Application Serverのデフォルトのプール・サイズは、最小が50、最大が500です。）
こうした違いに注意することは重要です。なぜなら、Beanプールが高い負荷の下で枯渇している場合、オブジェクトを作成するのにコストがかかる場合、またはリソースの消費量が多すぎる場合など、特定の状況では、WebSphere Application Serverでパフォーマンスやスケーラビリティーの問題が発生する場合があるからです。例えば、以下の状況を考えます。
- 作成するのに非常にコストのかかるセッションBeanをアプリケーションが実装します。このようなセッションBeanの例としては、ルール・ベースをヒープにキャッシュするルール・エンジンへのインターフェースを提供するセッションBeanがあります（ルール・ベースは、数百メガバイトのデータである場合があります）。
- このBeanは、作成するのに非常にコストがかかり、ヒープ内の使用可能スペースを大量に消費するので、アプリケーションは、空きプール内のBeanの最大数を5に制限しています。これにより、そのようなBeanの数は、実際にいつでも5に制限されます。
- アプリケーションは、高い負荷の下で追加のセッションBeanを繰り返し作成/破棄するよりも、5つのアクティブなセッションBeanインスタンスを通じてこの「ルール・サービス」の着信要求をすべて処理した方が（スケーラビリティーの観点から）よいため、アクティブBeanの数を制限します。
ここで、このプール・サイズ（最小値1、最大値5）をWebSphere Application Serverにマップします。プール・サイズは5に制限しますが、アクティブ・インスタンスのその数値は5に制限しないので、マッピングはうまく機能します。 5つのセッションBeanをすべて使用する5つの要求が存在する場合は、プールは空になります。ただし、これらのセッションBeanの1つに対して6番目の要求が届いた場合は、単にプールに戻されるのではなく、6番目のセッション・オブジェクトが作成されて使用されます。 WebLogicでは、6番目のセッション・オブジェクトの要求は、アクティブBeanの1つがプールに戻されるのを待機してから、処理を続行する必要があります。

お分かりのように、このようなストレートなプール・サイズのマッピングでは、追加のセッションBeanが作成される場合があります。そして、高い負荷の下でこのように追加のBeanを作成および破棄することにより、スケーラビリティーの問題が発生する場合があります。アクティブ・セッションの数に関してアプリケーションがハード・リミットを要求する場合、Beanは、空きプール内のBeanの数を追跡し、使用可能なBeanがない場合はアクティブBeanが完了するのを待機する必要があります。

この例から得られる重要な教訓は、負荷テストの間は、アクティブBeanの最大数を監視して、それがプールの最大サイズを超えないようにする必要があるということです。プールの最大サイズを超えた場合は、プール・サイズを大きくすることにより、オブジェクトが頻繁に作成および破棄されないようにする必要があります。または、アクティブBeanの数に対するハード・リミットを実装する必要があります。
max-beans-in-cache および idle-timeout-seconds

max-beans-in-cacheエレメントは、このクラスのいつでも活動化できるオブジェクトの最大数を制御します。 max-bean-in-cacheの値に到達すると、WebLogicは、クライアントが最近使用していないいくつかのEJBを非活性化します。

idle-timeout-secondsエレメントは、Beanがキャッシュ内に存続する最大時間を指定します。この時間が経過したときに、キャッシュ内のBeanの数がmax-beans-in-cacheに接近している場合は、コンテナーがBeanを除去します（このエレメントは、WebLogic 8.1 SP4より前では無視されていました）。

WebLogicでは、個々のBeanクラスのキャッシュを定義できます。メモリーに格納できるオブジェクトは、アイドル・タイムアウトと同様にクラスに応じても異なります。カスタマイズしたキャッシュを見つけるには、weblogic-ebj-jar.xmlで、以下のいずれかのエレメントを検索します。

<max-beans-in-cache> <idle-timeout-seconds>

WebSphere Application Serverでは、キャッシュ・サイズまたはidle-timeout（WebSphere Application Serverでは、 クリーンアップ間隔と呼ばれる）をBeanクラスごとに指定することはできませんが、 EJBコンテナー全体でアクティブなインスタンスのキャッシュ・サイズとクリーンアップ間隔を指定することはできます。

WebSphere Application Serverのキャッシュ・サイズは、max-beans-in-cacheと似ています。これは、EJBコンテナー内のアクティブ・インスタンス・リストのバケット数を指定します。バケットには複数のインスタンスを含めることができますが、アクティブ・インスタンス数がバケット数（キャッシュ・サイズ）を超えると、コンテナーは、一部のインスタンスを除去するために、それらを非活性化してディスクに移すことを試みます。したがって、一般的なワークロードの間に予期されるアクティブ・インスタンスの最大数にキャッシュ・サイズを設定した場合は、最高のパフォーマンスが得られます。

WebSphere Application Serverのクリーンアップ間隔は、idle-timeout-secondsと似ています。これは、キャッシュ内の項目の総数をキャッシュ・サイズの値に削減するために、コンテナーがキャッシュから未使用の項目を除去しようとする間隔を指定します。

WebLogicキャッシュ・サイズがクラス単位で調整されているアプリケーションがある場合は、 WebSphere EJBキャッシュ・サイズを調整するときに、それらのキャッシュ・サイズを検討する必要があります。各種のBeanに基づいて平均的なEJBキャッシュ所要量を計算するアルゴリズムが用意されており、これを使用して、コンテナーのEJBキャッシュ・サイズを調整することが可能です。

アプリケーションに多数のエンティティーBeanが存在する場合は、コンテナー内でアクティブなEJBの数について、その予期される最大値を、任意のインスタンスでmax-beans-in-cacheエレメントの値を使用して適時計算する必要があります。また、負荷テスト時にキャッシュをモニターして、キャッシュからの排除が発生していないこと、つまり、ejbStoresが頻繁に呼び出されていないことを確認する必要があります。このアクションは重要です。なぜなら、WebSphere Application Serverのデフォルトの最大キャッシュ・サイズはわずか 2、3000ですが、エンティティーBeanを多用するアプリケーションでは、プール・サイズに既に数千が指定されている場合があるからです。
trans-timeout-seconds

trans-timeout-secondsエレメントは、EJBのコンテナー開始トランザクションの最大期間を指定します。トランザクションがtrans-timeout-secondsより長く継続する場合、WebLogic EJBコンテナーは、トランザクションをロールバックします。この拡張は、すべてのweblogic-ejb-jar.xmlファイルで以下のエレメントを検索することにより確認できます。 <trans-timeout-seconds>
WebSphere Application Serverでは、トランザクション・タイムアウトを2つの方法で設定できます。

オプション1：すべてのBeanがトランザクション・タイムアウトに同じ値を設定している場合は、管理コンソールを使用して、 WebSphereトランザクション・サービスの最大トランザクション・タイムアウトを設定できます。
1. 管理コンソールから、「サーバー」=>「アプリケーション・サーバー」=> server_name =>「コンテナー・サービス」=>「トランザクション・サービス」を選択します。
2. 「合計トランザクション存続時間タイムアウト」に30を設定します。
オプション 2：Beanのデプロイメント記述子にトランザクション・タイムアウトを設定できます。これを行うには、以下のステップを実行します。
1. Rational Application Developerで、EJBプロジェクトごとにそのデプロイメント記述子をダブルクリックします。
2. トランザクション・タイムアウトを設定する特定のBeanをダブルクリックします。
3. 「コンポーネント・トランザクション・タイムアウト整数」に30を設定します。
通常は、すべてのBeanのトランザクション・サービスではなく、Beanのデプロイメント記述子を変更することをお勧めします。すべてのBeanのトランザクション・タイムアウトを変更すると、そのコンテナーで実行中のすべてのアプリケーションに影響が及びます。ただし、アプリケーションがすべてのBeanでトランザクション・タイムアウトに同じ値を設定しており、そのアプリケーションがこのコンテナー内で実行されている唯一のアプリケーションである場合は、各Bean内ではなく、 WebSphere Application Serverトランザクション・サービスで一度に値を設定したほうがはるかに簡単です。これが該当しない場合は、Beanごとにトランザクション・タイムアウトを設定する必要があります。
concurrency-strategy

concurrency-strategyエレメントは、エンティティーBeanへの同時アクセスをコンテナーで管理する方法を指定します。WebLogicは、4つの異なるコンカレンシー・ストラテジーをサポートしています。
- Exclusiveコンカレンシー・ストラテジー。このコンカレンシー・ストラテジーにより、WebLogic Serverは、 Beanがトランザクションに関連付けられているときに、キャッシュされたエンティティーEJBインスタンスを排他ロックします。 EJBインスタンスのその他の要求は、トランザクションが完了するまでブロックされます。 Exclusiveコンカレンシー・ストラテジーを使用するBeanを見つけるには、weblogic-ejb-jar.xmlファイルで以下のエレメントを検索します。 <concurrency-strategy>Exclusive</concurrency-strategy>
  これが見つかったら、そのEJBプロジェクトとEJB名をメモしておきます。EJBプロジェクトとEJB名は、これをWebSphere Application Serverにマップするときに必要になります。
  1. Rational Application DeveloperでEJBプロジェクトを開きます。
  2. デプロイメント記述子をダブルクリックします。
  3. 該当するJava Beanをダブルクリックします。
  4. 「Beanのキャッシュ」セクションが表示されるまで下にスクロールします。
  5. 「活動化」に「1回」を設定します。
  6. 「ロード」に「活動化」を設定します。
  これらのパラメーターにより、ejbLoad関数の呼び出しは行われませんが、Beanインスタンスへのアクセスはシリアライズされます。このオプションでは、キャッシュ内で永続状態が維持されることにより、メモリー使用率が増加します。ただし、Beanインスタンスが通常同時アクセスされない場合は、応答時間（US）が改善されます。このオプションは、EJB仕様のOption Aキャッシングと呼ばれます。
- ReadOnlyコンカレンシー・ストラテジー。このコンカレンシー・ストラテジーは、読み取り専用エンティティーBeanで使用されます。 ReadOnlyコンカレンシー・ストラテジーは、トランザクションごとに新しいインスタンスを活動化して、要求が同時に進行するようにします。 WebLogic Serverが読み取り専用BeanのejbLoad()を呼び出すときは、<read-timeout-seconds>エレメントに基づきます。
  
  read-timeout-secondsエレメントは、読み取り専用エンティティーBeanに対する複数のejbLoad()呼び出しの間隔（秒）を指定します。これは、ReadOnlyコンカレンシー・ストラテジーが指定されたBeanにのみ適用されます。 read-timeout-secondsの値を0にすると、読み取り専用Beanをデータベースから再ロードしないことが指定されます。
  
  読み取り専用Beanを見つけるには、weblogic-ejb-jar.xmlファイルで以下のエレメントを検索します。
  <concurrency-strategy>ReadOnly</concurrency-strategy> 繰り返しますが、EJBプロジェクトとEJB名は、必ずメモするようにしてください。そうすれば、これらをWebSphere Application Serverで読み取り専用Beanとしてマークできるようになります。
  1. Rational Application DeveloperでEJBプロジェクトを開きます。
  2. デプロイメント記述子をダブルクリックします。
  3. 該当するJava Beanをダブルクリックします。
  4. 「Beanのキャッシュ」セクションが表示されるまで下にスクロールします。
  5. 「活動化」に「1回」を設定します。
  6. 「ロード」に「間隔」を設定します。
  7. 「再ロード間隔整数」に適切な数値（分）を設定します。（例えば、WebLogicの<read-timeout-seconds>エレメントに600秒が設定されていた場合、WebSphere Application Serverでは「再ロード間隔整数」に10分を設定します。）
  WebLogicの<read-timeout-seconds>に0が設定されている場合、ejbLoadは、インスタンスが最初にキャッシュに格納されるときにのみ呼び出されます。WebSphere Application Serverでは、「再ロード間隔整数」の値に0を設定すると、コンテナーがBeanを再ロードしなくなります。（WebSphere Application Serverでの読み取り専用Beanの開発について詳しくは、『参考文献』を参照してください。）
- Databaseコンカレンシー・ストラテジー。このコンカレンシー・ストラテジーにより、WebLogic Serverは、エンティティーBeanのロック要求を基盤となるデータストアに委任します。このストラテジーにより、WebLogic Serverは、個別のエンティティーBeanインスタンスを割り振り、ロックとキャッシュをデータベースで処理できるようにします。これは、デフォルトのオプションです。
  
  WebLogic Databaseコンカレンシー・ストラテジーでは、トランザクションの開始時にBeanを活動化してキャッシュに追加し、トランザクションの終了時にBeanを非活動化してキャッシュから除去します。
  
  Databaseコンカレンシー・ストラテジーを使用するEJBコンポーネントおよびプロジェクトを見つけるには、weblogic-ejb-jar.xmlファイルで以下のエレメントを検索します。
  
  <concurrency-strategy>Database</concurrency-strategy> 繰り返しますが、EJBプロジェクトとEJB名はメモしておいてください。Databaseコンカレンシー・ストラテジーをWebSphere Application Serverにマップするには、以下のステップを実行します。
  1. Rational Application Developer で EJB プロジェクトを開きます。
  2. デプロイメント記述子をダブルクリックします。
  3. 該当する Java Bean をダブルクリックします。
  4. 「Bean のキャッシュ」セクションが表示されるまで下にスクロールします。
  5. 「活動化」に「トランザクション」を設定します。
  6. 「ロード」に「トランザクション」を設定します。
  WebSphere Application Server V6.0 Beanキャッシュのデフォルトは、「活動化」が「トランザクション」で「ロード」が「トランザクション」です。これはデフォルトなので、Databaseコンカレンシー・ストラテジーを使用するBeanごとに明示的に設定する必要はありません。このストラテジーは、EJB仕様のOption Cキャッシングとも呼ばれます。
- Optimisticコンカレンシー・ストラテジー。このコンカレンシー・ストラテジーは、トランザクション中にEJBコンテナーまたはデータベースにロックを保持しません。 EJBコンテナーは、トランザクションをコミットする前に、トランザクションが更新したデータが変更されていないことを確認します。更新データが変更されていた場合、EJBコンテナーは、トランザクションをロールバックします。
  
  Optimisticコンカレンシー・コントロールをサポートするBeanを見つけるには、weblogic-ejb-jar.xmlファイルで以下のエレメントを検索します。
  
  <concurrency-strategy>Optimistic</concurrency-strategy> EJBプロジェクトとEJB名は、必ずメモしてください。これらの値は、Databaseコンカレンシー・ストラテジーをマイグレーションするときに必要になります。
  
  これらのBeanを見つけて、その名前とEJBプロジェクトの名前をメモしたら、weblogic-cmp-rdbms-jar.xmlで<verify-columns>エレメントを検索します。テーブルのこれらの列は、データベースにそれをコミットする前に検証する必要のある列です。他のトランザクションがデータを変更していないことを確認する必要があります。
  
  以上で、WebSphere Application ServerでOptimisticコンカレンシーを構成する準備が整いました。
  1. 最初に、デプロイメント記述子のオプティミスティック・ロックを以下の手順で有効にします。
    1. Rational Application DeveloperでEJBプロジェクトを開きます。
    2. デプロイメント記述子をダブルクリックします。
    3. 「アクセス」タブを選択します。
    4. 「Entities 2.x のアクセス・インテント（Beanレベル）」でEJBを選択して、「追加」ボタンを押します。
    5. 「アクセス・インテント名」で「wsOptimisticUpdate」を選択して、「完了」ボタンを押します。
  2. 次に、変更データをコミットするときに過剰更新ステートメントに含めるフィールドを指定します。これを行うには、EJBからDDBへのマッピングに関してデータベース・マップを定義する必要があります。これを行うときは、以下のようにします。
    1. EJBプロジェクトを右クリックします。
    2. 「EJBからRDBへのマッピング」=>「マップの生成」を選択します。
    3. 「概要」セクションの「エンタープライズBean」ペインで、SQL過剰更新ステートメントに含めるオプティミスティック述部として使用する必要のあるCMPフィールドを選択します。
    4. 「プロパティー」ビューで、OptimisticPredicateに「True」を選択します。
enable-call-by-reference

通常、enable-call-by-referenceエレメントは、パラメーターのコピーを作成する必要がある値によるパラメーターの受け渡しではなく、参照によるパラメーターの受け渡しをするために使用されます。enable-call-by-referenceがTrueの場合は、同じEARファイルまたはスタンドアロンJARファイル内から呼び出されたEJBメソッドが引数を参照により受け渡しします。これにより、パラメーターがコピーされないので、メソッド呼び出しのパフォーマンスが向上します。

WebLogicでは、参照による呼び出しをBeanごとに有効にできますが、WebSphere Application Serverでは、参照による呼び出しをコンテナー・レベルで有効にします。したがって、参照による呼び出しが有効の場合は、アプリケーションのすべてのリモート・インターフェースのサブセットだけではなく、それらのすべてに参照による呼び出しが適用されます。

WebSphere Application Serverで参照による呼び出しを有効にするには、以下のステップを実行します。
1. 管理コンソールから、「サーバー」=>「アプリケーション・サーバー」=> server_name =>「コンテナー・サービス」=>「ORBサービス」を選択します。
2. 「参照による受け渡し」をチェックします。
cache-between-transactions

cache-between-transactionsエレメントは、EJBコンテナーがエンティティーBeanの永続状態をトランザクション間でキャッシュするかどうかを指定します。トランザクション間で永続状態をキャッシュする場合は、Trueを指定します。トランザクション間で永続状態をキャッシュしない場合は、False（デフォルト）を指定します。

トランザクション間でキャッシュを行えるかどうかは、コンカレンシー・ストラテジーによって決まります。
- コンカレンシー・ストラテジーがReadOnlyの場合、永続状態は常にトランザクション間でキャッシュされます。
- コンカレンシー・ストラテジーがDatabaseの場合、永続状態はトランザクション間でキャッシュされません。
したがって、エンティティーでReadOnlyまたはDatabaseコンカレンシー・ストラテジーを使用する場合、cache-between-tansactionsエレメントは、これらのBeanのEJBコンテナーによって実際には無視されます。

WebSphere Application Serverでは、cache-between-transactionsエレメントをマップする必要はありません。なぜなら、読み取り専用BeanのWebSphere Application Serverの実装では、永続状態はトランザクション間で常にキャッシュされ、 Databaseコンカレンシー・ストラテジーの実装では、永続状態はキャッシュされないからです。これは、WebLogicと同じ動作です。
delay-updates-until-end-of-tx

delay-updates-until-end-of-txエレメントは、デフォルトではTrueに設定されており、トランザクションの完了時にトランザクションのすべてのBeanの永続ストアを更新します。これは、トランザクションが終了するまですべてのデータベース操作をバッチ処理することと一致します（これは、WebLogicのデフォルトでもあります）。このエレメントをFalseに設定すると、CMP EJB設定メソッドを呼び出すたびに、更新情報がデータベースに書き込まれます。通常、これをTrueに設定するとパフォーマンスが向上しますが、データベース・トランザクション内のデータベース更新の順序が維持されなくなります。

WebLogicアプリケーションでは、delay-updates-until-end-of-txにFalseが指定されたBeanがいくつか存在する場合があります。通常は、これによって、トランザクションが終了するまでデータベース操作をすべて遅延するという、デフォルトのWebLogic設定がオーバーライドされるでしょう。トランザクションが終了するまで更新を遅延する機能をオフにするBeanを見つけるには、weblogic-ejb-jar.xmlファイルで以下のエレメントを検索します。
<delay-updates-until-end-of-tx>false</delay-updates-until-end-of-tx>
WebSphere Application Serverの場合は、デフォルトでは、トランザクションが終了するまで更新が遅延されるのではなく、 CMP mutatorを呼び出すたびにデータベース操作が実行されます。WebSphere Application Serverでは、パフォーマンスを最適化するために、トランザクションが終了するまで更新を遅延できますが、この機能は、コンテナー内のすべてのBeanに対してのみオンまたはオフにできます。

通常、トランザクションが終了するまで更新を遅延すると、パフォーマンスが向上します。ただし、そのトレードオフとして、バッチ操作で更新を実行する順序が、コードで更新を実行する順序と同じにはなりません。詳しくは、『enable-batch-operations』と『order-database-operations』を参照してください。
finders-load-bean

finders-load-beanエレメントは、参照をBeanに戻すfinderメソッドの呼び出し後に、WebLogic ServerがEJBをキャッシュにロードするかどうかを決定します。このエレメントにTrue（デフォルト）を設定し、Beanへの参照がfinderによって戻されると、WebLogic Serverは、Beanをただちにキャッシュにロードします。このエレメントにFalseを設定すると、WebLogic Serverは、最初のメソッド呼び出しまではBeanを自動的にキャッシュにロードしません。

WebSphere Application Serverの場合、デフォルトでは、finderの呼び出し時にBeanがキャッシュにロードされます。この動作は、CMP 2.0仕様に一致しています。この動作を変更して、最初のメソッド呼び出しまでBeanのキャッシュへのロードを遅延するには、EJB1.1仕様を実装したEJBを含むEJB JARを定義します。この動作は、その仕様に一致しているからです。
resource-description

resource-descriptionエレメントは、ejb-jar.xmlに定義されている<resource-ref>を実際のリソースのJNDI名にマップします。 ejb-jar.xmlファイルに定義されている<resource-ref>エレメントの典型的な例は、JDBCデータ・ソースとJMS接続ファクトリーです。これらのリソースの実際のJNDI名は、WebLogic config.xmlファイルにあります。

<resource-description>エレメントを使用すると、クライアントは、リソースの論理名をそのリソースの実際のJNDI名にバインドできます。クライアントは、実際のJNDI名（<jndi-name>など）ではなく、ローカル名前空間の論理JNDI参照（java:comp/env/<res-ref-name> など）を使用して、リソースを検索します。これにより、クライアントは、JNDI名の変更の影響を受けなくなります。

WebLogicでは、リソースからJNDI名へのマッピングは、weblogic-ejb-jar.xmlファイルで指定します。例を以下に示します。
<resource-description> <res-ref-name>jms/Mailing</res-ref-name> <jndi-name>jms/Mailing</jndi-name> </resource-description>
WebSphere Application Serverでは、リソースからJNDI名へのマッピングは、アセンブリー・ツールを使用して、以下のように指定します。
1. Rational Application Developerで、該当するEJBプロジェクト（ShippingAutoserviceEJBなど）を開きます。
2. デプロイメント記述子をダブルクリックします。
3. 「参照」タブをクリックします。
4. 目的のJava Bean（ShipmentManagerなど）を展開して、すべてのJNDIリソース参照を表示します。それぞれの参照ごとにJNDI名を指定する必要があります。参照の1つ（jms/MailingMqなど）を選択します。（WebLogicでは、<resource-ref>からJNDI名へのマッピングと<resource-env-ref>からJNDI名へのマッピングは、異なる方法で処理されます（次のセクションを参照）。一方、WebSphere Application Serverでは、これらのマッピングは同じ方法で処理されます。したがって、Java Beanを展開したときは、そのBeanのejb-jar.xmlファイルに定義されている<resource-ref>と<resource-env-ref>がすべて表示されます。）
5. 「WebSphere バインディング」セクションが表示されるまで下にスクロールして、（WebLogic config.xmlファイルにある）そのリソースの正しいJNDI名を入力します。
6. それぞれの<resource-ref>ごとに、ステップ4から5を繰り返します（必要な場合は、それぞれの<resource-env-ref>ごとにも、ステップ4から5を繰り返します）。
resource-env-description

resource-env-descriptionエレメントは、ejb-jar.xmlに定義された<resource-env-ref>を実際のリソースのJNDI名にマップします。 ejb-jar.xmlファイルに定義されている<resource-env-ref>の典型的な例は、JMS宛先など、管理対象オブジェクト用のものです。これらのリソースの実際のJNDI名は、WebLogicconfig.xml ファイルにあります。

<resource-env-description>エレメントを使用すると、クライアントは、リソースの論理名を実際のJNDI名にバインドできるようになります。クライアントは、実際のJNDI名（java:<jndi-name>など）ではなく、論理JNDI参照（java:comp/env/<res-ref-name>など）を使用して、リソースを検索します。これにより、クライアントは、JNDI名の変更の影響を受けなくなります。

WebLogicでは、リソースからJNDI名へのマッピングは、weblogic-ejb-jar.xmlファイルで指定します。例を以下に示します。
<resource-env-description> <res-env-ref-name>jms/Queue/RequestMailingMq</res-env-ref-name> <jndi-name>jms/Queue/RequestMailingMq</jndi-name> </resource-env-description>
WebSphere Application Serverでは、リソースからJNDI名へのマッピングは、アセンブリー・ツールを使用して、以下のように指定します。
1. Rational Application DeveloperでEJBプロジェクト（ShippingAutoserviceEJBなど）を開きます。
2. デプロイメント記述子をダブルクリックします。
3. 「参照」タブをクリックします。
4. Java Bean（ShipmentManagerなど）を展開して、すべてのJNDIリソース参照を表示します。それぞれの参照ごとにJNDI名を指定する必要があります。参照の1つ（jms/Queue/RequestMailingMqなど）を選択します。前のセクションで説明したように、WebLogic では、<resource-env-ref>からJNDI名へのマッピングと<resource-ref>からJNDI名へのマッピングは異なる方法で処理されますが、WebSphere Application Serverでは、これらのマッピングは同じ方法で処理されます。したがって、目的のJava Beanを展開すると、そのBeanに定義されている<resource-ref>と<resource-env-ref>がすべて表示されます。
5. 「WebSphereバインディング」セクションが表示されるまで下にスクロールして、そのリソースのJNDI名を入力します。
6. それぞれの<resource-env-ref>について、ステップ4から5を繰り返します（必要な場合は、それぞれの<resource-ref>についても、ステップ4から5を繰り返します）。

上に戻る

weblogic-cmp-rdbms-jarエレメントのマッピング

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

use-select-for-update
enable-batch-operations
order-database-operations
weblogic-ql
max-elements

WebLogicの構成エレメントについて詳しくは、『参考文献』を参照してください。

use-select-for-update

use-select-for-updateエレメントは、pessimisticコンカレンシーをBean単位で適用します。 Trueを指定すると、Beanがデータベースからロードされるときにselect for update拡張が常に使用され、トランザクションの間はそのロックが保持されます。このWebLogic拡張を使用すると、最初のトランザクションの実行中に、他のトランザクションがデータを読み取ったり、更新したりできなくなります。この拡張は、より長期間ロックを保持して、コンカレンシーの削減という犠牲を払うことにより、データの保全性を向上させ、デッドロックを減少させます。

select for update拡張を使用するEJBを見つけるには、weblogic-cmp-rdbms-jar.xmlファイルで以下のエレメントを検索します。そして、これが使用されているEJBプロジェクトとEJB名をメモします。

<use-select-for-update>
<use-select-for-update>エレメントをWebSphere Application Serverにマップするには、以下のステップを実行します。
1. Rational Application DeveloperでEJBプロジェクトを開きます。
2. デプロイメント記述子をダブルクリックします。
3. 「アクセス」タブを選択します。
4. 「Entities 2.xのアクセス・インテント（Beanレベル）」セクションでJava Beanを選択して、「追加」ボタンを押します。
5. 「アクセス・インテント名」で「wsPessimisticUpdate」を選択して、「完了」ボタンを押します。
アクセス・インテントにwsPessimisticUpdateを設定すると、コンテナーは常にuse select for updateを使用します。これにより、パフォーマンスの問題が発生する場合がありますが、デッドロックは解消されます。したがって、負荷テストを実行して、データ保全性、デッドロック、またはパフォーマンスの問題がないかどうかを判別できるようになるまでは、アクセス・インテント・ポリシーをデフォルトのままにします。判別できるようになったら、次に上記のステップに従ってアクセス・インテントを設定します。
enable-batch-operations

enable-batch-operationsエレメントは、データベース操作のバッチ処理（挿入、更新、削除のバッチ処理など）をEJBコンテナーで有効にするかどうかを制御します。有効にした場合、EJBコンテナーは、トランザクションのコミット時までデータベース操作を遅延します。

デフォルトでは、WebLogicは、バッチ操作を明示的にオフにしない限り、エンティティーBean上でバッチ操作を有効にします。バッチ操作を明示的にオフにするには、order-database-operationsおよびenable-batch-operationsエレメント（次のセクションを参照）を無効にします。これらの拡張を見つけるには、weblogic-cmp-rdbms-jar.xmlファイルで以下のエレメントを検索します。
<enable-batch-operations>false</enable-batch-operations>
繰り返しますが、WebLogicでは、バッチ操作はデフォルトで有効になっており、JAR内のすべてのCMPエンティティーBeanに対して、JARレベルで無効にできます。 WebSphere Application Serverでは、バッチ操作はデフォルトで無効になっており、コンテナーのすべてのCMPに対して、EJBコンテナー・レベルで有効にできます。

これは二者択一の拡張なので、すべてのCMPエンティティーに対してバッチ操作を有効にするかどうかを決定する必要があります。最初はデフォルト（バッチ操作が無効）で開始して、バッチ操作で解決できそうなパフォーマンスの問題がある場合はそれを変更します。

WebSphere Application Serverでバッチ操作を有効にするには、以下のステップを実行します。
1. 管理コンソールから、「アプリケーション・サーバー」=> server_name =>「プロセス定義」=>「Java仮想マシン」にナビゲートします。
2. 「汎用 JVM 引数」ボックスのすべての既存のJVM引数の後に、以下の引数を追加します。 -Dcom.ibm.ws.pm.batch=true
繰り返しますが、そのトレードオフとして、データベース操作のバッチ処理で更新を処理する順序が必ずしもコードと同じにはなりませんが、通常は、パフォーマンスが向上します。したがって、最初はデータベース操作のバッチ処理を行わずに開始して（WebSphere Application Server のデフォルト）、パフォーマンスを向上させる必要がある場合は、それをオンにします。
order-database-operations

order-database-operationsエレメントは、トランザクションが終了するまですべてのデータベース操作を遅延し、操作間の依存関係を自動的にソートして、データベース制約のエラーを回避するような方法でこれらの操作をデータベースに送信します。WebLogicでは、このエレメントはデフォルトで有効になっています。そのため、データベース操作を順序付けしない場合は、これを明示的に無効にする必要があります。

order-database-operationsを無効にするには、このエレメントとともにenable-batch-operationsエレメント（前のセクションを参照）を無効にする必要があります。両方とも無効にしないと、コンテナーは、引き続きデータベース操作の順序付けを行います。

WebSphere Application Serverでは、データベース操作の順序付け（およびバッチ処理）がデフォルトで無効になっています。そのため、これを明示的に有効にする必要があります。これを行うには、以下のシステム・パラメーターを使用して、作成時の遅延挿入を有効にする必要があります。

-Dcom.ibm.ws.pm.deferredcreate=true -Dcom.ibm.ws.pm.batch=true
先頭のパラメーターは、トランザクションのコミット時までデータベースの挿入を遅延します。 2番目のパラメーターは、トランザクションをコミットするまで、データベースに送信するその他のすべての操作を遅延します。負荷テスト時に参照保全性違反が見つかった場合は、コンテナー管理パーシスタンスに対するシーケンスのグループ化の設定も必要になる場合があります。

order database operations拡張で参照保全性を維持する必要性を説明するために、以下の例を検討します。
1. エンティティーBean Cust-AがSales-Aに関連付けられているものと想定します。
2. また、Sales-Aが削除され、Cust-Aに新しいSales-Bが割り当てられるものと想定します。
3. Cust-Aには販売担当者が必要であるという保全性制約がCust-Aにある場合は、最初にCust-Aを新しいSales-Bへと更新してから、Sales-Aを削除する必要があります。
WebSphere Application Serverでシーケンス・グループを設定するには、以下のステップを実行します。
1. Rational Application DeveloperでEJBプロジェクトを開きます。
2. デプロイメント記述子をダブルクリックします。
3. 「概要」タブをクリックします。
4. 「EJB CMPシーケンス・グループ」セクションで「追加」をクリックして、「EJB CMPシーケンス・グループ」ウィザードを起動します。
5. シーケンス・グループの名前を入力します。
6. グループ・タイプの指定をすべて大文字で入力します（RI_INSERTまたはUPDATE_LOCK）。削除操作の場合、パーシスタンス・マネージャーは、RI_INSERTグループの順序を反転させ、BeanとそのBeanに対応するデータベース行をそれに応じて削除します。
7. 「使用可能Bean」リストで、グループに配置する最初のBeanを強調表示します。「選択されたBean」リストの方向を指している矢印をクリックして、そのBeanを「使用可能なBean」リストから「選択されたBean」リストに移動します。
8. パーシスタンス・マネージャーで処理する順序ですべてのBeanを追加するまで、ステップ7を繰り返します。
weblogic-ql

weblogic-qlエレメントは、EJB 2.0 Query Language（EJB-QL）に対するWebLogic固有の拡張を含む照会を指定します。標準のEJB-QL言語機能は、ejb-jar.xmlデプロイメント記述子で使用され、WebLogic EJB-QL拡張は、weblogic-cmp-rdbms-jar.xmlで使用されます。通常、順序付け、集約、および副照会（サブクエリ）が、照会で使用されます。ただし、その他の拡張を使用することもできるので、必ずすべてのweblogic-qlエレメントを慎重に検査してください。

WebSphere Application Serverは、EJB-QL言語機能の拡張も行います。ただし、個別のQLを定義する代わりに、WebSphere Application Serverは、順序付け、副照会（サブクエリ）、集約関数をEJB-QL構文に提供します。つまり、WebSphereは、これらの拡張を含むようにEJB-QLの構文を拡張します。したがって、ejb-jar.xmlファイルの標準のejb-qlエレメント内でEJB-QLとその拡張を使用することが可能です。

weblogic-qlエレメントをejb-qlエレメントにマップするには、以下のステップを実行します。
1. Rational Application DeveloperでEJBプロジェクトを開きます。
2. デプロイメント記述子をダブルクリックします。
3. 該当するJava Beanをクリックします。
4. 「照会」セクションが表示されるまで下にスクロールします。
5. 該当する照会を選択した後、「編集」ボタンを押して、「ファインダー・メソッドの編集」ダイアログを表示します。
6. ウィザードのステップに従って、照会ステートメントを正しく作成します。
次のセクションでは、weblogic-qlエレメントからejb-qlエレメントへの照会ステートメントのマッピングを示します。

orderbyのマッピング

WebLogic QLのorderby拡張は、ファインダー・メソッドとともに機能するキーワードであり、検索から戻される結果の順序を指定します。 order byは、複数のフィールドに対しても使用することができ、結果を昇順と降順のどちらで戻すのかを指定できます。
- weblogic-qlエレメントの例： <weblogic-ql>select object(o) from MeetingAutoservice o where o.idInternAutoservice = ?1 orderby o.numberMeeting</weblogic-ql>
- マップされたejb-qlエレメント: <ejb-ql>select object(o) from MeetingAutoservice o where o.idInternAutoservice = ?1 order by o.numberMeeting</ejb-ql>
副照会と集約関数のマッピング

WebLogic QLのsubquery拡張を使用すると、検索データを更に制限する条件としてメインの照会で使用されるデータを、メインの照会のWHERE節に埋め込む照会によって戻すことができます。WebLogic QLのMAX拡張は、指定されたフィールドの最大値を戻します。この例は、副照会と集約関数、およびそのWebSphere Application Serverへのマッピングを示しています。
- weblogic-qlエレメントの例： <weblogic-ql>select OBJECT(o) from MeetingAutoservice o where o.idInternAutoservice=?1 AND o.meetingNumber = (select MAX(p.meetingNumber) from MeetingAutoservice p where p.idInternAutoservice = ?1)</weblogic-ql>
- マップされたejb-qlエレメント： <ejb-ql>select OBJECT(o) from MeetingAutoservice o where o.idInternAutoservice=?1 AND o.meetingNumber = (select MAX(p.meetingNumber) from MeetingAutoservice p where p.idInternAutoservice = ?1)</ejb-ql>
max-elements

max-elementsエレメントは、multi-finderメソッドまたはejbSelectメソッドで戻す必要のあるエレメントの最大数を指定します。つまり、照会で戻される行数を制限するものであり、JDBCのmaxRows機能と似ています。

J2EE仕様によると、結果セットのサイズを制限しない場合、multi-objectファインダー・メソッドまたはejbSelectメソッドの実行時にResultSetが最後まで読み取られ、クライアントはコレクション全体を受け取り、これに対して反復が実行されます。この方法は明らかに、結果セット（コレクション）が大きい場合は効率的ではありません。

max-elementsの出現箇所をすべて見つけるには、weblogic-cmp-rdbms-jar.xmlで以下のエレメントを検索します。
<max-elements> WebSphere Application Serverでは、ファインダーから取り出される行数を制限できません。アプリケーションでmax-elementsが使用されている場合は、コードを変更する必要があります。考えられる修正の一つは、適切なロジックをファサードに作成して、結果セットから先頭のn行を取り出すことです。

それはそれとして、一般に、結果セットが10を超えるファインダーはJDBCとともに実装し、比較的メモリーを多く使用するEJBファインダー・メソッドを使用しないことが、プログラミング・ガイドラインとして適切です。なぜなら、アプリケーションのボリュームが高くなることが意図されている場合、戻すエレメント数が10を超えると、ファインダーで問題が発生する場合があるからです。

上に戻る

まとめ

この記事では、アプリケーションのWebLogic独自の拡張を見つける方法と、それらの独自の拡張をWebSphere Application Serverにマイグレーションする方法を説明しました。ただし、それらの拡張を見つけたからといって、すべて実装する必要があるというわけではありません。通常、アプリケーションをWebLogicからWebSphere Application Serverにマイグレーションするときは、以下のことを行います。

WebLogic独自のすべての設定を入念に調べて、アプリケーションに適用された拡張を事前に理解します。これは、アプリケーションをより適切にテストおよび調整し、マイグレーションに要する時間を見積もり、不足の事態を避けるのに役立ちます。
アプリケーションの実行に必要な拡張のみを実装します（それ以外の拡張は実装しません）。必要な拡張は、アプリケーションで必要な管理対象リソース（JDBC接続プール、JMS接続ファクトリーなど）を作成する拡張です。
アプリケーションを実行したら、アプリケーションのパフォーマンスとスケーラビリティーの要件を満たすために、これらの拡張を必要に応じて実装します。つまり、WebSphere Application Serverのデフォルト設定で開始して、実装が必要な可能性のある他の拡張については、負荷テストを通じて理解します。
少なくともマイグレーションが完了するまでは、そのアプリケーションをリファクタリングしたいという気持ちを我慢します。例えば、アプリケーションでペシミスティック・ロックが使用されている場合は、マイグレーション中にオプティミスティック・ロックを使用するようにアプリケーションを変更しないでください。できるだけ最良の状態で動作するようにアプリケーションをテストおよび調整して、その後、リファクタリングを検討します。

WebLogicの拡張を識別して、それをWebSphere Application Serverにマイグレーションする方法を理解した上で、これらのガイドラインに従うと、途中で発生する多数の不測の事態を回避しながら、マイグレーションを正常に行うことが可能です。

参考文献