JPPF is a grid toolkit for Java that makes it easy to run applications in parallel, and speed up their execution by orders of magnitude. Write once, deploy once, execute everywhere! In this version:

• A new, very efficient load balancing algorithm was added.
• The administration console was upgraded accordingly.
• The server performance was enhanced.
• A web search engine application was added to the samples pack.
• Many minor bugs were fixed.

JPPF has many outstanding features: - a JPPF grid can be up and running in minutes - highly scalable, distributed framework for the execution of Java tasks - leverages JCA 1.5 to integrate with leading J2EE application servers - easy programming model that abstracts the complexity of distributed and parallel processing - graphical and programmatic tools for fine-grained monitoring and administration - reliability through redundancy, recovery and failover capabilities - a set of fully documented sample applications, demonstrating the use of JPPF on real-life problems - very flexible and non-constraining open-source licensing - and more .... JPPF is available under the Apache Software License. JPPF uses a standard server/client relationship, where a JPPF server farms out tasks to waiting clients (which can be J2EE servers, using the JCA module mentioned above.) Tasks are simple Java classes that are added to a submission queue, which then get sent out to waiting clients. The clients can share data using a number of mechanisms, including a memory map, url data providers, and others. An example of submitting a task and retrieving results is presented in the JPPF Wiki:/* * Submit a task */ //Perform a JNDI lookup of the JPPF connection factory InitialContext ctx = new InitialContext(); Object objref = ctx.lookup("eis/JPPFConnectionFactory"); ConnectionFactory factory = (ConnectionFactory) PortableRemoteObject.narrow(objref, ConnectionFactory.class); //Obtain a JPPF Connection from the connection factory JPPFConnection connection = (JPPFConnection) factory.getConnection(); //Use the connection to submit your JPPF tasks List tasks = new ArrayList(); tasks.add(new DemoTask()); //Use the connection to submit your JPPF tasks //And obtain a submission ID String submitID = connection.submitNonBlocking(tasks, null); //close the connection connection.close(); /* * Get results, presumably in a different method */ //Perform a JNDI lookup of the JPPF connection factory InitialContext ctx = new InitialContext(); Object objref = ctx.lookup("eis/JPPFConnectionFactory"); ConnectionFactory factory = (ConnectionFactory) PortableRemoteObject.narrow(objref, ConnectionFactory.class); //Obtain a JPPF Connection from the connection factory JPPFConnection connection = (JPPFConnection) factory.getConnection(); // JPPFSubmissionResult.Status status = connection.getSubmissionStatus(submitID); //Use the connection to check the status from the submission ID if (status.equals(JPPFSubmissionResult.Status.COMPLETE)) { //if successful process the results List results = connection.getSubmissionResults(submitID); } else if (status.equals(JPPFSubmissionResult.Status.FAILED)) { //if failed process the errors } //close the connection connection.close();

Good stuff. In a J2EE environment, I would expect to get completion events as JMS messages and process them with MDBs.

