Archived | Refactor existing monolithic applications to microservices one bite at a time, Part 1: Migrating the Liberty version
Follow the migration of a sample application to the latest Liberty version
For most new applications, microservices is the architecture of choice of many organizations. These organizations are starting to examine how they can refactor their existing monolithic Java applications into microservices to make them more flexible and agile without starting from scratch. Monoliths were designed not just for single tasks, but also to perform every step that is needed to complete a particular function. The size and complexity of monolithic applications are the result of numerous inter-related pieces of code and data models, which can be overwhelming to developers when they start refactoring. They might dive straight into changing code, where one monolith becomes 10 or 20 smaller monoliths. As a result, the developer can’t be sure whether the issues in testing are related to the migration to the cloud or the refactoring process.
This article series breaks down the complex problem of refactoring monoliths into microservices step-by-step. You learn how to implement a systematic approach to refactor your monolithic applications and how to use the tools and techniques to help you along that journey. You see how to migrate the monolith to microservices and then run that monolith in the cloud. The target cloud platforms are Docker Containers in IBM Cloud Private on-premises and Cloud Foundry in the IBM Cloud Public.
In Part 1 of this series, you migrate the Daytrader3 application from IBM® WebSphere® Application Server Liberty 22.214.171.124 to Liberty 126.96.36.199. After you migrate the application, you then deploy and run it on premises. This step is important to ensure that your application is at the latest version before you move it to the cloud. During this step, you might also want to eliminate other areas of technical debt, such as upgrading your open source libraries or upgrading your Java Enterprise Edition (Java EE) specification levels. Keep these changes to a minimum so that you do not introduce too much risk. By doing so, you can move your workloads to the cloud and benefit from cloud economics sooner, rather than later.
- Java SE Development Kit 1.8
- GitHub account
- Apache Maven 3.3 or later
- Eclipse Neon 3 IDE for Java EE Developers
- IBM Cloud Private: IBM Cloud Private community edition Docker (installed as part of IBM Cloud Private) Kubernetes CLI kubectl
- IBM Cloud: Cloud Foundry CLI IBM Cloud
Set up the development environment
To set up the development environment, you must complete the following steps:
- Download and install the Liberty kernel.
- Download and install the Daytrader3 application.
- Configure Eclipse IDE for Java EE Developers.
Download and install the Liberty kernel
The Liberty server process comprises a single Java virtual machine (JVM)–the Liberty kernel–and various optional features. The kernel does not provide any features by itself, but you can add features to it. By using the
installUtility command of the Liberty kernel, you can use the
bin/installUtility command to create your own server from the kernel with the features that you need.
- Download the Liberty kernel.
- Extract the Liberty kernel into a local folder. We refer to this path as %HOMEPATH%.
Download and install the Daytrader3 application
IBM provides a packaged Liberty server that contains everything that is required to run the Daytrader3 application. In this step, you download the packaged server and then extract it.
Download the Daytrader3Sample.jar file, and place it in the Liberty bin folder, for example:
The Daytrader3Sample.jar file is a packaged Liberty server. The following figure shows the structure of the Java archive (JAR) file.
The Daytrader3Sample.jar file contains the Daytrader3Sample server that is configured with the features that are required to run the Daytrader3 application. The JAR file also contains the Daytrader3 application (daytrader3-ee6.ear file), which includes the source code. In addition, the JAR file includes the externaldependencies.xml file, which is used to download the Derby database that the application uses.
Install the Daytrader3Sample.jar file from the command line by using the
- At a command prompt, go to the Liberty/bin directory, for example:
Enter the following command:
installUtility install DayTrader3Sample
When prompted, accept the terms of the license agreement, and click Yes to download the Derby prerequisite dependencies.
The following figure shows the artifacts that this process generates.
- At a command prompt, go to the Liberty/bin directory, for example:
Configure Eclipse IDE for Java EE Developers
- Open Eclipse, and create a workspace with the name
- Install WebSphere Developer Tools from WASdev. Then, follow the prompts to complete the installation.
- Install WebSphere Application Server Migration Toolkit from WASdev. Then, follow the prompts to complete the installation.
Create a Liberty runtime environment:
- In Eclipse, click Window -> Preferences -> Server -> Runtime Environment.
- Add a server. Click Add, and then select IBM -> WebSphere Application Server Liberty.
In the Specify the runtime environment creation and JRE window, enter the name (
WLP-188.8.131.52), and select an existing installation (%HOMEPATH%\wlp).
- In the next window, click Finish, and then click OK.
Create the Liberty Server:
- In Eclipse, click File -> New -> Other -> Server -> Server.
- Select the server type (WebSphere Application Server Liberty).
- In Choose the type of server to create, enter the server name (
Daytrader3Sample), and select a server runtime environment (WLP-184.108.40.206).
In the Liberty Server pane, select the Daytrader3Sample Liberty Server that you extracted earlier. Click Finish.
Import the code into the Web Tools Platform (Eclipse) projects
The daytrader3-ee6.ear file contains the source and binary files for the application. To import it into Eclipse to establish the application projects:
- In Eclipse, click File -> Import -> Java EE -> EAR file.
- Enter the
daytrader3-ee6.earfile. You can find the file in the %HOMEPATH%\wlp\usr\servers\Daytrader3Sample\dropins directory. Then, click Finish.
By having an enterprise archive (EAR) file with source code, you can easily import the code into Web Tools Platform projects. If you don’t have this file, you can modify your build system to create this EAR file. Alternatively, you can import the code from your source code repository that was used to create the EAR file.
Resolve Java problems
Now that you imported the source for the DayTrader application, you must resolve Java problems so that you can compile the application as ready for deployment.
- In Eclipse, select Project -> Clean -> Clean all projects.
Open the Markers view, and expand Java problems.
The web project uses types and interfaces from the dt-ejb project, which results in several “The import XXX cannot be resolved” Java problems. You can find the important problems to fix by searching for “
The import XXX cannot be resolved.”
The following sections examine two of the problems and their solutions.
The import com.ibm.websphere.samples.daytrader cannot be resolved
To resolve this Java problem, add the dt-ejb project to the Java build path of the web project:
- In Eclipse, right-click the web project, and select Properties -> Java Build Path.
On the Projects tab, add the dt-ejb project to the Java Build Path. Then, click OK.
The import org.apache.commons cannot be resolved
The dt-ejb project uses classes and interfaces from the Apache commons logging library (apache.commons.logging V1.0.3). The application does not provide this library. Although this same library is available in Liberty 220.127.116.11, it is not visible to the application. Regardless, an application should not rely on open source libraries from the application server.
The following steps explain how to solve this problem:
- Download the commons-logging-1.0.3.zip file, and extract it to the %HOMEPATH%\downloads directory.
- In Eclipse, right-click daytrader3-ee6, and select New -> Folder.
- Enter the folder name as lib, and click OK.
- Right-click daytrader3-ee6, and select File -> Import -> General -> File System.
- Set the From directory to
- Select the commons-logging.jar file to import.
- Set the Into folder to
- The Apache commons logging library has dependencies on the Log4J file, which create runtime issues if not resolved. You will find these dependencies in the manifest.mf file that is inside the commons-logging.jar file. To resolve this problem, download the log4j-1.2.6.jar and log4j-core-2.8.2.jar files to the %HOMEPATH%\downloads directory.
- Rename the log4j-1.2.6.jar file to
Rename the log4j-core-2.8.2.jar file to
Copy the log4j.jar and log4j-core.jar files into the daytrader3-ee6\lib directory.
Run the WebSphere Application Server Migration Toolkit
The WebSphere Application Server Migration Toolkit Eclipse plug-in analyzes source code and configuration files for known migration issues. In this step, you use the Migration Toolkit to look for known issues when you migrate from Liberty that is running Java 6 to Liberty that is running Java 8.
- In Eclipse, run the WebSphere Application Server Migration Toolkit. Click Run -> Analysis. In the left pane, click Software Analyzer, and then click New.
In the Create, manage, and configurations window:
- Enter a suitable name for the configuration.
- On the Scope tab, select Analyze entire workspace.
- On the Rules tab, for Rule Sets, select WebSphere Application Server Version Migration.
In the Rule set configuration window, for Source application server, select Liberty, and for Target Java version, select IBM Java 8. Click OK to confirm.
- Click Apply, and then click Analyze to begin the code analysis.
The Software Analyzer Results view shows the results. As Figure 12 shows, no additional problems are detected. Therefore, you can now move to the next step to deploy the application.
Deploy the DayTrader application on-premises
- In the Enterprise Explorer view, right-click the daytrader3-ee6 file, and select Export -> EAR File.
Click Browse, go to the %HOMEPATH%\wlp\usr\servers\Daytrader3Sample\dropins directory, and select the existing daytrader3-ee6.ear file. Select Overwrite existing file, and click Finish. This step replaces the provided EAR file with the file that you just created.
In the Server view, right-click the Daytrader3Sample Liberty Server, and then click Start.
Confirm that the application has started. In the Console view, look for the following message:
CWWKZ0001I: Application daytrader3 started in XX.XX seconds.
If the application has not started, resolve any deployment problems, and then redeploy it on-premises.
Run the DayTrader application on-premises
With the application deployed and started (starts by default when you deploy it), populate the sample data and log in to the application to do some trading. To run the application on-premises:
Access the application. Point your browser to
http://localhost:9080/daytrader. The following figure shows the home page of the application.
Click the Configuration tab.
- Click the (Re)-create DayTrader Database Tables and Indexes link. A window opens that shows the progress. When the database is created successfully, close the window, and return to the DayTrader Configuration page.
- Click the (Re)-populate DayTrader Database link to generate the sample data. A window opens that shows the progress. In this example, you see that the DayTrader Database is populated with 15,000 user accounts and 10,000 stock quotes. You can update these values by using the Configure DayTrader run-time parameters link on the Configuration tab. When the database is populated, close the window, and return to the DayTrader Configuration page.
Click the Trading & Portfolios link. Accept the default user ID and password, and click Login. You now see a window like the following example that you can use to begin trading.
You can download a completed Eclipse workspace for Part 1 from GitHub.
You now migrated the Daytrader3 application from Liberty 18.104.22.168 to Liberty 22.214.171.124 and are ready for Part 2.
The following resources also provide information about refactoring monoliths to microservices, but they do not define a systematic approach nor show how to do it as this series shows: