Um dos principais problemas com todo ambiente Reativo é que é muito difícil entender o vocabulário com todos os termos e as diferentes interpretações possíveis, Peter Ledbrook afirma e explica que depois de participar de conversas e ler posts em blogs, e ainda não conseguir entender o que Reativo significa, decidiu investigar na esperança de compartilhar seu conhecimento com outros desenvolvedores.
Começando com o Manifesto Reativo, Ledbrook, que é um dos principais committers do Grails, considera que um sistema reativo é:
- Responsivo, significa que um sistema sempre deve responder em tempo hábil mantendo a latência baixa;
- Resiliente, significa que um sistema deve ser responsivo mesmo quando partes começam a falhar, mantendo o tempo de parada a um nível mínimo;
- Elástico, significa que se a carga de trabalho aumentar o sistema deve escalar para se manter responsivo, mas também com a diminuição da carga de trabalho deve escalar para baixo, utilizando os recursos com eficiência;
- Orientado a mensagem, enviando mensagens para partes diferentes do sistema, que segundo Ledbrook afirma é uma característica que define um sistema Reativo.
O próximo conceito que Ledbrook ataca são os Reactive Streams, descrevendo-os como uma série de elementos emitidos ao longo do tempo, e segundo ele o padrão de projeto Observer é um bom início para entender o conceito. O padrão consiste de uma fonte emitindo eventos e um ou mais observadores esperando por eventos. Para Ledbrook, Reativo é efetivamente o padrão Observer mais a capacidade da fonte do evento notificar sobre a conclusão, a habilidade de propagar erros e finalmente a habilidade para os ouvintes (receptores dos eventos) poderem falar com a fonte dos eventos.
Reactive Streams é uma especificação e uma implementação multi-plataforma comum é o ReactiveX. Outras duas implementações que Ledbrook menciona são o ProjectReactor e o Akka. Três conceitos importantes que guiaram a construção da API Reactive Streams são:
- Publisher, quem envia eventos e para o qual é possível se inscrever;
- Subscriber, quem recebe os eventos;
- Subscription, é a conexão entre um subscriber e um publisher. É a subscription que faz com que seja possível para um subscriber receber eventos de um publisher.
Ledbrook conclui observando que muito dos Reactive Streams são compostos de conceitos conhecidos, mas que escondem pelo menos alguma complexidade. Casos de uso são contextos com alto I/O ou que precisam processar muitos dados. Os streams do Java 8 são similares aos Reactive Streams, mas porém, limitados, não têm a possibilidade de sinalização dos ouvintes e não são realmente voltados para I/O como os Reactive Streams.