Migrating IBM WebSphere Message Broker v6.1, 7, 8 to IBM Integration Bus v9 on Distributed Platforms - Checklist for a Successful Migration

IBM’s endeavor to offer one integration product capable of supporting .NET, Java, and various heterogeneous integration scenarios resulted in the launch of IBM Integration Bus (IIB). IIB v9 offers a standardized and flexible integration backbone. It allows placement of WebSphere Enterprise Service Bus (WESB), Rules Engine, and WebSphere Message Broker (WMB) under one software umbrella. One can expect significant benefits including enhanced support for .NET, improved Global Cache, a new Real-Time Performance Monitoring Tool and many other new features and upgrades such us Policy based WLM and BPM integration.

The below checklist is a compilation of IBM Integration Bus Information Center v9 instructions and offers a guideline to a successful migration of WMB v6.1, 7, 8 Broker Component to IIB v9 on distributed platforms. The checklist is comprised of the following topics: Migration of Broker Components and Migration of Development Artifacts.

Migration of Broker Components

The earliest version of WMB that one can migrate resources from is WMB v6.1. In a case where a migration from earlier versions is required, one must migrate to WMB v6.1, 7 or 8 first, however earlier version migrations are not in the scope of this document.

Migration from Windows x86 product to x86-64 product is not supported as well as migration of Linux x86 product to Linux x86-64.

In addition there are restrictions on migrations of earlier versions to IIBv9 Developer Edition. Supported operating modes are Full Edition, Remote Adapter Deployment, Express Edition and Standard Edition.

Finally, IIB v9.0 requires a minimum WebSphere MQ (WMQ) v7.5.0.1 on distributed platform. If publish/subscribe functionality is utilized by WMB v 6.1, a migration of WMQ Queue Manager is required first, followed by migration of subscriptions and then Broker component.

Remember: back up all of your resources prior to migration!

Migrating WMB v6.1, WMB v7.0, and WMB v8.0 Broker Component

• Back up all resources: configuration repository (WMBv.6.1), Broker database(WMBv6.1),  and development artifacts.
• If using ODBC connections, back up ODBC connection files.
• If using configurable services, back up configurable services properties.
• Install WMQ v7.5.0.1 and up.

In Place Broker Component Migration

Install at least Integration Bus component under new location on the same machine

Remove WMB v.6.1,7.0, 8.0 Broker from the domain configuration

Stop all channels connected to WMB v6.1,7.0,8.0 Broker

Stop WMB v6.1, 7.0, 8.0 Broker

Migrate WMB v6.1 Broker‘s Queue Manager to appropriate IIB v9 WMQ version

Migrate Pub\Sub components if required

Update ODBC connection filesto IIB v9.0 format if required

Set up IIB v9.0 command environment

Run the mqsimigratecomponents command to migrate WMB v6.1, 7.0, and 8.0 Broker (mqsimigratecomponents command migrates configuration data in forward and backward fashion (use “t” option for rollback): broker databases, queues and broker registry are migrated)

Copy environment settings if required

Start IIB Broker

Deploy migrated artifacts

Parallel Broker Component Migration:

Install at least Integration Bus component under new location on the same machine or on another machine

Update ODBC connection files to IIB v9.0 format if required

Set up IIB v9.0 command environment

Create IIBv9.0 Queue Manager on appropriate WMQ version

Create IIBv9.0 Broker

Copy environment settings if required

Start IIB Broker

Create Integration Servers (Recreate WMBv6.1, 7.0, 8.0 Execution Groups)

Deploy migrated artifacts

Migration of Development Artifacts

Development artifacts from all previous versions cannot be shared with IIB v9.0. 

Artifacts developed on IIB v9.0 cannot be deployed to earlier versions.

User Defined Node Jars developed in earlier versions  cannot be migrated to IIB v9.0.

User defined nodes require an extra diligence during migration. 

Resources which are imported into IIB v.9.0 cannot be used in earlier versions of the product.

Message flow projects are replaced with integration projects.

Message sets are “Read-only” once imported and not modifiable. (Modify message sets by

enabling msgset development in IBM Integration Toolkit -> Preferences)

WMB v6.1 and v.70 msgmap can be viewed, compiled and deployed but they are “Read- only” In order to modify .(msgmap) convert (.msgmap) to .map file

 Migrating WMB v6.1, WMB v7.0, and WMB v8.0 Development Artifacts

• Development resources can be imported into IIB v.9.0 as PI files.
• Workspaces can be migrated into IIB v9.0.
• Migrate Development Artifacts

PI Import:

Export development artifacts from a previous WMB version into a PI file

Import PI file into an IIB v.9.0 workspace

