[Version 5.0.2 and later]Migrating

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.

[5.0 only][Version 5.0.1][Version 5.0.2]Product migration functions are provided by the migration tools in IBM WebSphere Application Server, Version 5.0.x. The migration tools perform Version 3.5.x and Version 4.0.x migrations. The product installation wizard can call these tools, or you can start these tools directly.

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.x migration[5.0 only][Version 5.0.1][Version 5.0.2]

Migration from Version 4.x to Version 5.0.x involves minimal change because both releases implement the Java 2 Platform, Enterprise Edition (J2EE) specification. (Version 4 implements the J2EE 1.2 specification. Version 5.0.x implements the J2EE 1.3 specification.) Most Version 4.x applications can run without change.

Despite this fact, knowledge of how the migration tools migrate Version 4.x applications is important.

For example, extended messaging support service is now a component of IBM WebSphere Application Server Enterprise, Version 5.0.x. Applications that use Version 4.x extended messaging support services require migration to use in an IBM WebSphere Application Server Enterprise, Version 5.0.x system.

In Version 5.0, the statement cache size setting described in Data source settings is different from WebSphere Application Server Version 4.x. In Version 4.x, the maximum number of possible prepared statements is cached for the data source within an application server. In Version 5.0, statement cache size is defined on a given physical connection.

Version 3.5 migration: Moving to the J2EE model

Version 3.5.x users upgrading to Version 5 are moving to a platform that is fully compliant with J2EE specifications. J2EE technology clearly separates development and the creation of applications from application administration, deployment and management. Migration from Version 3.5 involves changes in application structures, development, and deployment.

[5.0 only][Version 5.0.1][Version 5.0.2]The migration tools assist in the transition from Version 3.5.x to Version 5.0.x by migrating system configurations and creating J2EE artifacts, including J2EE security roles mapping. The migration tools create initial J2EE enterprise applications based on Version 3.5.x configurations. However, because of the significant change in application structures, plan to carefully test and tune migrated applications, using development and deployment tools, to determine exactly how the applications function in the new environment.

The J2EE model enables you to develop applications independently from their final deployment environment. This task separation simplifies the process of promoting an application from initial development through production, or moving an application from one server to another. The intent is to change only the application deployment parameters, and not the application code.

New assembly and deployment user roles and tools

Version 3.5.x and Version 4.x users perform application tasks through the administrative console.

[5.0 only][Version 5.0.1][Version 5.0.2]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).

Version 5 administration

Version 5 administrators can install a Version 5 application onto the server and bind it to an environment. This capability enables administration at the application and module level. Administrators no longer must manage individual servlets, JSP files, or enterprise beans.

The relationship between applications and Application Servers has changed in the move to a J2EE base. After creating a J2EE application, deploy it by installing the application onto Application Servers through the administrative console. Through the administrative console, you can view, start, or stop deployed modules by the application to which they belong or by the Application Server on which they are deployed.

Support for J2EE resources. In addition to JDBC drivers and data sources, several resource types are added as the product transitioned to a J2EE base. Administrators now can configure URLs, the Java Message Service (JMS), and the JavaMail API. In each case, you can create a resource provider (such as a JMS provider) and then create resource factories for each provider (such as JMS destinations and JMS connections). The default JavaMail API provider does not appear in the administrative console because it is not configurable. You cannot create additional JavaMail API providers.

More information about the J2EE standard is available from the links in Installation: Resources for learning.

Role based security. Version 5 security is consistent with J2EE role-based security specifications. Deployment descriptors specify roles for an application. As the administrator installs the application, these roles are bound to users or to groups.

In the administrative console, a Security Center lets you perform all security tasks from a single location. Such tasks include everything from changing the binding information for roles in an application to setting Secure Sockets Layer (SSL) properties to enabling security. Application-specific security tasks are also supported, through the property sheets for each application.

Changes for application developers

Version 3.5.x and Version 4.x developers use the administrative console to create, edit, and view application configurations.

[5.0 only][Version 5.0.1][Version 5.0.2]Version 4.x and Version 5 developers use the application assembly tool (AAT) to package, edit, and view J2EE applications.

Packaging J2EE applications includes:

[5.0 only][Version 5.0.1][Version 5.0.2]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.

[5.0 only][Version 5.0.1][Version 5.0.2]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.

[5.0 only][Version 5.0.1][Version 5.0.2]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

[5.0 only][Version 5.0.1][Version 5.0.2]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.

[5.0 only][Version 5.0.1][Version 5.0.2]From Version 3.5.x to Version 5.0.x, the main migration areas include IBM extensions and the Java 2 SDK. In contrast, little migration is necessary to move from Version 4.x to Version 5.0.x.

[5.0 only][Version 5.0.1][Version 5.0.2]The following table summarizes potential migration areas.


Functional area Support in Version 3.5.x or Version 4.x Must migrate from Version 3.5.x? Must migrate from Version 4.x? Details
Enterprise beans EJB 1.0 Yes Not applicable Many EJB 1.0 applications can run unchanged in Version 5.0.x although some changes might be required or recommended. See Migrating enterprise bean code to the supported specification.
EJB 1.1 Not applicable 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 The preliminary Java 2 Connector support in Version 4.x is completed in Version 5.0.x. 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 Many applications can run unchanged in Version 5.0.x although some changes might be required or recommended. See Migrating a version 4.0 data access application to version 5.1.
JavaServer Pages (JSP) files JSP 1.0 Specification 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 Not applicable 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 Changes might be required due to J2EE security. See Migrating security configurations from previous releases and Migrating Java 2 security policy.
Servlets Servlet 2.1 Specification and IBM extensions Yes Yes Many Servlet 2.1 applications can run unchanged in Version 5 although changes might be required or recommended. See Developing servlets with WebSphere Application Server extensions.
Servlets Servlet 2.2 Specification 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 Many applications can run unchanged in Version 5 although changes might be required or recommended. See Developing session management in servlets and Migrating HTTP sessions.
Transactions IBM transactions Yes No A change in the import statement. Also, one data source connection cannot be used across multiple user transactions. See Using the transaction service and Isolation level and resource reference.
Web services Apache (SOAP) 2.2 Not applicable Yes Many applications can run unchanged although changes to use new support are recommended.
XML parser XML 2.0.x supported Yes Not applicable Changes to move to the supported API XML4J V4.0.6 level are required. See XML parser for Java code.
XML parser XML4J V3.1 Not applicable Yes Recompilation is required to convert to XML4J V4.0.6.
XML configuration tool XMLConfig Yes Yes Use the JMX support provided by wsadmin. See Migrating from wscp V4.0 to wsadmin V5.x.
WebSphere Control Program (WSCP) WSCP Yes Yes Use the JMX support provided by wsadmin. See Migrating from wscp V4.0 to wsadmin V5.x.






Searchable topic ID:   welc_migrating
Last updated: Jun 21, 2007 4:55:42 PM CDT    WebSphere Application Server Network Deployment, Version 5.0.2
http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/welc_migrating.html

Library | Support | Terms of Use | Feedback