Yes you could in theory create a Service/Event Bus between your client and the server. While you could do this over HTTP, I believe you are looking for WebSockets.
Several possible benefits of this are:
- distribution of services between the client machine, and server machine. Without either knowing where their collaborators live.
- the ability to have builtin redundancy, recovery, task relocation, parallel processing.
- the ability to see communication occur in real time between services located on the other machine.
- A very simplified api.
- Reduces the reliance on HTTP, permitting porting to other network protocols.
On the other hand it makes for:
- Complex distributed message handling.
- Bus Congestion
- Asynchrony issues
- Reduced network support from the Web Architecture.
The problem is this is not the Mediator pattern.
A Mediator doesn't necessarily provide a bus, neither does it expose the communication between the collaborating objects.
The Mediator alone is responsible for knowing how to arrange the communication between these objects, and change it at run-time.
- It may send some interactions to the equivalent of
/dev/null.
- Other interactions may be farmed out to hundreds of recipient objects.
- The interaction itself may be transformed into a different series of interactions.
You could create two Mediators one on either side of this Service Bus. They would be responsible for interfacing messages and interactions, perhaps with some interactions being directly forwarded to local contributors.
Run-time reconfiguration of services at scale isn't always needed. It may be wiser to use a builder pattern to construct each service independently. Constructed with an attachment to the service bus that is closed when the service (or service bus) is done.
