WebSphere User Group WAS v6 migration

1
IBM Software Group
WebSphere Application Server v6.0 Migration
Jonathan Marshall, WebSphere Technical
Sales marshalj_at_uk.ibm.com
2
Agenda

• Migration Planning
• Runtime Migration
• Tooling Migration
• Application Migration
• What to do today
• Summary

3
Why should you consider migration?

• Take advantage of new features in WebSphere
  Application Server 6.0
• Upgrade to new specifications
• Previous version of WebSphere Application Server
  out-of- support
• WAS v4.0 30th April 2005

4
Which version should I move to?

• Which version?
• v5.1
• Proven technology but back level
• Not necessarily simpler, will involve more work
  overall
• v6.0
• Leading edge technology but new product
• Why you should be confident moving to v6
• Migration assistance
• InfoCenter
• Migration Redbook (covers both v4 and v5)
• IBM WebSphere Services
• Update strategy timely fixpaks

5
Planning a migration

• Lots of factors to consider
• Changes to
• Runtime
• Development environment
• Application code,
• Timing of changes
• Existing skill level
• Use incremental and iterative approach
• Execute migration in stages
• Keep variables to the smallest number possible
• Reduce risk
• Build upon previous experience

6
How long will it take?

• Standard consulting answer It depends
• Relatively easy to estimate
• Skills
• Development environment installation
• Runtime environment installation
• Runtime rollout
• Very hard to estimate
• Code migration
• Use of internal APIs
• Third-party code, tools and services

7
How much will it cost?

• Again It depends (Sorry)
• Things to consider
• Licenses
• WebSphere Application Server
• Operating Systems
• Database
• Monitoring Tools
• Hardware
• Resources
• Training

8
Typical Migration Project Plan Runtime Phase

• Runtime Migration
• Assessment (1 week)
• Administrator Training (1 week)
• Runtime installation and migration (1 to 3 weeks)
• Scripts migration (1 day to 1 week)
• Testing regression, stress, performance (1 to 3
  weeks)
• Production rollout and fine-tuning (1 to 2 weeks)

9
Typical Migration Project Plan Application Phase

• Application Migration
• Assessment (1 week)
• Architecture re-factoring (1 to 2 weeks)
• Training (1 week)
• Development environment installation (1 to 2
  weeks)
• Application migration (1 to 3 weeks)
• Testing regression, stress, performance (1 to 3
  weeks)
• Production rollout and fine-tuning (1 to 2 weeks)

10
Agenda

• Migration Planning
• Runtime Migration
• Tooling Migration
• Application Migration
• What to do today
• Summary

11
Runtime Migration Goals

• Upgrade existing installations (v4.x and v5.x) to
  v6.0
• Application functionality is identical to that
  before upgrade
• Get it up and running
• Minimal (or no) changes in administrative scripts
  
• Performance is equal or better than that before
  upgrade
• Minimal downtime
• Exploit additional functionality of WebSphere
  later on

12
WebSphere v6 Runtime Overview

• Supports J2EE 1.2, 1.3 and 1.4 specifications
• Can upgrade runtime environment without upgrading
  applications
• Code migration is optional and should be the last
  step
• Supports mixed version nodes in a v6 ND Cell
• Allow for migration in stages within a cell
• Mixed v5 and v6 nodes must have v6 DMgr (cant
  add new v5 node)
• v6 ND introduces profiles
• Each profile has its own user data including
  WebSphere configuration
• All profiles share same WebSphere binaries
• Fixes applied to all profiles
• Less disk space required than separate
  installations
• stand-alone server, deployment manager or custom
  profile

13
Supported migration paths from previous versions

• WebSphere v4
• Adv. Single Server
• 4.0.2 and later
• Adv. Edition
• 4.0.2 and later
• Enterprise
• 4.1 and later

• WebSphere v5.0.x
• Express
• Base
• Network Deployment
• Enterprise

• WebSphere v5.1
• Express
• Base
• Network Deployment
• WBI Server Foundation

WebSphere Application Server 6 (Express, Base, ND)
14
Migration Approaches

• Use Migration Wizard
• GUI for WASPreUpgrade and WASPostUpgrade scripts
• Work for simple topology
• Run WASPreUpgrade and WASPostUpgrade scripts
• More control and flexibility
• Let you migrate and test incrementally
• Manual Migration
• Complete control

15
1. Use Migration Wizard

• Install WebSphere Application Server v6
• Create a v6 profile (Important same name as v4
  node)
