WebSphere 8 Migration v2

Contents

Migrating to WebSphere Application Server v8 ..................... 1

The Success Formula ........................................................... 1

Why Migrate? ...................................................................... 1

Change Impact Analysis ....................................................... 2

Case Study 1: Behavior of HttpServletRequest

sendRedirect() Changed .................................................. 3

Case Study 2: Default Content Type Has Changed ......... 3

Case Study 3: Changes in Java Programming Language . 4

Case Study 4: DB2 CLI Based Type 2 JDBC Driver Not

Supported ........................................................................ 5

The Anatomy of a Migration Project........................................ 6

Setting Business Priority and Project Scope ........................ 7

Planning the Project ............................................................ 8

Obtaining Skills .................................................................... 9

Code Migration .................................................................... 9

Administrative Migration .................................................. 10

Testing ............................................................................... 11

Deployment ....................................................................... 11

Leveraging New Value Adds ................................................... 12

Java EE 6 Enhancements .................................................... 12

Administrative Enhancements .......................................... 13

Summary ................................................................................ 14

About Web Age Solutions ...................................................... 14

Migrating to

WebSphere

Application

Server v8

A formula for success

Bibhas Bhattacharya Chief Technology Officer

Web Age Solutions

Pag

e1

Migrating to

WebSphere Application Server v8

The Success Formula

Migration can be seen as an activity that adds very little immediate value, involves risk and is usually

deferred as long as possible. In the case of WebSphere, a large cross-section of organization and

applications can be impacted – everything from the way people do their task of coding, to how code

functions and performs in the new environment may change. A good migration plan will extract

maximum value and minimize risk. We define the success factor for a migration project as follows:

Success factor = (Value gained) / (Risk + Cost)

The focus of this paper is to optimize this equation – not only looking at how to reduce risk, but how to

see dramatic improvements in coding efficiency post-migration to better offset the upfront costs.

Why Migrate?

Decision to migrate is never taken lightly. If the project succeeds, end users see very little change to

their day to day operations. If the project produces an

unstable environment, everyone is negatively affected.

The primary driver for migration is an end of support

(EOS) statement by the vendor. It is the date when the

vendor stops accepting product support request for a

version or may do so at an extra cost. The majority of

IBM software, including WebSphere Application Server,

follow a 5+3 support model. This means, a version is

supported for 5 years after the general availability and

is supported for another 3 years at an extra cost. For

IBM WebSphere Application Server, the EOS dates are

shown in the call-out box.

The second most important driver is the advancement

in technology. WebSphere 8 implements Java EE 6

which is a significant milestone event in the life of that

specification. Frankly, Java EE 6 turns enterprise

development on its head and offers significant

potential for gains in development efficiency. We can easily see in EE 6 developers can get far more

When will you need to migrate by?

Version End of Support Date

5.0.x 30-Sep-2006 5.1.x 26-Sep-2008 6.0.x 30-Sep-2010 6.1.x 30-Sep-2012 7.0.x Web Age estimate: Oct 20131 8.0.x Web Age estimate: Jul 20152

Sources:

www.ibm.com/software/websphere/support/lifecycle/

www.ibm.com/software/support/lifecycle/lc-policy.html

1 The EOS date for v7.0.x has not been announced at the time of this writing. Our estimate is based on the GA date of 17-Oct-2008 and 5+3 support policy. 2 Estimate based on the GA date of 22-Jul-2011 and 5+3 support policy.

Pag

e2

done in less time. This means that 8.0 migration presents a much better long term business case than

that offered for 7.0 migration. However, we also recommend organizations limit the scope of the project

to moving existing code to WebSphere 8 in the initial phase of migration.

The September 30, 2012 date is looming for the v6.1 users. Some have been using v5.x.x without any

formal support from IBM. These two groups will have the most impetus in launching a migration project.

Some 7.0 users will be seriously tempted by the improvements in the programming model. This will be a

good time for them to start adopting the new architecture – at least in a few pilot projects.

Change Impact Analysis

The risk factor for a migration project is generally proportional

to the sum of changes introduced by each subsequent version.

This means the further away your environment is from v8, the

higher the level of risk becomes.

An analysis by IBM quantifies the changes as follows.

Changes introduced by a version that can potentially risk migration

v6.0 v6.1 v7.0 v8.0 Programming changes 19 12 8 11 Administration changes 10 6 9 7 Total 29 18 17 18

Source: WebSphere Application Server Versions: What’s Different? IBM, 2012.

This means, an environment moving from v5.1 to v8 will have to potentially deal with about

