HTML5: Using WebSocket for Mobile and Web Convergence?
Designed back in 1989 as a simple markup language for sharing text documents and static content across the slow and unreliable 1990s networking, HTML has long overstayed its welcome as the web language of choice. Nobody foresaw the need to incorporate graphics, sound, alternate devices, or the possibility of ubiquitous wireless network connectivity.
Is it time to look again at HTML5 as a converged development platform for delivering real-time content to a plugged in audience?
Declared complete in December 2012, HTML5 offers the advantages of simplified development, semantics, and security by default. By eliminating the need for plugins and extensions, it avoids the possibility of introducing potential security vulnerabilities through added application complexity.
HTML5 is strongly associated with JavaScript because it transfers the workload back to the local machine rather than relying on the server side to do all the heavy lifting. The advantage is faster content delivery, but it does assume that the client application has the horsepower and proper security settings.
All modern browsers support HTML5. However, be aware that none supports ALL the new features, and to make matters more confusing, each supports a different subset of the functionality. Since modern web and mobile applications typically are expected to support multiple environments, there might still be a need to build emulators for some desired features.
One of the more interesting new HTML5 features is WebSocket, a stateful connection that allows sessions to traverse firewalls, proxies, and routers. This allows the client browser to access multiple sites on a page with essentially unlimited connections per domain.
WebSocket uses a standard W3C API and IETF protocol that establishes a bi-directional single connection over port 80. For example, an insecure connection URL would look like: ws://site.com/page, while wss://anothersite.com/securepage would be a secure connection URL.
Some see WebSocket as the TCP of the modern age. WebSocket is very flexible. It can be run outside of a browser or on the command line, so it can be used to establish secure application-to-application connections and company-to-company connections over the Internet.
Currently, WebSocket has only four calls, but that will probably change as the need for session-based real-time traffic increases. For example, a developer might want to layer JMS on top of WebSocket. The biggest disadvantage of WebSocket is that it assumes there is a reliable network.
App developers are rediscovering the advantages of stateful connections for real-time connections and speed. It seems ironic that stateful connections and harnessing local computing, thrown away a few years ago for being too insecure and unreliable, are now making a comeback. Hopefully we will not be bringing back PointCast any time soon!