• Install v6 compatible Web Server and plug-in
• For v4 AE, make sure admin server is running and
  it is located on the same server as v6
• Run First Steps-gtMigration Wizard
• Enter the location of previous installation
• Enter backup directory
• Select v6 Profile name
• Select Use port values assigned to previous
  installation or Use port values assigned to
  target profile
• Start v6 node and test

16
2. Run WASPreUpgrade and WASPostUpgrade scripts

• Install WebSphere Application Server v6
• Create a stand-alone or ND profile
• Install v6 compatible Web Server and plug-in
• Run WASPreUpgrade to generate backup copy of
  configuration
• If previous version is v4 AE, make sure v4 AE
  server is running.
• Run WASPostUpgrade on v6 profile to copy and
  transform configuration data from backup
• Start v6 profile and test

17
WASPreUpgrade Command

• Performs export of old version of WAS
• Syntax
• WASPreUpgrade(bat/.sh) ltbackupDirNamegt
  ltold_WAS_Dirgt options
• Required Options for v4 AE
• administrationNodeName v4 AE admin node name
• nameServiceHost v4 host name used to call
  XMLConfig nameServicePort bootstrap port for v4
  AE
• Required Options for v4 AEs
• import xml configuration file of v4 AEs

18
WASPostUpgrade Command

• Performs import into pre-existing v6 profile
• Syntax
• WASPostUpgrade backupDirectory
• -oldProfile profile_name
• -profileName profile_name
• -import xmi_data_file
• -scriptCompatibility true
  false
• -portBlock port_starting_number
  
• -backupConfig true false
• -replacePorts true false
• -substitute "key1value1key2v
  alue2..."
• -instance instance_name
  -hostName host_name
• -includeApps true false
• -traceString trace_spec
  -traceFile file_name
• -scriptCompatibility true
  false
• -connectionTimeout lt
  timeoutInMinutesgt

19
3. Migrate v4/v5 to v6 manually

• Install WebSphere Application Server v6
• Create a standalone or deployment manager profile
  
• Install v6 compatible Web Server and plug-in
• Configure server properties
• JVM Process Definition, WebSphere variables,
  Shared Libraries, Data Sources, etc.
• JMS Providers WebSphere JMS Provider has to be
  converted to v5 Default Messaging
• Web Services Security
• Deploy application or add node to DMgr
• Start v6 and test
• In other words, build it from scratch!

20
Migration Scenarios

• Consider the following
• Migrate v4 AE domain to v6 cell
• Migrate v5 cell to v6 cell

21
Migrate v4 AE domain to v6 cell

• Install v6 and create a Deployment Manager
  profile
• Create a v6 stand-alone profile for each v4 node
  in the Server Group.
• Migrate each v4 node to the v6 stand-alone
  profile
• Applications installed in Server Group are not
  migrated
• Start v6 Deployment Manager
• Use addNode to add each new v6 node to the cell
• Install v4 server group applications
• Migrated EAR is stored in installableApps
  directory
• Test

22
Migrate v4 AE domain to v6 cell
Load Balancer
Session DB
App. DB
23
Migrate v4 AE domain to v6 cell

• Install Deployment Manager
• Bring down first HTTP Server
• Upgrade first node
• For a short period of time, two versions of
  WebSphere must run concurrently
• Server affinity makes this easier
• Different versions cannot share session state
• Should appear as normal to users

Load Balancer
HTTP Server
V6 plugin
Session DB
App. DB
Session DB
24
Migrate v4 AE domain to v6 cell

• Repeat with second node
• Update both plugin configurations

Load Balancer
HTTP Server
V6 plugin
V6 plugin
Session DB
App. DB
Session DB
25
Migrate v4 AE domain to v6 cell

• Full v6 environment
• Remove redundant DBs

Load Balancer
V6 plugin
V6 plugin
V6 plugin
App. DB
Session DB
26
Migrate v4 AE domain to v6 cell - things to
watch out for

• JSP 0.91 not supported in v6
• V4 LTPA security not migrated
• Need to generate keys and enable security
• V4 Server groups not migrated

MIGR0219I The migration function is starting to
import Global Security. MIGR0334W If you
previously enabled security, it has been
disabled. You must configure the Lightweight
Third Party Authentication (LTPA) mechanism
before enabling security.
27
Migrate v5 cell to v6 cell

• Install v6 and create a Deployment Manager
  profile
• v6 cell and node name must match that in v5
• Migrate v5 deployment manager to v6
• v5 deployment manager is disabled
• migrationDisablementReversal.jacl reactivates if
  needed
