wiki:JavaParty

Version 2 (modified by hauma, 15 years ago) (diff)

Test new navigation bar

JavaParty Features

JPNav?

Transparent remote objects

JavaParty allows easy port of multi-threaded Java programs to distributed environments such as clusters. Regular Java already supports parallel applications with threads and synchronization mechanisms. While multi-threaded Java programs are limited to a single address space, JavaParty extends the capabilities of Java to distributed computing environments.

The normal way of porting a parallel application to a distributed environment is the use of a communication library. Java's Remote method invocation (RMI) renders the implementation of communication protocols unnecessary, but still leads to increased program complexity. The reasons for increased complexity are the limited RMI capabilities and additional functionality that must be implemented for creation and access of remote objects.

The JavaParty approach is different. JavaParty classes can be declared as remote. While regular Java classes are limited to one Java virtual machine, remote classes and their instances are visible and accessible anywhere in the distributed JavaParty environment. As far as remote classes are concerned, the JavaParty environment can be viewed as a Java virtual machine that is distributed over several computers.

The access and the creation of remote classes is syntactically indistinguishable from regular Java classes.

Object creation

Instances are created anywhere in the environment with the new statement and are immediately accessible from the entire JavaParty environment without explicitly exporting them or binding them to a name in a registry as in RMI.

Instance access

Methods and fields of remote objects can be accessed as if they were local Java objects. No additional exceptions need to be handled, because JavaParty is targeted towards cluster computing where network outages and failure of single computing nodes are rare. In the event of failure, either the system software of a cluster is expected to recover by resetting to the last checkpoint, or the complete application fails and terminates. Class access

Just as regular Java classes, remote classes also have a runtime representation in the distributed environment and are accessible from the application with the same constructs as in standard Java. Classes are loaded exactly once in the distributed environment. The state of a class consists of all its static variables. These static variables and all static methods of the class can be accessed as in regular Java.

Object mobility

Location transparency ends where performance considerations come into play. Even in state-of-the-art distributed systems (KaRMI, uka.transport, ParaStation), the access latency to a remote object is orders of magnitude slower than to a local object. A parallel program executed in a distributed JavaParty environment therefore can only utilize the full power of the parallel machine, if communication is minimized. Object migration is one way of adapting the distribution layout to changing locality requirements of the application. Manual object placement is also possible. For details see the JavaParty syntax section later on.

Unless remote objects are declared to be resident they can migrate from one node to another within the distributed JavaParty environment. This is an important capability even if remote objects are syntactically indistinguishable from regular Java objects, and their location within the distributed environment does not influence the semantics of a JavaParty program.