Essentially clients establish a WebSocket session and use STOMP for messaging (STOMP over WebSocket), not AMQP. In STOMP everything is driven by the destination header and it's up to message brokers to define what it means. For example, check the RabbitMQ STOMP plugin page to see how Rabbit maps STOMP destinations to queues and exchanges.
So if you think of RabbitMQ as your message broker where you already manage queues, exchanges, etc. On the web application side, the messaging protocol is STOMP, clients can send messages to STOMP destinations mapped to @MessageMapping
controller methods or to destinations supported by RabbitMQ. Furthermore, controllers, or any other component injected with a SimpMessagingTemplate
can send messages to the broker (Rabbit) which will then broadcast to connected web clients.
Hope this helps.