I was considering how to implement the ServiceStack Service Gateway and Discovery/Addressing, and it occurred to me that using MQ may be a way around this…I thought I would pose the question here to qualify whether I’m missing something.
In theory you could avoid using the Redis/Consul Discovery pieces by using an MQ implementation to publish the message in the service implementing IServiceGateway (if it couldn’t be handled locally of course) and let the consumers pull the messages from the queue and process/respond appropriately wherever they are hosted.
Does this sound feasible, or am I oversimplifying things?
MQ can be used for creation distributed services which process messages independently of their location. But if you want to make this architecture to be similar to service discovery you need to implement functionality of finding and choosing another MQ if you master MQ is down. Service Discovery allows to find another node for processing messages if master node or serveral masters nodes are down while Message Queue distributes the messages between clients and allow to scale processing but does not allow to make auto switch to another MQ if it is down for some reason.
ok thanks - that makes sense. It occurs to me that there is a certain elegance in forcing the communication through the formal API before placing it on the command queue in order to enforce a single point where validation takes place etc.