Jabberwocky – a Jabber Component (XEP 0114) Container for Glassfish

Personally I think that writing Jabber component (XEP-0114) (in Java) should be alot easier than the current state of the art. After struggling with it and documenting my experiences in my post, I’ve decided that I would like to make it a little easier, for me at least.

So let me introduce Jabberwocky, a Jabber component container, (à la JavaEE), for Glassfish application server. The purpose of Jabberwocky, currently, is twofold:

  1. To ease the development of Jabber component by allowing developers to focus only on their component and leave the runtime environment to Jabberwocky. What this means is that you focus on writing the component by either implementing Component or extend AbstractComponent, package it in a XAR file (a regular JAR file with the suffix renamed to XAR) and deploy it, using standard Glassfish tools, to the container. You don’t have to write the ‘server’ to host your component as I’ve shown in this blog. The XAR package contains among other things the component’s class files, any dependent JARs and a deployment file.
  2. To ease the management of the components by integrating into Glassfish so what we get is out of the box start/stop/deploy/suspend/resume, configuration management, and with a little bit of work publish statistics and other management control via Glassfish’s JMX infrastructure.

There is actually a third goal, which is a stretch goal,  so lets just focus on the two that I’ve listed first.

The figure below shows how Jabberwocky is used:

You need to run an instance of Glassfish with Jabberwocky (the green box); you then deploy your component in a XAR package into glassfish (the white box). If the XAR package is successfully deployed the component will now start communicating with the XMPP server. XMPP users and other applications can communicate with the component in the usual manner.

One of the side effect of running the components in Glassfish is that you can deploy multiple XAR files; each of the component is isolated from each other. Also in order to make the container more scalable, I’ve reimplemented  igniterealtime‘s ExternalComponent and other related classes with non blocking I/O. There is a thread which polls all selectors every 2 seconds. This value is tunable.

For those of you who are keen to try out, I’ve got a pre alpha binary here. There is a readme file documenting the installation process. I’ve also included 2 examples. There will be a better release soon (next week I hope) with another posting in technicolor detail how to install.

%d bloggers like this: