API Design and WebSocket
7 likes5,361 views
The document discusses the evolution of network communication, focusing on the limitations of traditional HTTP for event-based applications and the introduction of WebSocket as a bi-directional communication protocol to enable real-time interaction on the web. It highlights the importance of layering application protocols over WebSocket to reduce complexity and facilitate innovation, particularly in the context of the Internet of Things (IoT) and the Web of Things (WoT). The author emphasizes the need for new standards and systems to enhance interoperability and performance in rapidly evolving connected environments.
API Design and WebSocket
- 1. API Design and WebSocket WoT Next? @frankgreco
- 2. Background § Director of Technology @ Kaazing § Chairman NYJavaSIG (javasig.com) § Largest JUG in North America 8,000+ members § Financial Services, Architecture, Cloud § [email protected], @frankgreco
- 3. A Primary Tenet of Computing History History If History Repeats Itself, Is There No Future?
- 4. A Trip Down Memory Lane… In the beginning…
- 5. Enterprise – “inside the firewall” (1980’s – early 90’s) tcp Client-Server
- 6. Web – “over the firewall” (early 90’s – 2011) http tcp web server and/or app server app protocols Not efficient or effective for event-based systems…
- 7. But Modern Applications are Dynamic and Event-based FX trading Monitoring Stock trading Utilities trading XaaS Logistics Notification Compliance Betting & bidding Voting In-store & online Collaboration
- 8. Legacy Web u Designed for document transfer – HTTP ü Short-lived Request / Response interaction u Bidirectional, but half-duplex ü Traffic flows in only one direction at a time u Stateless ü Large amounts of metadata resent for each request The Web was not originally designed for “real-time”, event-based services…
- 9. WebSocket – “TCP for the Web” u IETF Protocol and W3C JavaScript API for real-time, bi-directional, always-on connections u RFC 6455 – Dec 2011 u Easily add event-based data to web apps ü ws://mycompany.com/collaboration_svc ü wss://anothercompany.com/marketdata u Avoids polling u Avoids HTTP meta-data overhead u Shares port with HTTP (80/443) u Traverses Firewalls
- 11. For Event-based Web Communication… Legacy HTTP vs WebSocket http:// ws:// u Application-level Socket over the Web u Supported by all Modern Browsers u Event-based Applications
- 12. W3C WebSocket JavaScript API
- 13. W3C WebSocket JavaScript API HTML5 WebSocket API But… Dealing with WebSocket is like dealing with TCP. It’s a streams-based model. You need to understand how to handle streams-based data over the wire. e.g., How do I do publish/subscribe?
- 14. What is Missing? Where is the Application-level Protocol? Who handles retries? How do we handle publish/ subscribe semantics? How do we handle market data? How can we guarantee delivery? What do we do with slow consumers, last value cache, etc? What if the client is not currently active? What about partial data? How do I handle entitlements? ACL?
- 15. Browser and Native Applications JMS XMPP AMQP B2B FTP VNC MQTT etc WebSocket TCP/IP Internet WebSocket Gateway WebSocket Gateway Protocol Layering is Possible WebSocket is a Transport layer
- 16. Simplicity is a Useful Abstraction! Simplicity enables Innovation Complexity Innovation Higher Level APIs Reduce Complexity
- 17. Higher Level APIs (over WebSocket) for JavaScript So if you can layer application protocols and APIs over WebSocket, what do you have? u Easier WebSocket programmability u Event-driven applications over the web u Event-driven APIs over the web u Not necessary to open non-standard ports u Web infrastructure now truly “disappears” u Reduction in complexity u Further opportunities to innovate u Mobile + cloud + HTML5/WebSocket u Internet of Things -> Web of Things u “Imagination is Everything”
- 18. Publish/Subscribe Java Message Service (JMS) over WebSocket For Example…
- 19. Java Message Service (JMS) u Java EE Message Oriented Middleware u JMS 1.0 2001, JMS 1.1 2002, JMS 2.0 2013 u Asynchronous Messaging vs. RPC u Loosely coupled vs. Tightly coupled u Pub/Sub, Topics, Queues u Transactions, Reliable
- 20. Basic JMS conn = createConnection(); sess = conn.createSession(); topic = jndiContext.lookup(topic); pub = sess.createProducer(topic); pub.send(“hey Frank”); conn = createConnection(); sess = conn.createSession(); topic = jndiContext.lookup(topic); sub = sess.createConsumer(topic); sub.setMessageListener(this); … public void onMessage(Message m) { String s = m.getText(); … do stuff… } conn = createConnection(); sess = conn.createSession(); topic = jndiContext.lookup(topic); sub = sess.createConsumer(topic); sub.setMessageListener(this); … public void onMessage(Message m) { String s = m.getText(); … do stuff… } conn = createConnection(); sess = conn.createSession(); topic = jndiContext.lookup(topic); sub = sess.createConsumer(topic); sub.setMessageListener(this); … public void onMessage(Message m) { String s = m.getText(); … do stuff… } msg broker
- 21. JMS Over the Web (JavaScript) Browser app - 100 msg/sec over port 80/443
- 22. What WebSocket is Not u It is not a New AJAX AJAX was a lovable hack u It is not a Push mechanism WebSocket is full-duplex, bi-directional u It is not a Messaging system It’s an agnostic wire protocol It’s a low-level transport API u It is not a Replacement for HTTP HTTP is still great for static, cacheable info
- 23. What’s next for WebSocket?
- 24. Internet of Things (IoT) + Heterogeneity + Scale + Usability Futures
- 25. The World is Naturally Event-based (“real-time”) Presentation Music Communication Logistics Big Data Risk Management Home Security Health Monitoring Intelligent Appliances Local Transportation Monitoring/ Management Remote control
- 27. Let’s Take 1 Step Back to go 2 Steps Ahead… u Internet – Global system of interconnected networks that use IP to communicate u Internetworking – Connecting one network with another through a series of Gateways that provide a common method of communication
- 28. The Web u A popular application service on the Internet u Based on TCP/IP u Advantages § Application deployment simplified – URI § Interoperable open standards and specifications § Ease of programmability – scripting § Global reach and Economy of scale § Accessed by ubiquitous Browsers and also non-Browsers u Two major protocols HTTP (1988/1999) and WebSocket (2007/2011)
- 29. The Hidden Web – Most of the Web is Not Visible browsers APIs http://thumbs.dreamstime.com/x/iceberg-23503494.jpg
- 30. Now… IoT, IIoT and M2M u A riff on “Ubiquitous Computing” (“Pervasive”) • Mark Weisner PARC 1988 u Its early so there’s different definitions • Similar to early days of Cloud Computing u M2M has been around for decades. • Primarily proprietary embedded systems and typically point-to-point (RPC) u IoT/IIoT (Industrial IoT) • Adds Internet connectivity • Networks of M2M systems connected via IP
- 31. IoT/IIoT – Connectivity isn’t Sufficient u No formal API standards u Many protocol standards – interoperability low u No common, wide-reaching frameworks u No composition possibilities u Difficult to leverage economies of scale u Barrier to entry is high for millions of app developers u Also… we’re in a cloud, mobile, web api world
- 32. u IoT – Internet of Things • Embedded computing endowed with Internet connectivity u WoT – Web of Things • Application and Services layer over IoT Developers! u Apply the benefits of the Web to IoT u WoT is a uniform interface to access IoT functionality u Provides the abstraction for control/monitoring (sensors/ actuators) u Accelerates innovation u Deployment, development, interoperability, economy of scale… IoT WoT Here’s Where the Web Comes In
- 33. But Is HTTP the Right Choice? u Disadvantages of HTTP Request/Response u Lack of resiliency and robustness u Enterprise events retrieved by resource intensive polling techniques • Much bandwidth is wasted • Information can be delayed u Composite services brittle and lack transactionality u Enterprises learned advantages of ESB 10+ years ago u See failures of CORBA, Sun RPC, etc. u Clumsy AJAX/Comet workarounds to simulate real-time
- 34. History Repeats Itself… RPC Asynchronous RPC Messaging REST Asynchronous REST Messaging ESB ISB? Enterprise Web/WoT • Can wait for response • Tight coupling • Centralized business processes • Vertical interaction • Easy to understand (xact) • Future response • Loose coupling • Independent business processes • More complexity (xact) Did I mention History repeats itself?...
- 35. The Message is the Medium “…terse, self-classified messages, networking overhead isolated to a specialized tier of devices, and publish/subscribe relationships are the only way to fully distill the power of the coming Internet of Things” – Francis daCosta
- 36. Typically an App Server and DB App Server is probably not the right architecture Data Flow – Human Web vs WoT Human Web WoT Large data to client Small data to server Do human-readable protocols make sense for non-humans?
- 37. GW GW GW IoT/IIoT WoT WoT WoT Event Gateway Architecture
- 38. Event Gateway Architecture – Future Directions GW GW GW GW GW GW Aggregator nodes GW • Scalability • Querying • Performance • Manageability • Composition • Circles of Trust • Event processing • CDN++
- 39. Demos Click to Edit Master Title Style