Grid Computing with the Java Parallel Processing Framework
- Share
-
- |
Read later
My Reading List
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();
ListtaskList = 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.
Why Not using JavaSpaces?
by
Shay Hassidim
See GigaSpaces with advanced master/worker framework , HA , GUI and CLI tools etc.
Shay
Re: Why Not using JavaSpaces?
by
Cameron Purdy
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
Re: Why Not using JavaSpaces?
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?
Re: Why Not using JavaSpaces?
by
Guy Nirpaz
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
Need to look more closely
by
ARI ZILKA
www.theserverside.com/news/thread.tss?thread_id...
Re: Need to look more closely
by
mohd yaqub
Educational Content
Large-Scale Continuous Testing in the Cloud
John Penix May 24, 2013
.jpg)
Managing Build Jobs for Continuous Delivery
Martin Peston May 24, 2013
Clojure in the Field
Stuart Halloway May 23, 2013
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think