Vert.x - A Primer
From the Vert.x website: “Eclipse Vert.x is a tool-kit for building reactive applications on the JVM”. Let’s break that down to better understand what it means.
Unlike many other solutions for Java, Vert.x is not a framework or application server. This means that Vert.x can be used in ANY Java application regardless of it’s structure. You can use Vert.x inside of Spring, JavaEE, Akka, Play!, etc… Vert.x is un-opinionated about how you integrate with other libraries/frameworks/platforms, and you can therefore integrate Vert.x with legacy applications and new development.
When the Vert.x team talks about Reactive applications, their meaning is reflected in the Reactive Manifesto. The Reactive Manifesto has four major tenets:
- Responsive - The system responds in a timely manner, even when under excessive load.
- Resilient - The system stays responsive even in the event of a failure.
- Elastic - The system stays responsive under varying load and can scale both vertically and horizontally
- Message Driven - Reactive systems rely on asynchronous message-passing to establish boundaries between components.
Vert.x provides a built-in message passing system known as the Event Bus, and additionally it supports using other external messaging providers. These messaging providers can be used discretely or as a way to extend the Vert.x event bus across multiple disparate systems (Think Python’s Celery or JavaEE’s JMS).
Non-blocking I/O is a relatively new concept in the last few years which has gained in popularity as the systems that we develop for have become more parallel in nature. No longer are we writing applications which run on a single CPU with a single pool of memory, we are writing applications which need to take advantage of systems with multiple CPUs and multiple CPU cores in each CPU. To facilitate this applications should be broken down so that discrete operations can run in parallel on different cores. Vert.x uses non-blocking methods to achieve this.
As a corollary to Non-Blocking, Vert.x is designed to be Event Driven. In practice, Vert.x methods and calls are executed asynchronously using callbacks and message passing. This ensures that there should not need to be any threads blocking in the primary execution path (Similar to NodeJS, but we see some differences as we go).