29+18+17+18 or 82 items. An environment moving from v6.1 may be affected by 53 items, and so on.

Also, these changes do not only result in a failure to compile or failure to execute as you might expect,

they may result in behavioral changes being instantiated in the application which are harder to detect.

On the next few pages are examples of changes that can affect application code or administration that

illustrate the situation.

Pag

e3

Case Study 1: Behavior of HttpServletRequest sendRedirect() Changed

The behavior of the sendRedirect() API has changed in WebSphere v6.0 which can introduce nasty

defects.

J2EE 1.3 and older (that is, WAS v5.x or older), were ambiguous about the behavior of sendRedirect().

WebSphere chose to implement the behavior as follows. Let's say a servlet has the URI "MyServlet" and

belongs to a web application with a context root URI of "myapp". The servlet is then accessed using this

URL: http://www.example.com/myapp/MyServlet?foo=bar.

Let's say that the application code did a redirection using an absolute URI (starting with "/"):

response.sendRedirect("/index.html");

WebSphere would then redirect the browser to: http://www.example.com/index.html.

As of WebSphere 6.0, an absolute URI is converted to a URL relative to the web application's context

root. That means, the same code will try to redirect the browser to:

http://www.example.com/myapp/index.html.

To achieve the old behavior, the application code needs to be modified to:

response.sendRedirect("http://www.example.com/index.html");

Case Study 2: Default Content Type Has Changed

Prior to WebSphere v6.0, the web container set the reply content type to "text/html". Since majority of

the applications intended to output HTML anyway, servlets and JSP pages did not need to set the

content type. Starting from WebSphere v6.0, the default content type has changed to "text/plain".

Applications that did not set the content type will most certainly look odd as the browser stops parsing

the response as HTML.

Before v6.0:

After v6.0:

The solution is to change code and explicitly set the content type:

response.setContentType("text/html");

Pag

e4

Case Study 3: Changes in Java Programming Language

Changes made in the Java programming language and the compiler is a concern for many. The table in

the callout box summarizes versions of Java used by WebSphere Application Server.

Let's have a look at a few common problems that may arise.

Compiler behaviour - Generally speaking, compiler has become

progressively stricter. Invalid code that compiled before may not do

so now.

Class name collision – Newer versions of Java may introduce a class

by the same name of an existing class but in a different package. For

example, starting from Java 5, there are two Proxy classes:

java.lang.reflect.Proxy

java.net.Proxy – newly added in Java 5.

If a file uses wild card import as below, there will be compilation error.

import java.lang.reflect.*;

import java.net.*;

Re-organization of internal classes – Older applications with XML parsing code may have used Apache

classes directly. These classes belonged to the org.apache package. Starting with Java 5, these classes

have been moved to com.sun package. Applications do not need to directly refer to these classes. You

should develop using pure SAX or DOM API. Similarly, classes in sun.* packages may have changed.

Applications should do their best to avoid using them directly. In the worst case, you should create

wrapper classes for them and use the wrappers. In that case, only the wrapper classes need to be

"fixed" during migration.

Class file format changed – The format of the compiled class files have changed several times since Java

1.3. The format is forward compatible. That means, a class file compiled in, say, Java 1.4, will be usable

in Java 6. But, the formats are not backward compatible. For example, a class file compiled in, say, Java

5, will not work in JRE 4 and you will get a UnsupportedClassVersionError exception.

This will present a problem if you have a common library project that is used by multiple applications

only some of which are being migrated to WAS v8.

References:

Changes in Java 6 compared to 5: http://www.oracle.com/technetwork/java/javase/compatibility-137541.html

Changes to Java 5 compared to 1.4: http://www.oracle.com/technetwork/java/javase/compatibility-137462.html

WAS Version

Java or JRE Version

5.1 1.4 6 1.4

6.1 1.5 7 6 8 6

Pag

e5

Case Study 4: DB2 CLI Based Type 2 JDBC Driver Not Supported

For many years, the legacy Type 2 driver was the only reliable option and it has been in heavy use

everywhere. Starting from WebSphere 8.0, this driver is no longer supported and one must start using

the Type 4 driver.

While the Type 2 driver may have been reliable, innovation stopped happening there a long time ago. All

the latest JDBC API enhancements are only available in the Type 4 driver. Also with Type 4, there is no

need to install any DB2 client runtime in the WebSphere machine.

While this change mostly affects administration, negative effects on application code cannot be ruled

out.

Similarly, support for Microsoft SQL Server 2000 Driver for JDBC and WebSphere SequeLink JDBC driver

