Anyway, WebSockets allow Servers to basically "push" data back to subscribed Browser clients in an effective manner instead of using workarounds such as long-polling. The WebSockets API is being standardized by the W3C (http://dev.w3.org/html5/websockets/) and the actual protocol is being defined by the Hypertext-Bidirectional (HyBi) working group (Part of IETF) - http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-09.
For further reading and to learn more about WebSockets in general, please also check out the following resources:
- http://www.html5rocks.com/en/tutorials/websockets/basics/
- http://websocket.org/
- https://developer.mozilla.org/en/WebSockets
- http://en.wikipedia.org/wiki/WebSockets
- http://hacks.mozilla.org/2010/12/websockets-disabled-in-firefox-4/
- https://developer.mozilla.org/en/WebSockets
Firefox 6 is supposed to bring back websockets support, albeit using a newer draft of the websocket protocol (hybi-07), which is not backwards compatible.
What about Web Servers?
Okay, so WebSockets look cool, yet with limited browser support. Furthermore, different webservers have varying stages of support for asynchronous messaging, with Jetty and Glassfish being the best options currently a provide native websocket support. It looks like Resin also has direct websocket support. See also:
Tomcat 7 currently does not support WebSockets, yet. Check out the following issue tracker entry to learn more about the current state of affairs in Tomcat 7:
What's next?
So, essentially what we want is some kind of framework that supports "graceful degradation": when available a suitable framework shall use websockets, but if not available, the framework should fall back to more traditional push work-arounds such as long-polling.
On the server-side, I am running Java, and therefore, I need a respective implementation on that platform. Choices, though, seem to be rather limited and I came up with the following list of options:
- Atmosphere (http://atmosphere.java.net/)
- Socket.IO (http://socket.io/) - Orginally for Node.JS there are Java implementations available
- jWebSocket (http://jwebsocket.org/)
- Stomp Websocket for HornetQ and ActiveMQ (http://jmesnil.net/stomp-websocket/doc/)
- https://github.com/maccman/juggernaut
- https://github.com/socky/socky-server-ruby
- https://github.com/igrigorik/em-websocket
Socket.IO looks like it has quite some traction but the default implementation is for Node.JS. There are Java implementations available but they did not seem to have much traction. jWebSocket actually looks promising but its licensing (LGPL) is too restrictive to me (My choice needs to be Apache license compatible ;-).
Out of the list above, I chose Atmosphere (http://atmosphere.java.net/). Atmosphere has pretty much all the features you would like to have incl. detecting server-side capabilities and using the best possible approach transparently. Atmosphere comes with a jQuery plugin that abstracts away the implementation details (same Api for using long-polling vs. websockets)
While Atmosphere comes with quite a few examples, they are interestingly mostly for JAX-RS and there are no examples for Spring MVC. Also, the documentations is rather limited but luckily you get very swift and helpful responses from Atmosphere mailing list.
In my next posting, I will provide a little example integrating Spring MVC and Atmosphere. So stay tuned.
Nevertheless, if you have other WebSocket recommendations and/or thoughts, please leave comments!
PS:
A funny thing, I just realized that Burr Sutter, a friend of mine and fellow AJUG board member wrote down his WebSockets research experiences as well. It is a small world. Go check it out at:
3 comments:
Play Framework, a java based framework is pretty good in general also also has great support for websockets
Waiting for your post about the integration with Spring :)
Siwpas 2.0.0 will support WebSocket. You can check siwpas from http://siwpas.mechsoft.com.tr
Post a Comment