24. Let’s say we did...
• Security?
• Skip existing auth infrastructure
25. Let’s say we did...
• Security?
• Skip existing auth infrastructure
• Need to make something up
26. Let’s say we did...
• Security?
• Skip existing auth infrastructure
• Need to make something up
• Direct connections?
27. Let’s say we did...
• Security?
• Skip existing auth infrastructure
• Need to make something up
• Direct connections?
• Lots of open connections, open ports
28. 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”
32. What do we want?
• Near feature/semantic parity with ZeroMQ
33. What do we want?
• Near feature/semantic parity with ZeroMQ
• Throughput performance not as important
34. What do we want?
• Near feature/semantic parity with ZeroMQ
• Throughput performance not as important
• Embrace nature of the web in design
35. 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
36. 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
37. 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
59. STOMP
• Simple and human-readable like HTTP
• Extensible via headers
60. STOMP
• Simple and human-readable like HTTP
• Extensible via headers
• Library and server support
61. STOMP
• Simple and human-readable like HTTP
• Extensible via headers
• Library and server support
• An easy WebSocket subprotocol
62. 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”
63. 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
64. STOMP “Extensions”
1. Frames include socket type header
2. Header for “connect” or “bind” in SUBSCRIBE
3. Req-Rep messages use “reply-to” header