Skip Headers

Oracle9iAS Migrating From WebSphere
Release 9.0.2

Part Number A95110-01
Go To Documentation Library
Home
Go To Table Of Contents
Contents
Go To Index
Index

Go to previous page Go to next page

B
Migrating from WebSphere 4.0

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

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

Table B-1 Summary of WebSphere 3.5.x and 4.0 feature differences
WebSphere Advanced Edition 3.5.x WebSphere Advanced Edition 4.0

Policy-based authorization

J2EE roles-based authorization - method invocation permissions for enterprise beans can now be assigned to users through their respective roles. Roles are specified in an application's deployment descriptors.

JSP 1.0

JSP 1.1

Servlet 2.1

Servlet 2.2

EJB 1.0

EJB 1.1

Presentation layer separation - HTML and CGI requests are served by a separate product. No implementation of J2EE Web Application concept.

J2EE Web Application support (support for .war files)

ServiceInitializer interface

CustomService interface - Similar to the ServiceInitializer interface except that CustomService does not pass in the context for the services to use for registration binding.

Connection Manager V2.0

Connection pooling - JDBC 2.0 or data access beans is used for connection pooling.

JNDI context interface used:
com.ibm.ejs.ns.jndi.
    CNInitialContextFactory

New JNDI context interface used:
com.ibm.websphere.naming.
    WsnInitialContextFactory

XML4J V2.0.15 parser

XML4J V3.1.1 parser

.servlet file support

Servlet extensions are bundled in .war file.

Open Servlet Engine (OSE) remote and servlet redirector support for remote request invocations.

HTTP transport plug-ins to communicate between web server and application server.

J2EE Specification Differences Between WebSphere Advanced Edition 4.0 and Oracle9iAS

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.

Table B-2 Summary of Oracle9iAS and WebSphere Advanced Edition 4.0 feature differences
J2EE Specification WebSphere Advanced Edition 4.0 Oracle9iAS

JDK

1.2.2 and 1.3

1.2.2 and 1.3

Servlet

2.2

2.2 and 2.3

JSP

1.1

1.1 and 1.2

EJB

1.1

1.1 and 2.0

JDBC

2.0

2.0

JNDI

1.2

1.2.1

JTA

1.0.1

1.0.1

JMS

1.0

1.0.1

Migrating WebSphere 4.0 Servlets to Oracle9iAS

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:

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

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 B-3 Deprecated 3.5.3 API and their Servlet 2.2 replacement
WebSphere 3.5.3 (supported in 4.0) Servlet 2.2
getValue()
getAttribute()
getValueNames()
getAttributeNames()
removeValue()
removeAttribute()
putValue()
setAttribute()

Migrating WebSphere 4.0 JSPs to Oracle9iAS

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.

Migrating WebSphere 4.0 EJBs to Oracle9iAS

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.

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

Data Access and Sources

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.


Go to previous page Go to next page
Oracle
Copyright © 2002 Oracle Corporation.

All Rights Reserved.
Go To Documentation Library
Home
Go To Table Of Contents
Contents
Go To Index
Index