Recently, there has been new hype about an architectural style called event-driven architecture (EDA). As its name implies, EDA is a software architecture pattern promoting the production, detection, consumption of, and reaction to events.
To some extent, one-way messages and publish/subscribe messages can be considered to be events. These events typically are notifications of significant changes in state that enable those interested in these changes to react accordingly.
For example, an event notifying consumers that a barrier has been placed on a phone company customer might result in all systems that deal with this customer disabling all functionality for the customer.
There is a lot of discussion at the moment about whether EDA is a special form of SOA, an enhancement of SOA, or something different. For example, some analysts and companies have introduced terms such as "Advanced SOA" or "SOA 2.0" to refer to the combination of EDA and SOA (see, e.g., [GartnerEDA06], which strictly speaking compares and combines EDA with "interactive SOA").
In my opinion, the most important distinction has to do with the types of events being sent around. Of course, as with services and objects, you can classify events very differently. One interesting difference has to do with whether the events notify consumers about changes with or without including corresponding data:
If an event just notifies consumers that customer data has changed and needs to be processed, only ...