官术网_书友最值得收藏!

Reactive Streams and Reactive Streams Specifications

The official document for Reactive Streams (http://www.reactive-streams.org/) says that—Reactive Streams is an initiative to provide a standard for asynchronous stream processing with non-blocking back pressure. This encompasses efforts aimed at runtime environments (JVM and JavaScript) as well as network protocols.

It started as an initiative between a group of companies in 2013. In April 2015, 1.0 of the specification was released and there were a number of implementations (such as Akka Streams and Vert.x) available at the same time. The specification was initiated with a target to get it included in the official Java standard library and in 2017, with the release of JDK9, it made it's way into it officially. As with any specification, the ultimate aim is to have a number of implementations conforming to the specification, and over time, the specification evolves. The specification consists of some core interfaces, some rules around these, and a Technology Compatibility Kit (TCK).

TCK is a suite of tests that will be executed to check the correctness/compliance of a Java Specification Request (JSR) implementation. In Java Community Process (JCP), TCK is one of the three required components for ratifying a JSR. The other two are JSR specification and JSR reference implementation. The TCK for the Java platform is called Java Compatibility Kit (JCK).

Being a specification, it enables any implementation respecting the specification to cooperate and interoperate with each other. For example, an implementation written in Akka can talk to the Vert.x implementation over the Reactive Streams protocol without any trouble. Adoption is growing and, as we speak, more implementations that conform to the specifications written in different languages are being released:

Figure 3: Reactive Streams Specification/API

The preceding figure clearly shows the Reactive Streams Specification. Some of the important specification rules are as follows:

  • The calls from Publisher to Subscriber and Subscriber to Publisher shouldn't be concurrent in nature.
  • The Subscriber can perform its job synchronously or asynchronously but always has to be non-blocking in nature.
  • From Publisher to Subscriber there should be an upper bound defined. After that defined bound, buffer overflows occur and could result in errors.
  • Apart from NullPointerException (NPE), no other exception can be raised. In the case of NPE, Publisher calls the onError method and Subscriber cancels the Subscription.

In the preceding definition of Reactive Streams, there are some very important terms, namely non-blocking and backpressure, which we'll explore a bit more to understand the core concepts of Reactive Streams.

主站蜘蛛池模板: 南川市| 瑞金市| 广州市| 花莲市| 德江县| 册亨县| 乐东| 保亭| 崇文区| 赤水市| 泽普县| 栾川县| 高州市| 山东省| 嵊泗县| 涟源市| 民乐县| 阳谷县| 缙云县| 甘洛县| 九龙县| 临湘市| 土默特左旗| 菏泽市| 岳池县| 堆龙德庆县| 秭归县| 云林县| 鄂州市| 泸州市| 沁阳市| 安多县| 盐亭县| 平果县| 阿城市| 昭苏县| 榆中县| 崇文区| 龙口市| 竹北市| 兴化市|