InfoQ

News

Grid Computing with the Java Parallel Processing Framework

Posted by Jason Lai on Jul 18, 2006 11:44 AM

Community
Java
Topics
Grid Computing
Tags
JPPF

The Java Parallel Processing Framework (JPPF) has been making frequent point releases recently. Currently at version 0.22, it is designed to distribute application tasks over a cluster of computers and coordinate their execution in parallel.   JPPF is made up of a client layer in which client apps request task executions, a service layer/JPPF Driver that queues execution requests from the client layer which will be taken by available nodes to process asynchronously, along with load balancing and recovery capabilities, and an execution layer on each node of the computation grid responsible for executing atomic tasks in parallel whose code is dynamically loaded from the JPPF driver. 

Defining a task is straight forward:

public class MyTask extends JPPFTask
{
public void run()
{
 ... my code ...

setResult(theComputationResult);
}
}

Then, submitting a task for execution from client code looks like this:

public class MyTaskSubmitter
{
 //Submit the tasks and wait for their execution.
 public void submit() throws Exception
 {
JPPFClient jppfClient = new JPPFClient();
List taskList = new ArrayList();
taskList.add(new MyTask());

jppfClient.submit(taskList, null);
 }
}


The key features of JPPF include:

  • An API to delegate the processing of parallelized tasks to local and remote execution services
  • API and UI support for server administration and monitoring
  • Asynchronous communication model to support a high level of concurrency
  • Scalability up to an arbitrary number of processing nodes
  • Built-in failover and recovery for all components of the framework (clients, server and nodes)
  • The framework is deployment-free: no need to install your application/task code on a server, just connect to the server and any new code is automatically taken into account

Licensed under the terms of LGPL, JPPF is aimed to be an open source alternative to the grid computing solution, in addition to the existing ones such as Globus, Sun's Grid Engine and Teragrid.

6 comments

Reply

Why Not using JavaSpaces? by Shay Hassidim Posted Jul 19, 2006 2:31 PM
Re: Why Not using JavaSpaces? by Cameron Purdy Posted Jul 19, 2006 7:21 PM
Re: Why Not using JavaSpaces? by ARI ZILKA Posted Jul 19, 2006 10:03 PM
Re: Why Not using JavaSpaces? by Guy Nirpaz Posted Jul 20, 2006 3:30 AM
Need to look more closely by ARI ZILKA Posted Jul 20, 2006 9:21 AM
Re: Need to look more closely by mohd yaqub Posted Apr 11, 2008 4:37 PM
  1. Back to top

    Why Not using JavaSpaces?

    Jul 19, 2006 2:31 PM by Shay Hassidim

    JavaSpaces seems as a better fit here. See GigaSpaces with advanced master/worker framework , HA , GUI and CLI tools etc. Shay

  2. Back to top

    Re: Why Not using JavaSpaces?

    Jul 19, 2006 7:21 PM by Cameron Purdy

    JavaSpaces is not an easy API to use to build applications with. The best api for work management might just be a WorkManager API ;-) .. you guys should check out both the IBM/BEA "commonj" APIs as well as the JSR 236/237 work that is a derivative of it. We've supported a grid implementation of WorkManager for a while now, and the feedback (ease of use, etc.) has been very positive. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid

  3. Back to top

    Re: Why Not using JavaSpaces?

    Jul 19, 2006 10:03 PM by ARI ZILKA

    JavaSpaces is not an easy API to use to build applications with. The best api for work management might just be a WorkManager API ;-) .. you guys should check out both the IBM/BEA "commonj" APIs as well as the JSR 236/237 work that is a derivative of it.
    Very kewl suggestion Cameron. I love the Workmanager pattern, generally speaking. How do I get access to your grid implementation to play around with it?

  4. Back to top

    Re: Why Not using JavaSpaces?

    Jul 20, 2006 3:30 AM by Guy Nirpaz

    There are several legitimate APIs out there. One should distinguish API from implementation. The implementation is what provides effective parallelism; the API has to be flexible and useable. Many people believe that a master/worker pattern based on Space semantics is adequate. For those who prefer a higher -level API, we offer Spring Remoting of the Space Based Architecture stack. Guy Nirpaz GigaSpaces: Write Once Scale Anywhere

  5. Back to top

    Need to look more closely

    Jul 20, 2006 9:21 AM by ARI ZILKA

    There are quite a few assumptions in this framework around how best to cluster. I am now concerned it might be a tad "too large." I will have to look into it more closely. Then again, my view of truly "simple" is--by now sounding like a broken record--true POJOs with nothing but the JDK or the JDK and Spring. I think Jonas Bonér offered up a very clean solution here: http://www.theserverside.com/news/thread.tss?thread_id=40552

  6. Back to top

    Re: Need to look more closely

    Apr 11, 2008 4:37 PM by mohd yaqub

    I hope Terracotta solves this problem in a much simpler and cleaner way .

Exclusive Content

VMware Infrastructure 3 Book Excerpt and Author Interview

VMware Infrastructure 3: Advanced Technical Design Guide and Advanced Operations Guide provides a wealth of practical insights into setting up virtualization in todays corporate environments.

Architectures of extraordinarily large, self-sustaining systems

Can a system that is so large it cannot be comprehended be "designed" in a conventional sense? The foundations of computing are about to change. In this talk, Richard P. Gabriel explores why and how.

Using Ruby Fibers for Async I/O: NeverBlock and Revactor

Ruby 1.9's Fibers and non-blocking I/O are getting more attention - we talked to Mohammad A. Ali of the NeverBlock project and Tony Arcieri of the Revactor project.

Agile and Beyond - The Power of Aspirational Teams

Tim Mackinnon talks about the aspirations behind the Agile principles and practices, the desire to become efficient, to write quality code which does not end up being thrown away.

Concurrency: Past and Present

Brian Goetz discusses the difficulties of creating multithreaded programs correctly, incorrect synchronization, race conditions, deadlock, STM, concurrency, alternatives to threads, Erlang, Scala.

ActionScript 3 for Java Programmers

Often the hardest part of changing technologies is language syntax differences. This new article provides Java developers with a transition guide to Actionscript which forms the foundation of Flex.

Neal Ford On Programming Languages and Platforms

Neal Ford talks about having multiple languages running on one of the two major platforms: Java and .NET. He also presents the advantages offered by Ruby compared to static languages like Java or C#.

Future Directions for Agile

David Anderson talks about the history of Agile, the current status of it and his vision for the future. The role of Agile consists in finding ways to implement its principles.