everythingpossible - Fotolia
Choose an event-processing architecture for an application
Sift through the state control methods that exist for event-driven applications and see which architecture type is the best fit.
As industries move IT closer to the people and business activities that these technologies serve, the chances increase that applications have to recognize and deal with events. An event-processing architecture requires multiple decisions about state control.
Event processing depends on the activity the application supports and the overall IT goals of the organization. Therefore, architects must prioritize a mission context to event processing in distributed architectures.
Architects should determine whether the application is directly event-driven, or if a set of steps that compose an online activity acts as events to trigger processes. They can then design the state control method appropriate to the business activity. Learn how event-driven applications work, then dive into the state control models for stored-state and complex event-processing designs.
Types of event-driven applications
Event-driven applications fall into two primary categories. In both, an Event is a simple signal of conditions or a change in conditions.
The first is a true event application, where external conditions signal for application attention by a set of sensors or other means. Many industrial event-driven systems and IoT applications fit into this category.
The second type of event-driven application is one designed with the decomposed transaction model, where an online activity -- usually a multistep process transaction -- is broken down into steps that are then processed as events. Many online social networks act this way.
Even in IoT applications, events usually need context, based on the state of the system. For example, an application raises and lowers a traffic gate. A signal that the gate is coming down either indicates successful event processing in response to a request to lower it, or a major fault if the request was to raise it. An event requires the application's overall current state information to be correctly processed. Event processing is often called state/event processing for this reason.
State control models
To define an event-processing architecture, first decide how to control state. State control can occur in the form of an imposed or interpreted state model.
In an imposed state model, the application derives the state of the system based on the progression of presented events. This model suits an architecture with stored state.
For an interpreted state model, the system infers state by correlating a series of events, often from different sources and occurring over a period of time. This model works with complex event-processing application architectures.
Stored-state control approaches
Stored-state event-processing architectures have three possible approaches: source-defined state, back-end state control with a database and state orchestration.
A source-defined state technique ensures the current state of the system is communicated with the event. This approach is often the easiest, because the source is closest to the physical system generating the events and the place where state is easiest to determine. The application architect should decompose a transaction into separate events.
The browser and web server -- or the app in use -- maintain an indicator for where it is in the multistep dialog, and this indicator is passed to subsequent processes. Source-defined state is risky if the state changes later in the transaction process, because a mechanism must communicate that change back to the source to synchronize the state.
For back-end state control, the application's current state is stored in a database for reference by any process, avoiding the risks of state change. Any process can read and write information in a back-end database, so a state change can be made anywhere and reflected everywhere. The risk lies in collision when reading and writing the back-end database.
With back-end state control, architects must allow only one process to write state changes, which means next-state determination should link with the event table processing and not with the individual processes. This is actually a best practice for all state control implementations.
A traditional event table process could be expressed as, "If Event occurs in State, run Process Set X and set Next State to Y." The state-event combination always sets the successor's state, and only one process -- that which looks up the event in the event table -- sets the state. The alternative to this single-process approach is to apply write collision protection to the back-end database updates, so two processes cannot write the state at the same time.
For state orchestration, the application relies on an external system to maintain state and select processes to run in response to the state-event combination. The single process, as seen in the back-end state control model, is outside the application. Orchestrated applications, using products such as AWS Step Functions or the Knative open source platform originating from Google, let the package decode the state-event combination and run the appropriate functions.
How complex event processing differs
While, in many cases, complex event-processing applications use state control approaches that overlap with those of stored-state systems, this architecture has distinct differences, too.
Generally, complex event processing presumes so many different possible external states exist for a system that it is not practical to track state explicitly through a progression of events. The system is often made up of a large number of somewhat autonomous subsystems, each of which might have its own state-event progression. When architects cannot model the system, they instead must interpret it by directly analyzing the sequence and timing of events.
The most complicated issue in event processing is perhaps that everything is event-linked, yet many activities are easily framed as sequences of events, as well. Development planners should look at their applications carefully to make the best choice.
