During the next few sections we will explore some of the basic principles and concepts commonly used in the creation of event-driven applications. These are the major "building blocks" for any solution that handles streaming event data.
What is an event and how is it defined? Many people and technical societies define an event in many different ways, but in the context of this book, an event is an object that has a change in its state immediately, or over a period of time.
For example, let's take an everyday object, a house front door.
The door's "properties" is that it is made of wood, it has hinges, perhaps separate wooden panels, screws to keep it together, a handle or knob, and it has a color, blue. When the door opens, then it has changed its "state" and effectively an event has happened.
The door can have many event states: open, closed, opening, closing, and so on. It can even have a "non-event" state, for example, if somebody turns the door handle or knob, but the door does not open in 10 seconds, then this could be a situation when although the door should have opened it didn't in a certain time period, so this is an event that did not happen, but probably should have happened, based on the fact that the door handle did turn.
Anticipation or expecting some event to happen in a certain period of time is something that your brain can easily process but in computing terms it is something that is, on most occasions, difficult to program.
Generated by hardware sensor devices, distributed anywhere from the "Internet of things", computer applications, database triggers, or generated from any of hundreds of different sources, events arrive for processing in an event stream or streams. Event streams can have events that are continuously flowing at high volumes or arrive in sporadic intervals, but the events never end and are always time ordered, just like in the real world.
A market data feed in the financial services world, the GPS signals from your mobile telecommunications device and business events from a Service Orientated Architecture Application (SOA) are all examples of event streams.
In general terms, event streams can be simple, streaming, or high volume.
Traditional computing systems based on database or Java Enterprise Edition (JEE) infrastructures are not designed to effectively handle this type of continuously flowing event data, as the reading and writing demands to disk, or "send/reply" implementation paradigms involve increased and detrimental processing latencies or delays. So there is a need to evolve a new approach to handing these requirements and with an event-driven infrastructure it can "impose" itself "over" the event streams in memory using a defined window of time or number of events count.
The event types that flow "along" the event stream defines the properties associated with the event. Event type definitions can range in their levels of complexity, but in most applications can be declaratively defined with a simple notation.
Using the door event example discussed earlier in this chapter, a house event stream that is continuously monitoring things that are related to all doors in a building could have a specific door event type defined with a collection of property names and their associated values.
So now we have an event, probably thousands or millions of them that need to be effectively handled and processed. As these events continuously flow they need to be identified, have a response very quickly and are often "transported" only in memory, so using a database is not a recommended design option.
For this purpose, many Complex Event Processing platforms provide the Event Processing Network (EPN) (otherwise known as a Directed Flow Graph ).
Provided as the best approach for handling streaming event data, the EPN can be generally designed and modeled using various tooling offerings. The EPN is designed as a loosely-coupled collection of event nodes, each performing a unique action on the events as they pass through the network. Each event node subscribes to one or many other event nodes with the state (conditions/properties) held in the event definition itself.
This application model design approach provides the ability for extreme event processing in low latencies with a simple way of extending and/or changing the event handing as real-time situations happen. It also facilitates a mechanism (foreign stages) to enable new event nodes to be introduced into the solution either dynamically or statically during the actual deployment life cycle of the executing application.
A well-structured EPN will probably perform beyond expectations and set the foundation for easy extensibility, integration, and solution maintenance.
While many kinds of event nodes are evolving, most can be one or more of the following types:
Event adapters provide the connectivity to event sources and sinks, and are relatively simple code implementations that normalize the incoming or outgoing data stream and convert this into event types that are processed downstream or upstream in the EPN. For example, an inbound event adapter can provide the connection to a TCP/IP socket and an outbound event adapter can provide an interface to a visual user interface.
Event channels are the conduits that effectively handle the routing of events, these event nodes not only play an important role in ensuring that the various events are analyzed efficiently, but they also can have properties that can powerfully effect the performance of the application, such as controlling the amount of memory used for the events and the number of processing threads.
Event cache and event POJO Bean nodes provide the in-memory persistence of long-term reference data and the solution-specific business logic written as a "Plain Old Java Object". These event nodes ensure that information needed for long periods of time can be managed, interrogated, and safely held in computing memory, and that any type of additional processing logic can be implemented. POJOs can sometimes act as event sources or event sinks. An example of using Event POJO Beans would be to include and enhance old legacy code, which has been mature and stable for a long period of time in other coded solutions, and would continue to provide additional value in the new Event Processing Network. One caveat when using this type of "old" code is to clearly understand the additional "cost", in terms of memory usage and processing load that will be incurred and how this will impact the overall performance of the new solution and this should be considered during the design phase.
Event processors are the meta-containers for the powerful event analysis needed for any type of solution. There can be one or many event processor nodes in an application and they store the event processing language, which can be rules or queries that statically executes continuously on the flow of arriving events. The event processors are the core engine service of a Complex Event Processing solution, and the capabilities of such engines in most cases, dictate how successful the technology will be in delivering the desired business solution.
