From what I have read so far, the difference consists in the fact that the later (@EnableWebSocketMessageBroker
) offers a better handling for the exchanged messages. In order to keep them somehow in controll, a very good approach is to use a message broker:
- easy to broadcast to intersted parts. Otherwise you have to keep trace of session and to iterate through them in order to send a message to each client who is interested
- assuring the message got to the client. Out of the box, a message broker offers acknowledgement flags that will be interchanged between client and server in order to assure the message transmission and interception
Note: the annotation @EnableWebSocketMessageBroker
does not by default add an underlying full-featured Broker, but a "Simple one".
The simple version:
- supports subset of STOMP: SUBSCRIBE, UNSUBSCRIBE, MESSAGE
- no acks, receipts, transactions
- simple message sending loop
- not suitable for clustering
A full-featured one will add more functionalities, that can be found on its presentation documentation.
(read more in http://rstoyanchev.github.io/s2gx2013-websocket-browser-apps-with-spring)
Other nice to read reference: Message queues vs sockets, The MessageBroker WebSocket Subprotocol