I was reading this article called Variations in event-driven architecture in which they demonstrate both the mediator and broker topologies.
According to the article the mediator topology looks somewhat like this:
The event flow starts with the client sending an event to an event queue, which is used to transport the event to the mediator. The event mediator receives the initial event and orchestrates that event by sending additional asynchronous events to event channels to execute each step of the process. Event processors, which listen on the event channels, receive the event from the even mediator and execute specific business logic to process the event [...] It is important to note that the event mediator doesn't actually perform the business logic necessary to process the initial event, rather, it knows of the steps required to process the event [...] The event channels can be either message queues o message topics.
So, I was studying this diagram, trying to understand how the mediator could determine when a given processor has finished processing a given event, such that it could orchestrate the next step of the process.
The article is not clear enough when it says
For each initial event step, the event mediator creates a processing event, sends that processing event and waits for the processing event to be processed by the corresponding event processor. This process continues until all of the steps in the initial event have been processed.
Now, the article is clear in that the communication is asynchronous, and event messages will travel through message queues, but the diagram does not show any events coming out of the event processor and back to the mediator.
The article says the mediator waits for the event processor to finish, but it is not clear how this is supposed to happen in architectural terms.
Is it asynchronous, queue-based RPC (e.g. Rabbit RPC), or is there another listener waiting for an asynchronous response somewhere?
Any thoughts on how this can be implemented from an architectural standpoint?
I think you have the answer on the diagram itself:
Initial Event step (red color) is the key. Every Event Processor produces an event, which is what gets into the Event Queue and then to the Event Mediator.
The architecture is Event Driven and asynchronous. Single Event Queue handles path to the Event Mediator. And since this is the only way to get the event into the Event Mediator, obviously, anything wanting to send an event to the mediator would need to use this path.
At some point, after certain event, the Event Mediator will declare the operation as successfully complete and will not dispatch more events to the Event Processors.
Although, I must say, you are right, this is not clearly stated in the article. I assume this will be better clarified in the book they are previewing.