Reactive Streams (http://www.reactive-streams.org) is an initiative to provide a standard for asynchronous stream processing with non-blocking backpressure.
The non-blocking back pressure is a mechanism to deal with deficiencies of both pull and push semantics in the streaming environment. It is better explained by an example.
Imagine a building site with a foreman responsible for timely delivery of building materials among other duties. The site can only accommodate as much as 100 tons of materials. The foreman can order materials from another company but the orders are taken by one of the truck drivers as soon as one is in the company's office and not bringing materials to the customer.
The pull behavior for the foreman would be to call a contractor and wait until a truck driver is in the office and answers the call (blocking pull) or make calls periodically with the hope that this time somebody will pick up the phone (polling). In our case, the foreman sends a voice message to the contractor asking for 100 tons of materials and returns to his daily work instead. This is a non-blocking pull.
The contractor accepts the order as soon as they have the capacity to do so. They are about to send a couple of trucks with the capacity of 32 tons each but realize they cannot send more than 100 tons because the building site won't be able to receive such volume. Therefore, only three trucks and 96 tons of materials are sent.
After 30 tons of materials are consumed, the foreman realizes that they can order more from the contractor to avoid the building site becoming idle later if the rest of materials are quickly consumed. They order another 30 tons. But the contractor remembers that there are still another 4 tons remaining from the previous order so it is safe to send another full truck with 32 tons which can fit in the single truck. We reflect the fact that some demand in the first request was satisfied later by consecutive delivery and saying that requests are additive.
And this is basically how the backpressure concept of Reactive Streams works. It is arguable that in reality the approach would be better reflected by the name forward ease but probably this name wouldn't take off as back-pressure did.
The Reactive Stream specification strives to define a low-level API which can be implemented by different libraries in order to achieve interoperability between implementation. The standard defines the API and the Technology Compatibility Kit (TCK) which is a standard test suite for the API implementations.
The API contains the following components:
- Publisher
- Subscriber
- Subscription
- Processor
The Publisher represents the source, the Subscriber relates to the consumer, the Processor is a processing stage of the stream, and the Subscription is a representation of the back-pressure.
All of the methods defined in the API return void which means they are intended to be executed without the caller waiting for the result, hence the asynchronous stream processing in the definition of the Reactive Streams standard.
Reactive Streams is a library standard and defines how libraries are expected to communicate with each other in order to be able to interoperate. It is expected that libraries will offer different, higher-level APIs to the user, likely reflecting some aspects of the implementation details.
Akka Streams is one of such libraries built using Akka actors as the underlying technology. It implements the Reactive Streams standard and has a rich, high-level API which allows you to describe streams using high-level DSL and also exhibits the underlying Akka machinery.