Release 9.0.2
Part Number A95110-01
 Home |
 Contents |
 Index |
| Oracle9iAS Migrating From WebSphere Release 9.0.2 Part Number A95110-01 |
|
This appendix outlines the migration strategy from WebSphere Advanced Edition 4.0 to Oracle9iAS in the following aspects:
WebSphere Advanced Edition 4.0 is an evolution of the 3.5.x version in several areas including J2EE specification support up to J2EE 1.2 for 4.0. Table B-1 summarizes the evolved features. The information in the table provides a general reference for what you can reuse from the other chapters in this book for your migration tasks from WebSphere Advanced Edition 4.0 tp Oracle9iAS Release 2.
WebSphere Advanced Edition 4.0 advances on the J2EE specification support from WebSphere Advanced Edition 3.x. It has more comparable features with Oracle9iAS in the J2EE specification levels. Table B-2 compares the specification levels supported by Oracle9iAS Release 2 and WebSphere Advanced Edition 4.0.
WebSphere 4.0 is compliant with Servlet 2.2 specifications. It has proprietary mechanisms to enable servlet chaining and filtering and is not fully Servlet 2.3-compliant. The WebSphere 3.5.3 compatibility mode is not available. With those points in mind and not taking Servlet 2.3 features into consideration, migrating WebSphere Advanced Edition 4.0 servlets to Oracle9iAS OC4J servlets should be straightforward as both products support the same level of specifications (Servlets 2.2). However, the following possible incompatibilities should be noted and resolved if applicable to your servlets:
The servlet extensions from WebSphere Advanced Edition 3.5.3 are still available in WebSphere Advanced Edition 4.0. Information in the section "WebSphere Extensions to the Servlet API" is still valid when these extensions are used. If your servlets use any of these extensions, they need to be re-written to conform with the standard Servlet 2.2 or 2.3 API in order to run in OC4J.
WebSphere Advanced Edition uses non-J2EE compliant deployment descriptors. WebSphere 4.0's Application Assembly Tool generates additional descriptor files in addition to the standard J2EE files. These are the DDL and XMI files used to store binding and WebSphere-specific extension information.
Since these files apply to WebSphere-specific extensions, they are redundant in Oracle9iAS and need not be migrated. Ensure that other WebSphere-specific extensions are not implemented in the migrated application before deploying in Oracle9iAS.
If your servlets deployed in WebSphere 4.0 use the 3.5.3 deprecated API shown in the following table, you need to re-write them to use the equivalent Servlet 2.2 API as follows:
| WebSphere 3.5.3 (supported in 4.0) | Servlet 2.2 |
|---|---|
getValue() |
getAttribute() |
getValueNames() |
getAttributeNames() |
removeValue() |
removeAttribute() |
putValue() |
setAttribute() |
WebSphere Advanced Edition 4.0 and Oracle9iAS both support JSP 1.1 (with Oracle9iAS supporting 1.2 as well). Hence, JSP migration between the two products should be straightforward. In general, the rules and processes that apply when migrating JSPs from WebSphere Advanced Edition 3.x to Oracle9iAS can also be applied here. This is especially true for variations deviating from the JSP 1.1 specifications. These are related to the "tsx" family of tags. In OC4J, these should be replaced with OracleJSP's JML tags. Refer to the section "Migrating WebSphere Extensions to OC4J" for more information.
WebSphere Advanced Edition 4.0 complies with EJB 1.1. This is the same specification level which Oracle9iAS is compliant with (some EJB 2.0 features are also supported by Oracle9iAS). Hence, migrating EJBs between the two application servers should not pose any significant challenges. We strongly recommend that you archive your EJBs in a EAR file with any web applications and deploy that file using OEM or dcmctl to ensure that appropriate stubs are generated by Oracle9iAS. Copying EJB classes and their WebSphere-compiled stubs manually is not recommended.
We are investigating the EJB migration process further and will update this document and information in the Oracle Technology Network website (http://otn.oracle.com) if we encounter any issues.
In addition to the migration points above, the following should also be observed:
Dynamic Fragment Cache is a performance enhancement feature in WebShpere that caches the output of servlets and JSPs. This feature intercepts calls to the service method of servlets and determines if the calls can be serviced by its cache. For servlets or JSPs to use this feature, they have to use the com.ibm.websphere.servlet.cache package. When migrating to Oracle9iAS, ensure that this package is removed and any related code modified. For caching functionality in Oracle9iAS, consider using Oracle9iAS Web Cache and its Edge Side Includes for Java (JESI) technology.
WebSphere 4.0 provided the com.ibm.db package as a substitute for the standard JDBC package java.sql. When migrating to Oracle9iAS, replace usage of com.ibm.db with java.sql (standard JDBC 2.0 package is recommended). If your application and components also use IBM data access beans, follow the guidelines in "Data Access Beans" .
In WebSphere 4.0, all data sources must be created using com.ibm.websphere.advanced.cm.factory.DataSourceFactory. To migrate to Oracle9iAS, data sources can be obtained using the JDBC 2.0 java.sql.Datasource, which is a connection factory to a data source. A Datasource object can be obtained by looking it up in the JNDI namespace. Refer to "The DataSource Class" for more information.
|
 Copyright © 2002 Oracle Corporation. All Rights Reserved. |
|
