SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.
SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.
Successfully reported this slideshow.
Activate your 14 day free trial to unlock unlimited reading.
19.
Let’s say we did...
• Security?
• Skip existing auth infrastructure
20.
Let’s say we did...
• Security?
• Skip existing auth infrastructure
• Need to make something up
21.
Let’s say we did...
• Security?
• Skip existing auth infrastructure
• Need to make something up
• Direct connections?
22.
Let’s say we did...
• Security?
• Skip existing auth infrastructure
• Need to make something up
• Direct connections?
• Lots of open connections, open ports
23.
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”
24.
Philosophy
High-level patterns
API / Semantics
libzmq
25.
Philosophy
High-level patterns
API / Semantics
libzmq
27.
What do we want?
• Near feature/semantic parity with ZeroMQ
28.
What do we want?
• Near feature/semantic parity with ZeroMQ
• Throughput performance not as important
29.
What do we want?
• Near feature/semantic parity with ZeroMQ
• Throughput performance not as important
• Embrace nature of the web in design
30.
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
31.
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
32.
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
53.
STOMP
• Simple and human-readable like HTTP
• Extensible via headers
54.
STOMP
• Simple and human-readable like HTTP
• Extensible via headers
• Library and server support
55.
STOMP
• Simple and human-readable like HTTP
• Extensible via headers
• Library and server support
• An easy WebSocket subprotocol
56.
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”
57.
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
58.
STOMP “Extensions”
1. Frames include socket type header
2. Header for “connect” or “bind” in SUBSCRIBE
3. Req-Rep messages use “reply-to” header