• Start v6 Deployment Manager
• Migrate v5 nodes (optional)
• Migrate v5 Java clients (optional)
• Test

28
Migrate v5 cell to v6 cell

• Can take same approach as with v4
• Dual Cell configuration
• Alternative can use migration tooling

Load Balancer
HTTP Server
HTTP Server
V5 plugin
V5 plugin
V5 plugin
App. DB
Session DB
29
Migrate v5 cell to v6 cell

• Migrate Deployment Manager
• Retains cell configuration

Load Balancer
HTTP Server
HTTP Server
V5 plugin
V5 plugin
V5 plugin
App. DB
Session DB
30
Migrate v5 cell to v6 cell

• Install IHS v6 (optional) and v6 plugin and
  configure as normal
• Create unmanaged node
• Add web server to configuration
• Map application to cluster web server

Load Balancer
HTTP Server
HTTP Server
V6 plugin
V5 plugin
V5 plugin
App. DB
Session DB
31
Migrate v5 cell to v6 cell

• Create custom profile in v6 DM (same node name as
  in v5)
• Use migration tools to migrate node (not GUI)
• WASPreUpgrade
• WASPostUpgrade
• Start v6 node agent
• Note Same session DB

Load Balancer
HTTP Server
HTTP Server
V6 plugin
V5 plugin
V5 plugin
App. DB
Session DB
32
Migrate v5 cell to v6 cell

• Fully configured v6 cell
• Switch off compatibility
• convertScriptCompatibility

Load Balancer
HTTP Server
HTTP Server
V6 plugin
V6 plugin
V6 plugin
App. DB
Session DB
33
Migrate Administrative Scripts

• Version 4
• XMLConfig and wscp scripts are not supported in
  v6
• Need to migrate to wsadmin scripts manually
• Many examples in v6 InfoCenter and Redbooks
• Version 5
• Mostly work in v6
• Embedded messaging changed to default messaging
• processDef changed to processDefs
• Location of transaction logs directory has
  changed
• Compatibility mode for duration of migration

34
Agenda

• Migration Planning
• Runtime Migration
• Tooling Migration
• Application Migration
• What to do today
• Summary

35
IBM Rational Application Developer for
WebSphere

• Rational Application Developer v6
• Supports J2EE 1.2, 1.3 and 1.4 application
  development
• Rational Web Developer is designed for web
  developers
• Does not support EJB development (comes with WAS
  express)
• Test environments
• WebSphere Application Server v5.x and v6.0
• WebSphere Portal development and test server
• No support for v4 test environment

36
Eclipse Plugin Migration

• Rational Developer v6 is based on Eclipse 3.0
• Supports Eclipse 2.1 plugin
• Plug-in using internal APIs may not work
• Migration steps
• Import plug-in source code to RAD v6
• Run PDETools-gtMigrate to 3.0
• Update requires plugin version in plugin.xml
• Change internal API code to public ones

37
Source Repository Migration

• Workspace
• Backward compatible with WebSphere Studio v5.1.x
• Changes made when loaded in v6 but can still be
  used by both v5.1.x and v6 (not v5.0)
• Note Portlets developed in the v5.0.2.2 toolkit
  will not be backward compatible
• Known problems
• Initial start up in v6 may show errors trying to
  display editors, close perspectives and re-open.
• Repositories (e.g. CVS, ClearCase)
• Compatible with WebSphere Studio v5.1.x source
  whilst v6 features are not used
• Compatibilty maintained by .compatibility file
  do not edit!
• When migrated, select Remove Compatibility from
  Enterprise Application context menu

38
Agenda

• Migration Planning
• Runtime Migration
• Tooling Migration
• Application Migration
• What to do today
• Summary

39
Application Migration

• Application doesnt have to be migrated
• Can be done incrementally
• Migrate application code to take advantage of new
  specifications and features
• E.g Web Services Security, new EJB functionality
• J2EE Migration Wizard can migrate application
  from J2EE 1.2/1.3 to 1.4 automatically
• What else needs to be done?
• Just work through the problem list in
  Application Developer

40
J2EE Specifications Supported by WebSphere v6

• J2EE 1.4 applications can contain J2EE 1.2/1.3
  modules

41
J2EE Specifications Supported by WebSphere v6
(Cont.)
42
J2EE Migration Wizard (1/2)

• Migration from v4.0/v5.x to v6.0
• Supports specification level migration from J2EE
  1.2/1.3 to 1.3/1.4

