Let’s say we did...
• Security?
• Skip existing auth infrastructure
Let’s say we did...
• Security?
• Skip existing auth infrastructure
• Need to make something up
Let’s say we did...
• Security?
• Skip existing auth infrastructure
• Need to make something up
• Direct connections?
Let’s say we did...
• Security?
• Skip existing auth infrastructure
• Need to make something up
• Direct connections?
• Lots of open connections, open ports
Let’s say we did...
• Security?
• Skip existing auth infrastructure
• Need to make something up
• Direct connections?
• Lots of open connections, open ports
• Just not “web friendly”
What do we want?
• Near feature/semantic parity with ZeroMQ
What do we want?
• Near feature/semantic parity with ZeroMQ
• Throughput performance not as important
What do we want?
• Near feature/semantic parity with ZeroMQ
• Throughput performance not as important
• Embrace nature of the web in design
What do we want?
• Near feature/semantic parity with ZeroMQ
• Throughput performance not as important
• Embrace nature of the web in design
• Single connection, service multiplexing
What do we want?
• Near feature/semantic parity with ZeroMQ
• Throughput performance not as important
• Embrace nature of the web in design
• Single connection, service multiplexing
• Use existing transports, protocols, etc
NullMQ
What do we want?
• Near feature/semantic parity with ZeroMQ
• Throughput performance not as important
• Embrace nature of the web in design
• Single connection, service multiplexing
• Use existing transports, protocols, etc
STOMP
• Simple and human-readable like HTTP
• Extensible via headers
STOMP
• Simple and human-readable like HTTP
• Extensible via headers
• Library and server support
STOMP
• Simple and human-readable like HTTP
• Extensible via headers
• Library and server support
• An easy WebSocket subprotocol
STOMP
• Simple and human-readable like HTTP
• Extensible via headers
• Library and server support
• An easy WebSocket subprotocol
• Can be used to model “virtual connections”
STOMP
• Simple and human-readable like HTTP
• Extensible via headers
• Library and server support
• An easy WebSocket subprotocol
• Can be used to model “virtual connections”
• Transactions for multipart messages
STOMP “Extensions”
1. Frames include socket type header
2. Header for “connect” or “bind” in SUBSCRIBE
3. Req-Rep messages use “reply-to” header