Microservices With Apache Camel and Quarkus (Part 2)

In the first part of this series, we saw a simplified microservices-based money transfer application, implemented using Apache Camel and AWS SDK (Software Development Kit) as Java development tools and Quarkus as a runtime platform. As noted, there are many deployment scenarios that might be considered in order to run the production of such an application; the first and simplest one is running it locally in a standalone manner. It's the scenario that we'll be considering during this new post.

Quarkus is able to run your applications in two modes: JVM (Java Virtual Machine)-based and native. The JVM-based mode is the standard classical way of running Java applications. Here, the running application isn't executed directly against the operating system, but in kind of an execution medium where Java libraries and APIs are embedded and wrapped around. These libraries and APIs might be very large, and they occupy a specific part of the memory named Resident Set Size (RSS). In order to know more about the RSS and Quarkus (as opposed to how Spring Boot handles it), see here. 

So, in JVM mode, a Quarkus build process results in several JAR (Java Archive) files, as follows:

• A skinny JAR named <finalName>.jar  located in target/quarkus-app/app containing all the application's classes and other artifacts
• A hollow JAR named quarkus-run.jar located in target/quarkus-app and containing the list of all the artifacts required to run the application, but not the artifacts themself and not the application
• A JAR containing the transformed application bytecode named generated-bytecode.jar and located in target/quarkus-app/quarkus
• A lib folder located in target/quarkus-app containing all the application's dependencies

All the artifacts above are generated by the quarkus-maven-plugin while building the project. This same plugin also supports the creation of an über JAR containing everything which is required in order to run the application (i.e., the application's code, as well as the code of all the dependencies).

As opposed to the JVM mode, the Quarkus native mode runs executable programs. These programs execute directly against the operating system and don't require any JVM. This technique consisting of compiling Java code not to the usual byte code (as in the JVM mode) but rather to executable files significantly reduces the amount of the RSS and, hence, the program's size. This improves their performance. In order to support the native mode, Quarkus relies on GraalVM.

Running in JVM Mode

As mentioned previously, the JVM mode is the simplest Quarkus running mode. It consists in executing the quarkus-run.jar, located in the target/quarkus-app. Several scripts are provided with our project in the source code repository located here. Let's have a look at the start-ms.sh one which, as its name implies, starts our microservices.

#!/bin/sh
./delete-all-buckets.sh
./create-queue.sh
java -jar ./aws-camelk-file/target/quarkus-app/quarkus-run.jar &
sleep 3
java -jar ./aws-camelk-s3/target/quarkus-app/quarkus-run.jar &
sleep 3
java -jar ./aws-camelk-jaxrs/target/quarkus-app/quarkus-run.jar &
sleep 3
java -jar ./aws-camelk-sqs/target/quarkus-app/quarkus-run.jar &
sleep 3
ps ef | grep -i aws-camelk-file | grep -v grep | awk {'print $1'} > pid-aws-camelk-file.pid
ps ef | grep -i aws-camelk-s3 | grep -v grep | awk {'print $1'} > pid-aws-camelk-s3.pid
ps ef | grep -i aws-camelk-jaxrs | grep -v grep | awk {'print $1'} > pid-aws-camelk-jaxrs.pid
ps ef | grep -i aws-camelk-sqs | grep -v grep | awk {'print $1'} > pid-aws-camelk-sqs.pid
./copy-xml-file.sh

The shell script above is a kind of factotum as it takes over all the operations required in order to run our four microservices and handle them appropriately. First, it deletes all the S3 buckets having a name starting with the string "mys3" and followed by a random suffix. Then, it creates an AWS SQS queue if it doesn't exist already. These are all sanity operations making sure to start from a clean situation.

After that, our four microservices are executed, one after another, with a 3-second waiting interval between them in order to guarantee that they have completely started before being called by their partners. Once started, their PIDs are saved in files having the "pid" extension. These files will be used later when you'll want to stop them.

As soon as all the microservices have started, the pipeline is triggered by copying the input XML file containing the money transfer to be performed to the input folder on each of the first Camel route polling. This will activate the whole process, as described in the first part of our story.

So, to resume, in order to run our money transfer application in Quarkus' JVM mode, execute the following commands:

$ cd aws-camelk
$ ./delete-all-buckets.sh #Deletes all the possible existent "mys3..." S3 buckets
$ ./purge-sqs-queue.sh #Purge the myQueue SQS queue
$ mvn clean package  #This will also executes all te defined unit tests
$ ./start-ms.sh      #Starts the micro-services and save their associated PIDs

This will copy the file money-transfers.xml located in aws-camelk-model/src/main/resources/xml to the /tmp/input folder. This is the input folder on which the Camel route in aws-camelk-file is polling. 

As soon as the XML file lands there, it is validated against its own schema, located in aws-camelk-file/src/main/resource/xsd, and, if valid, it is stored in the AWS S3 bucket whose name is the string "mys3" to which we append a randomly generated string. Here, the XML file is processed by the aws-camelk-s3 Camel route which splits, tokenizes, and streams it, before publishing each resulting XML message to the AWS SQS queue named "myQueue."

Last but not least, the Camel route aws-camelk-sqs is processing each published message by unmarshaling it from XML to Java, then marshaling it to JSON, before sending an HTTP POST request to the REST endpoint http://localhost:8080/xfer.

All this pipeline may be followed by inspecting the log files that Quarkus displays on the console. You may repeat the process as long as you want by copying different XML files into the input directory. But beware: you can't process the same file twice or more because the associated route is idempotent, meaning that the same input file will be ignored if served several times. But you can, of course, change its name.

Once you have enough to play with your micro-services, run the following commands:

$ ./kill-ms.sh              #Stop the micro-services one by one using their PID
$ ./delete-all-buckets.sh   #Delete all the S3 buckets which names start with "mys3"
$ ./purge-sqs-queue.sh      #Deletes all the messages in the myQueue SQS queue
$ ./delete-sqs-queue.sh     #Deletes the myQueue SQS queue

Now your environment is clean. The next post will show how to perform the same operations of locally running the microservices but in the Quarkus native mode.

Stay tuned!