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.

About TweetStream

The Code...

We used infinispan in both instances, but our @TwitterLocal is a single node caching a direct twitter stream from Twitter4J.

Now that we have our types defined as follows…

We need not only an implementation of each, but also a deciding bean that tells us which type to use.

First, our implementation of each Type implements an interface:

And our implementations have a different usage of the init method. TwitterLocal starts the stream coming from twitter and updates the infinispan cache. TwitterServer starts a method which allows us to start receiving data from the keynote which uses complex event processing and a datagrid with 6–8 nodes.

So now, how do we decide which Type to use? There are a few different ways to do it, but in the case of this being a demo and not a lot of time on my part. I used this approach:

This is all in the source code. Feel free to pull it and make improvements or run it to see it in action. There are many more blog posts to come from this demo, so stay tuned…