Saturday, February 19. 2011
Today entry is the last one (at east for the moment) about the Scatter Graph problem. If you remember this series started as a HTML5 migration study of an old applet scatter graph application, the first post tried to implement a XY client-side graph using Canvas element and the second one added Web Services real samples (prototypejs + JSON + JAX-RS). Now I am going to replace the Web Services for a new HTML5 feature: WebSockets. I had no experience at all with them and I think this is a good example where this new technique fits smoothly.
The technology has been hardly pushed by Google since the beginning, obviously this company is very interested in simplifying and improving web 2.0 applications. Therefore Chrome supports WebSockets since its version 4.0 and Apple joined later with Safari 5. Until some months ago the adoption was going smoothly with firefox 4 and Opera 11 announcing WebSockets as one of their new features. Nevertheless they turned out wrong when a protocol security flaw was discovered (standard is still in draft version 76). Adam Barth showed how a malicious code can be injected in the browser using a technique called cache poisoning (exploiting a problem in the initial handshake between client and server when a web proxy is involved). Some days after the bug was reported firefox announced the new feature would be disabled by default in its new beta and same did Opera. Microsoft was always more reluctant to WebSockets, even before the security flaw was pointed out they had not said a word about this protocol and IE9. In my opinion WebSockets is a perfect example of the current anxiety about the web (all browsers trying to support any new feature before competitors, no matter if the technique is mature or not, at the same time they put any stumbling block in another's path) but the technology behind them is clearly a good idea that just needs more time. Here it is a good and more detailed report of these events.
So now my scatter graph application is going to obtain the samples using a WebSocket instead of the prototype/JAX-RS web service. In order to use the new protocol both sides need to support it, for the client part default debian Chromium 6 will be used and Glassfish 3.1 (RC2 - b41) will be our Application Server (Glassfish uses Grizzly as its Web Server component which is the piece of software that really supports WebSockets). In the implementation side almost all remain the same but the following changes:
- The WebSockets technology in Grizzly needs a WebSocketsServlet.java to integrate the previous application into the WAR module. GlassFish Web Sockets Sample and Web Sockets and HTML5 in Glassfish are two good entries about how to implement a WebSocket Application using Glassfish/Grizzly.
- The WebSocket application uses the same JPA entities to access the database but now a simple EJB PlotQueryEjb.java has been implemented (adding @Stateless annotation to the WebSocket application threw an exception). CDI is used for injection as usual.
For all these reasons the video this time is similar and less interesting. I first execute a test.html page that shows the JSON data exchanged, only WAVE type is requested so the last 24 hours of wave highs are returned, the WebSocket is then closed. After that the same actions of the previous scatter graph video are performed (first showing sea level magnitude, one sample per minute, and then waves, one per hour). The WebSocket scatter graph has been tested with Chromium 6 and firefox4 b11 obtaining a good and smooth usability (FF4 needs to override the security block for WebSockets).
In short this entry is a presentation of the WebSockets, another HTML5 improvement. WebSockets are not just a new feature they are really a new protocol definition standardized to make an easier and better Web 2.0. Its adoption is being full of obstacles and many browsers do not support them by default (only Chrome and Safari right now). So current entry has to be intended as a training application and not a production ready example. You can download the complete NetBeans project used for the video from here.
Stay tuned for more about the Web Wars!