Time is running out! Submit now
Dave Mulley, Donald Vines | Updated March 29, 2019 - Published September 19, 2017
CloudHybrid CloudOn premisesContainersJavaMicroservices
Archived date: 2019-05-22
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 188.8.131.52 to Liberty 184.108.40.206. 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.
Downloadable files. To view the original monolith and the refactored monolith at each stage of refactoring, go to this repository on GitHub.
To set up the development environment, you must complete the following steps:
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.
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: %HOMEPATH%\wlp\bin.
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 installUtility command.
Enter the following command:
installUtility install DayTrader3Sample
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.
Create a Liberty runtime environment:
In the Specify the runtime environment creation and JRE window, enter the name (WLP-220.127.116.11), and select an existing installation (%HOMEPATH%\wlp).
Create the Liberty Server:
In the Liberty Server pane, select the Daytrader3Sample Liberty Server that you extracted earlier. Click Finish.
The daytrader3-ee6.ear file contains the source and binary files for the application. To import it into Eclipse to establish the application projects:
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.
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.
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 import XXX cannot be resolved
The following sections examine two of the problems and their solutions.
To resolve this Java problem, add the dt-ejb project to the Java build path of the web project:
On the Projects tab, add the dt-ejb project to the Java Build Path. Then, click OK.
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 18.104.22.168, 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:
Rename the log4j-core-2.8.2.jar file to log4j-core.jar.
Copy the log4j.jar and log4j-core.jar files into the daytrader3-ee6\lib directory.
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 the Create, manage, and configurations window:
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.
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.
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.
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 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 22.214.171.124 to Liberty 126.96.36.199 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:
Back to top