Reactive Streams es una iniciativa para proporcionar un estándar para el procesamiento de flujos asincrónicos con contrapresión sin bloqueo . [1] [2]
Reactive Streams comenzó como una iniciativa a fines de 2013 entre ingenieros de Netflix , Pivotal y Lightbend . Algunas de las primeras discusiones comenzaron en 2013 entre los equipos de Play y Akka en Lightbend. [3] [4] Lightbend es uno de los principales contribuyentes de Reactive Streams. [5] Otros contribuyentes incluyen a Red Hat , Oracle , Twitter y spray.io. [6]
El objetivo principal de Reactive Streams es controlar el intercambio de datos de flujo a través de un límite asincrónico (como pasar elementos a otro subproceso o grupo de subprocesos ) y, al mismo tiempo, garantizar que el lado receptor no se vea obligado a almacenar en búfer cantidades arbitrarias de datos. En otras palabras, la contrapresión es una parte integral de este modelo para permitir que las colas que median entre subprocesos estén delimitadas .
La intención de la especificación es permitir la creación de muchas implementaciones conformes , que en virtud de cumplir con las reglas podrán interoperar sin problemas, preservando los beneficios y características mencionados en todo el gráfico de procesamiento de una aplicación de flujo. Junto con la especificación se desarrolló un Kit de compatibilidad de tecnología [7] disponible gratuitamente que permite a los implementadores de la especificación verificar si cubrieron todas las reglas y requisitos, incluidas las verificaciones de posibles condiciones de carrera .
El alcance de Reactive Streams es un conjunto mínimo de interfaces , métodos y protocolos que describen las operaciones y entidades necesarias para lograr flujos asincrónicos de datos con contrapresión sin bloqueo. [2] Los DSL de usuario final o las API de enlace de protocolo se han dejado deliberadamente fuera del alcance para alentar y permitir diferentes implementaciones que potencialmente usan diferentes lenguajes de programación para mantenerse lo más fieles posible a los modismos de su plataforma.
La especificación se desarrolló con la intención de incluirla en el futuro en la biblioteca estándar oficial de Java, si se demuestra que es exitosa y es adoptada por suficientes bibliotecas y proveedores.
Doug Lea , líder de JSR 166 [8], propuso que Reactive Streams formara parte de Java 9 como una nueva clase de flujo [9] que incluiría las interfaces que Reactive Streams actualmente proporciona. [5] [10] Después de un exitoso lanzamiento de la versión 1.0 de Reactive Streams y una creciente adopción, la propuesta fue aceptada y Reactive Streams se incluyó en JDK9 a través de JEP -266. [10]
El 30 de abril de 2015 se publicó la versión 1.0.0 de Reactive Streams para JVM , [5] [6] [11] que incluye una API de Java , [12] una especificación textual , [13] un TCK y ejemplos de implementación. Viene con una multitud de implementaciones compatibles verificadas por el TCK para 1.0.0, enumeradas en orden alfabético: [11]
Otras implementaciones incluyen Cassandra , [23] Elasticsearch , [24] Apache Kafka , [25] Parallel Universe Quasar, [26] Play Framework , [27] Armeria. [28]
Se anuncia que Spring 5 se basará en Reactor Core compatible con Reactive Streams. [29]
Amazon anunció que su SDK de Amazon Web Services admitirá Reactive Streams para proporcionar capacidades de transmisión en sus bibliotecas de clientes en la versión 2.0. [30]
Reactive Streams 1.0.1 se lanzó el 9 de agosto de 2017 e incluyó varias mejoras en la precisión de las especificaciones, mejoras en TCK y otras aclaraciones. La especificación, así como las interfaces, siguieron siendo totalmente compatibles con la versión 1.0.0, pero su objetivo era simplificar la adopción para futuros implementadores y alinearse con algunos requisitos adicionales establecidos por OpenJDK . [31]
Este artículo incorpora texto de www.reactive-streams.org , que se publica bajo una licencia de dominio público CC0 1.0 Universal (CC0 1.0) .