Skip navigation
All Places > Ignite Realtime Blog > 2012 > September
2012

A few years ago, Matt and Gaston wrote a good introduction to XMPP Publish and Subscribe. You can read it here.  Back then, Pubsub was regarded the killer feature of XMPP looking for an application. Since then, Twitter has now shown us how to use Pubsub and many XMPP clients like Jappix now have realtime micro-blogging implementations using XMPP Pubsub.

 

I have been developing realtime business web applications that use Pubsub for a while now and my normal tools for such work would be Flex/ActionScript with XIFF to develop the Flash client and Java for the Openfire plugin. With Pubsub, I am not doing the classic client request and server response of multiple HTTP pages from a web server. It is usually a single page dynamically updated on each client responding to pushed subscribed events as they are published among clients. The server side code is just another publisher. Read this for more infromation about this approach.

 

Thanks  to Apple's IOS and Google's V8 JavaScript engine, Flex/ActionScript is now past tense and it is all about HTML5/JavaScript. JSON over WebSockets with NodeJs even makes a lighter and even sometimes, a better replacement for XMPP and Openfire plugins developed in Java.

 

Despite all the buzz about JavaScript as the single development language for client, server and network messages, the corporate market in which I do most of my work still has its user directories locked up in Microsoft Active Directories, all its mission critical data stored in Oracle and MS SQLServer databases and its enterprise applications living in Java bytecode. This means for some to come, Openfire, XMPP and all the application features (clustering, security, permissions, provisioning, user/groups, etc) will remain the choice application platform for my line for work.

 

However, I have to use HTML5 for developing my realtime web applications and the case for JavaScript everywhere is compelling. This lead me to investigate a JavaScript library or framework that I could use as my application platform and would be compatible with OpenfireJS on the server.

 

To cut a long story short, I have ended up with Backbone.Marionette. I seriously considered Derby and Meteor, but the heavy dependency on NodeJs was a show stopper.

 

Backbone has an XMPP Pubsub implementation in Strophe which I modified to work with Openfire.

 

In evaluating the myriad of JS frameworks/libraries, I used the excellent TodoMVC.

 

Image2.jpg

 

In the spirit of the TodoMVC project, here is a TodoMVC implementation of Backbone.Marionette with XMPP Pubsub all working in Openfire with no server side code. Pubsub manages the storing and distribution of the JSON data. Open as many application web pages. They are all showing the same data always in sync in realtime. If I wrote a server script in OpenfireJS, it would not be to respond to client requests, but to publish new Todos from an independent source.

By Tom Evans

 

A few of you more intrepid Openfire fans may have noticed a bit of recent activity in one of the branches of the Openfire SVN repository. Well, some of your fellow developers have been working behind the scenes to provide clustering support for PubSub, perhaps one of the lesser-known modules of our beloved real-time collaboration server. PubSub is an implementation of the XEP-0060 specification which extends the XMPP standard to add publish-subscribe functionality to the XMPP Core. However, if you have ever tried to use this module in Openfire, you may have been disappointed to discover that it was not designed to work in a clustered deployment. In fact, PubSub was forcibly disabled when deployed in a cluster! The main focus of the development effort was to address OF-205 and implement clustering support for the PubSub module. This work is now complete and the PubSub module is cluster-enabled and ready for action.

 

My Kingdom for  a Cluster!

 

However, during the course of this development effort, the team also took a critical look at the current clustering implementation itself (the "clustering" plugin). This solution is currently the only way to run Openfire in a clustered configuration (where multiple servers share the load). Unfortunately this plugin is inextricably tied to Oracle Coherence, an enterprise class (and enterprise priced) middleware component. A recent quote from Oracle put the price of Coherence (EE) at well over $300K for a smallish deployment ... clearly an untenable solution and incompatible partnership with the Openfire project.

 

We looked around for clustering alternatives that would have better affinity with Openfire, and landed with Hazelcast (Community Edition). Hazelcast is an open source clustering and highly scalable data distribution platform for Java. It enjoys a large deployment base and is licensed under the community-friendly Apache 2.0 license. There are also commercial licensing options available for deployments where professional support and enterprise security (among other features) are must-haves. This looked like a perfect fit for our needs, and likely for the Openfire community as well.

 

Where Two or Three are Gathered...

 

We are pleased to annouce the immediate availabilty of a new Hazelcast-based clustering plugin for Openfire. Starting today in the trunk of the Openfire SVN repository you will find the new plugin (/src/plugins/hazelcast/). Note that you will need to also setup the latest version of the Openfire core (currently 3.7.2-Beta) to use the new plugin.

 

We are looking for a few brave Openfire afficionados who can take the latest build and give it a whirl with your various deployment scenarios:

  • How many users and/or cluster member nodes do you have?
  • Which modules/components of Openfire are you using?
  • What is your typical JVM configuration? Preferred OS? Network topology (load balancer, LAN/WAN, etc.)?

Your feedback is very important and will help ensure that this new clustering solution will be a robust and stable component in the next Openfire release.

 

Those who have wrestled with the existing clustering plugin will hopefully find the new solution to be much simpler to configure and deploy ... and certainly much lower cost! There is a README file included with the new Hazelcast plugin that documents the basic steps for setting up an Openfire cluster, including links to the supporting Hazelcast documentation (if needed).

 

Testing ... Testing ... Is this thing on?

 

Please take the new build for a spin and report your feedback here. We will be posting an article to the main community page before long, but would love to have some initial feedback from the core developers before engaging a wider audience. No doubt there will be some bugs and configuration glitches ... can you help us find and fix them?

 

Thanks in advance for your consideration and assistance.

 

Cross posted from http://community.igniterealtime.org/message/224947#224947

 

--UPDATE--

 

I have added a slighlty modified version of hazelcast that is backwards compatible with Openfire 3.6.4 and Openfire 3.7.1. Unzip and copy the clustering.jar file to your plugins folder.

 

Please test and post your results at http://community.igniterealtime.org/message/224947#224947

Filter Blog

By date: By tag: