Disclaimer: Minimal load testing was performed with 10000 concurrent WebSocket connections. You can see some true performance numbers
here.
Here is the demo in action. As you can see on the right, I have 2 chat windows open and on the left we have a member registration. Users are chatting across a raw WebSocket connection and when another user registers, the CDI event is fired all the way through to the browser as a JavaScript alert via the connected WebSocket clients.
With WebSockets, we have a new development model for server side applications; event based programming. There are 3 out-of-box events associated with WebSockets: onopen, onmessage, and onclose. For starters, we must wire up these three listeners to utilize the core functionality that the WebSocket specification gives us. The open event is fired when the WebSocket connection is opened successfully. The message event is fired when the server sends data. The close event is fired when the WebSocket connection is closed.
But sending messages in the form of strings over raw WebSockets isn't very appealing when we're wanting to develop advanced web applications. Obviously, we're going to be using JSON to transfer data to and from the server. But how do we propagate our CDI events which are fired on the server and have them bubble up on the client?
First, we'll start with the server. I'm using the JBoss AS7 application server and embedding Jetty within my web application. Thanks to this article, I was able to easily add the latest Jetty server to my maven project (dependencies below) to get everything up and running in a few minutes.
A few things worth noting:
- Security: Since our WebSocket server is running on a different port (8081) than our AS7 server (8080), we must account for not having the ability to share cookies, etc...
- Proxies: As if proxy servers weren't already a huge problem for running WebSockets and HTTP over the same port, we are now running the separately (but I have a semi-solution for this below)
- Threading: Since we're observing/listening for CDI events, we must perform some thread same operations and connection sharing.
So, if you're still reading ;) let's get on with the code.
Download the latest JBoss AS7 (7.1.0.CR1b as of this writing)
Add the Jetty maven dependencies to your project. This demo is based off of the original html5-mobile quickstart for JBoss AS7.
Next we setup the WebSocket server using Jetty's WebSocketHandler and embedding it inside a ServletContextListener.
Here we're sharing a synchronized set of WebSocket connections across threads. Using the synchronized keyword, we ensure that only a single thread can execute a method or block at one time. The ChatWebSocketHandler contains a global Set of webSocket connections and adds each new connection as it's made within the Jetty server
View complete source here.
Now we'll create a method to observe CDI events and send the fired "Member" events to all active connections.
The above code will observe the following event when a new Member is registered through the web interface.
Finally, we setup our WebSocket JavaScript client and safely avoid using the eval() method to execute the received JavaScript.
Here is the JavaScript code which listens for our CDI event, and executes the necessary client side code. (This is the alert popup seen in the video above.)
One additional piece I added to this approach is the use of HAProxy. This gives us a reverse-proxy on the WebSocket port (8081), in the end allowing all traffic (HTTP and ws/wss) to be sent across a central port - 8080 in this case.
As you can see, this is a very prototyped approach to achieve $SUBJECT, but it's a step forward in adding a usable programming layer on top of the WebSocket protocol. There's probably a few framework out there which try to provide a programming model on top of WebSockets, so leave comments if you know of any.
Luckily I was in the right place at the right time and I must say that it was quite an honor to be allowed to make such a move. I’m looking forward to making good stuff happen.
