EDA and Rule Engine
I presented sometime ago an architecture overview and use case for deploying a Rule Engine inside an Event Driven Architecture. There are papers from analysts and other bloggers on that subject which are predicting that EDA is becoming a hot subject in the next few months. I want to share what I found interesting.
Event Driven Architecture is an asynchronous publish-and-subscribe communication pattern: Publisher applications send events to a mediation layer which is notifying the subscribers interested by the events. The publisher is completely unaware of the subscriber. Components are loosely coupled in the sense that they only share the semantic of the message. The simplest Java implementation is based on using JMS Topics as it is a natural API for pub-subscribe messaging.
The data carried on the message payload are events with business means. The goal to embrace EDA is to deliver real-time access to business data. This is not really an extension of SOA but a complement of it as publishers may call services on event detection. But it can be seen orthogonal to SOA, as SOA is using a traditional procedural pattern around synchronous controlled orchestration of services.
Some are saying SOA is dead, replaced by EDA. Well SOA is still a valid approach to design IT architecture. SOA is not dead, and EDA is a complement of it. One thing that I think make EDA very attractive is the flexibility to add new function/application without impacting existing ones.
By the way EDA is not new: One of the mainframe programming models was to have batch application waiting for the result of other batches to process their own work. It is very close to subscribers waiting for events coming from publishers. At least we can say EDA is the distributed version of the old mainframe programming approach.
As soon as current application in the IT are able to post events, you have the flexibility to add/ remove listeners to address a new business needs.
So why rule engine is a critical component within EDA? One deployment is to use a BRE to support the implementation of such listener. Instead of developing rigid application you use BRE to bring the agility inside the flexibility. The component can be seen as a decision agent. The second interest is in the implementation of the event processing that has to detect event, process it and take action.
We can see multiple levels to support this event processing depending of the characteristics of the architecture and the type of event processing we look at. I'm seeing at least three:
- Simple event processing: the subscriber focuses on processing a few types of event with specific static conditions, and initiating action such as creating a new event, or calling a service. This processing can be real time or not. We may not want to consider any time dimension in the event.
- Event stream processing: Events are ordered and arrived as a stream to the subscribers. The processing may involve time windows, count based window, leveraging time based pattern,... It is used to synthesize data in real time.
- Complex Event Processing: Detect complex patterns of events, consisting of events that are widely distributed in time and location of occurrence. It supports low latency, high throughput, complex event management with aggregation, join, stateful operators, event A followed by B and by C, and all the combinations of it.
The technologies to support each processing are different, and it is important to do not use one for the other, or we will generate frustration.
Event Driven Architecture is an asynchronous publish-and-subscribe communication pattern: Publisher applications send events to a mediation layer which is notifying the subscribers interested by the events. The publisher is completely unaware of the subscriber. Components are loosely coupled in the sense that they only share the semantic of the message. The simplest Java implementation is based on using JMS Topics as it is a natural API for pub-subscribe messaging.
The data carried on the message payload are events with business means. The goal to embrace EDA is to deliver real-time access to business data. This is not really an extension of SOA but a complement of it as publishers may call services on event detection. But it can be seen orthogonal to SOA, as SOA is using a traditional procedural pattern around synchronous controlled orchestration of services.
Some are saying SOA is dead, replaced by EDA. Well SOA is still a valid approach to design IT architecture. SOA is not dead, and EDA is a complement of it. One thing that I think make EDA very attractive is the flexibility to add new function/application without impacting existing ones.
By the way EDA is not new: One of the mainframe programming models was to have batch application waiting for the result of other batches to process their own work. It is very close to subscribers waiting for events coming from publishers. At least we can say EDA is the distributed version of the old mainframe programming approach.
As soon as current application in the IT are able to post events, you have the flexibility to add/ remove listeners to address a new business needs.
So why rule engine is a critical component within EDA? One deployment is to use a BRE to support the implementation of such listener. Instead of developing rigid application you use BRE to bring the agility inside the flexibility. The component can be seen as a decision agent. The second interest is in the implementation of the event processing that has to detect event, process it and take action.We can see multiple levels to support this event processing depending of the characteristics of the architecture and the type of event processing we look at. I'm seeing at least three:
- Simple event processing: the subscriber focuses on processing a few types of event with specific static conditions, and initiating action such as creating a new event, or calling a service. This processing can be real time or not. We may not want to consider any time dimension in the event.
- Event stream processing: Events are ordered and arrived as a stream to the subscribers. The processing may involve time windows, count based window, leveraging time based pattern,... It is used to synthesize data in real time.
- Complex Event Processing: Detect complex patterns of events, consisting of events that are widely distributed in time and location of occurrence. It supports low latency, high throughput, complex event management with aggregation, join, stateful operators, event A followed by B and by C, and all the combinations of it.
The technologies to support each processing are different, and it is important to do not use one for the other, or we will generate frustration.
Comments