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

In consequence, though Client is only interested
in finding and listing topics (the operations of the
BookService interface), it has to know implemen-
tation details of BookDB .
The center of Figure 2 shows the DI version
of the application. The DI container nows injects
a concrete implementation of BookService , such
as our previous BookDB or a Web Service inter-
face to Amazon Books. Consequently, DI removes
the dependency between the client and the service
provider, because Client is no longer in charge of
instantiating an implementation of the topic ser-
vice. Besides, as long as different implementations
of the topic catalog realize BookService , any of
them could be used without modifying the source
code of Client .
JGRIM takes DI a step further by introduc-
ing an indirection between software components
to inject Grid metaservices (right of Figure 2).
After gridification the container no longer injects
a service implementation into the client but a
metaservice, which is for example able to find
the fastest service from several implementations
residing in the Grid. The client interacts with
the metaservice, which in turn interacts with
an implementation of the required service. This
indirection is transparent to the client: there is no
need to change its code, since both the service
implementation and the metaservice realize the
same interface ( BookService ). Besides discovery,
metaservices may add load balancing, fault toler-
ance, distribution, etc.
From an application perspective, after the
metaservice finds a proper service implementa-
tion S , it becomes a proxy to S . A service such
as the topic catalog, for which many realizations
may exist and access is mediated by interfaced
metaservices, is called a functional service (FS).
FSs are entities that expose their functionality
through clear interfaces. Within Grids, they are
often materialized as Web Services (Atkinson et al.,
2005). FSs are categorized as internal or external.
The former are parts of a complete application
that, during gridification, are exposed so that other

applications can use them. The latter are deployed
Grid applications, external to the application being
gridified, acting as building blocks. The second
type of services JGRIM takes advantage of are
called non-functional services (NFS). NFSs lack
a clear and standard interface to their capabilities,
as they represent abstract Grid concerns rather
than explicitly-interfaced services. Examples of
NFSs are parallelism, mobility, load balancing,
security and distribution (Service layer of Figure
1). An NFS also may have many materializations.
For instance, load balancing is simultaneously
featured by Ibis, Globus and ProActive.
Conceptually, injecting FSs sometimes also
requires the injection of NFSs, but not the other
way around. For instance, this would be the case
of using security mechanisms when contacting
or invoking FSs.

Gridification Process

JGRIM prescribes a semi-automatic gridification
process that developers have to follow to gridify
their applications, which consists of the following
steps (see Figure 3):

1. Developers identify application components
and dependencies between components that
will benefit from the Grid, or the hot-spots
for gridification within their applications.
Conceptually, hot-spot are the portions of
an ordinary application to which one or more
metaservices are associated.
2. Modification of the application code to obey
some simple and standard object-oriented
coding conventions, ensuring that applica-
tion components defined in the previous
step are implicitly linked through get/set
accessors using the JavaBeans style. Any
reference to a component C within the code
must be done by calling a fictitious method
getC() , instead of accessing it directly as
C.operation() . For example, if an application
reads data from a file component, it should