Convert integration projects into applications or libraries if required

Workspace migration:

Point IIB v.9.0 IBM Integration Toolkit to location of an existing workspace

Click OK

In case of errors during migration apply “Quick Fix” by right clicking task list warning or error in the Problems view, then click Quick Fix.

Resources:

*Figure 1, 2: Migrating to IBM® Integration Bus v90

http://www-01.ibm.com/support/docview.wss?uid=swg27038933&aid=1

*All Content: IBM Integration Bus Information Center

http://pic.dhe.ibm.com/infocenter/wmbhelp/v9r0m0/index.jsp

Eva Khalil is a middleware solutions designer with more than 12 years of experience in systems and applications integration area.   She has been working with Prolifics for the past five years.   Eva has successfully led many integration projects for various business industries: financial, government, healthcare, insurance and utilities. She is especially fond of WMQ and IIB.

The Curious Case of Web Services Migration - Part II

Vladimir Serebryany, Senior Consultant

As I mentioned in the previous blog entry, the final goal was to develop a Maven-powered environment in which the deployable unit - in our case the EAR file - would be generated by a set of scripts starting from checking out versioned code from PVCS. I would lie if I tell you that I liked Maven at first sight. My initial feelings were anger and frustration as Maven-enabled RAD essentially diminished RAD to be just a fancy code editor - and nothing more. Gone were round-trip interactive development, and my productivity as a developer really suffered. Only by the end of the project I found out how to keep RAD effective and fully engaged and still be able to build using Maven. At the very end of the project I started to really appreciate the effectiveness of Maven as a build tool especially when it comes to building deployable units for different environments in a very uniform and reliable way. Its ability to manage versioned dependencies is just outstanding given the relative simplicity with which this is achieved.

Anyway, for regular Dynamic Web Projects the task would be trivial - Maven already has a plug-in to generate all deployable artifacts. But for Web projects with Web services there was nothing I could use because there were a number of generated artifacts which simply did not fit into Maven’s rigid default directory structure. I faced a task of developing a new Maven plug-in just for the tasks on hand (as long as I am mentioning this, you may guess that plug-in was successfully implemented, but read below to find out at what cost).

To assess the scope of the effort involved, let me just list the tasks accomplished.
Given: set of RAD projects fresh from PVCS each with Maven pom.xml. One specialized project had all WSDL and XSD files. Parent folder had pom.xml with our custom Maven Web services plug-in properties and configurations. Note that only scripts and libraries available with WAS 6.1 run-time are used for code generation. No part of RAD is used for Maven plug-in (in fact our customer uses AIX to run build scripts).

Below is the overview of custom plug-in functionality:

• For each WSDL in parent pom.xml run WSDL2Java script, create temporary folder structure with all Java and XML configuration files.
• For each generated webservices.xml go in and replace generated placeholder with actual servlet class name (this is because WSDL2Java script just does not do that by design).
• Combine all webservices.xml files together and create single webservices.xml to be put in the target project.
• Collect all mapping xml files and put them together in the target project.
• Collect all servlets names and classes names for each WSDL and put them as servlet/servlet-mapping entries in the Web Deployment Descriptor in the target project.
• Copy WSDL and XSD files into the target project WEB-INF/wsdl folder.
• Copy all generated Java sources and put them together with existing source code.
• Pass resulting project to the standard Maven Web project plug-in to be compiled and built.

At the end the Prolifics team had accomplished everything the client asked us to do. and we left the site with application up and running in production with no problems. The only thing they asked with amazement was: "How did you do that, guys?"

Vladimir Serebryany is a Senior Consultant at Prolifics with in-depth knowledge and broad hands-on experience with the J2EE environment as well as expertise in EJBs, Servlets, JSP and JSF. Excelling at migrations, Vladimir has over 9 years of experience with a wide range of complementary skills including WebSphere, WebSphere MQ, WebSphere Business Integration Message Broker, UNIX, C/C++, Java, HTML/ASP, JavaScript, and Visual Basic. He has served as team leader/senior developer roles in large, complex projects and configurations with clients in the financial, insurance and telecommunication industries - among others.

The Curious Case of Web Services Migration - Part I

Vladimir Serebryany, Senior Consultant

During one of my recent BEA WebLogic to IBM WebSphere migration assignments at a major insurance company, I encountered an interesting problem.

The client had a large number of Web services which were running on BEA WebLogic and consumed by a .NET front-end. In the course of migration, our team had to not only migrate code to WebSphere but also help the customer refactor the source code repository and create a set of Maven scripts to provide a fully scripted build/deploy process for all environments - from unit test to production.

