Tutorial: Java Enterprise App Modernization
How To Transform the Medrec JEE Application into Microservices
Refactoring the Medrec Application into Microservices
Legacy Java applications are difficult to modernize. Enterprises rely on these monolithic apps to power their businesses but face an urgent mandate to move to the cloud and adopt a cloud native architecture. The following sections track the process of refactoring the MedRec application (also known as the Avitek Medical Records application), a monolithic WebLogic sample Java EE application, into microservices and deploying the new microservices on Oracle Container Engine for Kubernetes (OKE).
Getting Started
The key goal in refactoring the Medrec application will be to identify the services to extract from the monolith, their interfaces, and the classes included in their scope. Following this analysis, we will be able to extract each service, so it can be developed and deployed separately on a Kubernetes cluster such as OKE, using Oracle’s tooling to create WebLogic based docker containers. The vFunction process follows three steps that accelerate the application modernization process using intelligent automation that observes actual business domain flows and replaces months of manual work and tedious modernization labs.
Step 1: Learning and Assessment
vFunction dynamic analysis observes the actual Medrec business flows and behaviors via a JVM agent then applies static analysis of the bytecode for static dependencies and to assure code coverage. An initial application migration assessment report (see image below) measures application complexity across five dimensions, specifies the set of initial services that vFunction has identified, and related classes, API end points, and exclusivity calculations. The video below introduces the Medrec analysis and discusses several key refactoring concepts including service exclusivity, infrastructure classes, and entry points.
Step 2: Analysis and Automation
Once the learning and assessment phase is completed, vFunction presents the analysis to the architect in an interactive console that provides an initial service topology and detailed visibility into all related interdependencies that may require additional refinement by the architect. The next video in the Medrec analysis walks you through the vFunction user interface and reviews the initial results, interactions, and recommendations.
Consolidating Services: Chat Function
As an architect, augmented by the vFunction UI, you have the power to apply your perspective and refinement to the system recommendations. In the Medrec application example, the next step in the process is to begin to further consolidate the services and maximize service exclusivity based on vFunction’s initial decomposition. These next steps show how vFunction takes an architect from an initial service topology to a final, simplified microservice architecture of five services and a common library using best practices including merging services, creating new API endpoints, and building a common services library. The next step involves creating a singular Chat function for the Medrec application. This short video below demonstrates how to merge services, explore dynamic class exclusivity, create new API entry points, and rename a new complete microservice as DrPatientChat which is 100% exclusive.
Creating a Single Search Microservice
Next, the Medrec analysis focuses on creating a single Search microservice by investigating static classes that are identified as non-exclusive and marking them as infrastructure classes and thus assigning them to a common library. The following video tracks that process, merges two search services into one, identifies resources that should also be common, and renaming the consolidated new microservice as PatientSearch.
Constructing a Common Library
The next video illustrates best practices for ensuring a clean common library by identifying non-foundational classes in the common jar and ways to reduce the scope of a service by ignoring redundant classes that then yield a minimal context.
A Final Microservice Architecture
The final video showcases the remaining steps to create a new microservice architecture consisting of 5 services for chat, search, authentication, record management, and registration.
Step 3: Service Extraction & Deployment
From the vFunction UI, you can select which services to extract and the system will create a set of Service Specification JSON files. That file is referenced by a vFunction code-copy utility that pulls from the necessary source code and creates a POM file to use with Maven to build the new service. To deploy on Kubernetes and OCI, vFunction leverages WebLogic Server Deploy Tooling and the WebLogic Image Tool. In addition, you’ll need:
- A running service instance of Oracle Container Engine for Kubernetes (OKE) cluster
- Familiarity with kubectl
- Access to Helm
- WebLogic Kubernetes operator installed on the cluster
- Ingress controller (operator) installed on the cluster (currently supported “Nginx” and “Traefik”)
- An Oracle account with permissions to download WebLogic base docker images
- A docker repository to upload all images that are created during the process.
Summary
Monolithic Java applications can be modernized quickly and migrated confidently to the cloud with the vFunction platform, using a low-risk approach that results in high value. Not only does this avoid the downside and disappointments of the typical lift-and-shift approach to cloud migration, but it also allows the enterprise application to now access all the services and advantages a cloud native application available on OCI, from increased elasticity and scalability, faster release cycles, modern developer services, and rising productivity and business agility.
