In the previous examples, we deployed simple processing solutions that are deployable using GridGain's
peer-to-peer class-loading mechanism. We haven't done anything too complex, however, and as they
say, the devil's in the details.
Creating a Grid Node
Let's look at the infrastructural components of GridGain in detail. First, let's consider how a node is
started up. As we saw before, GridGain lets you start up nodes using the startup script in the bin
directory of the distribution. This script invokes a class of type GridLoader , of which there are many. The
GridLoader 's job is to hoist a grid node into existence. It responds to the lifecycle events and knows how
to work in specific environments. The one that gets started when you use the script that comes with the
distribution is the GridCommandLineLoader . There are others, though, including several for loading a grid
instance from within a servlet container or application server instance. A GridLoader instance is
responsible for many things, not the least of which is correctly calling GridFactory.start and
GridFactory.start can take as its first parameter a GridConfiguration object or a Spring
application context or a path to a Spring application context. This GridConfiguration object is
what tells GridGain what is unique about a given node and the grid's topology. By default, it uses
$GRIDGAIN_HOME/config/default-spring.xml , which in turn does things such as load a Grid object and
configure user parameters about a specific node. These parameters may be queried to determine the
candidacy of a node to handle a specific job. GridGain, because it is so deeply rooted in Spring, is very
flexible and configurable. Different subsystems may be swapped out and replaced. GridGain provides
several options via its SPI s. In the directory where default-spring.xml is located, there are several other
Spring configurations for grids demonstrating integrations with many other technologies. Perhaps you'd
like to use JMS as your message exchange platform? There are examples there for three different
vendors. Perhaps you'd like to use Mule, or JBoss Cache?
Provisioning a Grid Node
In the previous examples, we deployed instances that were self-contained and had no dependency on
any other components. When we do start introducing dependency — and you will, naturally — you'll
want to be able to leverage Spring for dependency injection. At this point, we lose some of the elegance
of GridGain's peer-to-peer class loading.
You can deploy a .GAR archive, for which there is an ant task, to package your .jars and resources
and then deploy that to every node's $GRIDGAIN_HOME/work/deployment/file folder. This is far easier
than it sounds if you can get away with an NFS mount or something like that to simplify deployment.
Additionally, you can tell GridGain to load a resource from a, HTTP, or another remote, URL.
This mechanism has a lot of advantages for production: your extra .jars are visible to the node
(which means you won't have to transfer megabytes of libraries over the wire each time you hot redeploy
a node instance), and, most importantly, the custom beans inside the Spring application context we've
been working with will be visible should you need them. When using this method, you can disable peer-
to-peer class loading; this, while not significant, represents a gain in startup time.
A .GAR archive looks like a standard .JAR or .WAR . It provides several things that are mainly of
concern for production. The first is that the libraries are already present, which we discussed. Secondly,
the gridgain.xml file, which is optional, enables you to tell GridGain about which GridTask classes