Mediator Topology in Event-Driven Architecture

Key Insight

The mediator topology addresses several limitations of the broker topology by centralizing workflow management. Key to this style is an event mediator that controls and coordinates the processing steps for initiating events involving multiple event processors. Its core components include an initiating event, an event queue, the event mediator, dedicated event channels (usually queues), and event processors. Unlike the broker topology, event processors in the mediator topology do not broadcast their actions but rather send 'commands' point-to-point and typically respond directly to the mediator upon completing their work. Implementations often feature multiple mediators, usually associated with specific domains, to reduce single points of failure and enhance performance.

The event mediator's implementation varies based on the complexity of the events it processes. For simple error handling and orchestration, tools like Apache Camel or Spring Integration, with custom programming code, are often sufficient. For intricate workflows requiring conditional processing, dynamic paths, and complex error handling, BPEL-based mediators such as Apache ODE are suitable, utilizing an XML-like structure. For long-running transactions that involve human intervention, Business Process Management (BPM) engines like jBPM are necessary. A recommended hybrid approach classifies events (simple, hard, or complex) and uses a simple mediator to either handle them directly or forward them to more specialized mediators (BPEL or BPM engines) for appropriate processing.

Illustrating with a retail order entry system, a 'PlaceOrder' initiating event is managed by a Customer mediator which orchestrates steps like creating an order, then concurrently emailing the customer, applying payment, and adjusting inventory. The mediator must wait for acknowledgements from all parallel processes before advancing to the next stage, such as fulfilling the order. This control enables robust error handling (e.g., stopping workflow if payment fails and restarting from that point), recoverability, and improved data consistency. However, this topology leads to greater coupling among event processors and generally exhibits lower scalability, performance, and fault tolerance compared to the broker topology. Additionally, modeling highly dynamic and complex workflows within the mediator topology can be challenging.