Grid-Enabling Applications with JGRIM - Cloud, Grid and High Performance Computing: Emerging Applications - page 49

KNN application is executed, JGRIM searches an
appropriate dataset in the Grid and injects it into
KNN . Besides, JGRIM mediates between these two
components, hiding the actual location of the da-
taset and the communication details. Furthermore,
the application is converted into a Grid service
capable of transparently migrating its execution.
Thus, the application becomes a callable entity
that other applications can discover and use.
Now we will use JGRIM for executing KNN
in multiple distributed threads to improve its
performance. The sameClass operation classifies
two instances and compares the results:

value=”Classifier”/>
</bean>
</beans>

JGRIMMethodSpawner 1 parallelizes the invo-
cations to the methods specified by the Classifier
interface. Also, the programmer must replace the
calls to classifyInstance by calls to a fictitious
getclassifier method. Future uses of c1 and c2 will
block the execution of sameClass until their values
are computed by JGRIMMethodSpawner. This
coordination is supported through Java futures,
which are available in the java.util.concurrent
package of the JVM since version 5.0. Behind
scenes, JGRIM installs classifyInstance in several
computers of the Grid and dynamically finds idle
computers to execute one invocation per computer.
This is, JGRIM not only parallelizes KNN, but also
distributes its execution. For supporting parallel-
ism on Grids, JGRIM relies on Satin (Wrzesinska
et al., 2006), a subsystem of Ibis that is designed
to execute embarrasingly parallel computations on
distributed environments. Furthermore, a spawner
based on raw, local threads is also available.
Besides parallelism, JGRIM allows developers
to tune applications by using code mobility and
policies based on environmental conditions. To
briefly illustrate this mechanism, let us suppose
our MGS is deployed on a Grid of several sites
each hosting a replica of the dataset. Let us ad-
ditionally assume that bandwidth between sites
could drastically vary along time.
As KNN works by reading data blocks from
the dataset and then performing computations on
them, bandwidth indirectly affects response time.
Particularly, accessing a replica through a busy
network channel might decrease performance.
JGRIM metaservices, unless otherwise indicated,
assume that the best service instance is always the
one offering the highest throughput. Through a
policy, we can redefine what “best” means to an
application, i.e. the highest transfer capabilities
in our scenario.

...
c1 = classifyInstance(instA);
c2 = classifyInstance(instB);
return (c1 == c2);

The calls to classifyInstance are independent
between each other, thus they can be computed
concurrently. Let us exploit this by injecting par-
allelism into the sameClass operation. We have
to define an interface for the classifyInstance
operation:

public interface Classifier {
public double
classifyInstance(Instance instance);
}

After processing the code with JGRIM, a new
component is added to the XML file:

<beans>
<bean id=”knnComponent” class=”KNN”>
...
<property name=”classifier”
ref=”spawnerMetaService”/>
</bean>
...
<bean id=”spawnerMetaService”
class=”jgrimapi.JGRIMMethodSpawner”>
<property name=”spawnableMethods”