A
Migrating from WebSphere 4.0

This appendix outlines the migration strategy from WebSphere Advanced Edition 4.0 to Oracle Application Server in the following aspects:

• Feature Differences Between WebSphere Advanced Edition 3.5.3 and 4.0

• J2EE Specification Differences Between WebSphere Advanced Edition 4.0 and Oracle Application Server

• Migrating WebSphere 4.0 Servlets to Oracle Application Server

• Migrating WebSphere 4.0 JSPs to Oracle Application Server

• Migrating WebSphere 4.0 EJBs to Oracle Application Server

• Other Considerations

Feature Differences Between WebSphere Advanced Edition 3.5.3 and 4.0

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 A-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 to Oracle Application Server 10g (9.0.4).

Table A-1 Summary of WebSphere 3.5.x and 4.0 feature differences

J2EE Specification Differences Between WebSphere Advanced Edition 4.0 and Oracle Application Server

WebSphere Advanced Edition 4.0 advances on the J2EE specification support from WebSphere Advanced Edition 3.x. It has more comparable features with Oracle Application Server in the J2EE specification levels. Table A-2 compares the specification levels supported by Oracle Application Server 10g (9.0.4) and WebSphere Advanced Edition 4.0.

Table A-2 Summary of Oracle Application Server and WebSphere Advanced Edition 4.0 feature differences

Migrating WebSphere 4.0 Servlets to Oracle Application Server

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 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:

• WebSphere Specific Servlet Extensions

• WebSphere-Specific Deployment Descriptors

• Deprecated 3.5.3 API (Supported in WebSphere 4.0)

WebSphere Specific Servlet Extensions

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-Specific Deployment Descriptors

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 Oracle Application Server and need not be migrated. Ensure that other WebSphere-specific extensions are not implemented in the migrated application before deploying in Oracle Application Server.

Deprecated 3.5.3 API (Supported in WebSphere 4.0)

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:

Table A-3 Deprecated 3.5.3 API and their Servlet 2.2 replacement

getValue()

getAttribute()

getValueNames()

getAttributeNames()

removeValue()

removeAttribute()

putValue()

setAttribute()

Migrating WebSphere 4.0 JSPs to Oracle Application Server

WebSphere Advanced Edition 4.0 and Oracle Application Server 10g (9.0.4) both support JSP 1.1 (with Oracle Application Server 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 Oracle Application Server 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 OC4J JML tags. Refer to the section "Migrating WebSphere Extensions to OC4J" for more information.

Migrating WebSphere 4.0 EJBs to Oracle Application Server

WebSphere Advanced Edition 4.0 complies with EJB 1.1. Oracle Application Server is compliant with EJB 2.0. Hence, migrating EJBs from WebSphere 4.0 to Oracle Application Server requires upgrading EJBs to EJB 2.0 specifications level.

We strongly recommend that you archive your EJBs in a EAR file with any web applications and deploy that file using Oracle Enterprise Manager Application Server Control or dcmctl to ensure that appropriate stubs are generated by Oracle Application Server. 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).

Other Considerations

In addition to the migration points above, the following should also be observed:

Dynamic Fragment Cache

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 Oracle Application Server, ensure that this package is removed and any related code modified. For caching functionality in Oracle Application Server, consider using Oracle Application Server Web Cache and its Edge Side Includes for Java (JESI) technology.

Data Access and Sources

WebSphere 4.0 provides the com.ibm.db package as a substitute for the standard JDBC package java.sql. When migrating to Oracle Application Server, 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 Oracle Application Server, 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.