We started with the typical set of issues:

• WSDL files and corresponding XSD files had relative namespaces in them - and the spec strongly recommends absolute ones
• Source code was stored in typical WebLogic structures and deployable components were created by running four (!) different Ant scripts
• Code and WSDL files were stored in PVCS and the revision history had to be preserved
• WSDL2Java wizard was invoked every time scripts ran so binding Java code would be generated on the fly and not stored in PVCS - wise decision but binding implementation classes with client's code in them had to be preserved from being overwritten.

The first issue was easy to deal with – a couple sed/awk scripts took care of the namespaces. We gave WSDL files back to client; they validated them against their .NET environment and found no problems with new namespaces.

Item #2 was also relatively easy to solve - we manually rearranged code into a Rational Application Developer (RAD) structure and that was it. RAD is really good at that sort of thing. While doing that we also extracted PVCS archives as files from the central repository and rearranged these archives in the file system according to the new directory structure. We sent back these directories to the client’s PVCS team, and they imported these archives back into a new PVCS project. That way all the previous generations of source code have been preserved. We now were able to work with PVCS and track a file’s revision history right back to Noah's Ark.

Now we had to deal with WSDL to Java files generation. There were three sorts of files: custom code with business logic, binding code and classes generated from data types definitions in XSD files, and binding implementation classes. We did not have to worry about the first two types: the first set was permanent code which we shifted to another utility’s Java project for simplicity of maintenance. Generated Java was what it was - generated code which the wizard took care of, only the binding implementation classes was something we had to take care of. On one hand all the methods stubs are generated by the WSDL2Java wizard - on the other hand these methods already contained the customer's code. If we allowed the wizard to run "freely," this code would be overwritten.

Here we needed a trick and we found one. As it is well-known, RAD may designate one or more folders in the project to be the Source folders - meaning it will compile all Java code in these and only these folders into binary form. It happens that built-in RAD wizards are very sensitive to the order in which Source folders are listed in "Order and Export" tab of "Java Build Path" configuration page. If the WSDL2Java wizard for bottom-down Web services generation is invoked either from the pop-up menu or from the wsgen.xml script, it always places all generated files into the folder listed first in "Order and Export" tab. That "observation" provided us with opportunity to solve the problem. We would define two Source folders: “src/main/java” and “src/main/java2.” “src/main/java” would be listed first in "Order and Export" tab, “src/main/java2” would be the second. The single "target/bin" folder was designed for binary files. We placed all existing binding implementation files into “src/main/java2” folder, and we put WSDL and XSD files into a separate project. (Note that by using “src/main/java” folder structure we were shooting to use Maven.)

From that point on, if a WSDL definition changed, we would clean “src/main/java” folder and run the Web services wizard/script against new WSDL/XSD files. Newly generated binding files would go into “src/main/java” folder. As long as binding implementation files were also on the classpath, WSDL2Java wizard was smart enough to not regenerate *BindingImpl.java files, but rather pick them up from “src/main/java2” folder. IBM provided ws_gen Ant task, script and sample properties files were customized to run the whole task at any time for all 20 WSDL's we had in the service definition (see http://publib.boulder.ibm.com/infocenter/radhelp/v7r0m0/topic/com.ibm.etools.webservice.was.creation.core.doc/ref/rtdwsajava.html). We didn't include “src/main/java” folder into PVCS and never had to check-in transient generated code.

The remaining issue to solve was to reproduce in RAD the style in which WebLogic's WSDL2Java script generated the code. By tweaking WSDL2Java options on Window->Preferences->Web services->Websphere->JAX-RPC Code Generation->WSDL2Java tab in RAD, we matched the style of generated code so that RAD-generated code was almost drop-in replacement for WebLogic-generated code. The problem was solved - but only for development phase so far.

Coming in Part II: “My initial feelings were anger and frustration as Maven-enabled RAD essentially diminished RAD to be just a fancy code editor - and nothing more. Gone were round-trip interactive development, and my productivity as a developer really suffered. Only by the end of the project I found out how to keep RAD effective and fully engaged and still be able to build using Maven…”

Vladimir Serebryany is a Senior Consultant at Prolifics with in-depth knowledge and broad hands-on experience with the J2EE environment as well as expertise in EJBs, Servlets, JSP and JSF. Excelling at migrations, Vladimir has over 9 years of experience with a wide range of complementary skills including WebSphere, WebSphere MQ, WebSphere Business Integration Message Broker, UNIX, C/C++, Java, HTML/ASP, JavaScript, and Visual Basic. He has served as team leader/senior developer roles in large, complex projects and configurations with clients in the financial, insurance and telecommunication industries - among others.