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

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. When will you need to migrate by? 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. Version 5.0.x 5.1.x 6.0.x 6.1.x 7.0.x 8.0.x
Sources:

End of Support Date 30-Sep-2006 26-Sep-2008 30-Sep-2010 30-Sep-2012 Web Age estimate: Oct 20131 Web Age estimate: Jul 20152

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

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

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.

Page

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 19 12 8 11 10 6 9 7 29 18 17 18

Programming changes Administration changes Total

Source: WebSphere Application Server Versions: Whats 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.

Page

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"); Page

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. WAS Version 5.1 6 6.1 7 8 Java or JRE Version 1.4 1.4 1.5 6 6

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/compatibility137541.html Changes to Java 5 compared to 1.4: http://www.oracle.com/technetwork/java/javase/compatibility137462.html

Page

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.

Page

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.

Page

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.

Page

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:

Page

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.

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

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:

Page

10

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.

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.

Page

11

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:

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.

Page

12

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.

Page

13

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

Page

14