Modernizing a traditional WebSphere app using IBM Cloud Transformation Advisor

Application modernization is a challenge for many organizations. Migrating our applications to use modern, dynamic, and open-source tools can be of great help in this modernization process.

This article shows how to migrate an enterprise Java EE application from WebSphere Application Server traditional to Open Liberty using the IBM Transformation Advisor tool. By using IBM Cloud Transformation Advisor, you can quickly evaluate your on-premises applications for rapid deployment on WebSphere Application Server and Liberty to public and private cloud environments. Learn more about IBM Cloud Transformation Advisor in the IBM docs.

During the course of this migration, you'll update our sample application from Java EE 6 to Java EE 7. After we migrate the sample application, the next step is to deploy it effectively to the cloud. To demonstrate this, we show you how to deploy this application to the Red Hat OpenShift Container Platform using the Open Liberty Operator.

The Java EE 6 application used in this article is the eBuy application, which mimics an e-commerce on-line store. Within this sample application, you can add and remove products, manage prices, and monitor sales, similar to www.ebay.com. It uses the following Liberty features: appSecurity-2.0, ejbLite-3.2, jpa-2.1, jsp-2.3, servlet-3.1, and it makes use of Db2 to store data.

Migration step 1: Use Transformation Advisor to create a migration plan

After we ran our sample app that was running on WebSphere Application Server traditional (v8.5.5) through Transformation Advisor, it suggested several migration options. We selected to migrate our eBuy application to Open Liberty. After Transformation Advisor analyzed the sample application it produced a report that indicated severe and moderate issues and suggested a migration plan.

The sample application used in this article makes use of the Java Persistence API (JPA) 2.0 feature. The Java Persistence API provides Java developers with an object/relational mapping facility for managing relational data in Java applications. During the migration of this application, Transformation Advisor determined that this feature needed to be migrated to JPA 2.1 level because we are also moving to using Java EE 7 with Open Liberty, which does not support JPA 2.0. Transformation Advisor was very helpful suggesting various solutions for this JPA migration.

Migration step 2: Use Transformation Advisor to address critical technology issues

Four severe technology issues were identified by Transformation Advisor, which must be addressed before the migration:

In this article, to give tangible examples of how the output from Transformation Advisor helped us in making the necessary changes for this migration, we show how we were able to address two of these critical issues:

1. Do not use OpenJPA providers in the persistence.xml file
2. The openjpa.jdbc.Schema configuration property must be migrated to the mapping file.

Migrating from OpenJPA to JPA 2.1

To address the first critical issue, we modified the persistence.xml file.

Here is the old persistence.xml file:

<persistence xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd...>
<persistence-unit name="ebuy" >
<provider>org.apache.openjpa.persistence.PersistenceProviderImpl</provider>
<jta-data-source>jdbc/ebuy</jta-data-source>
<class>com.ibm.ebuy.entity.Book</class>
............
</persistence-unit>

The suggested solution from Transformation Advisor was to migrate to EclipseLink and to replace the OpenJPA provider with the appropriate EclipseLink provider in the persistence.xml file. OpenJPA is an older technology not supported by JPA 2.1, which is why we needed to migrate to EclipseLink.

We used the suggested solution and migrated to JPA 2.1, modifying the persistence.xml file as follows:

<persistence xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd"...>
<persistence-unit name="ebuy" >
<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
<jta-data-source>jdbc/ebuy</jta-data-source>
<class>com.ibm.ebuy.entity.Book</class>
.......
</persistence-unit>

Migrating the Schema configuration property

To address the second critical issue, "The openjpa.jdbc.Schema configuration property must be migrated to the mapping file," we once again modified the persistence.xml file.

The old persistence.xml file defined Schema with the openjpa.jdbc.Schema property: <property name="openjpa.jdbc.Schema" value="ebuy"/>.

The suggested solution from Transformation Advisor was to manually migrate the properties to standardized or EclipeLink properties.

Because we had already chosen to use the EclipseLink implementation, as recommended in the Eclipse migration guide, we needed to create an orm.xml file for the schema:

<entity-mappings xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence/orm http://xmlns.jcp.org/xml/ns/persistence/orm_2_1.xsd"...>
    <persistence-unit-metadata>
        <persistence-unit-defaults>
            <schema>ebuy</schema>
        </persistence-unit-defaults>
    </persistence-unit-metadata>
</entity-mappings>

Then, in the persistence.xml file, we added the following line in order to include the orm.xml file: <mapping-file>META-INF/orm.xml</mapping-file>.

Migration step 3: Preparing the migrated application for deployment

After we modified and added the appropriate files for migrating to use JPA 2.1, we are ready to deploy the new Open Liberty application onto an OpenShift cluster. Transformation Advisor recommended that we use the Open Liberty Operator to deploy our sample application.

As part of the migration plan, Transformation Advisor auto-generated some new files, such as a Dockerfile and a pom.xml file, to make it easier for us to build a new application image using the Open Liberty image and files like application-cr.yaml.

Here is a list of actions taken during the migration based on the recommendations given by Transformation Advisor:

1. The files required for transitioning from an on-premises app to the cloud app (see the previous screen capture) were automatically added to the application by Transformation Advisor.

   Inside the Dockerfile, Transformation Advisor specified the JDK and Open Liberty images to be pulled as follows:

    FROM adoptopenjdk/openjdk8-openj9
    FROM openliberty/open-liberty:kernel-slim-java8-openj9-ubi
   

   Show more

2. Pushed all the generated files to a GitHub repository to create a project for deployment of the application.

3. Installed the Open Liberty Operator to our Red Hat OpenShift cluster using OperatorHub.

Migration step 4: Deploying the migrated app to the cloud

Now that we've successfully followed the recommendations set out in the Transformation Advisor migration plan, we can complete the final migration step of deploying this application to the cloud. To do this, we needed an application-cr.yaml file for the Open Liberty Operator, which Transformation Advisor generated for us:

apiVersion: openliberty.io/v1beta1
kind: OpenLibertyApplication
metadata:
  name: ebuy1
  namespace: openshift
spec:
  replicas: 1
  applicationImage: default-route-openshift-image-registry.apps.tanyakulik.cp.fyre.ibm.com/openshift/ebuy1
  expose: true

In this application-cr.yaml file, we specified the name of the application ebuy1 to be deployed in the OpenShift namespace in our OpenShift cluster. We also specified the application image name using applicationImage variable, which was first built using Docker and then pushed to the registry on the OpenShift cluster. The replicas variable in this file indicates how many pods for this deployment we want running in our OpenShift cluster.

We then ran the following command to apply the yaml file that we added to our application, to create a deployment: oc apply –f application-cr.yaml.

Once this command completed, our application was successfully running in our OpenShift cluster. To verify this, we used the 'oc get routes' command which will gave us the URL to access the application, below is the output of this:

oc get routes
NAME       HOST/PORT                                                   SERVICES             PORT
ebuy1      ebuy1-openshift.apps.tanyakulik.cp.fyre.ibm.com             ebuy1                  9080-tcp

Summary and next steps

Transformation Advisor makes it easy to transition a traditional WebSphere application to Open Liberty and migrate that same application from an on-premises environment to the cloud. It saved us a lot of time and effort figuring out which additional files needed to be created for this migration to the cloud and how to make an additional transition from JPA 2.0 to 2.1, which was required for this migration. Transformation Advisor was helpful in suggesting several solutions from which you could choose the most appropriate option for your own circumstances.

To explore more of the strategies and tooling you can use to modernize your applications, check out the tutorials, articles, and more on the Application Modernization hub on IBM Developer.