- Hands-On Spring Security 5 for Reactive Applications
- Tomcy John
- 419字
- 2021-07-23 18:59:11
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:
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.
- 網(wǎng)絡安全與管理
- API安全實戰(zhàn)
- 走進新安全:讀懂網(wǎng)絡安全威脅、技術與新思想
- Python Penetration Testing Cookbook
- Falco云原生安全:Falco原理、實踐與擴展
- Advanced Penetration Testing for Highly:Secured Environments(Second Edition)
- 無線傳感器網(wǎng)絡安全與加權復雜網(wǎng)絡抗毀性建模分析
- 黑客攻防實戰(zhàn)從入門到精通
- 信息技術基礎:提高篇·實驗與習題
- Learning Pentesting for Android Devices
- 華為Anti-DDoS技術漫談
- 計算機網(wǎng)絡安全實驗指導
- Web代碼安全漏洞深度剖析
- Kali Linux無線網(wǎng)絡滲透測試詳解
- 從實踐中學習Nmap滲透測試