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