Information Technology Reference
In-Depth Information
Event-driven architecture and complex event
processing
Event-driven architecture ( EDA ) allows developers to construct highly decoupled sys-
tems composed of single function components that interact through events and manage
complex situations by aggregation of more components in the architecture. It is another
way of building scalable applications that are different from SOA, but both methodologies
complement each other depending on the desired result and the path of the growth of our
systems.
The components proposed by EDA are divided in four different elements: event producers,
event processing agents, event consumers, and event channels. Event producers are in
charge of generating events that will be consumed, composed, aggregated, and analyzed by
event processing agents ( EPAs ). EPAs can also generate high-level events based on com-
position or aggregations of other events. The resulting object is called a complex event.
Event consumers will usually consume these generated events, but they can also consume
the ones generated by the producers. Event channels merely represent communication
structures to send data between producers, consumers, and EPAs.
To relate it to our BPM systems, we could consider the process engine, an event producer,
which will produce a new event every time a process is created or completed. An event
consumer in this scenario would be a process-monitoring dashboard that handles warnings
when the process engine is performing in a non-sustainable way. One or more event-pro-
cessing agents would be in charge of monitoring when specific scenarios that could indic-
ate such behavior present themselves. One of such cases could be the process creation to
completion ratio given by all the events produced in the last few hours. When it exceeds a
particular threshold, we should send alerts to the dashboard.
It is important to notice the decoupled nature of event-driven architectures. Event produ-
cers, consumers, and processing agents don't need to know about the existence of each oth-
er. They all work and are able to exist separately, without any other dependency than the
possibly shared event definitions.
The Drools rule engine allows you to create rules that perform complex event processing,
therefore producing event-processing agents. Since jBPM6 is seamlessly integrated with
Drools, if we chose both technologies to construct our EDA, the event channel could
simply be the internal memory of KieSession (called the working memory).
Search WWH ::




Custom Search