MicroProfile Reactive Messaging 1.0 is now available as a standalone release, i.e. outside the MicroProfile umbrella/platform release.
MicroProfile Reactive Messaging delivers a development model to build event-driven microservices and data streaming applications. A long-time has passed since the initial discussions about reactive in MicroProfile. In February, we released Reactive Streams Operators 1.0 providing a set of operators to create, process and consumes reactive streams. This specification was the layer required to build MicroProfile Reactive Messaging.
What’s the goal of Reactive Messaging?
MicroProfile Reactive Messaging 1.0 enables the implementation of reactive data streaming applications, event-driven microservices, and event-sourcing patterns. The specification defines a way to implement reactive data processing applications using a CDI development model. With Reactive Messaging, you can process and produce messages transiting on various message-oriented middleware, such as AMQP, Apache Kafka, MQTT and so on.
For example, you can process transiting data as follows:
@ApplicationScoped
public class MyProcessingBean {
@Incoming("incoming-channel")
@Outgoing("outgoing-channel")
public String process(String data) {
return data.toUpperCase();
}
}
Reactive Messaging methods are annotated with @Incoming and/or @Outgoing indicating from which channel the consumed data comes from and to which channel the processed data must be sent. The process method, from the previous code snippet, is called for every item transiting on the incoming-channel channel and the outcome is written to the outgoing-channel channel. A channel is a logical name that can be mapped to a remote queue, topic or addresses. For example, in the previous example, we can configure Reactive Messaging to associate the channel incoming-channel to a Kafka topic and the channel outgoing-channel to an AMQP address.
Where is reactive?
The code shown above does not look reactive. Behind the hood, Reactive Messaging builds Reactive Streams and enforces the back-pressure protocol. So, data is only ingested when your application is able to consume it (which may depend on the state of the outgoing destination).
In addition, while you can process the data item by item (as in the previous example), you can also express the processing using a stream-based logic:
@ApplicationScoped
public class MyProcessingBean {
@Incoming("incoming-channel")
@Outgoing("outgoing-channel")
public PublisherBuilder<String> process(PublisherBuilder<String> stream) {
return stream.map(String::toUpperCase).flatMap(...);
}
}
This example uses PublisherBuilder (from MicroProfile Reactive Streams Operators 1.0), but Reactive Messaging also supports raw Reactive Streams types namely: Publisher, Subscriber, and `Processor`. So you can use popular Reactive Programming libraries such as RX Java 2 (and 3) or Reactor.
Connectors
In order to support different message sources and sinks, Reactive Messaging defines the concept of connectors. A Connector is a plugin managing a specific protocol. For instance, you would be able to find Apache Kafka connectors, AMQP connectors, MQTT connectors, or even connectors not associated with a message-oriented protocol such as HTTP connectors.
The connector can be implemented regardless of the implementation of Reactive Messaging. Connectors are then associated with channels and are responsible for retrieving and dispatching the messages.
Message, Payload & Acknowledgement…
The previous examples manipulate payloads, i.e. the body of a Message. A Message abstracts the underlying message protocol. Each message-oriented middleware has its own set of characteristics, so the Message interface has been kept minimal allowing each connector to provide implementation containing the metadata related to the protocol. For instance, an implementation of Message for Kafka would provide access to the topic, partition and other Kafka metadata.
Most protocols require some sort of acknowledgment. Reactive Messaging supports acknowledgment using the @Acknowledgement annotation and users can decide to acknowledged message explicitly or indicate to the Reactive Messaging when the incoming message must be acknowledged.
Maven Coordinates
Available Implementations
You can check for implementations of Reactive Messaging on the MicroProfile implementation page.
Further information
For more information about MicroProfile Reactive Messaging 1.0, please visit its release GitHub page.
