Over a million developers have joined DZone.

JPPF Grid Toolkit 1.2: Execution Policy, Serialization Schemes, Tomcat

· Java Zone

Microservices! They are everywhere, or at least, the term is. When should you use a microservice architecture? What factors should be considered when making that decision? Do the benefits outweigh the costs? Why is everyone so excited about them, anyway?  Brought to you in partnership with IBM.

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-->
<Contains ignoreCase="true">

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.

About JPPF:

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!

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.

Discover how the Watson team is further developing SDKs in Java, Node.js, Python, iOS, and Android to access these services and make programming easy. Brought to you in partnership with IBM.


Published at DZone with permission of Laurent Cohen. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}