Software project: Creating a real-life transactional microservices application on Kubernetes

Part 3: Setting up the LRA coordinator

Now that we have our microservices development environment set with database connectivity in the Part 2 let’s take a look at developing the Gymapp microservices with LRA.

Long Running Actions (LRA) is a MicroProfile specification that introduces APIs for services to coordinate activities. For more information check out microprofile-lra on GitHub.

In the Part 1 I had sketched up the high-level architecture for the Gymapp that consist of 2 custom microservices, , Gymuser and Gyminstructor, and PayPal® payment service.

Here is a closer look to this is in the picture below with a use case for the Gymuser attending a gym class:

• Instructor creates a class that is available for Gymusers
• Gymuser browses instructor classes and picks up a class to attend
• Gymuser attends an instructor class by making a payment to PayPal®
• Attending a class creates a Myclass for the Gymuser and a matching class Sign-up for the Instructor that are loosely coupled with a long running transaction (LRA)

Gymapp microservices loose coupling using LRA coordinator

In such a small application like Gymapp with only 2 microservices the system could be easily implemented point-to-point without the LRA as opposite to what is described above. But when the system grows and adding new microservices that could lead to some of sort of spaghetti code requiring more point-to-point connections and the benefits of using LRA become evident.

This is easy to see when either the Instructor decides to cancel the class due to low participation or Gymuser decides to cancel the attendance (sign-up) at a class for some reason. Then, we also need to return the money to the Gymuser in both use cases. Without LRA this would add the number of point-to-point calls between microservices.

However, with LRA we can leave this functionality to the LRA coordinator to manage and concentrate on just implementing the logic to make the money returned back to the Gymuser by PayPal® in case of such cancellations. Using LRA will make the code cleaner and more manageable and saves us writing this spaghetti code to our microservices.

When the system grows that could easily lead to some of sort of spaghetti code requiring more point-to-point microservices connections and the benefits of using LRA become evident.

After the class is done and the class is completed by the Instructor the long running transaction of the Gymuser to attend a gym class use case is closed (multiple actually, since there are likely several Gymusers to attend a class) which will in turn close the LRAs involved with status “complete”. Likewise the cancellation will close the LRA, but as opposite to status “complete” with a status “compensate”.

To get going with LRA in Gymapp first I added the following dependencies to the Gymuser and Gyminstructor projects pom.xml :

<dependency>
    <groupId>io.helidon.microprofile.lra</groupId>
    <artifactId>helidon-microprofile-lra</artifactId>
</dependency>
<dependency>
    <groupId>io.helidon.lra</groupId>
    <artifactId>helidon-lra-coordinator-narayana-client</artifactId>
</dependency>

To run the LRA for the Helidon Dev there are a couple of ways to do it.

On my local Helidon Dev I’ve been using Narayana LRA Coordinator on Quarkus for quite some time now, following the instructions in this nice article.

Unfortunately it appears not be available prebuilt anymore and needs to be built from the GitHub source. Once built running it in port 9000 is simple:

java -Dquarkus.http.port=9000 -jar narayana-coordinator.jar
__  ____  __  _____   ___  __ ____  ______ 
 --/ __ \/ / / / _ | / _ \/ //_/ / / / __/ 
 -/ /_/ / /_/ / __ |/ , _/ ,< / /_/ /\ \   
--\___\_\____/_/ |_/_/|_/_/|_|\____/___/   
2024-01-16 15:26:05,028 INFO  [io.quarkus] (main) lra-coordinator-quarkus 5.11.1.Final on JVM (powered by Quarkus 1.8.3.Final) started in 0.394s. Listening on: http://0.0.0.0:9000
2024-01-16 15:26:05,040 INFO  [io.quarkus] (main) Profile prod activated. 
2024-01-16 15:26:05,040 INFO  [io.quarkus] (main) Installed features: [cdi, rest-client, resteasy, resteasy-jsonb, smallrye-context-propagation, smallrye-fault-tolerance, smallrye-openapi, swagger-ui]

To make the Narayana coordinator work in Gymapp the LRA config needs to be added to the Helidon microservices projects. For this we need to add the file src/main/resources/application.xml to both Gymapp microservices projects.

Gymuser (runs in port 8080):

mp.lra:
  coordinator.url: http://otmm-tcs:9000/lra-coordinator
  propagation.active: true
  participant.url: http://gymuser:8080

Gyminstructor (runs in port 8081):

mp.lra:
  coordinator.url: http://otmm-tcs:9000/lra-coordinator
  propagation.active: true
  participant.url: http://gyminstructor:8081

Using “localhost” will also work locally, but prefer having a virtual hosts configured in /etc/hosts file:

127.0.0.1         otmm-tcs
#130.66.229.222   otmm-tcs # IP addr of the OCI VM for remote dev
127.0.0.1         gymuser
#130.66.229.222   gymuser # IP addr of the OCI VM for remote dev
127.0.0.1         gyminstructor
#130.66.229.222   gyminstructor # # IP addr of the OCI VM for remote dev

The other option is to run Oracle MicroTx as a Docker image.

First download Oracle Transaction Manager for Microservices Free using, then copy and unzip the package into it’s place and finally run runme.sh installer from it. (The prerequisite is to have JDK 21 and Maven installed.)

Select the option 1 from the installer which will run the MicroTX on Docker:

sh runme.sh
java version "11.0.21" 2023-10-17 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.21+9-LTS-193)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.21+9-LTS-193, mixed mode)
*************************

 Use this script to run microservices and get started with Oracle Transaction Manager for Microservices.

*************************

Enter a number (1-3) to specify the platform on which you want to run the microservice
1) Docker - only the transaction coordinator will run in a docker container and the sample microservices will run in the local environment
2) Minikube
3) Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE)
#?

I am running the MicroTX installer for the Kubernetes setup (option 3 from the installer) and will cover this once we get to the Kubernetes part.

BTW, MicroTX Docker image is also available to be pulled from Oracle container registry directly under Database repositories (also the Enterprise Edition is available).

Let’s move on to writing some LRA code for the Gymapp in the Part 4.