Chapter 10. Reactive Messaging: The Connective Tissue
In Part III, you saw many features to develop reactive applications with Quarkus. But, as you remember from Part II, we don’t want to limit ourselves to reactive applications; we want to build reactive systems. That’s what we are going to do now.
Reactive systems use asynchronous message passing among their components. However, while middleware and frameworks can sometimes hide this message-passing aspect, we believe it’s far more efficient to make it apparent. It not only helps you write event-driven code (on event x, do y), but also helps decompose your application into a set of components receiving and producing messages. Thus, Quarkus offers a message-driven development model that is simple but powerful to consume, process, and create messages. This chapter focuses on this model, how it relates to Reactive Streams, and how it makes building message-driven and event-driven applications straightforward.
From Reactive Applications to Reactive Systems
When you talk to a Java developer about messaging, you can feel the frustration. For years, JMS has been the de facto standard for messaging. However, that API didn’t age well, and new messaging technologies such as Kafka and Pulsar use concepts that do not work well with JMS. In addition, JMS is a blocking API, which prevents us from implementing reactive principles.
While Quarkus can use JMS, we are going to look at another approach called Reactive Messaging. This MicroProfile ...
Get Reactive Systems in Java now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.