I think it would be equally as nice to have JPPF generate standard Java events when tasks are complete. Then, in a J2EE environment, a little framework code would register for these events, and upon receiving one, just convert it to a JMS Message and publish it to a Destination. I.e. it would essentially be a Java event-to-JMS Destination relay. JPPF sounds nice though - but how does it compare to JavaSpaces or Coherence? (I dunno if Coherence supports distributed job execution. I'm sure Cameron will be happy to let me know though ;) )

how does it compare to [..] Coherence? (I dunno if Coherence supports distributed job execution. I'm sure Cameron will be happy to let me know though ;) )

Coherence supports distributed job execution using the WorkManager API. It's pretty simple, and is supported by the major app servers, etc. Peace, Cameron Purdy Oracle Coherence: The Java Data Grid

How can this be compared to GridGain? We use GridGain as Grid software at the HAN University, maybe we could change to JPPF.

Rody,

How can this be compared to GridGain? We use GridGain as Grid software at the HAN University, maybe we could change to JPPF.

Both JPPF and GridGain provide an easy to use grid computing framework, albeit based upon different architectural and design approaches. Both also are open-source, 100% Java frameworks. The differences reside mainly in the following areas: • grid topology (multi-tiered in JPPF vs. peer-to-peer in GridGain) • design/implementation of work submission (JPPF static API, GridGain annotations-based) • administration and monitoring facilities (see JPPF management and monitoring) • type and ease of installation, configuration, use, update and maintenance You may also consider the following general points before making a decision to switch framework: • what do you need that JPPF does and GridGain doesn't? • given your current investment with GridGain, in terms of persons, time and money, what is the cost/benefit ratio of changing? • what are your needs in terms of support and services? • how well does it integrate into your IT infrastructure? -Laurent Cohen Visit JPPF at http://www.jppf.org

With regard to GridGain monitoring I do not think the JPPF equivalent comes any near to what is offered by JXInsight's Grid Gain extensions that supports tracing of jobs across multiple threads within one or more JVM processes. We also offer the ability to inspect the runtime state (object field state graph) of jobs currently executing and to generate diagnostics images in the event of job failures. GridGain: Parallel & Remote Tracing http://blog.jinspired.com/?p=144 GridGain: Diagnostics and Resource Metering http://blog.jinspired.com/?p=145 GridGain: Object Spotting http://blog.jinspired.com/?p=148 GridGain: Callflow Visualized http://blog.jinspired.com/?p=142 You are right there is a difference a big difference but not necessarily the way implied. Note we also provide similar extensions for Oracle Coherence (used also by GridGain) as well as all Java EE standard technologies allowing an administrator or operations person to get a complete comprehensive view of their grid and middleware stacks instead of a single (limited) product/technology centric view. William Louth JXInsight Product Architect JINSPIRED

The differences reside mainly in the following areas: ... design/implementation of work submission (JPPF static API, GridGain annotations-based) ...

GridGain supports API-based approach in addition to Annotation-based one. Best, Dmitriy Setrakyan GridGain - Grid Computing Made Simple

I think it would be equally as nice to have JPPF generate standard Java events when tasks are complete.

Then, in a J2EE environment, a little framework code would register for these events, and upon receiving one, just convert it to a JMS Message and publish it to a Destination. I.e. it would essentially be a Java event-to-JMS Destination relay.

That is exactly the approach we have chosen to implement in the next version. The event-driven approach is already available in the J2SE client, it will be simply a matter of exposing it through the JCA connection. We will, however, leave the choice of what to do with the events to the application developers. We do not wish to increase the complexity of installing or using JPPF, nor are we in favor of imposing a particular design upon the applications that use it. Posting the results to a JMS queue is one choice among many. For instance, another approach could be to post the results to a database. We are implementation-agnostic with regards to this.

but how does it compare to JavaSpaces or Coherence?

In addition to Cameron's comments, I would say that the major difference between Coherence and JPPF is that Coherence is a data grid, whereas JPPF is a computational grid. JavaSpaces is definitely a very promising approach to distributed computing. However, it is not a grid computing framework in itself, you have to build upon it to turn it into a grid solution. -Laurent Cohen Visit JPPF at http://www.jppf.org

JavaSpaces is definitely a very promising approach to distributed computing. However, it is not a grid computing framework in itself, you have to build upon it to turn it into a grid solution.

Do you mean use Rio? Spaces +Rio seems to be mature platform that has been around for a long time, why should I look at JPPF rather than Rio +Spaces as implementation for a computational grid?

If there is to be an overriding reason, I will definitely say that JPPF is the easiest to install and use. It's more than a one-time thing, as it results in long-term benefits: • shortened time to completion of grid-enabled applications • reduced maintenance costs • developers and users can focus on their goals, work or business, instead of worrying about the grid infrastructure At the same time, JPPF has a very strong focus on performance, scalability and reliability. In any case, I invite you to see and try it for yourself, and determine whether it fits your goals.

First of all, congratulations on the release! As a founder of another Open Source grid computing product, I am pleased to see several open source products in the space. It definitely shows that demand for grid computing solutions is on the rise. In your post you mention a "very efficient load balancing algorithm". Can you go into more details on what it does? Also, does JPPF support a concept of "Work Stealing" described in Java Fork/Join Framework by Doug Lea? Basically, if some nodes in the grid are idle or less loaded, can they steal tasks/jobs from other more loaded nodes in the grid to equalize the overall load and CPU utilization? This feature becomes very useful in un-even grids/clusters, when some more powerful nodes would execute tasks faster than less powerful nodes. Best, Dmitry Setrakyan GridGain - Grid Computing Made Simple

To Dmitry:

First of all, congratulations on the release! As a founder of another Open Source grid computing product, I am pleased to see several open source products in the space. It definitely shows that demand for grid computing solutions is on the rise.

Thank you, the feeling is mutual. I really like to think that initiatives such as GridGain and JPPF contribute, in some way, to spreading the awareness of grid computing, by making it easily accessible to a larger community.

In your post you mention a "very efficient load balancing algorithm". Can you go into more details on what it does?

In short, the assignment of tasks to the nodes is computed in proportion to the mean task execution time of each node. I invite you to read more about it for yourself at this location. Let me know if you need more details. As you may see, our approach to load-balancing is simple, you might even say naive, and ... it is working. It is non-optimal by design, however it gets very close. It is also fully integrated into our overall approach of simplicity for JPPF users and developers.

Also, does JPPF support a concept of "Work Stealing" described in Java Fork/Join Framework by Doug Lea?

JPPF does not currently support this design. -Laurent Cohen Visit JPPF at http://www.jppf.org