Moving from Kaazing to NodeJS backend

Openfire Openfire Support
1

We had been using Kaazing, which comes bundled with Openfire 3.6.0a for a Websockets based HTML5 Chat application. We need to get rid of Kaazing, and wish to use NodeJS for the socket server. So, I was wondering what is involved with migrating a given version of Openfire (e.g. 3.7.x or 3.6.x) to run on a node.js based server backend, and if anyone has any detailed information on this subject. We used Kaazing for the WebSocket server support and related gateway functionality, and had not written any custom server-side Kaazing or other code-- we just ran the default Openfire installation on top of the Kaazing install.

2

I am curious as to why you want to move away from Kaazing? Their gateway is pretty much the only thing doing native protocols and emulating websockets in various browsers going back to IE6.

Of course, it is possible to migrate to node.js, but be prepared to re-write a number of features, not the least of which is parsing the native XMPP protocol, and full backward compatibility for older browsers. If it’s the cost you’re concerned with, you might just want to talk to Kaazing and see if they can help you. They’re a pretty cool company and would probably give you a break.

3

Although Kaazing is great (the “king” as some say) for doing the many things it supports, including fallback communications support; sadly, it is too expensive for the volume of customers we have to support (almost $1mm/year just for Kaazing licenses).

As you say, they are a really great group of people and developers, but it just does not make business sense for this project. Over the past 9 years of being heavily involved with socket and Websocket related technologies including Kaazing (open source versions and since), I know how to roll my own nodejs-based solution, and, just in case, I have already scoped out what is involved for the several month project to replace it-- including all of the below things we will need to replicate across the whole project. However, I was just wondering if there is anything out there to replace it.). I am pretty familliar with many of the various WebSocket, XMPP and related technologies currently available, but like anyone, I still learn something new every day. So, I am just asking the community if anybody knows, or is in the process of developing any such alternatives.

  1. Websocket Server with high scaling capabilities;

  2. Automatic Websocket tranport negotiation failover (i.e. from Websocket, to Flash Socket, to Long Polling, to multipart streaming to Hidden Iframe to JSONP Polling, as necessary for the given client);

  3. Client-side libraries to integrate Websocket and related IO;

  4. SSL/TLS transport wrapper extensions;

  5. Protocol Validation for XMPP and WebSockets;

  6. Protocol gateway with redirection;

  7. CORS support (Cross-Origin Resource Sharing);

  8. LDAP gateway redirection and coop authentication;

  9. Session keep-alive (heartbeat) support;

So, given that, I just wanted to get a broader set of input than what is in my own head.
Thanks so much for the input.

4

Hi,

I’d be interested in learning a little more about what you’re trying to do and see what we can do to keep you using Kaazing. Please contact me or provide your contact info and I’ll be happy to reach out to you too.

Thanks,

Peter Moskovits

Developer Evangelist, Kaazing

[myFirstName].[myLastName] at kaazing dot com

5

Take a look at the Websockets Connection manager plugin for Openfire