for Microsoft SQL Server also have been removed in v8.0. If you are a MS SQL Server user, you must

adopt Microsoft SQL Server 2005 JDBC driver or DataDirect Connect JDBC driver for SQL Server.

Pag

e6

The Anatomy of a Migration Project While every migration project is different, they follow a certain path. Knowing the sequence of activities

will help someone visualize the lifecycle of a migration project.

Pag

e7

Setting Business Priority and Project Scope

Which applications will be migrated? Will you purchase new hardware for WAS 8? These are the

questions discussed at this stage. Decisions made at this stage guide the rest of the project.

WAS 8 Migration Business Priority Decision Table

Which applications to migrate to WAS 8? Start with smaller and less complicated applications. Applications that have deep integration with external systems, such as, main frame DB2, CICS, SAP etc., are more complex.

Will the number of machines (topology) in the environment change? If your present environment had been struggling with the user load, this may be a good time to re-architect the topology. Otherwise, defer any topology change for a later time.

Will you purchase new hardware and establish a brand new environment for WAS 8, or, will it coexist with older WAS in existing machines? If you have recently made significant investment in hardware, consider the co-existence option. If the hardware is showing signs of age, this is an excellent time to invest in new hardware. Incorporating new hardware adds very little risk. Doing the work now will save labor cost compared to if you do it a few months down the road.

Will developers add new features to the application during the migration project? Generally speaking, making significant changes to the code base during migration increases risk. It is recommended that you do a feature freeze until migration is over. This will simplify and minimize the testing effort.

Should you re-architect the application using Java EE 6? Customers who are in WAS v7, have some breathing room with the EOS date. They can certainly undertake a re-architecture project. Customers that are in v6 or v5, have more issues to deal with and have less time on hand. They should consider migrating the code as is.

Pag

e8

In addition to setting the priority and scope, this stage should also establish a Service Level Agreement

(SLA). Stakeholders and IT managers of development and administration groups should agree on the

SLA. Success and failure of the project are evaluated against these SLA metrics.

Migration SLA is a tripartite agreement

Sample SLA metrics (Note, these are for example purposes only. Exact metrics will vary for each

organization):

Downtime to production environment during the migration project should not exceed 4 hours of weekend days between 5PM to 9PM.

Downtime to production environment after the migration (due to defects etc.) should not exceed 2 hours in the first 2 weeks.

Average response time of a migrated application should not be more than 10% of a previously established baseline.

There can be a maximum of 0 severity 1 defect and 5 severity 2 defects.

Planning the Project

This stage defines the blue print for the actual migration work. First, an avant-garde team of senior

developers and administrators need to learn as much as possible about WAS 8 and various risks

associated with migration. They will form the main planning committee.

The committee has many deliverables:

An education plan for the rest of the team. Hardware specifications, if new hardware is being purchased. Also consider upgrading

development machines. New topology design, if applicable. Choose a development IDE – You can use Rational (RAD/RSA) or plain Eclipse. Define the rollout

plan for developer machines. Automation plan – Automation can significantly speed up work and reduce risk. Planners need

to create a document that lists all available automation tools, some of which are discussed in this paper.

Project plan – A detail plan indicating who will do what work and when.

Pag

e9

Obtaining Skills

We recommend full retraining for the developers. Here is a sample training path:

1. New language features of Java 5 & 6 - 1 day. This is applicable to companies that are in WAS v5 or 6.0.

2. Web Application Development Using Java EE 6 for WebSphere 8. 5 days. This course teaches JSF 2.0, Facelet templating, Contexts and Dependency injection (CDI), basic Java Persistence Architecture (JPA) and stateless session EJB.

3. EJB 3.1 Programming for WebSphere 8. 5 days. This is applicable to shops that are using EJB extensively. All aspects of EJB 3.1 are covered. JPA is covered in details. Use of CDI from EJB is also covered.

Optionally, for companies planning on developing web services, we recommend:

1. Web Service Development Using JAX-WS for WebSphere 8. 5 days. Teaches SOAP based web services.

2. RESTful Web Service Development Using JAX-RS for WebSphere 8. 3 days.

For administrators currently managing WAS v5 or 6.x, we recommend a full 5 day administration course

while for v7 users, a shortened 3 day course may be appropriate.

Code Migration

This stage involves preparing the Java code and various associated supporting files like deployment

descriptors for WebSphere 8. Following are the key steps:

Migrate the project structure from the old IDE to the new one. The directory structure and project file formats have changed over the years. The quickest way to migrate a project is to bring it into the workspace of the new IDE. This can be done by checking out the project from CVS or by importing it from a ZIP archive.

