WebSockets with ColdFusion
Today I released a ColdFusion WebSocket Gateway on RIAForge and Github. The name pretty much says it all. It is a event gateway for messaging between ColdFusion and conforming clients via the WebSocket protocol. The gateway is based on Nathan Rajlich's Java-WebSocket server implementation, which I updated to support both WebSocket draft 75 and draft 76 clients. For more info on how to install and use this gateway see the Github wiki page.
How This Project Came About
A few weeks ago a co-worker asked about keeping multiple web clients in sync. He mentioned he was currently using AJAX polling, but wondered if there were better methods. He specifically asked about using LiveCycle Data Services (LCDS) with ColdFusion and wanted to know if anyone had any further information on how to do this. While I have not done a whole lot with LCDS, I do have experience with BlazeDS, so I decided to put together a quick demo showing how to keep two lists in sync using the BlazeDS AJAX client library. (The code for this demo is available here.)
This ultimately led to a discussion about Pusher and WebSockets. I had seen Ben Nadel's posts on Pusher, and I knew there were Pusher libraries for ColdFusion, but I also knew ColdFusion had a socket gateway, which got me thinking about how to implement WebSockets for ColdFusion without having to use a third party service like Pusher. I found a few WebSocket servers for Java, but Nathan Rajlich's ended up being one of the more straightforward implementations, the only issue was it needed to be updated to support the latest version of the WebSocket specification. So I took a few days and updated the Java-WebSocket server and client implementations and wrapped the server in a ColdFusion Gateway interface. The results are the ColdFusion WebSocket Gateway.
I have to admit that I wasn't the first to get this idea. After creating my project on Github I was contacted by Julian Gautier, who had created CFWebsocket earlier this month. His project is also based on Java-WebSocket, however it doesn't support as many server configuration options as my implementation. I've been talking with Julian since I found out we have similar interests in WebSocket support for ColdFusion, so we may end up combining our efforts to improve the current offerings.
As always, feedback is welcome. Please let me know what you think of this project and what can be done to make it better.




Does that make sense?
With web sockets all of the web browsers connected to the same "channel" will receive the data sent from the server without having to make a request. Examples of the data could be a message from any one of the connected browsers (like a chat app) or a status update of a process on the server sent by the server without any request from a browser.
@Johans: Yeah, I realize the difference between WebSocket and AJAX, but I was completely forgetting about SendGatewayMessage(). When I was looking at the documentation on the site, I wasn't seeing how the server could initiate a message, only how it could respond to incoming messages. If the server can't push, than its pretty much like handling an AJAX request.
When it comes to WebSockets, I automatically thought of the KEG (Kaazing Enterprise Gateway) until now; but it is NOT free for deployment ...
Please allow me to ask several questions:
- In April 2011, is Your "ColdFusion WebSocket Gateway" still recommended by You ?
- Which JavaScript/Ajax library should be used on the Web Clients ?
- I know that the KEG does NOT provide sophisticated messaging capabilities itself; of course, neither can do the "ColdFusion WebSocket Gateway"; the KEG hooks itself instead into TCP-based Messaging Engines (AMQP, JMS, etc.); how can the "ColdFusion WebSocket Gateway" be leveraged for providing sophisticated messaging capabilities from ColdFusion to Web Ajax Clients ?
TIA for Your reply
Cheers and Tschüss
Kai (Tischler) from Northrhine-Westfalia in Germany