Reactive Streams specifications

Let's try to understand in more detail, what the specifications for Reactive Streams are. It is dealing with the asynchronous processing of a stream. Let’s look at the specification available at https://github.com/reactive-streams/reactive-streams-jvm . It comprises the following two parts:

• API: This describes the specification.
• Technology Compatibility Kit (TCK): This is a criteria or standard test suite for compliance testing of implementations. In short, it will make sure the given implementation conforms to the declared specification. 

Taking a closer look at the API, we find that it is rather simple and comprises just four interfaces as follows:

• Publisher: This interface represents an entity that acts as a supplier of an unbounded number of sequenced events or elements. It will publish the elements as per the requirement of the subscriber.
• Subscriber: It represents a consumer of an event from a publisher. For that, it will subscribe to the publisher. 
• Subscription: This interface illustrates the process of subscribing or registering of a subscriber to a publisher. 

• Processor: It is a composition of both the publisher and subscriber. It represents a processing stage that implements the contract of both. 

Java 9 has started providing native support for Reactive Streams. The implementation of these interfaces is part of the Flow API in Java 9. Looking at the structure of JAR containing the Reactive Streams, we find the following structure:

This seems rather straightforward, and implementing a set of a few interfaces shouldn’t be a challenge for any developer in Java. Are we able to go to production with the implementation of these interfaces, and will it give us a stable system? Are we ready to get started with the reactive development? The answers are, not quite yet.

Passing the messages in an asynchronous way is the key area of focus for Reactive Streams. It ensures that it is not just the consumer that is protected from being overwhelmed by all the distributed systems. The Publisher is also safeguarded in case one or more subscribers is slow to process the messages. It primarily says that this is the way you should pass a message from thread A to thread B in a protected manner, to ensure both the publisher and the subscriber are protected.

Let’s dig further into the specifications, (we will come to the TCK a little later) and see how they correspond with the original statement of the Reactive Streams manifesto. Starting with the publisher, we see that the specifications also define a set of rules that must be adhered to by the implementer of the specifications.

The rules are defined for all the four interfaces: publisher, subscriber, subscription, and processor. It won’t be possible to go through all the rules here, and neither it is required, as the rules are available at: https://github.com/reactive-streams/reactive-streams-jvm/blob/v1.0.2/README.md .

However, in order to draw some relevance from the Reactive Streams manifesto, let’s look at some of the important rules. We will analyze one or two rules each from all four interfaces to help you understand how they are laid out. Do have a look at the glossary table before reading these rules and specifications.

You should have a look at the rest of the rules, as going through them will give you a good idea about how detailed the rules are. By the time you finish reading all the rules, you will have a very good grasp of what to expect from the implementation of Reactive Streams.