Information Technology Reference
In-Depth Information
Usually, event producers send events to a series of event processing agents, which are
software components in charge of consuming one group or many groups of events as in-
puts and produce complex events as outputs. These event processing agents will connect
with each other depending on the type of events they consume or produce to form an
event processing network
.
The final outcome of this network is usually a final set of events, which are not needed to
infer any other events, but are to be directly used by other components. These components
that are waiting for specific events are called
event consumers
. They can be any compon-
ent interested in receiving a notification of a state—from an application to a dashboard to
a machine-state-based piece of hardware waiting for instructions.
One big advantage to these types of architecture is that event producers, consumers, and
processing agents don't need to know each other. This allows EDA-influenced applica-
tions to grow in a nonintrusive way, even along with other architectures (such as
service-
oriented architecture
) without breaking its structure, but rather enriching its functional-
ity.
The importance of these concepts in BPM relates to the fact that thanks to Intermediate
Catch and Throw events, business processes can also be consumers and producers of these
sorts of events. Considering that signaling can be done back and forth from rules to pro-
cesses, these concepts add a lot of value for inferring the state of the world and notifying
this to our processes. At the same time, process instances themselves could be treated as
events. All these possibilities will be explored in the next section when we will discuss
how CEP can be implemented with jBPM6 and Drools.
