The Definitive Guide to HTML5 WebSocket

The book is on the way now! You can pre-order it here. It has been so much fun and a lot of work but I personally hope you can get a copy and enjoy all the content we're putting together.

Here is part of the book description if you want more information about it:

"The Definitive Guide to HTML5 WebSocket is the ultimate insider’s WebSocket resource. This revolutionary new web technology enables you to harness the power of true real-time connectivity and build responsive, modern web applications.   

This book contains everything web developers and architects need to know about WebSocket. It discusses how WebSocket-based architectures provide a dramatic reduction in unnecessary network overhead and latency compared to older HTTP (Ajax) architectures, how to layer widely used protocols such as XMPP and STOMP on top of WebSocket, and how to secure WebSocket connections and deploy WebSocket-based applications to the enterprise. Build real-time web applications with HTML5."

The book gives you an overview of HTML5 WebSocket, the WebSocket API and the protocol, the high level protocols you can use on top of WebSocket, security aspects and enterprise deployment. 

The WebSocket bufferedAmount attribute

If you have been working or planning to work with HTML5 WebSocket you may end up transporting large amounts of data and/or you may have the requirement to transport data as fast as possible. 

The WebSocket object has an attribute called bufferedAmount that's particularly useful to check for the amount of data buffered for transmission to the server. You can use the bufferedAmount attribute to check the number of bytes that have been queued but not yet transmitted to the server.

The values reported in that attribute don’t include framing overhead incurred by the protocol or buffering done by the operating system or network hardware.

The code below shows an example of how to use the bufferedAmount attribute to keep sending updates every second, if the network can handle that rate, or at whatever rate the network can handle, if that is too fast.

// Buffering threshold at 10k

var THRESHOLD = 10240;

