Description
Event-Driven Architecture (EDA) uses unidirectional messaging to communicate among two or more, largely independent peer procedures. The communication is initiated by an "event". This event typically corresponds to some business occurrence. A system acting as the event publisher places the event on a queue or publishes it to a topic. Any event listeners subscribing to that topic are then notified and thus activated. The event publisher and the event subscriber are independent of one another. This allows for completely decoupled operation. Events may be further categorized into simple and complex events:
- Simple events are the computerized record of a business event generated by some change in state in the business environment.
- A complex event is a software event that is derived from two or more elementary “member” software events through a process of event aggregation or correlation.
Initially, NIH will focus on the management of simple events. Complex event processing will be explored as NIH's application integration capabilities mature.
The integration infrastructure may provide higher level services to facilitate the implementation of EDA including:
- Content-based Routing - The Integration Broker Suite (IBS) can route a published event to other queues or topics
- Mapping and transformation - The IBS can transform incoming messages into alternate formats based on the needs of the receiving applications.
- Reliable Messaging - The IBS can provide for reliable messaging ensuring that messages are delivered once and only once via queues or providing durable subscriptions ensuring that all subscribers receive all events published to topic.
- Security - The IBS provides message encryption, non-repudiation, and authentication and access control.
Please view the Event Driven Architecture (EDA) Pattern below:
Diagram
Benefits
- Reduces the elapsed time of a business process by working with individual events rather than batches and executing activities concurrently.
- Decoupled interactions - Event publishers are not aware of the existence of event subscribers. Subscribers do not need to be available for sending system to continue processing.
- Can be achieved less invasively than request-reply service interactions in many cases.
- Many-to-many communications - Publish/Subscribe messaging where one specific event can impact many subscribers.
- Asynchronous - Supports asynchronous operations through event messaging.
- Can support asynchronous acknowledgement when required to complete a process step.
Limitations
- Effective monitoring must be in place to track queue depth, exceptions, and other possible indicators of problems. The traceability of an event through a dynamic multi-path event network can be difficult making problem isolation/debugging more difficult in some cases.
Recommended Usage
There are a number of appropriate circumstances for the use of EDA. In general, integration points with the following characteristics are suitable for EDA:
- The business process is inherently asynchronous.
- Events being published are of interest to multiple other systems or business processes.
- Real-time request/reply processing is not required.
- No immediate acknowledgement is required by the event source.
Time Table
This architecture definition approved on:
May 24, 2006
The next review is scheduled in:
TBD
