ActiveMQ vs. Jabber

If you have or plan an application with synchronous communications over an external API, it will sooner or later break. Why do we need asynchronous communications? Matt Tucker is clear about that:

Take, for example, Twitter. High Scalability recently covered the load stats on Twitter reporting that they average 200-300 connections per second with spikes that climb to 800 connections per second. Their MySQL server handles 2,400 requests per second! Recently, the [2008] Macworld keynote became the most recent culprit for causing Twitter to cut off its API, which has 10x the load of their website.

When one of my web pet projects needed a messaging backbone which extends to the browser. Whenever a resource did change on the server, all users watching the resource should get a notification without need to reload their browser. Two candidates are Javascript for ActiveMQ, which uses Comet

ActiveMQ supports Ajax which is an Asychronous Javascript And Xml mechanism for real time web applications. This means you can create highly real time web applications taking full advantage of the publish/subscribe nature of ActiveMQ.

ActiveMQ is a messaging bus, often used as an Enterprise Service bus as mentioned in my recent concurrency rant. Components can send messages to the bus and subscribe to topics.


smokin
Creative Commons License photo credit: mudpig

The other unsuspected contender is Javascript for Jabber. Jabber with the XMPP protocol is usally used for sending chat messages. Comparing these two and my thoughts:

ActiveMQ

  • Standard solution, JMS based
  • Routing solutions like Camel available
  • Easy access for different languages via Stomp
  • Attach Jabber as a service
  • Notification easily over topics

Jabber

  • Free OpenFire server
  • Messaging with only one user with UUID for resource which did change
  • Messaging with many users, who join one chat room
  • Chat rooms as topics
  • Server side filtering? How to make it secure, that people only get their own messages?

In the end I decided to go with Jabber/XMPP. The main points for me have been:

  • Server does scale to connections
  • Chat client can be used for debugging
  • Very easy to use with different programming languages
  • Presence protocol to detect services
  • Easy to implement additional chat solution

This worked quite well as a spike. I followed a similar mode as Adrian Sutton, who had good experiences with Jabber/XMPP too when spiking a cache solution:

We grabbed the Smack API and started playing with it and quickly discovered that sending and receiving messages was ridiculously easy. It turns out that the absolute simplest way you can minimize stale data in your caches is to simply have all the servers join a preconfigured chat room. Whenever they save a change to a resource they send a message to the room with the unique ID of that resource and whenever they receive a message from the room they assume it’s a unique ID and remove any cached versions of that resource.

Though I had some major problems accessing Jabber consistently from Javascript. With more on messaging in the backend, I would have went with ActiveMQ as a message bus. And perhaps I might move to ActiveMQ in the backend and then I’m still free to attach Jabber on top of that and keep the frontend code. Best from two worlds.

Think innovative, use technologies in a way to help you. Jabber/XMPP is more than a chat protocol.

John Resig on ExtJS, the GPL fiasco and open source community style

It seems as it does not end.

Reading a comment from John Resig, the (or one of the geniuses, sorry if there are more :-) genius behind jQuery, a library which was for some time a basis for ExtJs (beside YUI), irritated me a lot.


We (the jQuery project) worked hard with them to try and fix bugs and add features for an ExtJS integration layer. They turned around and built their own, specialized, library (removing the need for any of our work) and then mutated the licensing into this bizzaro scheme that they have now. We can’t, in good consciousness, even recommend their library anymore due to its very nature. On top of this they ended up hiring our lead evangelist to promote their work. I can’t speak for everyone on the team but I feel quite frustrated and used.

I’m speechless about the style of ExtJS. Without the not correct comments on my blog by Jack I wouldn’t believe someone could act this way.

I think you are missing the point. This has nothing to do with money, we are doing fine financially. It had to do with cleaning up what had until 2.1 been a hodge-podge of licenses that came out of necessity into a clean simple licensing structure that is aligned with what we expected all along.

says Jack. Sure it’s about money, everything could be clear – or to most people is clear – with the LGPL. No need to switch to the GPL at all. When it’s about being open source, switch to the ASL. And I find it highly irritating how Jacks kids are always dragged into this ydiscussion as in “my kids are waking up so I have to cut this short.” and “With my third child due, and savings running low”. I have no kids on my own but most certainly not drag them into a business discussion as an excuse.

Funny thing: “Ext JS is currently asking for input on two FLOSS exceptions to help make open source usage of Ext JS more flexible.” if this plays out like the switch to LGPL or GPL, hooray another episode in this mind boggling soap opera.

Update: “The intention of this exception is to allow for more liberal licensing of extensions, language packs, themes and open source developer toolkits and frameworks for Ext libraries under a variety of open source licenses.” on their blog.

Sure, because the more liberal the licenses of extensions are, the better it would be for the commercial side of ExtJS. Best to have the extensions as Apache licensed code and ExtJS to be GPL. The Ext LLC can reuse and resell the extensions without bothering. “(Note: this exception is not for applications and does not grant any exception for the library itself. A FLOSS exception on the libraries for open source applications will be addressed in the exception discussed in “Next Up” below).” This is so ridiculous and gives Open Source such a bad name. They hurt everyone who tries to make a living in the open source space.

Another ExtJS GPL thought – Should extensions switch to the GPL?

Sorry, this would better go to twitter – but I’m not twittering.

Another thought. And not because I want to bash ExtJS, but because I’ve been interested into the GPL, open source licensing and the implications for over a decade.

IANAL. The best situation for the company behind ExtJS would be if extension developers stay with the LGPL for their extension (or switch to a more liberal Apache license). The people who buy the OEM license from Ext can then use the extension. If someone releases his ExtJS extension as GPL, to be more “in line” with ExtJS, people with the OEM license cannot use the plugin, because it’s GPL (they can use the extension in a way that their customer need to download and install the extension on his own, but this is most often too cumbersome for customers. They are not allowed to distribute their commercial application with the extension or any code which references the extension).

The plugin writers do not gain anything for staying with the LGPL license, but Ext LLC gains a lot. It makes their OEM license much more valuable. If every Plugin writer switches to the GPL version, this could have an impact on the OEM sale. Especially because most enterprise won’t touch GPL software.

The best for a plugin author is to also go to a dual GPL/commercial license.

Very interesting situation.

Update: Very interesting