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.
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.
Frank Sommers: Could you describe how a programmer interacts with the Web Socket’s API?
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.
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.
> I am curious how WebSockets addresses two fundamental > issues: scalability WRT clients, and statelessness.
sheesh, hasn't everybody given up on 'statelessness' already? i mean that somewhat in jest, because i like engineering principles -- but i think most live commercial sites do /something/ or other in order to have state. there are principles, and then there's what everybody is doing to make a buck?
> sheesh, hasn't everybody given up on 'statelessness' already?
Smaller sites use state because it is so convenient, but many high volume sites intentionally avoid server side state because of the scalability challenges it presents. Client side state (such as cookies) can be very useful here. Of course, eventually there is state needed in the database, and there might be a cache layer in front of that which mirrors that state as well, but holding state in the web tier is by no means necessary.
WebSockets itself does not address scalability. The spec defines the protocol and nothing more. Scalability is really up to the vendor. Kaazing Gateway was built on NIO and leverages a SEDA-based architecture. Through effective async processing of requests we have been able to connect hundreds of thousands of users to a single machine.
State is more dependent on application level protocols than on WebSocket. For example, you can build an XMPP client on top of WebSockets. In this case, the definition of state is defined by XMPP and as such should be handled by the client and the XMPP server that you are connecting to via WebSocket. Therefore, state would be managed on the client (i.e. in the browser) and/or the XMPP server.