Event-driven architecture
From Wikipedia, the free encyclopedia
(Redirected from Event Driven Architecture)
Jump to: navigation, search
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 detected, produced, published 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 consumers and event producers. Event consumers subscribe to an intermediary event manager, and event producers publish to this manager. When the event manager receives an event from a producer, the manager forwards the event to the consumer. If the consumer is unavailable, the manager can store the event and try to forward it later. This method of event transmission is referred to in message-based systems as "store and forward" [2].
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 complements service-oriented architecture (SOA) because services can be started by triggers such as events[2][3].
Computing machinery and sensing devices 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
[hide]
* 1 Event structure
* 2 Event flow layers
o 2.1 Event generator
o 2.2 Event channel
o 2.3 Event processing engine
o 2.4 Downstream event-driven activity
* 3 Event processing styles
o 3.1 Simple event processing
o 3.2 Event Stream Processing
o 3.3 Complex event processing
* 4 Extreme loose coupling and well distributed
* 5 See also
* 6 Articles
* 7 References
* 8 External links
[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 could describe the cause of why the event was triggered. If the value of a stock falls under a threshold this may be a cause of why an event is triggered.[4] The event body can also contain just the description of a fact (a change in state or anything that can increase the entropy of the universe) without any reference to the cause of the fact itself.
[edit] Event flow layers
An event triggered architecture is built on four logical layers. It start with the creation of an event and ends with some type of reaction to that event.[4]
[edit] Event generator
The first logical layer is the event generator, which is the cause of an event. Since an event can be almost anything, 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]
[edit] Event channel
An event channel is a mechanism whereby the information from an event generator is transferred to the event engine[4]. 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 asynchroneously. 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, selected and processed. This can also lead to another event being triggered. I.e., if the event that comes into the event processing engine is a “product ID low in stock”, this may trigger events 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]
[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.
[edit] References
1. K. Mani Chandy Event-Driven Applications: Costs, Benefits and Design Approaches, California Institute of Technology, 2006
2. Jeff Hanson, Event-driven services in SOA,Javaworld, January 31, 2005
3. Carol Sliwa Event-driven architecture poised for wide adoption , Computerworld, May 12, 2003
4. Brenda M. Michelson, Event-Driven Architecture Overview, Patricia Seybold Group, February 2, 2006
[edit] External links
* Elemental Links: Event-Driven Architecture Overview — blog post by Brenda Michelson
Retrieved from ""
Categories: Enterprise application integration | Software architecture | Service-oriented (business computing) | Events (computing)
阅读(2120) | 评论(0) | 转发(0) |
