Frank Sommers: WebSockets promises to allow us to bypass the Web server and create fully-duplex sockets between the Web browser and server components. How does WebSockets fundamentally alter how we build enterprise Web applications?

Ric Smith: If you think of how the Web works today, you can think of it as having a walkie-talkie, request-response communication: You click a button and say what you want to say; and then you have to wait for the response in order get something back. There is no way for the server to initiate any kind of communication back to the browser.

A new specification inside the HTML 5 spec, WebSockets, makes a full-duplex connection between the browser and the server possible. The HTML 5 spec is new, and none of the major browsers implement it currently. Our Kaazing gateway and our client-side JavaScript library enable WebSockets to work on existing browsers. Once browsers start supporting this standard, the client-side component of our tool will just use the native browser implementation of WebSockets. If you’re building a Web site, and want to use Web Sockets, therefore, you can do that now.

In a nutshell, then, Web Sockets allows you to have a push-style communication over a single connection. Some of the use-cases we see are interactive games written entirely in JavaScript and HTML; there is also interest in terms of casino-style gaming. We receive a lot of interest from the financial community: applications, such as trading platforms or stock matrices, can get real-time information to the browser using Web sockets.

Our client side library provides an emulation layer that works across the major browser versions. To back that JavaScript API, we have a server, or gateway, that manages the connections and provides a layer of security as well. When you’re accessing this backend directly from the browser, you have a proxy where you can inject your security credentials, and you can scale out all the persistent connections.

Frank Sommers: How does WebSockets compare with similar push-style technologies, such as Comet?

Ric Smith: First, Comet is not a standard. The Dojo community invented it, and it provides bi-directional communication that is limited to a pub-sub model.

Web Sockets, on the other hand, is a purely single-socket model: you’re not using two connections, one for a request, and one for the server to push data. Another big difference is that you’re provided a socket-level API with Web Sockets: You’re dealing with just point-to-point communication. It’s very easy to build a pub-sub type of model on top of Web sockets, so you could have the same interaction you currently have with Comet, if that’s what you wanted. However, Comet doesn’t do point-to-point: You have to create your own meta-channels, and it’s still going to be limited to the pub-sub model.

Ric Smith: As programmer, you open up a text editor and write an HTML file. Then, you open up two script tags, and in those script tags you instantiate a JavaScript object called WebSocket, passing it a URL that specifies the server you want to connect to. That will create the connection. There is a handful of callbacks you can add to that object such as onOpen, onClose, or onMessage. You would then use the postMessage() method on that object to post messages to the server. Once you’ve done that, you are then able to integrate various services with a Web Sockets framework.

There is a small configuration file on the server where you define the services that will be available. Those services, such as Active MQ or a database installation or a Web service, are proxied through the Kaazing gateway. As long as those services are TCP-based, you can declare them as service in the configuration file, and then you’ll be able to reference them via a URL when you instantiate a Web socket.

Another distinction between Comet and Web sockets, by the way, is that the message the back-end service sends in the Web Socket case is the same message that’s received in the browser. In Comet, a translation occurs: the back-end service would push the information to your Comet server, and that message is then translated to a format received in the browser. So Web sockets take out a major translation step, removing significant latency. In the XMPP case, for instance, when Google Talk sends a message, the server sends an XMPP message, in fact.

In a typical scenario, you run the Kaazing Gateway alongside a Web server, such as Apache. Apache still distributes all of your static data, so you could be coding in PHP, or using Tomcat, of instance, and write Java-based services, and along the Apache instance you have our gateway that proxies all of your socket connections. On the client, we have a very lightweight JavaScript library that gets downloaded from our gateway into the client browser.

We have an open-source version at Kaazing.org that you can download under an OSI-approved license. You can also download an evaluation of our enterprise offering. The open-source version provides the same functionality, minus APIs for Flex and some management tools.