DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Please enter at least three characters to search
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

The software you build is only as secure as the code that powers it. Learn how malicious code creeps into your software supply chain.

Apache Cassandra combines the benefits of major NoSQL databases to support data management needs not covered by traditional RDBMS vendors.

Generative AI has transformed nearly every industry. How can you leverage GenAI to improve your productivity and efficiency?

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workloads.

Related

  • Microservices With Apache Camel and Quarkus (Part 4)
  • Microservices With Apache Camel and Quarkus
  • Microservices With Apache Camel and Quarkus (Part 5)
  • Microservices With Apache Camel and Quarkus (Part 3)

Trending

  • How to Ensure Cross-Time Zone Data Integrity and Consistency in Global Data Pipelines
  • Simpler Data Transfer Objects With Java Records
  • Assessing Bias in AI Chatbot Responses
  • Mastering Deployment Strategies: Navigating the Path to Seamless Software Releases
  1. DZone
  2. Software Design and Architecture
  3. Microservices
  4. Microservices With Apache Camel and Quarkus (Part 2)

Microservices With Apache Camel and Quarkus (Part 2)

Take a look at a scenario to deploy and run locally the simplified money transfer application presented in part 1 as Quarkus standalone services.

By 
Nicolas Duminil user avatar
Nicolas Duminil
DZone Core CORE ·
Jun. 03, 23 · Tutorial
Likes (2)
Comment
Save
Tweet
Share
10.4K Views

Join the DZone community and get the full member experience.

Join For Free

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.

Shell
 
#!/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:

Shell
 
$ 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:

Shell
 
$ ./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!

AWS Apache Camel Java virtual machine Quarkus microservice

Opinions expressed by DZone contributors are their own.

Related

  • Microservices With Apache Camel and Quarkus (Part 4)
  • Microservices With Apache Camel and Quarkus
  • Microservices With Apache Camel and Quarkus (Part 5)
  • Microservices With Apache Camel and Quarkus (Part 3)

Partner Resources

×

Comments
Oops! Something Went Wrong

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!