We’re giving away 1,500 more DJI Tello drones. Enter to win ›
Dave Mulley, Donald Vines | Updated March 29, 2019 - Published September 19, 2017
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 220.127.116.11 to Liberty 18.104.22.168. 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.
installUtility install DayTrader3Sample
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.
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:
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 22.214.171.124, 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:
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.
CWWKZ0001I: Application daytrader3 started in XX.XX seconds.
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:
You can download a completed Eclipse workspace for Part 1 from GitHub.
You now migrated the Daytrader3 application from Liberty 126.96.36.199 to Liberty 188.8.131.52 and are ready for Part 2 in this series to migrate the application to the cloud. If your monolith is already running on the latest Java and application server containers, you can skip this step and go directly to Part 2. Conversely, if you are lifting and shifting your Java workloads to the cloud, you can install the earlier version of your software on an infrastructure as a service platform, such as SoftLayer, Amazon Web Services, or Google Cloud Services. But, this series assumes that you want to do more than a simple lift and shift.
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