Skip to main content
added 1012 characters in body
Source Link
Martin Maat
  • 18.5k
  • 3
  • 31
  • 58

It looks to me you created a synchronous messaging system. If you make BridgeService a queue you will have something very common and proven, it will be asynchronous and the decoupling will be even better.

[Edit in response to comment]

Software components that communicate with each other through message queues is a common pattern, if you want to call it that. The queue can be an object in a single process (for in-process communication) or a database table on a separate server for inter-system communication, or something in between.

This is asynchronous by nature, the "caller" puts a message in the queue and the service will read and process the message when it gets around to do it. It may then respond by posting a message back, in a queue that is to be read by the caller. The caller can wait for that message, effectively making it synchronous again from its perspective, or rely on an event mechanism to get the results, if there are any.

All of the internet works that way because the IP protocol is a message protocol. Whether this model is a good fit for your application is for you to decide. It may not be the most convenient option, it requires a lot of plumbing which could be overkill.

It looks to me you created a synchronous messaging system. If you make BridgeService a queue you will have something very common and proven, it will be asynchronous and the decoupling will be even better.

It looks to me you created a synchronous messaging system. If you make BridgeService a queue you will have something very common and proven, it will be asynchronous and the decoupling will be even better.

[Edit in response to comment]

Software components that communicate with each other through message queues is a common pattern, if you want to call it that. The queue can be an object in a single process (for in-process communication) or a database table on a separate server for inter-system communication, or something in between.

This is asynchronous by nature, the "caller" puts a message in the queue and the service will read and process the message when it gets around to do it. It may then respond by posting a message back, in a queue that is to be read by the caller. The caller can wait for that message, effectively making it synchronous again from its perspective, or rely on an event mechanism to get the results, if there are any.

All of the internet works that way because the IP protocol is a message protocol. Whether this model is a good fit for your application is for you to decide. It may not be the most convenient option, it requires a lot of plumbing which could be overkill.

Source Link
Martin Maat
  • 18.5k
  • 3
  • 31
  • 58

It looks to me you created a synchronous messaging system. If you make BridgeService a queue you will have something very common and proven, it will be asynchronous and the decoupling will be even better.