The Middleware Diet
The benefits of replacing Comet and AJAX with a native socket implementation in terms of latency reduction are apparent. However, what is not apparent is the impact Web Sockets will have on traditional enterprise applications, particularly those applications that rely heavily on middleware. With a more efficient channel of communications between browser and server, we are sure to see an acceleration in the shift back to client-side development - a transition first initiated by the AJAX community and further supported by Adobe and Microsoft. This shift will not only impact software architecture, but will bring with it the added benefits of eliminating unnecessary "glue" or "translation" code and the thinning of the loads now carried by our overburdened application servers, all of which will continue to place a downward pressure on latency.

Lightening the Load
As an example, large corporations maintain a mind-boggling array of data services, ranging from JMS message queues to in-house IMAP and SMTP servers, or even custom proprietary protocols. A common effort within these organizations is to bridge back-end data services to the Web. Typically, this means taking an existing service and authoring code to translate messages produced by that service into a format (e.g., JSON or XML) that is consumable in a browser. With Web Sockets, this translation code is unnecessary. Using Web Sockets, the message format used behind your corporate firewall is equally at home in your browser, which means your client-side code is handling an alerted message delivered from your server. Eliminating translation code provides three key advantages. First, it limits complexity by removing the need for unnecessary code to support both internally and externally facing protocols. Second, it allows full exposure of your internal protocol capabilities, eliminating the need to dumb-down functions for use on the Web. Finally, it eliminates some of the overhead in delivering content to your customers.

At first glance, simplifying the bridge between your services and the browser has seemingly minimal impact. However, with full access to data services in their native format, the browser now provides a platform by which JavaScript (as well as Adobe Flex and Microsoft Silverlight) can be used to build feature-rich thick clients for your services. This means that the browser is not simply a lightweight client used for rendering displays, but is a fully featured client that in addition to rendering user interfaces, executes business logic that acts on your services and as a result lifts some of the burden from your over-taxed middleware.

Return of the Client/Server
The shift of code from middleware to client also means that transient state is now a function of the client as it was in the days of yore, when client/server architectures were the predominant application infrastructure. To some, this may appear to be a bad thing, but in reality it is exactly how we wished the Web to evolve. Client/server applications were abandoned primarily because of the costs associated with supporting applications on various operating systems over diverse network topologies. Applications were migrated to the Web to provide a single source of deployment and development. Web Sockets do not diminish this objective. Instead, they complement it by helping to reintroduce the rich client, but in a form that is compatible with the Web. In short, with the introduction of Web Sockets the "last mile" required to port desktop applications to the Web is quickly becoming a reality.

Re-Thinking the Web Server
AJAX and Comet introduced asynchronous processing to traditional Web servers, and made the staged event-driven architecture (SEDA) a mainstay. These advances paved the way for Web Sockets, making the Web server more than just a simple device to serve static content and establishing it as the gateway or proxy through which your services are exposed to the Web. However, existing Web servers still have a long way to go in order to support higher orders of concurrent persistent connections. The issue has been pervasive enough that some major companies have rolled their own servers.

Better Performance
For example, Meebo famously wrote its mod_meebo lighttpd extension in order to translate HTTP requests from the browser into XMPP to communicate with a Gaim server and support the startup's massive user base. Likewise, Facebook recently wrote its own epoll-based Web server to serve chat to its, as of the writing of this article, 100 million users. Neither Facebook nor Meebo used Web Sockets to build their applications. Instead, both companies built specialized solutions to meet their individual needs. However, Web Sockets represents a more general purpose solution than those implemented by Facebook and Meebo. Web Sockets, unlike the Facebook and Meebo solutions, has the ability to proxy any protocol, not just XMPP. Furthermore, Web Sockets, on a finely tuned server, is well suited to meet the demands of such applications and, Kaazing and its Kaazing Enterprise Gateway, offer solutions that provide the vertical and horizontal scalability necessary to support large numbers concurrent connections, preventing your development team from having to surmount the same feats as the engineering teams of Facebook and Meebo.

Richer Features
Beyond performance and scalability, Web servers in the Web Socket era must now provide more advanced security features. In particular, there is a requirement for general interfaces by which HTTP authentication is used to authenticate against services exposed to the Web. Protocol validation is also soon to become an important function of the Web server, providing a first line of defense against denial-of-service attacks on corporate services.

The Web Socket Server?
With the advent of the Web Socket, Web servers will soon diverge from their current role on the Web, moving away from a general purpose content server and becoming the "gateway" to all services. This multi-faceted role begs the question of whether "Web server" is even the appropriate vernacular for the modern Web server? Will we soon be deploying "Web Socket servers" instead? Only time will tell.

Summary
Low latency is the mother of interactivity, and in no place is this more apparent than on the Web. Every slip of a millisecond equates to a slower end-user experience, which in turn translates into elevated risk that a user's eyes will avert elsewhere. Both AJAX and Comet attempt to obscure latency problems, and certainly address the issue of user-perceived latency. However, Web Sockets removes the need to obscure such problems and introduces a real solution, one that does not play tricks on the perception of our end users, but delivers content in real time with real results.

References

• "Latency is Everywhere and it Costs You Sales - How to Crush It," Todd Hoff, Highscalability.com
• HTML 5 Specification, Ian Hickson and David Hyatt, W3C
• Kaazing Enterprise Gateway Product Information