Java EE 6 migration. Various deployment descriptors are migrated to the new specification. RAD8 has a wizard that can automate this step.

Resolve compilation errors. Fix errors introduced by changes to the compiler's behavior and changes in Java language.

Fix JSP pages. Problems with JSP pages are best identified during unit testing. There are tools that can automate certain fixes and reduce the time to identify common code issues.

New JDBC driver. If you are using DB2 or MS SQL Server as the database, switch to the new JDBC drivers. This is discussed earlier in the paper.

Deprecated API. Some of the Java API may have been deprecated. Consider fixing them as much as possible to avoid future problems. Again, there is tooling from IBM that may help you with this.

Unit testing. Run the full suite of automated or manual test scripts.

Pag

e1

0

Administrative Migration

IBM provides a myriad of options to migrate the configurations of an environment. The primary factor

that affects your decision path is if you will be reusing existing hardware and topology or if you will be

adopting brand new hardware and design a new topology.

IBM provides set of tools, called Runtime Migration Tool (RMT), to copy configuration from existing

environment and migrate them into a WAS 8 environment. You will need to decide if you will use this

tool or use your own scripts and some manual work. Besides reducing effort, RMT also migrates any fine

tuning, such as JVM heap size, done over the years.

Coexistence is a powerful concept, where you can setup a WAS v8 node in the same machine as an older

node running v5, v6 or v7. This option is useful when your topology is remaining unchanged and you

don't have any new hardware. To implement coexistence, follow these steps in each WAS machine:

Install WAS v8 where an older version of WAS is already installed. Create a profile for the WAS v8 node. Let the system choose unique TCP port numbers so that they

don't conflict with the old node. This is the key factor in coexistence. It allows both the old and the new environment to execute at the same time.

Use RMT to copy configuration from old node to the new one. Make sure that you set the -replacePorts command line option to false to preserve the unique port values selected in previous step. Use the option not to copy the old applications. Applications should be migrated as per the steps discussed before and then deployed at a later time.

Change web server plugin configuration to forward traffic to the new node.

With coexistence, the old environment remains intact. This greatly enhances any rollback procedure.

Essentially, all you have to do is to restore the old web server plugin so that HTTP traffic gets forwarded

to the old nodes.

A downside of coexistence is that the new ports may run afoul of firewall rules or conflict with other

applications running in the OS. Keep a detailed inventory of ports when a profile is created. This will

later help you resolve any issues.

There are a few flexibility options built into WebSphere. Knowing them will help you resolve tricky

problems:

A WAS v8 web server plugin can successfully forward traffic to v6.x and v7 nodes (but not v5). This will help you with incremental migration of applications and nodes. See: www.ibm.com/support/docview.wss?uid=swg21160581.

A WAS v8 Deployment Manager (DMGR) can manage v5, v6.x and v7 nodes. This will help you simplify the topology as you incrementally migrate nodes. Instead of having a separate DMGR for each version, you can have one.

Pag

e1

1

RMT can copy configuration of an old node and migrate it in a new machine with a completely different OS. For example, this will help you migrate from Windows 2000 to Linux or Windows 7 server.

Testing

The majority of defects should be caught during unit testing which may require you to beef up the unit

testing bucket.

Once code passes unit testing, the application should be deployed in a QA environment. This should as

closely mimic the production as possible. At minimum, clustering should be enabled in QA if that is the

case in production.

Two types of tests need to be carried out in full.

Function testing. All previously developed test scripts need to be followed. Generally speaking, no change is expected in the behavior of the application. This helps you reuse the existing scripts.

Performance and stress testing. Run all existing stress test scenarios and compare the performance with existing baselines. Look for problems that appear only under heavy load, such as transaction rollback exception.

Deployment

Key aspect of deployment to production is a procedure to fallback to the previous environment. This

procedure is employed if a migrated environment fails to meet one or more SLA metrics and IT

managers feel that fixing these problems "in place" is not an option. The procedure itself has to meet

the agreed SLA metrics for maximum downtime and must be reliable. In most cases, the procedure will

comprise of:

1. Restoring web server plugin configuration so that traffic goes to the old nodes. 2. If coexistence was not used, then the old environment may be restored via WebSphere tools or

using OS images.

The procedure needs to be tested and practiced in a QA environment.

Pag

e1

2

Leveraging New Value Adds WAS v8 brings a treasure trove of new features, especially for application development. You can

consider adopting some of the new approaches at the time of environment migration or at a later time.

We think organizations can get a substantial improvement from contexts and dependency injection, Java

