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

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.

主站蜘蛛池模板: 达拉特旗| 阳高县| 远安县| 上杭县| 施秉县| 沈阳市| 宁德市| 崇仁县| 陆川县| 泸西县| 阿勒泰市| 梨树县| 宁津县| 美姑县| 墨竹工卡县| 宜春市| 浙江省| 铜陵市| 方山县| 新宾| 汉川市| 岳阳市| 寻甸| 永春县| 铁岭市| 江油市| 岳阳市| 运城市| 绿春县| 三门县| 临洮县| 山东| 江孜县| 宜黄县| 兰州市| 上蔡县| 兴隆县| 忻城县| 灌南县| 曲松县| 哈尔滨市|