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

Table 2. Test applications: code metrics

k-NN Image restoration

Tool TLOC GLOC Tool TLOC GLOC

Original 192 N/A Original 241 N/A

Satin 1477 10 Satin 227 5

ProActive 404 404 ProActive 299 17

JGRIM 166 4 JGRIM 226 0

JGRIM (with caching policy) 179 6 JGRIM (with mobility policy) 233 1

by comparing TLOC (Total Lines Of Code) and
GLOC (Grid Lines Of Code) metrics for the
original applications and their gridified counter-
parts. Basically, these metrics were computed as
follows:

From Table 2, it is clear that at least for these
applications, JGRIM obtained good TLOC and
GLOC. Satin k-NN resulted in high TLOC since
the platform does not provide support for using
Web Services. On the other hand, ProActive sup-
port for Web Services is minimal. This feature,
however, is crucial to achieve interoperability
across Grids (Atkinson et al., 2005). Conversely,
discovery metaservices allowed JGRIM k-NN to
delegate dataset discovery and access to the un-
derlying platform, discarding the code for using
a file-based dataset present in the original k-NN
application. Moreover, achieving parallelism (i.e.
classify several instances in parallel) with Satin
and ProActive demanded more API code. Remark-
ably, unlike its competitors, the JGRIM API was
only used for coding policies, not affecting the
original codes. These facts suggest that using
JGRIM may lead to more maintainable and por-
table Grid code, since JGRIM effectively pushes
most of the code for handling Grid-specific con-
cerns out of the application logic. Besides, the
lower GLOC values of the JGRIM applications
indicate that JGRIM is appropriate for users not
proficient in JGRIM or even Grid technologies,
as the amount of API functionality that is neces-
sary to learn before using the tool is much less
compared to employing Satin and ProActive.
To evaluate the performance and resource
usage of the Grid-enabled codes, each gridified
version of k-NN was used to classify several list
of input instances with different sizes (5, 10, 15,
20 and 25 instances). For the image application

• TLOC : Number of non-blank, non-com-
mented code lines including algorithms,
code for interacting with data, performing
Grid exception handling, and parallelism.
Note that this metric is closely related to
the extra effort necessary to adapt the ordi-
nary version of the applications to execute
on our Grid.
• GLOC : Number of lines within the code
of a gridified application that explicitly
access the underlying Grid platform API.
Intuitively, the larger the GLOC, the more
the time a developer spends learning the
API. In addition, greater GLOC means the
application is more tied to a specific Grid
library.

Before measuring, all codes were uniformly
formatted with the help of the Eclipse SDK. Table
2 summarizes the obtained values for these met-
rics (lower values are better). Moreover, for the
JGRIM applications we obtained two variants by
implementing a caching policy for k-NN, which
stores dataset accesses to reduce network traffic,
and a mobility policy for the image application,
which explicitly moves application components
to reduce network latency.