43
J2EE Migration Wizard (2/2)

• Migrate J2EE Projects from 1.2/1.3 to 1.3/1.4
• Migrates EJB projects to 2.0/2.1
• Updates deployment descriptors
• Updates existing CMP beans
• Change bean class to abstract
• Changes create method, removes fields and
  replaces getters and setters for CMP entity beans
• Update mapping metadata
• Converts proprietary IBM relationships to CMR
• Does not migrate custom finders
• Adds Local interfaces

44
Application Migration Web Services considerations

• Secure Web Services need manual migration
• Configure binding information for Request
  Consumer and Response Generator in
  webservices.xml (using tooling)
• Similarly for client side in web or EJB
  deployment descriptor
• UDDI v2 not supported
• Migrate v1.1.1 (WAS v4) to v2 and then v3
• Run uddiDeploy.jacl to deploy UDDI v3 application

45
Application Migration Migrating MDBs

• J2EE Migration Wizard migrates MDB apps to v6
• MDB application will work without any changes
• To improve performance and use multiple messaging
  engines in a service integration bus
• Change to new JMS activation specification
  instead of listener port.
• Re-deploy/rebind MDB
• v4 JMS listener message bean automatically
  migrated
• Use of non-MDB listeners not permitted in J2EE
  1.3/1.4
• Use mb2mdb tool

46
Application Migration Bits n Pieces

• Application code that deviates from the J2EE
  specification may require some modification
• Use of proprietary technologies like VAP, EAB,
  CCF,
• Third party libraries and potentially difficult
  dependencies
• Additions to JDK 1.4 may cause conflict
• E.g. XML
• Use of alternative XML libraries may require
  changes
• Be careful about classloading issues
• Generally recommended that all code be recompiled
  with JDK 1.4 before deploying to v6.0 (and v5.1)

47
Deprecated functions

• Apache Soap API and deployment model
• Re-implement with J2EE 1.4 Web Services
• CMP method level access intent is deprecated
• Re-configure CMP to use bean level access intent
• Data Access Beans are deprecated
• Use Service Data Objects (SDO) instead
• CustomRegistry deprecated in v5.0
• Replaced by UserRegistry in 5.0 and 6.0
• Common Connector Framework
• Generated code runs in 4.0/5.x
• No editing support in Application Developer
• Primarily manual migration process to JCA

48
No longer supported

• The following features are no longer supported
• C SDK provided in WAS Enterprise
• C CORBA apps need to be manually converted to
  Java ORB APIs
• Persistence Builder
• Generated code runs in 4.0/5.x with minor
  modification
• No editing support in Application Developer
• Primarily manual migration process to EJB CMP

49
Agenda

• Migration Planning
• Runtime Migration
• Tooling Migration
• Application Migration
• What to do today
• Summary

50
Best Practices Pointers

• Experience has shown that well-structured
  applications migrate easier
• Important design patterns to consider
• Façade, Proxy
• Abstraction - Reduces your dependency on any
  particular technology
• Loose Coupling - minimize the amount of
  information that each part of the code knows
  about other parts
• Unit tests - Confirm that your application code
  works as expected
• Effective unit tests reduce migration complexity
  and gauge progress
• Refactor, refactor, refactor

51
Agenda

• Migration Planning
• Runtime Migration
• Tooling Migration
• Application Migration
• What to do today
• Summary and References
• Questions

52
Summary

• Overview of efforts involved in planning a
  migration
• Advantages of using incremental strategy
• J2EE 1.4, 1.3, and 1.2 all supported by
• WebSphere Application Server v6
• Rational Application Developer v6
• Migrating runtime and applications are greatly
  facilitated using built-in wizards and command
  line utilities.
• Start preparing today

53
References

• WebSphere Application Server v6 Information
  Center
• http//publib.boulder.ibm.com/infocenter/ws60help/
  index.jsp
• IBM Redbooks - http//www.redbooks.ibm.com
• WebSphere Application Server v6 Migration Guide
• http//publib-b.boulder.ibm.com/redpieces/abstract
  s/sg246369.html
• Also useful - Migrating to WebSphere v5 Redbook
  (SG246910)
• WebSphere Application Server v6 Handbook series
• System Management and configuration
  recommended
• Performance and Scalability
• Planning and Design
• Security
• Web Services
• WebSphere Application Server support site
• Dates and Fix packs
• http//www-306.ibm.com/software/webservers/appserv
  /was/support/

54
Questions?
Contact marshalj_at_uk.ibm.com