January 3, 2011 2 Comments
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.
- 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.
- 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:
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.