From the get go we put developers productivity as one of our main goals without sacrificing any enterprise grid computing features. But then you would think – how easy can it really get, any product can be installed and set up relatively easy. Here is a good analogy for you – think IPhone. I never thought that using my Motorola cell phone was hard, but IPhone just makes my life a lot easier. I can now check weather or flight status within seconds (things I didn’t even bother doing on my old cell phone). The same kind of productivity you get with GridGain. Take a look at some of the GridGain features that make it so easy to use and work with.
Uniform Programing ModelThis basicaly means that your application should produce the same results wthether there is no grid, 1 node in the grid, or a 1000 nodes in the grid (of course the more nodes you add, the faster and more scalable your application should become). When writing your boiler plate code you should not worry about grid-enabling it. However, if you ever do need to grid-enable it, grid-enabling logic should be orthogonal to your business logic. GridGain provides two ways you can grid-enable your code.
Transparent Grid-EnablingWith transparent grid enabling you can move execution of your code to the grid by simply attaching
@Gridify annotation to it, like so:
public class BizLogic {
@Gridify
public Object process(Object arg) throws ProcessException {
// Perform bizness logic here.
}
}
Without GridGain, method
process(..) above would simply run locally, as usual. However, by simply attaching
@Gridify annotation, the execution of this method will be taken to a remote grid node. This alone can significantly improve scalability of your application, as now you have automatic fail-over, node topology management, and load balancing provided to you by GridGain out of the box.
Now, if you decided that your method
process(..) takes to long and you need to split its execution, you would need to implement
GridTask interface to tell GridGain how your logic will be split. However, the only change you would need to make to your main code is specify which task it should use like so:
@Gridify(taskClass = MyProcessTask.class)
API-based Grid EnablingIf you would like to use direct API calls instead of
@Gridify annotation or if you need to wait for results asynchronously, GridGain allows you to do it as well. Simply invoke any of the
Grid.execute(..) methods directly as following:
Grid grid = GridFactory.start();
// Execute.
GridTaskFuture<Object> future =
grid.execute(MyProcessTask.class, /*task argument*/someArg);
// Wait for result.
Object result = future.get();
Or for asynchronous execution you would execute your task as follows:
GridTaskListener resultListener = new MyProcessTaskResultListener();
grid.execute(MyProcessTask.class, someArg, resultListener);
Zero DeploymentThis means that you don’t need to explicitly deploy your code when using GridGain. When developing with GridGain, you can simply start up several grid instances, and then write your code in the IDE of your choice as you would usually do. When ready to execute, just click Run button in your IDE and watch your code execute on the grid. All the classes and resources will be automatically deployed to all participating grid nodes absolutely transparently to a user.
Just think how much time you will save from not having to constantly run Ant or Maven builds to deploy your code to all remote nodes. Every time you change your code, just hit a Run button and GridGain will automatically detect that and load the changed classes.
Simple StartupGridGain startup is as easy as it gets – just execute gridgain.sh or gridgain.bat scripts under
bin folder and you got your grid node. There are no ports or IP addresses to configure, it all happens automatically (of course you have an option to change it if you have a need).
But there is more. You can start multiple instances of grid nodes on the same box without any extra effort. Just think how much time you would have to spend trying to configure multiple instances of JBoss on the same machine – it’s doable, but it’s not easy. With GridGain, you just execute the same startup script multiple times and that’s it - you got your grid on your laptop. When developing and testing on your local box, this does come in handy.
On top of that, you can start multiple GridGain instances in the same VM. This becomes extremely useful during debugging. Just set breakpoints in your code as you would usually do locally, hit Debug button in your IDE and you are able to step through your code as it executes on the grid. You don’t need to setup remote debugging to run your code “remotely”.
TestabilityTestability of a distributed system is always a big issue. However, with GridGain, ability to startup multiple grid instances in the same VM makes writing Unit Tests extremely easy. Simply startup several grid nodes within the same test and perform all the necessary checks. Here is a simple JUnit3 example:
public MyGridTest extends TestCase {
// Simple test case.
public void testGrid() throws Exception {
GridConfiguration cfg1 = new GridConfigurationAdapter();
GridConfiguration cfg2 = new GridConfigurationAdapter();
cfg1.setGridName("grid1");
cfg2.setGridName("grid2");
try {
Grid grid1 = GridFactory.start(cfg1);
Grid grid2 = GridFactory.start(cfg2);
GridTaskFuture<Object> future = grid1.execute(MyTestTask.class, ...);
Object result = future.get();
assertNotNull(result);
}
finally {
GridFactory.stop("grid1", true);
GridFactory.stop("grid2", true);
}
}
}
I guess I will stop here, otherwise this post will never end :)
Please visit
GridGain Website for more features and developer documentation.
Recently I have had to work a lot with NetBeans. We are working on integrating GridGain management console with SUN VisualVm, so NetBeans is pretty much the only IDE we have available for the task.
View comments