Persistence API (JPA), JavaServer Faces (JSF), Web Service using JAX-WS and JAX-RS and the Simplified

EJB3 introduced in this version. Here are some examples:

Java EE 6 Enhancements

Java EE 6 completely changes the architectural thinking behind enterprise application development. At

the crux lies contexts and dependency injection (CDI). If you know Spring, you will be familiar with how

dependency injection (DI) and aspect oriented programming (AOP) work. These styles of programming

can significantly reduce complexity of the architecture and the need to write boilerplate code1.

Let's take a look at an example. A class that needed to perform logging, will look like this prior to CDI.

public class MyClass {

Logger logger = Logger.getLogger("MyApplication");

public void sayHello() {

logger.fine("Hello world");

}

}

After CDI:

public class MyClass {

@Inject Logger logger; //Injected by a producer

public void sayHello() {

logger.fine("Hello world");

}

}

This is a very simple example and the amount of reduced code appears very small. But, in fact, it is one

less boilerplate code the developer has to worry about and she can get right to developing actual

business logic.

JSF 2.0 is a major enhancement over previous iterations. If you had looked at JSF 1.x in the past and

rejected it, now is the time to consider it again. Biggest value add in JSF 2.0 are:

1 Boilerplate code is code that deals with infrastructure, such as security and transaction management, and does

not implement any business logic per se. Excessive time spent writing boilerplate code makes a developer unproductive. CDI helps one minimize such code.

Pag

e1

3

Facelet templating technology. With this, the layout and look and feel of a site is captured in a small number of template pages. When you change the layout in a template, hundreds of pages using that template will be instantly updated.

Using Ajax to do partial page update becomes utterly simple. No knowledge of JavaScript required. You can always use more advanced toolkits like jQuery for a richer user interface experience.

Use of CDI gives you conversation context, which is essentially a per tab session manager. A regular HTTP session should be avoided due to problems in today's multi-tab browsers where all tabs share the same session.

Input validation has been greatly simplified through the bean validation framework. All you have to do is annotate your managed bean fields.

Now you can develop session EJB within a web application. If you have not used EJB before, now you

should seriously consider adopting local stateless session EJB as a way to implement facade pattern. This

gives you security and good transaction support. Thanks to CDI, using these EJBs from JSF managed

beans can't be any easier.

Finally, we should mention Java Persistence Architecture (JPA) 2.0. JPA was introduced earlier and WAS

v7 had support for it. It was a major simplification of the CMP entity bean framework. With JSF 2.0 as

the front end, JPA entities are easier to use than ever. You can use JPA entities to directly capture user

input and display output in a Facelet page.

Administrative Enhancements

WAS v8 introduces a few new tools for the administrators. Here is a sample collection.

OSGi packaging. Helps you deploy shared libraries that are used by multiple applications. OSGi manages versions of the same library and applications express their need for specific versions.

Job manager. Now you can log into the scripting shell and run commands in remote nodes. Many different types of commands are supported:

o WebSphere command line tools, like startServer and stopServer. o Any OS command. o Ability to install fixpaks in remote machines using the installation manager. o Ability to modify remote profiles using the manage profiles command.

Java heap and core dumps. You can now produce these valuable files directly from admin console without the need for complex scripting commands.

High Performance Extensible Logging (HPEL). HPEL improves performance of logging and tracing. The LogViewer[.sh|.bat] command line tool can continuously monitor HPEL log files and show the output.

Pag

e1

4

Summary In this paper, we identified two key drivers behind migration to WAS v8 – the end of service date of

older versions and new value add. Various sources of risks are identified. They are broadly categorized in

two groups – problems in application code and problems in environment configuration.

The paper provides a detailed roadmap for a migration project. IT managers will find it useful.

Finally, we looked at a few benefits brought on board by WAS v8. Architects will need to take a close

look at Java EE 6. It can make developers significantly more productive and reduce cost of new software

development.

About Web Age Solutions Almost 15 years ago, Web Age Solutions was founded to provide services on WebSphere technology. It has

since grown to encompass many offices across North America, over 50 consultants, and has evolved one of the

largest WebSphere course libraries in the world – with something over 140 courses in this area. The firm is

known for its excellence in architecture and implementing best practices, setting up centers of excellence, and

helping implement complex change efficiently. In WAS 8 migration, Web Age is a consulting company able to

complete migrations, facilitate skills transfer and improve post-migration productivity.

Contact our consulting division at 416-406-3994 x22, or book an appointment directly with a consultant by

using https://my.timedriver.com/1PLPR