Mistral is an open-source, high-level layer on top of Java imaging engines, such as JAI or ImageJ. According to its documentation, Mistral

Allow[s] the programmer to focus on the algorithm, without wasting time on implementation details—a sort of extension of the WORA (Write Once, Run Anywhere) concept. Mistral goes even further, by providing a simple-but-effective ImagingProcessor which is able to schedule well-written image processing algorithms in different computing scenarios: from the single CPU, to the multi-core, up to the Sun Grid Computing Facility.

An interesting aspect of Mistral is that it provides a plug-in framework to clustering solutions that can process images in parallel. Mistral project lead Fabrizio Giudici recently posted a tutorial on extending Mistral with the Jini-based Rio clustering framework, Clustering with Rio.

While Jini defines a dynamic network environment for Java, with automatic service discovery and mobile code features, Rio extends Jini with capabilities needed for cluster computing. (For an overview of cluster and grid computing with Jini, see the Artima article, Dynamic Clustering with Jini Technology.)

Rio adds to the basic Jini framework, for instance, the ability for cluster nodes to advertise their capabilities, such as their available memory or CPUs, and for computing tasks to declare their requirements. The Rio system matches resources with requirements in the cluster.

In his blog post, Giudici highlights how Rio and Jini together form the basis of a high-performance cluster-based imaging engine built with Mistral:

In one of the simplest configurations... used by Mistral, you have a “master” node which runs the Provision Monitor, the LUS [Jini Lookup Service] and Webster [Rio's built-in Web server that serves up Java classes], and some “satellite” nodes which just run an empty Cybernode [the basic Rio compute node]. You can run any number of them, they will join your federation and the Provision Monitor will dispatch to them an instance of the RioServiceWorker bean, ready to accept and process ImagingTasks.

How does the deployment mechanism work? It is based on the “operational string”, which is just the equivalent of the EJB "deployment descriptor"—it's just more dynamic. In fact, since the number of nodes in the cluster is varying over time, and generally speaking it's not known a priori, deployment is based on Service Level Agreement (SLA), that is a set of rules to decide where a certain piece of code should run. Since Rio has a crush for Quality of Service, SLAs can be a function of things such as the CPU load, or the percentage of free disk space, or memory, or everything else you need (SLAs can be extended with custom code). This is really an interesting concept for Mistral—and more in general for clustering—as for instance it allows you to dynamically schedule workers only on hosts with an idle CPU.

With Jini recently having been accepted into the Apache family, it can provide an effective alternative to build high-performance compute engines, as Giudici's post illustrates. What Java clustering solutions have you used before?