The no BS intro to event-driven architecture

Event-driven architecture (EDA) is a complimentary architecture to SOA. They work together because services can logically be configured to be triggered by events. In it's simplest form, EDA is just another architectural pattern; It's one that focuses on producing, detecting, consuming, and reacting to events.

This increases business agility; When implemented, services react to events transmitted from other loosely coupled services. This is more flexible than the alternative Publish and Subscribe architecture pattern.

Let's look at a simple example. Debbie is an Atlantic fisherman that catches a really nice Bluefin tuna. She immediately realizes this fish is worth far more than all the fish she's brought in over the last few trips. She hauls in her lines, heads for the shore, and radios her broker. She tells him the details of the fish and when she'll be back ashore. The broker calls the owner of a sushi restaurant in Tokyo with the details, negotiates a price, and makes another call to arrange express shipping.

Now picture Debbie, the broker, and the restaurant owner as services. The event is catching the Bluefin tuna, the communications protocols are radio (Debbie to the broker) or telephone (the broker to the restaurant owner and the shipper). The services have an arrangement to send details of an event to each other, and they all react to fulfil their individual tasks. In other words, each person knows who to inform and what information to send when reacting to an event.

Event flows can be broken down into four layers and three styles. The layers are the generator, channel, processor, and downstream activity. The styles are Simple event processing, Event Stream Processing, & Complex event processing. In a sophisticated EDA, these are typically
used together.


Obviously, this is just an introduction. If you want to learn more about EDA and how it works with SOA, you'll have to head over to Jack van Hoof's blog.