| Oracle Application Server WebSphereからの移行 10g リリース3（10.1.3.1.0） B31845-02 |
|
 戻る |
 次へ |
この付録では、WebSphere Advanced Edition 4.0からOracle Application Serverへの移行計画の概要について説明します。内容は次のとおりです。
WebSphere Advanced Edition 4.0は、3.5.xバージョンを機能強化したものであり、J2EE 1.2仕様のサポートなど、強化された機能は多岐にわたります。表A-1に、それらの機能を示します。このドキュメントの他の章では、WebSphere Advanced Edition 4.0からOracle Application Server 10g リリース 3（10.1.3.1.0）への移行時に再利用できるコンポーネントが記載されていますが、この表はそれらの情報をまとめたものです。
表A-1 WebSphere 3.5.xと4.0の機能上の相違点のサマリー
WebSphere Advanced Edition 4.0では、WebSphere Advanced Edition 3.xにおけるJ2EE仕様のサポートをさらに強化しています。 J2EEの仕様レベルにおいては、Oracle Application Serverにより近い機能を提供します。表A-2では、Oracle Application Server 10g リリース 3（10.1.3.1.0）とWebSphere Advanced Edition 4.0でサポートされる仕様レベルを比較します。
WebSphere 4.0は、サーブレット仕様2.2に準拠しています。この製品では、サーブレット・チェイニングとサーブレット・フィルタリングに関して独自のメカニズムが実装されており、サーブレット仕様2.3に完全準拠していません。また、WebSphere 3.5.3の互換モードは使用できません。これらのことを念頭に置くと（サーブレット2.3は使用しない）、WebSphere Advanced Edition 4.0からOC4Jへのサーブレットの移行作業は簡単に行えるはずです。これらの2つの製品では、サーブレット2.2という同じ仕様レベルをサポートしているからです。ただし、使用するサーブレットで次の互換性の問題が生じる場合は、適切な対応をとる必要があります。
WebSphere Advanced Edition 3.5.3のサーブレットの拡張機能は、WebSphere Advanced Edition 4.0でも利用可能です。この場合も、サーブレットの拡張機能には、「WebSphereのサーブレットAPIの拡張機能」の説明が当てはまります。OC4Jでサーブレットを実行するには、このような拡張機能を使用するサーブレットを再コーディングして、サーブレット2.2や2.3の標準APIに準拠させる必要があります。
WebSphere Advanced Editionでは、J2EEに準拠しないデプロイメント・ディスクリプタが使用されています。WebSphere 4.0のApplication Assembly Toolで標準的なJ2EEファイルとともにディスクリプタ・ファイルが追加生成されるためです。バインディングおよびWebSphere固有の拡張機能情報を含んだDDLやXMIファイルがそれに該当します。
これらのファイルは、WebSphere固有の拡張機能の実装に必要なため、Oracle Application Serverへの移行では不要です。Oracle Application Serverを配置する前に、移行したアプリケーションにWebSphere固有の拡張機能が他にも実装されていないか確認してください。
WebSphere Advanced Edition 4.0とOracle Application Server10g リリース 3（10.1.3.1.0）では、どちらもJSP 1.1がサポートされています（Oracle Application ServerではJSP 1.2もサポートされています）。したがって、両製品間でのJSPの移行は簡単です。通常、WebSphere Advanced Edition 3.xからOracle Application Serverへの移行時における規則やプロセスが同様に適用されます。JSP 1.1仕様のバリエーションを扱う際には、特に注意を要します。たとえば、tsxなどのタグがあります。OC4Jでは、これをJMLタグに置き換える必要があります。詳細は、「WebSphereの拡張機能のOC4Jへの移行」を参照してください。
WebSphere Advanced Edition 4.0はEJB 1.1に準拠しています。Oracle Application ServerはEJB2.0に準拠しています。つまり、EJBをWebSphere 3.5.3からOracle Application Serverに移行する場合は、EJB 2.0の仕様レベルにアップグレードする必要があります。
EJBは、Webアプリケーションと一緒にEARファイルにアーカイブすること、またそのファイルをOracle Enterprise Manager 10g Application Server Controlコンソールやdcmctlを使用してデプロイすることを強くお薦めします。そうすることで、Oracle Application Serverによって適切なスタブが生成されます。EJBクラスとWebSphereでコンパイルしたスタブは、手動でコピーしないでください。
EJBの移行プロセスについては現在調査中です。このドキュメントを更新する最新情報は、OTN-J（Oracle Technology Network Japan）（http://otn.oracle.co.jp）から入手できます。
前述の移行時の注意点のほかに、次のことにも留意してください。
ダイナミック・フラグメント・キャッシュとは、サーブレットおよびJSPの出力をキャッシュすることによってパフォーマンスを向上させるWebSphereの拡張機能です。この機能は、サーブレットのserviceへのコールを中断し、そのコールをキャッシュで処理できるかどうかを確認します。サーブレットまたはJSPでこの機能を利用するには、com.ibm.websphere.servlet.cacheパッケージが必要です。Oracle Application Serverへ移行する際には、このパッケージが削除されていることと関連コードが修正されていることを確認します。Oracle Application Serverでキャッシュ機能を必要とする場合は、Oracle Web CacheとEdge Side Includes for Java（JESI）の使用をご検討ください。
WebSphere 4.0では、JDBCの標準パッケージjava.sqlのかわりにcom.ibm.dbパッケージが用意されています。Oracle Application Serverへ移行する際には、com.ibm.dbのかわりにjava.sql（JDBC 2.0の標準パッケージの使用を推奨）を使用してください。アプリケーションとコンポーネントでIBMデータ・アクセスBeanが使用されている場合は、「データ・アクセスBean」の手順に従ってください。
WebSphere 4.0では、com.ibm.websphere.advanced.cm.factory.DataSourceFactoryを使用して、すべてのデータソースを作成する必要があります。Oracle Application Serverへ移行する際には、JDBC 2.0のjava.sql.Datasourceを使用してデータソースを取得できます。これは、データソースへのコネクション・ファクトリです。Datasourceオブジェクトは、JNDIネームスペースを検索して取得できます。詳細は、「DataSourceクラス」を参照してください。
