3 Event-bus: the backbone of a Vert.x application

The previous chapter introduced verticles. A Vert.x application is made of 1 or more verticles, and each verticle forms a unit for processing asynchronous events. It is common to specialize verticles by functional and technical concerns, such as a verticle for exposing a HTTP API and a verticle for dealing with a data store. This design also encourages deploying several instances of a given verticle for scalability purposes.

Now what we did not cover is how verticles can communicate with each other. Back to the previous example a HTTP API verticle needs to talk to the data store verticle if the larger Vert.x application is doing anything useful.

Connecting verticles and making sure they can cooperate is exactly the role of the event-bus.

3.1  What is the event-bus?

The event-bus is a mean for sending and receiving messages in an asynchronous fashion. Messages are being sent (and retrieved) from destinations. A destination is simply a free-form string, such as incoming.purchase.orders or incoming-purchase-orders, although the former form with dots is preferred.

3.1.1  So is the event-bus just another message broker?

3.1.2  Point-to-point messaging

3.1.3  Request-reply messaging

3.1.4  Publish / subscribe messaging

3.2  The event-bus through an example

3.2.1  Heat sensor verticle

3.2.2   Listener verticle

3.2.3  Sensor data verticle

3.2.4  HTTP server verticle

3.2.5  Bootstrapping the application

3.3  Clustering and the distributed event-bus

3.3.1  Clustering in Vert.x

3.3.2  From event-bus to distributed event-bus

3.4  Summary

3.5  References