Reactive is getting more and more popular. I decided to check it out, started to do some research. A thought came into my mind – is Reactive related to EDA ? If you check Reactive Manifesto then quick answer would be yes, it is. But it is more complicated than than.
What is Reactive Programming ? According to the manifesto it is a way of building systems so that they have certain characteristics:
- responsiveness – they respond in timely manner
- resilience – they are fault tolerant and highly available
- elastic – I must cite Manifesto here 🙂 “The system stays responsive under varying workload.” You’ll see why
- message driven – reactive systems use asynchronous messages to propagate information and achieve loose coupling
Some points in the manifesto are more detailed, some less – but it is a manifesto, not a tech spec. So don’t expect too much. Manifesto tells about an approach to design and development of systems though. But it is not an architecture, nor a design pattern. Maybe this Manifesto level of detail is the reason that most of the articles or presentations I came across was about Reactive approach to programming and did not touch architecture design.
Important fact about Reactive Manifesto is that it sets goals but only gives some advice in case of resilience and message orientation. I can’t help to thing about it as a… Manifesto… 🙂 I’ll get back to Reactive in a minute.
EDA (Event Driven Architecture) is well known, proven architecture used to decouple system’s modules, provide better scalability. EDA architecture is achieved when components communicate using events that are carried in messages. Important factor is that event generator, that is component that emits event, does not know anything about consumers. EDA is extremely loosely coupled.
Most common way to propagate events is to use messaging system, but EDA can be done in various ways depending on the system being developed:
- Single instance (JVM in case of Java) processing can be implemented using CDI events, simple observer pattern implementation, asynchronous invocations.
- Event processing with several application instances – here we would probably use some messaging technology (MOM), but we are not limited to this:
- remote method invocations would also do
- one-way soap web services would do
- restful web services with asynchronous invocations
Using messaging technology like JMS (HornetQ, ActiveMQ, SonicMQ among others) or AMQP (RabbitMQ, Apache Qpid) will give us a few important benefits:
- Reliability: both JMS and AMQP provide a few message production and consumption modes. JMS provides persistent and non-persistent delivery, durable subscriptions (subscribers will receive messages even if the weren’t listening at the time of publication), a few ackowledgement modes (allowing or not duplicate messages, exactly once guarantee is available with JTA transacted session and XA may be required).
- Great scalability: messages can be queued and processed without being overwhelmed even in case of peak of messages a few time greater than normal processing. Message processing components can be scaled independently from other – e.g. number of threads for a given MDB component can be increased, allowing events to be consumed faster.
- Fault tolerance: both JMS and AMQP can survive message broker crashes
EDA can have one of a few implementation types:
- simple event processing – like in case of observer pattern implementation, some event is generated by event generator and consumed by observers
- streaming event processing – here events are routed and processed and can be the source of other events
- complex event processing – in this case not only current event is analyzed but also past events are taken into analysis scope, with some sophisticated event stream queries (like in Oracle CEP).
So as we can see EDA can be:
- resilient – if done using appropriate tools that will guranteee delivery, fault tollerance, high availability
- elastic – this is why I wanted to cite manifesto. If you do EDA using messaging system than you get elasticity. System can and will cope with peaks in events, the messages will get queued possibly spread across cluster of messagign system’s nodes. Even more – using SEDA architecture we can throtle and dynamically control throughput
- using messaging – we can use messaging and most of the time we do
- responsive – due to asynchronous nature of EDA system will be responsive. It will require a different style of programming though.
As you can see there are similarities between EDA and Reactive. But as I mentioned before most of the time Reactive is about how to implement details of code and does not touch architecture level. On the other hand EDA is all about architecture – it tells about components and way to connect them so they can interact.
Reactive is more about how to structure your code, get rid of some flow statements, replace pull / imperative style with push streams. Like Introduction to Reactive Programming says Reactive programming is programming with asynchronous data streams. Another nice introduction is Jonathan Worthington presentation. We must differentiate between Reactive Programming and Reactive approach to architecture. The second one is less common.
This lets me think that EDA can be Reactive and most of the time Reactive is just more about coding your solution using streams, observables or promises.
And btw. doing EDA in simple or streaming strategy is extremely easy in Java 😉
Have a nice day !