Event-driven architecture
From Wikipedia, the free encyclopedia
Event-driven architecture (EDA) is a software architecture pattern promoting the production, detection, consumption of, and reaction to events.
An event can be defined as "a significant change in state"[1]. For example, when a consumer purchases a car, the car's state changes from "for sale" to "sold". A car dealer's system architecture may treat this state change as an event to be produced, published, detected and consumed by various applications within the architecture.
This architectural pattern may be applied by the design and implementation of applications and systems which transmit events among loosely coupled software components and services. An event-driven system typically consists of event emitters (or agents) and event consumers (or sinks). Sinks have the responsibility of applying a reaction as soon as an event is presented. The reaction might or might not be completely provided by the sink itself. For instance, the sink might just have the responsibility to filter, transform and forward the event to another component or it might provide a self contained reaction to such event. The first category of sinks can be based upon traditional components such as message oriented middleware while the second category of sinks (self contained online reaction) might require a more appropriate transactional executive framework.
Building applications and systems around an event-driven architecture allows these applications and systems to be constructed in a manner that facilitates more responsiveness, because event-driven systems are, by design, more normalized to unpredictable and asynchronous environments[2].
Event-driven architecture can complement service-oriented architecture (SOA) because services can be activated by triggers fired on incoming events[2][3]. This paradigm is particularly useful whenever the sink does not provide any self-contained executive.
Computing machinery and sensing devices (like sensors, actuators, controllers) can detect state changes of objects or conditions and create events which can then be processed by a service or system. Event triggers are conditions that result in the creation of an event[citation needed].
Contents |
[edit] Event structure
An event can be made of two parts, the event header and the event body. The event header might include information such as event name, timestamp for the event, and type of event. The event body is the part that describes the fact that has happened in reality. An event body must not be confused with the pattern or the logic that can be applied in reaction to the event itself.
[edit] Event flow layers
An event triggered architecture is built on four logical layers. It starts with the sensing of a fact, its technical representation in the form of an event and ends with a non-empty set of reactions to that event.[4]
[edit] Event generator
The first logical layer is the event generator, which senses a fact and represents the fact into an event. Since a fact can be almost anything that can be sensed, so can an event generator. As an example, an event generator could be an email client, an E-commerce system or some type of sensor. Converting the different data collected from the sensors to one standardized data form that can be evaluated is a significant problem in the design and implementation of this layer.[4] However, considering that an event is a strongly declarative frame, any transformational operations can be easily applied, thus eliminating the need for a high level of standardization.
[edit] Event channel
An event channel is a mechanism whereby the information from an event generator is transferred to the event engine[4] or sink. This could be a TCP/IP connection or any type of input file (flat, XML format, e-mail, etc). Several event channels can be opened at the same time. Usually, because the event processing engine has to process them in near real time, the event channels will be read asynchronously. The events are stored in a queue, waiting to be processed later by the event processing engine.
[edit] Event processing engine
The event processing engine is where the event is identified, and the appropriate reaction is selected and executed. This can also lead to a number of assertions being produced. I.e., if the event that comes into the event processing engine is a “product ID low in stock”, this may trigger reactions such as, “Order product ID” and “Notify personnel”.[4]
[edit] Downstream event-driven activity
This is where the consequences of the event are shown. This can be done in many different ways and forms; e.g., an email is sent to someone and an application may display some kind of warning on the screen.[4]. Depending on the level of automation provided by the sink (event processing engine) the downstream activity might not be required.
[edit] Event processing styles
There are three general styles of event processing: simple, stream, and complex. The three styles are often used together in a mature event-driven architecture[4].
[edit] Simple event processing
Simple event processing concerns events that are directly related to specific, measurable changes of condition. In simple event processing, a notable event happens which initiates downstream action(s). Simple event processing is commonly used to drive the real-time flow of work, thereby reducing lag time and cost[4].
For example, simple events can be created by a sensor detecting changes in tire pressures or ambient temperature.
[edit] Event Stream Processing
In Event Stream Processing (ESP), both ordinary and notable events happen. Ordinary events (orders, RFID transmissions) are screened for notability and streamed to information subscribers. Stream event processing is commonly used to drive the real-time flow of information in and around the enterprise, which enables in-time decision making[4].
[edit] Complex event processing
Complex event processing (CEP) allows patterns of simple and ordinary events to be considered to infer that a complex event has occurred. Complex event processing evaluates a confluence of events and then takes action. The events (notable or ordinary) may cross event types and occur over a long period of time. The event correlation may be causal, temporal, or spatial. CEP requires the employment of sophisticated event interpreters, event pattern definition and matching, and correlation techniques. CEP is commonly used to detect and respond to business anomalies, threats, and opportunities[4].
[edit] Extreme loose coupling and well distributed
An event driven architecture is extremely loose coupled and well distributed. The great distribution of this architecture exists because an event can be almost anything and exist almost anywhere. The architecture is extremely loose coupled because the event itself doesn’t know about the consequences of its cause. e.g. If we have an alarm system that records information when the front door opens, the door itself doesn’t know that the alarm system will add information when the door opens, just that the door has been opened.[4]
[edit] See also
- Event-driven programming
- Service-oriented architecture
- Space based architecture
- Complex Event Processing
- Event Stream Processing
[edit] Articles
- Article defining the differences between EDA and SOA: How EDA extends SOA and why it is important by Jack van Hoof.
- Real-world example of business events flowing in an SOA: SOA, EDA, and CEP - a winning combo by Udi Dahan.
[edit] References
- ^ K. Mani Chandy Event-Driven Applications: Costs, Benefits and Design Approaches, California Institute of Technology, 2006
- ^ a b Jeff Hanson, Event-driven services in SOA,Javaworld, January 31, 2005
- ^ Carol Sliwa Event-driven architecture poised for wide adoption , Computerworld, May 12, 2003
- ^ a b c d e f g h i j Brenda M. Michelson, Event-Driven Architecture Overview, Patricia Seybold Group, February 2, 2006
