Reactive programming is a broad term—that's why Reactive Streams comes to standardize the way different implementations should communicate between them.
- [Manuel] Hi, welcome to the last video of this section, Reactive Streams. In the previous video, we saw the different entities involved in the reactive programming, as well as the four principles behind it. At the end of the video, we talked about how Java can support reactive programming before Java 9. We also introduced Reactive Streams, and that's going to be the topic of this video. We'll see what Reactive Streams is, beta scope, and API. Let's go. Reactive Streams is an initiative to provide a standard or asynchronous stream processing with non-blocking back pressure.
It also has to deal with back pressure, as we know from previous experience. The end goal is to allow the creation of different implementations which will be able to interoperate smoothly. One of the benefits is that different implementations use the same standard, so you will be able to interchange them without any problems. The scope is finding a minimal set of interfaces, methods, and protocols that will describe the necessary operations and entities to achieve the goal. End user DSLs or protocol binding APIs have been left out of this code to encourage and enable different implementations that potentially use different programming languages to stay as true as possible to the idioms of their platform.
Back pressure is an integral part of this model in order to allow the queues which mediates between threats to be bounded. There are different groups working on different parts of Reactive Streams. Let's see them. The basic semantics define how the transmission of data is regulated through back pressure. How elements are transmitted, their representations during transfer, or how back pressure is signaled is not part of this specification. JVM interfaces already fills this specification.
Network protocols defines network protocols for passive and reactive streams, (mumbling) transport media that involves the realization and utilization of the data elements. The samples of such are TCP, UTP and web circuits. Rather to be interested in the JVM interfaces, which is applicable to Java, let's take a look at that. How are the different entities we learned in the previous video mapped to Reactive Streams? The source of information is called publisher, and it's of type T.
The consumer is called subscriber, of type T as well. The subscription remains the same, and there is a new entity I didn't mention before. A processor acts as both source of information and consumer. It has the ability of receiving data as well as sending it. Depending on the implementation, the data that is received or sent can be of different types. Reactive Streams API are a set of interfaces that define the behavior of each entity in Java.
What methods are involved? As you can see, the publisher has to define the methods to subscribe, which we say is a subscriber as a parameter. What methods are available in a subscriber? onNext, onError, and onComplete. Those methods are going to be called by the publisher whenever it wants to send a message. Do you remember the different types of messages? onNext for a value, onError to signal that an error occurred and onComplete to signal to tell that the publisher has unlimited items.
As you can see, there is another method that a subscriber has to implement. The method onSubscribe receives a subscription as parameter. A subscription is going to be established by the publisher and it's going to manage how the flow of information is going to happen. Here is where back pressure comes (mumbling). Let's take a look at the subscription interface. We can guess that cancel is going to be called when any of them want to cancel the flow. What about request? This is how a subscriber signals the amount for work.
When a subscriber signals the month by invoking request one, that's effectively a pull. When a subscriber signals the month by requesting more elements, then the publisher is ready to emit for a sample request 100. That changes the flow to push. There are some rules they have to consider on implement. Most of them are common sense. These are just some examples I took from the official documentation. If a publisher fails, it must signal an onError.
If a publisher terminates successfully, a finite stream, it must signal an onComplete. We already knew this. If a subscription is canceled, its subscriber must eventually stop being signaled. Publisher.subscribe may be called as many times as we want but must be with a different subscriber each time. This is quite important. The same object cannot subscribe tries to a publisher. A subscribr must signal demand via subscription.request to receive onNext signals.
As we talked about before, if you don't request, you won't receive any information. This is the end of the video. Now, you know what is in both in Reactive Streams, and the nomenclature for reactive programming in Java. Let's take a look back and see what we've learned. We started introducing reactive programming as a new paradigm that works with data flows. It seemed a bit blurry at the beginning, but when we introduced the analogy, it was much better. From the four principles, we could understand better all the benefits it can bring to our applications.
All the elements involved in reactive programming has been standardized with Reactive Streams. (mumbling) We have a specification and a standard with which we can call the different entities by name. In the next section, we are going to introduce some new Java 9 features, and we know how it supports reactive programming natively. You might have heard of functional programming when reading about reactive programming.
What are the differences? What is functional programming? How are they related? That's something we'll learn in the next section. Hope you enjoyed this one, and I will see you there.
This course was created and produced by Packt Publishing. We are honored to host this training in our library.
- What is reactive programming?
- Java 9 reactive features
- Creating and observing sources with RxJava
- Unit testing
- Akka streams in a reactive environment
- Building a sample reactive application