Vert.x is a toolkit or platform for implementing reactive applications on the Java Virtual Machine (JVM). Now, what does that mean? And how does the internal Vert.x design look? This Vert.x overview will explain all that.
Vert.x can deploy and execute components called Verticles. You can think of verticles as being similar to servlets or message driven EJBs in the Java Enterprise Edition model. Here is a simple diagram illustrating the Vert.x platform with 4 verticles running:
The Event Bus
Verticles are event driven, meaning they do not run unless they receive a message. Until then they remain dormant. Verticles can communicate with each other via the Vert.x event bus. This diagram illustrates how the verticles communicate via the Vert.x event bus:
Messages can be simple objects (e.g. Java objects), strings, CSV, JSON, binary data or whatever else you need.
Verticles can send and listen to addresses. An address is like a named channel. When a message is sent to a given address, all verticles that listen on that address receive the message. Verticles can subscribe and unsubscribe to addresses without the senders knowing. This results in a very loose coupling between message senders and message receivers.
All message handling is asynchronous. If a verticle sends a message to another verticle, that message is first put on the event bus, and control returned to the sending verticle. Later, the message is dequeued and given to the verticles listening on the address the message was sent to.
The Vert.x Thread Model
Verticles run in single thread mode. That means, that a verticle is only ever executed by a single thread, and always by the same thread. That means that you will never have to think about multithreading inside your verticle (unless you yourself start other threads which your verticle communicates with etc).
Vert.x is capable of using all the CPUs in your machine, or cores in your CPU. Vert.x does this by creating one thread per CPU. Each thread can send messages to multiple verticles. Remember, verticles are event driven and are only running when receiving messages, so a verticle does not need to have its own exclusive thread. A single thread can distribute messages to multiple verticles.
When a thread delivers a message to a verticle, the message handling code of that verticle is executed by the thread. The message delivery and message handling logic is executed by calling a method in a handler (listener object) registered by the verticle. Once the verticle's message handling logic finishes, the thread can deliver a message to another verticle.
Vert.x comes with a set of built-in services (functionality). Some of these services are:
- HTTP server
- JDBC connector
- MongoDB connector
- SMTP Mail
- Message queue connectors
And these are only a few of the many, many services Vert.x provides, and which the community have provided for Vert.x.