// Create a New WebSocket connection
var mySocket = new WebSocket(“ws://echo.websocket.org/updates”);

// Listen for the opening event
mySocket.onopen = function () {
 setInterval(function() {

// Check for amount of data buffered but not sent yet //and then send an update in case there is nothing //in the buffer

if (mySocket.bufferedAmount < THRESHOLD)

                                    mySocket.send(getUpdateData());

                  }, 1000);

};

Using the bufferedAmount attribute can be useful for throttling the rate at the applications send data to the server avoiding network saturation.

Checking for WebSocket Support on Your Web Browser

It’s frustrating to execute some code and don’t see anything happening after that. But, depending on the web browser you or the end user running your application is using that may be impacting the WebSocket functionality at this point since not all current browsers in use support HTML5 WebSocket natively yet.

So, let’s take a look on some techniques to make the web browser supports WebSocket.

We are going to use the JavaScript console available in all web browsers to start with the WebSocket support investigation. Each web browser has a different way to initiate the JavaScript console but if you’re using the suggested web browser (Google Chrome) take a look on the following resource to learn more about it (https://developers.google.com/chrome-developer-tools/docs/overview).

If you open your browser’s interactive JavaScript console and evaluate the expression window.WebSocket you should see the WebSocket constructor object:

 function WebSocket() { [native code] }

which means that your web browser supports WebSocket natively.

The same test above in some other browsers comes back blank or undefined indicating no native support.

If you want to add that capability for WebSocket support to your application or on our sample client code, you can use the following approach.

By just adding the following conditional check to your code before you try the WebSocket connection then it would be enough to tell you if the web browser supports WebSocket natively.

if (window.WebSocket){
     console.log("BROWSER SUPPORTED");
} else {
     console.log("BROWSER NOT SUPPORTED");
}

If your target web browser doesn't support HTML5 WebSocket and you want to have that amazing capability on your application, it's time for you to look into some vendors like Kaazing where you have WebSocket emulation that enables any browser (modern or not) to support the HTML5 WebSocket standard APIs.

From the developers perspective they can work in a fully transparent environment, using the client libraries that enable them to simply code against standard WebSocket APIs. And from the end-user point of view, they interact with a WebSocket application that Kaazing’s WebSocket emulation technology kicks in when native WebSocket support is unavailable, giving the user a seamless experience.

There are several web sites available on the Internet to help you with compatibility, not only WebSocket, but also HTML5 features in general. To mention a couple of them, you can navigate to http://caniuse.com/ or http://html5please.com/ and check for the HTML5 feature you want to use on the target web browser manufacturer and/or version.

The WebSocket readyState attribute

The WebSocket object will report the state of its connection through a read-only attribute called readyState.

There are four different values that the readyState attribute can receive to represent the state of the connection.

0 - CONNECTING – The connection has not been established yet.
1 - OPEN – The connection has been established and messages can be exchanged between the client and the server.
2 - CLOSING – The connection is going through the closing handshake.
3 - CLOSED – The connection has been closed or could not be opened.

When the WebSocket object is first created its readyState is 0, indicating that the socket is CONNECTING.

Inspecting WebSocket Frames

So far, it has been a challenge for us working with HTML5 WebSocket to analyze the traffic going back and forth from the client to the server and from the server to the client. Without using packet sniffing tools like Wireshark or tcpdump the analysis and debugging of WebSocket messages is almost impossible.

But, recently, things are changing and it's now possible to see frame data along with arrows indicating the direction of the data is going to.

A WebKit patch has been created and you can use Chrome Canary to check the latest changes and start inspecting WebSocket frames. A huge advance for those working with HTML5 WebSocket.

There is also a step-by-step demo located here: http://blog.kaazing.com/2012/05/09/inspecting-websocket-traffic-with-chrome-developer-tools/

Accessing Databases with HTML5 WebSockets and Apache Camel

As I have said on my previous post, I've been working with several companies with the most diverse use cases and one that really brought my attention was the requirement to access databases using HTML5 WebSockets which seems to be a clever thing to do with the right tools.

So, basically what I've setup for this is represented on the picture below:

Let's go over the implementation details of all of the components described here:

From right to left, the backend datasource I had to use was MySQL that you can download from http://www.mysql.com/downloads/. Then, I used Apache Camel as the backend framework accessing the database and also exposing a TCP-based component (Mina in this case). Moving to the left, we have the Kaazing WebSocket Gateway connecting to the Apache Camel framework and exposing WebSocket connectivity to the web clients (browser-based, mobile-based and desktop thick client applications).

The web-browser sample client is pretty straightforward and with a few lines of code you can get the functionality. There are sample javascript clients shipped with the Kaazing WebSocket Gateway that you can re-use or modify to your needs. The Kaazing WebSocket Gateway documentation set is also helpful and good starting point. Check it out: http://tech.kaazing.com/documentation/html5/3.3/o_dev_js.html

Then the only change you have to make in the Kaazing WebSocket Gateway is in the gateway-config.xml (under $KWG_HOME/conf) to include the service you want to expose to the web clients and where you want to connect to the backend framework with access to the database.

Here is what I have included on my configuration:

<!-- Demo JDBC Backend System Config -->

  <!-- Proxy service --> 

  <service>

<accept>ws://${gateway.hostname}:${gateway.extras.port}/jdbc</accept> 

<type>proxy</type>

<properties>

<connect>tcp://${gateway.hostname}:8888</connect>

</properties>

   </service>

Check the Kaazing WebSocket Gateway documentation to get more familiar with these settings.

Last but not least, the Apache Camel route hosting the Mina endpoint and the database connectivity:

 <camelContext xmlns="http://camel.apache.org/schema/spring">

    <package>com.kaazing.gateway.demo.db</package>

    <route id="WSMinaJDBCSample">

        <from uri="mina:tcp://localhost:8888?timeout=30000"/>

        <log message="RECEIVED: ${body}"/>

        <setBody>

        <simple>select * from customers where customers.email = '${body}'</simple>

        </setBody>

        <to uri="jdbc:myDataSource"/>

        <log message="GENERATED: ${body}"/>

    </route>

</camelContext>

<!-- MySQL datasource -->

  <bean class="org.springframework.jdbc.datasource.DriverManagerDataSource" id="myDataSource">

    <property name="driverClassName" value="com.mysql.jdbc.Driver"/>

    <property name="url" value="jdbc:mysql://localhost:3306/test"/>

    <property name="username" value="root"/>

    <!-- <property name="password" value="XXXXX"/>  -->

  </bean>

The MySQL database setup is very simple and you can use any sample database tables you want. Just make sure you update the Apache Camel route and your environment settings accordingly.

Code will be available soon...

UDPATE:
Sample code is now available at: https://github.com/mjabali/DBOverWS

It's not lack of content...

We all have that excuse of no time for blogging or lack of interesting content for not updating our tech-y blogs but in fact there are tons of interesting things that I'm working on right now like a JDBC over WebSocket project which seems to be a really nice thing to do and also an end-to-end prototype that we at Kaazing put together for an airline company.

Basically, the airline use case goes from backend JMS-based systems to mobile devices over WebSocket using Kaazing WebSocket Gateway JMS Edition notifying the users about gate changes and flight cancellations. You gotta see this in action! It's super cool... Since it has some proprietary systems I won't be able to show you all parts but I've been working on a generic version of it where you can install all the pieces in your machine and run the whole thing locally. Ping me if you want to take a look on that.

The other project that I'm working on is the JDBC over WebSocket which basically uses Kaazing WebSocket Gateway HTML5 Edition to connect to an Apache Camel route with a Mina component and JDBC access to a MySQL database. Everything is pretty straightforward and I'll be writing a tutorial on that in the near future. But, if you need any additional info or sample code just let me know and I'll walk you thru whatever is needed to get you going...

Stay tuned!

Installing Erlang on Mac OS X Snow Leopard

I'm working with a customer who is using the Kaazing WebSocket Gateway - AMQP Edition with RabbitMQ and while his install was pretty straightforward on Windows 7 I thought the same would be applicable to my case (a Mac user). Well, to summarize the process, it was quite of a challenge to get everything working, not from the complexity perspective but for the number of steps involved in the process to get the environment running starting from the point that RabbitMQ depends on Erlang to run. So, that was the first step... Installing Erlang on Mac OS X

Here are the steps I had to take:

- Download and install Apple Xcode 4.3 from Apple's AppStore (yeah, you read it right!)

- The tricky part here was to enable Command Line Tools which is not selected by default in Xcode. To do that, go to Xcode Preferences --> Downloads --> Components and install Command Line Tools. It's just another 170MB over the already downloaded 1.35GB of Xcode :)

- Download Erlang latest release from http://www.erlang.org/download.html

- Extract the Erlang package (i.e. tar -xvf otp_src_R15B.tar) and navigate into the recently created directory

- Run ./configure

- Run ./make

- Run sudo make install

Hope this help you to get your project going...

Quick Start with the Kaazing WebSocket Gateway in Less Than 6 Minutes

One of my colleagues at Kaazing just recorded a very nice tutorial on how to get started with the Kaazing WebSocket Gateway using the extreme powerful JMS Edition.

It only takes a few minutes to download, install, start up, and try out the Kaazing WebSocket Gateway. So, it's really worth it...

You can take a peek here: http://vimeo.com/36919680

Enjoy...

Moving On...

Well, it has been a while since I updated this blog and there are many reasons just to say that I wasn't motivated enough to write anything lately. Some personal issues as well as another job change associated with a short vacation contributed to the delay but the good part is that I'm back and really happy with how the year is shaping up. 


It seems to be that all personal stuff is sorted out and I also have decided to join Kaazing as a Solutions Architect. Kaazing is the first Enterprise-grade Web Communications Platform leveraging HTML5 WebSockets designed for real-time, massive scalability and providing reliability necessary for companies to deploy those kind of solutions over the web.


If you're not familiar with HTML5 and WebSockets and I'd recommend you to take a look on the following presentation available at http://www.infoq.com/presentations/WebSockets-The-Web-Communication-Revolution.


Stay tuned for more...