HTML 5 WebSocket cracks the HTTP request-response barrier

In this interview we speak to Jonas Jacobi and John Fallows, the founders of Kaazing. Kaazing is the creator of the Kaazing Enterprise Gateway product and is active in the real-time bi-directional Internet technology space with the Kaazing gateway leveraging the new HTML 5 WebSocket standard. Jonas and John talk of the need for two way communication and compare it with established request-response and Ajax models of communication. They also touch on how WebSocket can be used in JavaEE applications and its impact on existing architecture and code.

Harshad Oak >> Welcome to IndicThreads! Could you please introduce yourself and Kaazing?

Jonas Jacobi >> Hi Harshad! Really great talking with you again, it’s been a while. Well, many still recognize us for the work that we did at Oracle with ADF Faces, and also for the book that we authored – Pro JSF and Ajax. A year and a half ago we decided to fulfill a dream to create a new company with a vision of unlocking the full networking potential of the Web. The fruit of that labor is a company called Kaazing and the product is called Kaazing Enterprise Gateway.

John Fallows >> Kaazing is a company that is centered around a new breed of technology and the HTML 5 Communication standard. Kaazing’s products are the first to fully support the HTML 5 WebSocket and Server-Sent Events standards, a standard that will evolve browser networking to the next level. With Kaazing’s Enterprise Gateway, plug-in free browsers can leverage the power of the HTML 5 Communication standard today, even before browser vendors have added native support.

“Kaazing’s products are the first to fully support the HTML 5 WebSocket and Server-Sent Events standards, a standard that will evolve browser networking to the next level…”

Harshad >> I guess you would have answered this question 100s of times but as the question is still out there, can’t help but ask – What is Comet & WebSocket and why is two-way communication required?

Jonas >> Ha ha! Yes, we do get this question a lot. We have been working on research and development since 2006 to find the best solution for browser networking, including the use of Comet and WebSockets.

“For 20 years, we have been told that the ONLY way to use the Web is with HTTP and its request-response paradigm…”

For almost 20 years, we have been told that the ONLY way to use the Web is with HTTP and its request-response paradigm. So, naturally there is no initial requirement for two-way communication per se, but over time developers have improved the user experience of the Web by various techniques and technologies, and most recently with Ajax & Flash.

By fooling the end-user into believing that data “just” appears, while in reality we “still” make extra requests behind the scenes (using Ajax), we have opened the flood gates to more requirements and demands for an even richer Web experience. Demands such as porting traditional desktop applications to the Web, such as trading, betting, IM, poker games, and many more. These are typical applications that require server initiated message delivery, often with mission critical information.

We can already see companies such as Meebo, Facebook, and Google providing their end-users with proprietary browser-based IM solutions, and this is just the beginning.

“We are still not addressing the traditional limitation of the Web – its stateless, request-response HTTP architecture…”

This progress is all great, but we are still not addressing the traditional limitation of the Web – its stateless, request-response HTTP architecture. Some might argue that this architecture was necessary back then for the Web to gain widespread adoption, but in order to create and deploy these types of Web-based real-time applications, developers need reliable architectures and technologies that provide true bi-directional communication today.

This is where HTML 5 WebSocket and, as you mentioned, Comet come into play.

“Comet and HTML 5’s WebSocket are different…”

John >> There is a distinct difference between Comet and HTML 5’s WebSocket.

Comet is a term that describes a technique allowing servers to push information to Web clients via the HTTP response. To achieve this, implementations are mostly relying on long-polling, and in rare cases – streaming, but with an astonishing amount of hackery to bridge server-side message delivery to something that the browser can understand. This in turn adds latency, performance overhead and unnecessary complexity.

HTML 5 Server-Sent Events (SSE) formalizes Comet to eliminate the hackery by standardizing the syntax of messages in the HTTP response, and by describing the reconnect semantics used after the HTTP response completes.

“HTML 5 Server-Sent Events (SSE) formalizes Comet to eliminate the hackery…”

HTML 5 WebSockets, on the other hand, defines a JavaScript API for a bidirectional, full-duplex communication channel over a single TCP socket. A WebSocket connection is established by upgrading the connection from the HTTP protocol to the WebSocket protocol during the initial handshake between the client and the server, providing integration with the existing HTTP architecture of the Web.  Once the handshake is completed, the protocol is upgraded from HTTP request-response to WebSocket data framing, and text messages can be sent back and forth between the client and the server at any time.

