Frank Greco - @frankgreco Director of Technology, Kaazing
WebSocket Perspectives and Vision for the Future
Oct 2013
© 2013 Kaazing Corporation
§ Brief Background on WebSocket § Layered Approach to Web Protocols § The Web beyond the Browser – XaaS § The Internet of Things and WebSocket § Demos
Outline
© 2013 Kaazing Corporation
Me…
§ Director of Technology @ Kaazing § Chairman NYJavaSIG (javasig.com) § Largest Java UG in North America
7,500+ members § Chair NYHTML5
1,500+ members
§ Email: [email protected] § Twitter: @frankgreco § Yell: “Hey Frank!”
© 2013 Kaazing Corporation
Welcome HTML5 (aka The New Web)
§ Users are Demanding more from Apps § UI/UX Requirements are more sophisticated § Browser Enhancements and Evolution § API Explosion § Web no longer just about Documents… even partial or
pseudo documents
The New Web is a Programmatic Foundation for Rich, Reliable and Really Cool Apps
© 2013 Kaazing Corporation
Welcome HTML5 (aka The New Web)
§ Users are Demanding more from Apps § UI/UX Requirements are more sophisticated § Browser Enhancements and Evolution § API Explosion § Web no longer just about Documents… even partial or
pseudo documents
The New Web is a Programmatic Foundation for Rich, Reliable and Really Cool Apps
But…
© 2013 Kaazing Corporation
§ Designed for document transfer - Short-lived Request / Response interaction
§ Bidirectional, but half-duplex - Traffic flows in only one direction at a time
§ Stateless - Large amounts of metadata resent for each request
HTTP – Not Designed for an Event-Driven World…
Yes, HTTP 2.0 will be better, but the Web was not originally designed for “real-time”, event-based services…
© 2013 Kaazing Corporation
WebSocket
• “Real-Time”, bi-directional connectivity • IETF Protocol - RFC 6455 – Dec 2011 • W3C API • Easily add event-based capability to web apps • Avoids polling (and resource consumption) • Avoids HTTP meta-data overhead • Shares port with HTTP (80/443) • Peer protocol to HTTP (both use TCP) • The Most Important API in “HTML5”
© 2013 Kaazing Corporation
§ IETF Formal Protocol (RFC 6455) - Event-driven JavaScript API - Full-duplex communication protocol
§ W3C API – Candidate Recommendation - http://www.w3.org/TR/websockets/
§ Integrates HTTP addressing - ws://yourcompany.com/collaboration_svc
- wss://anothercompany.com/marketdata_svc
§ Traverses firewalls, proxies, routers securely § Text and Binary § Leverages Cross-Origin Resource Sharing (CORS)
WebSocket Standards
Java JSR 356
© 2013 Kaazing Corporation
The WebSocket Handshake
© 2013 Kaazing Corporation
WebSocket Frames
§ Frames have a few header bytes § Data may be text or binary § Frames from client to server are masked
(XORed w/ random value) to avoid black hats with old proxies
§ Use TLS in production – avoids a lot of issues…
© 2013 Kaazing Corporation
What WebSocket is Not
• It is not a New AJAX AJAX was a lovable hack
• It is not a Push mechanism WebSocket is full-duplex, bi-directional
• It is not a Messaging system It’s an agnostic wire protocol It’s a low-level transport API
• It is not a Replacement for HTTP HTTP is still great for static,
cacheable info
© 2013 Kaazing Corporation
WebSocket Projects, OSS, Vendors
• Kaazing • Node.js/socket.io/SockJS/engine.io • ActiveMQ • Tomcat • Jetty • Oracle Glassfish • Java EE – JSR 356 • Play Framework – Reactive Apps • Rabbit MQ • JBoss • IIS/ASP .NET 4.5 • PHP, Objective-C, Ruby, Python, C/C++, JVM-langs… • Many more…
© 2013 Kaazing Corporation
Legacy HTTP vs. WebSocket
For Real-Time, Event-based Web Communication…
Seems like a no-brainer for most apps…
© 2013 Kaazing Corporation
HTML5 WebSocket API
Make sure WS is open before usage… J
© 2013 Kaazing Corporation
HTML5 WebSocket API
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?
But…
© 2013 Kaazing Corporation
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?
© 2013 Kaazing Corporation
WebSocket
TCP
JMS XMPP AMQP B2B FTP VNC mktdata etc
Browser and Native Applications
WebSocket Gateway
Internet
WebSocket Gateway
Whoa… Its just like TCP! Huzzah!
But wait… Protocol Layering is Possible!
© 2013 Kaazing Corporation
Higher Level APIs (over WebSocket) for JavaScript
So if you can layer application protocols and APIs over WebSocket, what do you have? • Easier WebSocket programmability • Event-driven applications over the web • Event-driven APIs over the web • Not necessary to open non-standard ports • Web infrastructure now truly “disappears” • Reduction in complexity • Further opportunities to innovate • Mobile + cloud + HTML5/WebSocket • Internet of Things -> Web of Things • “Imagination is Everything”
© 2013 Kaazing Corporation
Higher Level APIs Reduces Complexity
Simplicity is a Useful
Abstraction!
Simplicity enables Innovation
Complexity
Innovation
© 2013 Kaazing Corporation
XaaS integration – the Web beyond the browser
Anything Else Missing?
Other Considerations for the Real-World…
Need to handle multiple WS versions
What about multiple (and legacy) browser versions?
Must handle unfriendly network intermediaries
Can’t have business logic in the DMZ
Has to work in multiple DMZs
AuthN/AuthZ has to work
multiple times
Need high-availability topology
Concerns about open ports with back-end
service
Services architecture needs to be consistent
Native, HTML5 and hybrid environments
Integrate easily with non-messaging services
Bandwidth management
All things you need for a real enterprise app Other language libs
© 2013 Kaazing Corporation
Futures
What’s next for WebSocket?
© 2013 Kaazing Corporation
Explosion of Open Web APIs
§ APIs from everywhere § Over 10K public APIs and even more Mashups
- programmableweb.com/apis/directory - Amazon, Facebook, LinkedIn, AT&T, Google, Microsoft,
NYTimes, Orange, SalesForce, Telefonica, Twitter, Visa, Vodafone, Bloomberg, NYSE, Thomson-Reuters, etc.
§ Over time, more will be event-based – NoREST? § Mashape.com, APIhub.com § Enterprise and B2B APIs § Services… Services… Services…
© 2013 Kaazing Corporation
Industry View
© 2013 Kaazing Corporation
Event-based XaaS
Monitoring as a Service Integration as a Service
Enterprise Messaging as a Service
WAN Optimization as a Service
Governance as a Service
Database as a Service
Analytics as a Service
EAI as a Service
CDN as a Service
Trade Clearance as a Service
Windows Desktop as a Service
Sentiment Analysis as a Service
Auditing as a Service
Telephony as a Service
Data Center as a Service
Network as a Service
Risk Analytics as a Service
Backup as a Service
Security as a Service Notification as a Service
Identity as a Service Testing as a
Service
© 2013 Kaazing Corporation
History Repeats Itself
RPC
Asynchronous RPC
Messaging
Enterprise Web
REST
Asynchronous REST
Messaging
• 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?...
ESB ISB
© 2013 Kaazing Corporation
Other Event-based (“real-time”) Systems?
Communication
Presentation Music Logistics
Big Data
Risk Management
Home Security
Health Monitoring
Intelligent Appliances
Local Transportation
Monitoring/Management
Remote control
© 2013 Kaazing Corporation
Demos Robin Zimmermann
[email protected], @robinzim
§ Prashant Khanal § Software Engineer – Kaazing § [email protected] § Twitter: @ipras
§ David Witherspoon § Software Engineer – Kaazing § [email protected] § Twitter: @dpwspoon