RGraph Scatter Plot using WebSockets

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.

WebSockets are a new protocol coordinated by the IETC (The Internet Engineering Task Force) that tries to complement our old friend HTTP which falls short in some aspects of the Web 2.0. A WebSocket is a bidirectional (communication can be started by server or client), full-duplex (both ends can send information at the same time), minimal overhead (only two bytes are used in each frame), long lived (it remains opened until an end explicitly closes it) communication channel over a single TCP socket. Standardized by the W3C the JavaScript WebSockets API is completely asynchronous and very easy to use. The protocol also defines new ws:// and wss:// prefixes which indicate a WebSocket and a WebSocket Secure connection respectively. This technique is clearly defined for avoiding all the pain associated with AJAX/Web2.0 frameworks (overcoming HTTP limitations, more simplicity, better performance,...).

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 JAX-RS resource class is replaced by a WebSocketApplication (Grizzly WebSocket 1.9 API). PlotApplication.java is the real class and JAXB is still being used for marshalling and unmarshalling stuff (the same PlotData object is used but JAXB is now directly called). Other difference is that JSON is now used in both ways (communication from Server/Java to browser/JavaScript and vice-versa).
• 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.
• The JavaScript in the server side also needs to be changed, basically prototype.js is replaced by the WebSocket API. So now the TestRGraphChart.js (JavaScript object) and TestRGraphChart.xhtml (Facelets page) are slightly modified in the sending/receiving part.

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!