0

We are in the process of migrating the existing architecture to queue based architecture. Our system contains one centralized server connected to 300+ KIOSK systems where the data synchronization is done to sql based CRUD operation.

We decided to create an exchange and a queue for centralized service and an exchange with multiple queues (for each KIOSK) using header binding.

The KIOSK always initiates the synchronization( limitation due legal issues). So we decided to use Request/Response model.

The question is, can we use the header based exchange binding for this Request/Response model.

Raajkumar
  • 857
  • 2
  • 13
  • 26

1 Answers1

1

If I understand right, your kiosk sends a message to the central server and it needs to respond to a header exchange, which routes the message to a queue dedicated to messages of that kiosk. Each kiosk consumes messages from its own dedicated queue.

Let's imagine you do binding based on StoreLocationId and KioskId. When the kiosk sends the its message to the central server, it ensures that the StoreLocationId and KioskId are included in the message. The central server does what it needs to do and adds to the response message two message headers: StoreLocationId and KioskId with the values it received from the Kiosk. The responses sent to that header exchange will now be routed correctly the desired kiosk.

I should note that you could also use a Topic exchange and use a Routing Key like LocationId_KioskId. Or use the Default exchange if your kiosk queues follow a standard naming convention which can be derived from data included in the request message.

From a security point of view, perhaps the Default exchange would be best as the kiosks could not set up bindings that would allow them to consume messages from multiple other kiosks. When using the Default exchange, one and only one kiosk would receive the response.

Vanlightly
  • 1,389
  • 8
  • 10
  • Thank you very much @Vanlightly. I wasn't sure whether using Request/Response model can be used to solve the problem. I was experimenting the above mentioned idea using EasyNetQ – Raajkumar May 11 '18 at 18:44
  • BTW @Vanlightly , if the KIOSK gets restarted due some reason, and how do we need to handle that situation. Create a unread message queue and push it there? The reason is, in request/response, we are using the CorrelationId to determine which handler needs to be called. Upon restart, the correlation id will be lost so does the callback reference. – Raajkumar May 11 '18 at 19:42
  • In that case I would simply discard messages that have a CorrelationId you don't have stored in memory. The Kiosk could always make a fresh request on start-up. – Vanlightly May 11 '18 at 19:54