What are Event-Driven Architectures?Many traditional software architectures are build around the request-response-model. Here components ask other components to do something for them or to return an information, both based on passed arguments. The communication model is often synchronous, sometimes asynchronous messages are used. But both times the requests are formulated as imperative verbs together with nouns, like "get address", "change order", or "query network equipment by IP address". As opposed to this event-driven architectures use the raising of events to notify the system that something has happened. They've got the form noun together with a verb in its past form, like "order placed", "goods delivered", or "network equipment disconnected". The source of those events can be front-end applications, external sensors, or components inside the EDA application. They all are just fire and forget their individual events. But they are networked, directly or using a bus as communication infrastructure. And here are one or more other components that have subscribed to events they are interested in. Those components use the raised events as triggers for their actions. How do Event-Driven Architectures work?Let's build a scenario showing the principles. Think about a dine, where multiple persons work together hand in hand without the needance to give expicit instructions. Their communication is based an signals, sometimes by voice, but very often indirect. Integration with SOAWays of processingSimple Event ProcessingStream Event ProcessingComplex Event ProcessingCommon Patterns |