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

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.

主站蜘蛛池模板: 泰和县| 长武县| 沅江市| 凤庆县| 东海县| 松桃| 五峰| 蒲江县| 吉林省| 山东| 丰宁| 北流市| 通化县| 赤水市| 郸城县| 尼木县| 重庆市| 红安县| 宾川县| 阜南县| 分宜县| 广宗县| 革吉县| 陆河县| 青州市| 运城市| 靖边县| 资溪县| 景东| 石景山区| 蓬莱市| 大同县| 揭西县| 云霄县| 芦溪县| 木里| 仙居县| 文登市| 安远县| 黔江区| 泉州市|