JPPF Grid Toolkit 1.2: Execution Policy, Serialization Schemes, Tomcat
Version 1.2 the Java Parallel Processing Framework (JPPF), the grid toolkit for Java, brings 3 major new features, outlined in this article.
Submitting jobs with an execution policy
A capability that was missing in the previous versions, was the ability to specify on which nodes a set of tasks - or job - could run. It is now possible to specify a set of conditions that a node must satisfy to execute a given set of computational tasks.
Let's take an example. Imagine that we have tasks that require a lot of memory, say 512 MB, and embed a large amount of data. We want that data to be transported as fast as possible, so we want the nodes to be as close as possible, for instance in the "mydomain.com" internet domain.
We would express our execution policy as follows:
<!--max memory in bytes-->
This translates as execute only if the node has at least 520,000,000 bytes of max memory and is in the "mydomain.com" domain.
Now all that remains to do is parse this XML policy and submit it along with the tasks:
ExecutionPolicy policy = PolicyParser.parsePolicyFile("../policies/MyPolicy.xml");
List<JPPFTask> results = jppfClient.submit(tasks, dataProvider, policy);
A second example: let's consider that we have N nodes, each one with a numeric ID, named very creatively "node.id", with a value from 1 to N.
We want our tasks to be executed only on nodes 2 to 5 and 9 to 12. We then specify an execution policy like this:
It looks very easy, doesn't it? I invite you to read a lot more in the full execution policy documentation pages.
Using alternate serialization schemes
A recurrent problem with Java serialization, is that our objects have to be ... Serializable, i.e. their classes must implement java.io.Serializable or java.io.Externalizable.
JPPF makes an extensive use of serialization to transport objects to its servers and nodes. But what happens if the application uses 3rd-party libraries where it is not possible to change the code to make objects Serializable?
JPPF addresses this situation by providing the capability to function with object streams other than the standard java.io.ObjectInputStream and java.io.ObjectOutputStream.
A built-in implementation is provided that enables JPPF to work entirely with the XStream XML serialization framework.
More on this in the JPPF documentation.
Tomcat port of JPPF client
Unlike the other J2EE application server ports (see JPPF and J2EE), the port to Tomcat is not based on the JPPF JCA connector.
It is rather a simple embedding of the J2SE client into a web application that can be deployed into a Tomcat container.
JPPF has many outstanding features:
- A JPPF grid can be up and running in minutes
- Simple programming model that abstracts the complexity of distributed and parallel processing
- Highly scalable, distributed framework for the parallel execution of cpu-intensive tasks
- Seamless integration with leading J2EE application servers
- Graphical and programmatic tools for fine-grained monitoring and administration
- Fault-tolerance and self-repair capabilities ensure the highest level of service and reliability
- A set of fully documented sample applications of JPPF to real-life problems
- JPPF@Home screensaver leverages idle enterprise resources
- Runs on any platform that supports Java ®
- Very flexible and business-friendly open source licensing
- and more ....
Try it for yourself at the JPPF.org web site.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)