STOMP over websockets vs plain STOMP. Which one is better?

Question

As from spring 4, we have support of STOMP (sub)protocol over WebSocket. I do understand the benefits of WebSocket as compared to HTTP and the use & benefits of using STOMP over the WebSocket but I would like to understand the following:

1. Are there any Performance benefits of directly using the stomp protocol to talk with the MB (like RabbitMQ or Kafka - probably in future)

2. Is there any benefit of using STOMP as a sub-protocol over web-sockets other than to take care of the handshake required by the client to connect to the server/MB

Answer 1

Those are orthogonal concerns. Websocket is a transport; in fact, when using sock.js, you can use many transports as fallbacks and still use STOMP.

STOMP describes the message format exchanged between clients and servers.

It's like asking to compare TCP and HTTP.

1. You can't "just use" STOMP to communicate with a server or a message broker. You have to use a transport to send those STOMP messages.
2. STOMP doesn't take care of the websocket handshake, in fact, it's not aware of it at all. Case in point, you can transparently use STOMP on top of HTTP and see no difference from the STOMP perspective.