faultCode0faultStringWarning:include_once(analyticstracking.php): failed to open stream: No such file or directory in /data/htdocs-users/hogie/public_html/software/index.php on line 7faultCode0faultStringWarning:include_once(): Failed opening 'analyticstracking.php' for inclusion (include_path='.:/usr/share/php5:/usr/share/php') in /data/htdocs-users/hogie/public_html/software/index.php on line 7 Deploying and running distributed Java applications on shared-nothing clusters
Deploying and bootstrapping distributing Java applications made easy
Home › Description

Jacaboo is a zero-configuration middleware enabling the deployment and the bootstrapping of distributed Java applications over Share-Nothing Clusters (SNCs).

The primary motivation for developing Jacaboo is to have an efficient and comprehensive deployment infrastructure for the BigGrph distributed graph library.

Jacaboo's design makes it suited to the experimentation of distributed applications. It is started from a specific node called the initiator node. This specific node is allowed to be out of the computational cluster. For instance, the initiator node may be the workstation of the developer, who can hence execute his distributed code from inside his favourite IDE. The initiator node simply needs to be given the names of the computational nodes it will contact, as well as the permission to access them through SSH. If these requirements are met, then Jacaboo is able to start the distributed application by executing the following workflow:

  1. it automatically discovers the application binaries by scanning the application classpath;
  2. it deploys the binaries found in an incremental way, dealing with shared filesystems (NFS, SSHfs, Samba, etc);
  3. it deploys a compliant Java virtual machine on cluster nodes, if needed;
  4. it bootstraps the application by running a local main() on every cluster node;

This process is fully automatized. It is hence transparent to the programmer/user.

Jacaboo-based applications have the following properties:

  • the standard outputs (stdout and stderr) of their remote components are forwarded back to the initiator node, which facilitates tracing/logging;
  • exceptions on remote components are forwarded back to the initiator node in the form of exception, which allow the caller to deal with them using standard try/catch blocks;
  • killing any process on any node results in the entire shutdown of the application on the entire cluster.