“WebSocket upgrades the connection from the HTTP protocol to the WebSocket protocol during the initial handshake…”

Harshad >> How are these push technologies different from those we have been hearing about for several years? One can’t help but think of Pointcast, which was once the rage (1996) but later sank supposedly because PointCast’s endless appetite for bandwidth overwhelmed connections and clogged corporate networks.

Jonas >> If we look at the current Comet technologies available there are definitely similarities, but also differences. As with previous attempts to enable real-time message delivery, current Comet technologies have been forced to rely on the HTTP protocol and the request-response paradigm. Compared with previous attempts – in this case I mean late 90’s and early 2000 – Comet technologies are benefiting from recent developments within the community, and more specifically Java NIO. This new development technique allows Comet servers to process more than one socket connection per server thread, which increases vertical scalability at the server.

“Comet technologies are benefiting from Java NIO…”

John >> The HTML 5 WebSocket standard addresses the fundamental limitations of the HTTP request-response paradigm, by eliminating HTTP from the equation after the initial WebSocket handshake over HTTP.  This minimizes the amount of network traffic needed to send messages between browser and server in either direction, because no HTTP headers are included after the protocol upgrade is complete.

“HTML 5 WebSocket addresses the fundamental limitations of HTTP…”

Previous attempts did not have the luxury of upgrading the protocol, nor did they have such modern browsers to rely on for client-side processing.  In many cases, previous attempts either required browser plug-ins, were limited to a small fraction of browsers with non-standard push enhancements, or were forced to use full HTTP request-response round trips on the most common browser to be informed when the server wanted to send some data.  All of this led to overwhelming use of bandwidth and server scalability issues.

{mospagebreak}

Harshad >> Is there an overhead involved in going with server push instead of the normal request-response or even the Ajax model? Are there scenarios where Comet / WebSocket might be overkill and should be avoided?

John >> If your architecture is exclusively based on Remote Procedure Calls (RPC) then Comet is not needed because Comet provides “push” and RPC over HTTP is the opposite of “push” over HTTP.  However, WebSockets is beneficial in both “push” and RPC scenarios, because it can eliminate the overhead of bridging RPC over HTTP to the real back-end protocols, such as JMS, Jabber, JMX, RMI, JDBC, leading to improved server scalability.

With the traditional Ajax request-response paradigm, an HTTP 1.1 persistent connection is typically used by the browser to keep sending HTTP requests to the same server over the same TCP connection, so the server is maintaining an open socket connection for that purpose.  Of course, there is a timeout to clean up a dormant connection, partly because less scalable servers might be commiting a thread of execution to each open connection, and partly because the browser has a maximum number of total persistent connections to share.  A new TCP connection can easily be re-established when needed by the browser for the next HTTP request.

“Comet is not needed if architecture is based on Remote Procedure Calls (RPC)…”

In cases where Comet is used, the HTTP persistent connection never gets a chance to timeout, because the response is almost always in progress.  In cases where browsers do pro-actively timeout responses that are still in-flight, the Comet servers typically send a heartbeat back to the browser causing it to reset its local timeout.  Naturally, this is only needed for dormant connections, because sending data in the response automatically resets the local timeout.

WebSocket connections eliminate the overhead of HTTP headers entirely and do not timeout either.  By eliminating the glue code typically found in the Web tier of traditional Comet and Ajax applications, server scalability and performance is significantly improved.  In fact, total data throughput is much more relevant to WebSocket server scalability than the total number of concurrent connections.

HTML 5 WebSockets are a smart choice to integrate with bi-directional back-end protocols.  HTML 5 Server-Sent Events are a smart choice to integrate with push-only back-end protocols.

Harshad >> Do you expect all RIA applications to soon rely on real time updates or will usage be limited to niche areas like stock broking? Any popular applications that already use Comet?

Jonas >> It will take some time before real-time updates are available to all users on the Internet, but it is more of a question when it will happen, not if it will happen. You can already see companies such as Meebo, Facebook, and Google attempting to provide their users with Web-based IM clients. There is also an increasing interest from industries such as Finance and online gaming to provide real-time updates.

