Repackaging workloads as-is to a container without requiring development teams to make application changes. Explore how to move a WebSphere application to run on Red Hat OpenShift Container Platform with a traditional WAS container.
Introduction
Operational modernization gives an operations team the opportunity to embrace modern operations best practices without putting change requirements on the development team. Modernizing from WebSphere Network Deployment (ND) to the traditional WebSphere Application Server Base V9 runtime in a container allows the application to be moved to the cloud without code changes.
The scaling, routing, clustering, high availability and continuous availability functionality that WebSphere ND was required for previously can be provided by the container runtime and allows the operations team to run cloud-native and older applications in the same environment with the same standardized logging, monitoring and security frameworks.
While traditional WebSphere isn’t a ‘built for the cloud’ runtime like WebSphere Liberty, it can still be run in a container and will receive the benefits of the consistency and reliability of containers as well as helping to improve DevOps and speed to market.
This type of modernization should not require any code changes and can be driven by the operations team. This path gets the application in to a container with the least amount of effort but doesn’t modernize the application or the runtime.
As organizations modernize to cloud platforms, new technologies and methodologies will be used for build, deployment and management of applications. While this modernization will be focused on cloud-native (built for the cloud) applications, using the traditional WebSphere container will allow common technologies and methodologies to be used regardless of the runtime.
The diagram below shows the high level decision flow where IBM Cloud Transformation Advisor is used to analyze existing assets and a decision is made to not make code changes to the application and use the traditional WebSphere container as the target runtime.
This repository holds a solution that is the result of a operational modernization for an existing WebSphere Java EE application that was moved from WebSphere ND v8.5.5 to the traditional WebSphere Base v9 container and is deployed to Red Hat OpenShift.
Application Overview
The Customer Order Services application is a simple store-front shopping application, built during the early days of the Web 2.0 movement. Users interact directly with a browser-based interface and manage their cart to submit orders. This application is built using the traditional 3-Tier Architecture model, with an HTTP server, an application server, and a supporting database.
There are several components of the overall application architecture:
- Starting with the database, the application leverages two SQL-based databases running on IBM DB2.
- The application exposes its data model through an Enterprise JavaBean layer, named CustomerOrderServices. This components leverages the Java Persistence API to exposed the backend data model to calling services with minimal coding effort.
- This build of the application uses JavaEE6 features for EJBs and JPA.
- The next tier of the application, named CustomerOrderServicesWeb, exposes the necessary business APIs via REST-based web services. This component leverages the JAX-RS libraries for creating Java-based REST services with minimal coding effort.
- This build of the application is using JAX-RS 1.1 version of the respective capability.
- The application’s user interface is exposed through the CustomerOrderServicesWeb component as well, in the form of a Dojo Toolkit-based JavaScript application. Delivering the user interface and business APIs in the same component is one major inhibitor our migration strategy will help to alleviate in the long-term.
- Finally, there is an additional integration testing component, named CustomerOrderServicesTest that is built to quickly validate an application’s build and deployment to a given application server. This test component contains both JPA and JAX-RS-based tests.
How the Application was Modernized
In order to modernize the application from WebSphere ND v8.5.5 to the WebSphere Base v9 container running on OpenShift, the application went through analysis, build and deploy phases.
Analysis
IBM Cloud Transformation Advisor was used to analyze the existing Customer Order Services application and the WebSphere ND runtime. The steps were:
Install IBM Cloud Transformation Advisor either with an Operator, locally, or as part of IBM Cloud Pak for Applications.
Download and execute the Transformation Advisor Data Collector against the existing WebSphere ND runtime.
Upload the results of the data collection in to IBM Cloud Transformation Advisor and review the analysis. A screenshot of the analysis is shown below:
In the case of the CustomerOrderServicesApp.ear application, IBM Cloud Transformation Advisor has determined that the migration to WebSphere traditional is of Simple complexity and that there are six Suggested Issues that have been detected.
Drilling down in to Detailed Migration Analysis Report that is part of the application analysis, it is worth noting that IBM Cloud Transformation Advisor has detected that there are issues with JPA. In this case it determined to use a non-default setting to avoid an issue where the second-level cache and the JPA configuration properties would need to be migrated. There is also a JAX-RS suggestion to use a non-default setting. If not using the non-default settings there would be changes required with JAX-RS (to handle missing Apache and Wink packages). These two issues are related to a decision that was taken by IBM to allow WebSphere Application Server V9 to run in either JPA 2.0 or JPA 2.1 mode as described here and in either JAX-RS 2.0 or JAX-RS 1.1 mode as described here. Transformation Advisor will make the needed changes for you in order to run in JPA 2.1 mode and JAX-RS 2.0 mode. The application can run in JPA 2.0 mode and JAX-RS 1.1 mode with no changes by the user due to the automated changes Transformation Advisor makes.
In summary, no code changes are required to move this application to the traditional WebSphere Base v9 runtime and the decision was taken to proceed with the operational modernization.
Detailed, step-by-step instructions on how to replicate these steps are provided here
Build
The build phase created the traditional WebSphere container configuration artifacts. The steps were:
- Update the generated scripts that configure the runtime environment to configure the JPA 2.0 and JAXRS 1.1 engines. The final versions of the configuration script can be found here:
- The containerized application was tested locally before the code and configuration files were committed to the git repository
Detailed, step-by-step instructions on how to replicate these steps are provided here
Deploy
The deploy phase created the OpenShift Pipelines using Tekton to deploy the application. The pipeline builds the container and then deploys the deployment, service and route for the application.
The steps were:
Define the Tekton pipeline to create th
Tasks,PipelineandPipelineResources.Run the pipeline manually to create the first deployment. Eventually, the pipeline will be triggered by a webhook on each new git commit.
Verify the pipeline. View the logs and access the application to confirm the deployment was succesful.
Detailed, step-by-step instructions on how to replicate these steps are provided here
Summary
This application has been modified from the initial WebSphere ND v8.5.5 version to run on traditional WebSphere and deployed to Red Hat OpenShift