Migrating is an activity in which you take advantage of existing materials. Migration tasks and tools help you upgrade the product and its prerequisites, reuse existing application components when feasible, and transfer administrative configurations from your past version to a current one.
Migration of WebSphere Application Server products is about leveraging the existing environment and applications and changing them to be compatible with the current product version.
Because of the
changes in architecture/structure compared to prior WebSphere Application
Server for z/OS releases, the IBM WebSphere Application Server, Version 5.0.x
migration strategy is one of coexistence with prior levels. Upgrading of
WebSphere Application Server Version 3.5 SE or WebSphere Application Server
for z/OS Version 4.0.1 to Version 5 is not supported. However, Version 5.0.x
can coexist with prior levels of WebSphere Application Server for z/OS on
a z/OS image or Sysplex. Support for migrating Version 4.0.1 applications
to Version 5.0.x has been shipped in Version 4.0.1 service (W401502). This
support has been provided as a new -v5mp option for the 390fy tool. WebSphere
Application Server for z/OS Version 5.0 servers must be defined manually in
preparation for the migration of the application.
Migration Redbook
Migrating to WebSphere V5: An End-to-End Migration Guide is available from the Redbooks Web site at http://www.ibm.com/redbooks . To locate the Redbook, search for the document number SG24-6910-01. The Redbook provides a broader coverage than the information center articles, including more detailed planning information for application migration and WebSphere Studio Application Developer tooling and samples. Migrating Applications from WebSphere for z/OS V4 and V3.5 to V5 is also available from the Redbooks Web site. Search on document number SG24-7044-00 to locate this book.
Version
4.0.1 migration
Migration from Version
4.0.1 to Version 5.0.x involves minimal change because both releases implement
the Java 2 Platform, Enterprise Edition (J2EE) specification. (Version 4.0.1
implements the J2EE 1.2 specification. Version 5 implements the J2EE 1.3 specification.)
Most Version 4.0.1 applications can run without change.
New assembly and deployment user roles and tools
Version 3.5 SE applications are file based and defined
to the server through the WAS.CONF file. Version 5 application settings are
defined in J2EE deployment descriptors, by application assemblers using
the application assembly tool (AAT). A deployer follows the instructions
in the deployment descriptor to install the application into a particular
server environment. (See Deploying).
Suppose
you need to update an application that is already deployed to the server.
Unless you must change information that affects the bindings of an installed
application, you can edit and save the deployment descriptors in place. Redeploy
such an application, by opening the application assembly tool (AAT) directly
on the installedApps folder that holds the application.
You
can also create or edit applications manually. For example, to add a JavaServer
Page (JSP) file or to change a servlet class, place the new or changed file
in the appropriate location in the installedApps folder. Redeploy
an installed application that requires changes to binding, by exporting the
application through the Administrative Console, edit the application in the
application assembly tool (AAT), and reinstalling the application through
the administrative console. Because existing binding information is saved
during the export step, the only additional binding information needed is
for the components or modules added during editing.
Changes for application developers
Version 3.5 SE developers manually create, edit, and view application configurations.
Version 4.0.1 and Version
5.0.x developers use the application assembly tool (AAT) to package, edit,
and view J2EE applications.
Packaging J2EE applications includes:
In Version 5, the application
assembly tool (AAT) enables users to copy files with appropriate relative
paths into the archive and provides a GUI method for defining deployment
descriptors. Developers also can set environment-specific binding information
through the application assembly tool. These bindings are defaults for the
administrator to use when installing the application through the administrative
console.
You can define IBM extensions to the J2EE specification, for example supporting servlets to be served by class name. These extensions are saved in an XML file that is separate from the standard J2EE deployment descriptor to ensure portability to other Application Servers.
If
your existing applications use IBM extensions from earlier product versions,
it might be necessary for you to perform mandatory or optional migration to
use the same kinds of extensions in Version 5.0.x.
Version 5.1 supports the Java 2 SDK Version 1.4.1. There are several implications for migration and coexistence. The Version 5.1 Network Deployment cell is a mixed node environment, where some Application Server nodes might be Version 5.0.x running Java 2 SDK 1.3.1 and some nodes might be Version 5.1 nodes running Java 2 SDK 1.4.1.
Applications compiled on Version 5.0.x nodes can also run on Version 5.1 nodes. The IBM SDK 1.4.1 in Version 5.1 provides this backward compatibility.
There is also a cross compiler option for the IBM SDK 1.4.1 that supports compiling code against a bootstrap and extension classes of a previous IBM SDK version. By default, the javac compiler compiles against the bootstrap and extension classes on its platform: the IBM SDK 1.4.1 compiles for 1.4 by default. You can use the IBM SDK 1.4.1 to compile for IBM SDK 1.3.1 compatible output. For example, a developer can issue this command on a Version 5.1 node to compile against a 1.3 target:
/ javac -target 1.3 -bootclasspath jdk1.3\lib\classes.zip \ -extdirs "" OldCode.java
The compiled code runs on a 1.3 Java virtual machine (JVM). The -target 1.3 parameter generates class files that are compatible with 1.3 JVMs. If you do not specify the -target option, the -bootclasspath option and the -extdirs option, the compiled code runs on 1.4 JVMs only. You must specifically compile for 1.3 JVMs on a Version 5.1 node, to avoid compiling against a Java 2 Platform API that is not present on a 1.3 JVM. A 1.4 application fails at run time on a Version 5.0.x node.
In WebSphere
Application Server Version 4.0.1 for z/OS and OS/390, the generated code for
a useBean tag uses a Beans.instantiate instead of creating
a new object with the default constructor:
v4: beanId = (beanClass)Beans.instantiate(getClassLoader(), "...BeanClassName..."); v5: beanId = new ...BeanClassName...();With JSP code generated for a useBean tag in WebSphere Application Server Version 4.0.1 for z/OS and OS/390, a bean class without a default constructor still compiles, but fails at run-time if the bean is not found within the specified scope or context. In WebSphere Application Server Version 5 for z/OS, a bean class without a default constructor does not compile.
Migrating APIs and specifications
Migrating APIs and specifications means
moving to the current Java component level and to other technologies that
IBM WebSphere Application Server, Version 5.0.x supports.
Migrating APIs and specifications also includes moving to the most contemporary open specification levels. If your existing applications currently support different specification levels than those supported by this product version, updating at least some aspects of the applications to comply with the new specifications is probable.
From
Version 3.5 to Version 5.0.x, main migration area concerns are with IBM extensions,
uplifting Servlet/JSP to the appropriate J2EE 1.2 specification levels, and
packaging as J2EE applications. In contrast, little migration is necessary
to move from Version 4.0.1 to Version 5.0.x.
See Specification level summary of WebSphere Application Server which shows the various releases of the WebSphere for z/OS family and the specification and functional differences between them.
The following table summarizes potential migration areas.
Functional area | Support in Version 3.5 SE or Version 4.0.1 | Must migrate from Version 3.5 SE? | Must migrate from Version 4.0.1? | Must migrate from Version 5? | Details |
---|---|---|---|---|---|
Enterprise beans | EJB 1.1 | Not applicable | No | No | Full support for EJB 1.1 is provided. See Migrating enterprise bean code to the supported specification. |
Java 2 Connectors | Java 2 Connectors | Not applicable | Yes | No | The preliminary Java 2 Connector support in Version 4.0.1 is completed in Version 5.1. Some changes might be necessary to take full advantage of this support. See J2EE Connector Architecture migration tips, Connection management architecture, and Connection considerations when migrating servlets, JavaServer Pages, or enterprise session beans. Also see the Statement Cache Size section in Data source settings |
JDBC API | JDBC API | Yes | Not applicable | No | Many applications can run unchanged in Version 5.1 although some changes might be required or recommended. |
JSP files | JSP 1.0 Specification | No | No | No | JSP 1.0 APIs are a pure subset of JSP 1.2. See Developing JavaServer Pages files with WebSphere extensions. |
JSP 1.1 Specification | No | No | No | JSP 1.1 APIs are a pure subset of JSP 1.2. See Developing JavaServer Pages files with WebSphere extensions. | |
Security | IBM security | Yes | Yes | No | Changes might be required due to J2EE security. See Migrating Java 2 security policy. |
Servlets | Servlet 2.1 Specification and IBM extensions | Yes | Yes | No | Many Servlet 2.1 applications can run unchanged in Version 5.1 although changes might be required or recommended. See Developing servlets with WebSphere Application Server extensions. |
Servlets | Servlet 2.2 Specification | No | No | No | Servlet 2.2 APIs are a pure subset of Servlet 2.3. See Developing servlets with WebSphere Application Server extensions. |
Sessions | IBM sessions | Yes | Yes | No | Many applications can run unchanged in Version 5.1 although changes might be required or recommended. See Developing session management in servlets and Migrating HTTP sessions. |
Transactions | IBM transactions | No | No | No | Version 3.5 SE did not support application initiated transactions through JTA APIs. See Using the transaction service and Isolation level and resource reference. |
Web services | Apache SOAP 2.2 | Not applicable | Yes | No | WSIF API |
XML parser | XML 2.0.x supported | Yes | Not applicable | Not applicable | Changes to move to the supported API XML4J V4.2.2 level are required. See Migrating XML applications. |
XML parser | XML4J V3.1 | Not applicable | Yes | Not applicable | Recompilation is required to convert to XML4J V4.2.2. |
Administrative console | Administrative console | Not applicable | Yes | No | Use the JMX support provided by wsadmin. |