“You can keep your existing infrastructure in place and add a WebSocket server alongside to enable full-duplex communication from the browser…”

Harshad >> So what would my architecture look like? Where does the Kaazing server fit in?

John >> Using an HTML 5 WebSocket server, your architectural impact can be kept to a minimum.  You can keep your existing infrastructure in place and add a WebSocket server alongside to enable full-duplex communication from the browser.  Depending on your application needs, you can instead replace your Web-tier entirely with a WebSocket server.

Kaazing Enterprise Gateway is the industry’s first HTML 5 compliant WebSocket server and users can get it either with an enterprise subscription or as an open source alternative.

Harshad >> How would the code for a normal JavaEE application change if one uses Kaazing’s Comet / WebSocket solution?

John >> The JavaEE technology stack consists of many different APIs, including Servlets, JSP, JSF at the Web tier and EJB, JMS, and JDBC at the application tier.
The impact of using a Kaazing Enterprise Gateway is relevant only to the Web tier, which implicitly impacts the JavaScript code running in the browser as well.

“Kaazing Enterprise Gateway only impacts the web tier of JavaEE applications…”

Kaazing Enterprise Gateway provides an emulation of the WebSocket API today, working on all modern browsers without requiring any plug-ins and without the dreaded “page-still-loading” indicator.  In certain cases, when we detect the presence of a particular plug-in, we can provide a more efficient emulation of the same WebSocket API, but developers can remain blissfully unaware of the details, and focus directly on using the WebSocket JavaScript API.

You can configure Kaazing Enterprise Gateway to act as a WebSocket proxy for connecting to application tier technologies, such as JMS, directly from the browser.  This requires a JavaScript implementation of the protocol based on the WebSocket API.  Investing in this strategy now supports falling forward directly onto the HTML 5 WebSocket standard later, when it becomes available as a native part of browsers when they begin to implement the standard.

“With Kaazing Enterprise Gateway you get full client-side access to any server-side protocol…”

With Kaazing Enterprise Gateway you can have full client-side access to any server-side protocol such as JMS, JMX, SMTP, XMPP, and many more.  This leaves you with several options; you can use any Ajax toolkit, Flex, Silverlight, or something like GWT for Java developers, or you can continue to use the Servlet tier alongside. Your application suddenly became a lot lighter and tremendously cheaper to maintain and support.

Harshad >> Can I get Comet / WebSocket capability out of the box with any of the popular application servers? I am sure readers would want to know what are the other alternatives for two way communication on the web. How does one evaluate and compare these alternatives?

Jonas >> There are several attempts to provide Comet out of the box by the application server providers using something called Bayeux.  But be aware that Bayeux is NOT a standard. It is an HTTP-based wire protocol for Comet, currently used by a few application server vendors (Glassfish, Tomcat, Jetty). There is some effort to get Bayeux into the Servlet 3 specification, but from our point of view this would be fruitless since Bayeux is already superseded by Server-Sent Events in the HTML 5 specification.

“Getting Bayeux into the Servlet 3 specification would be fruitless since Bayeux is already superseded by Server-Sent Events…”

John >> That’s right, and Kaazing Enterprise Gateway supports HTML 5 Server-Sent Events wire protocol syntax on all modern browsers today.

Harshad >> Finally, with multiple vendors doing different things in the WebSocket space, is it safe to develop a WebSocket application today without any risk of getting locked into a vendor? Can I be sure that a WebSocket application developed today will work fine when WebSockets start being supported natively by browsers?

Jonas >> I don’t know of anyone else providing a fully compliant WebSocket server, but there are some early python-based open source projects targeting WebSockets. From our point of view, as long as you develop against the standard APIs defined in the HTML 5 specification you should be fine regardless of which WebSocket server you choose. For example, our Kaazing Gateway will automatically detect if a browser provides native support for WebSocket and use this for added performance.

Harshad >> Thanks Jonas & John. It was wonderful talking to you both. WebSockets and real time web applications definitely looks like an exciting space that all developers need to take a look at.

Jonas >> You are welcome. As always, it was great chatting with you and get this chance to educate IndicThreads readers about HTML WebSockets.

Harshad >> For more on Kaazing check out http://www.kaazing.com. You can also learn more on these technologies at the Comet, WebSocket sessions at the IndicThreads.com Conference On Java Technology 08.