Subject: Voyager versus JavaParty

From: Michael Philippsen <[email-masked]>
Date: Sun, 14 Sep 1997 14:54:53 +0200

Objectspace's Voyager is a commercial product that is similar in
spirit as JavaParty with respect to the fact that it alleviates much of
the trouble a programmer faces when remote-enabling classes with RMI.

There are several key points that are different in JavaParty and
Voyager that are discussed below. If you want to comment on this
comparison or if you want to add another point, please contact me

	Michael Philippsen
	[email-masked]
	http://wwwipd.ira.uka.de/JavaParty

Voyager versus JavaParty
========================

- JavaParty programs are completely transparent with respect to the
underlying network of workstations. After the programmer has started
the JavaParty environment, there are no explicit machine names and
port numbers in the program. If a new remote object is created in a
JavaParty program either the JavaParty environment selects a node
based on load, bandwidth or other criteria, or the programmer provides
a placement strategy himself, or the placement of a different remote
object is used to place the new object close by.

In contrast, in Voyager a programmer has to specify machine name
and/or port number explicitly whenever a new remote object is
created. Moreover, if a remote object of class FOO is to be created,
the code must explicitly mention VFOO. 

Voyager programs therefore are tightly mapped to a underlying network
configuration. Adding and removing of workstations requires
alterations of a Voyager program. Moreover, if the programmer decides
up upgrade a class from local to remote, all locations where objects
are created and remote variables are created must be changed.

- JavaParty is more complete when it comes to remote-enabling of
classes.  

Firstly, in JavaParty programs remote classes may have instance
variables (primary types, user types and especially multi-dimensional
arrays). The necessary accessor routines are generated automatically
and every reference to an instance variable of a remote class is
automatically replaced by an invocation of the accessor routine. For
arrays, individual elements or whole dimensions can be accessed
remotely without inducing the penalty of copying over the whole array.

Voyager does not allow instance variables in  remote classes at all.

Secondly, static methods and static variables of remote classes are
handled in JavaParty as a Java programmer would expect: Conceptually,
there is only one instance of every static variable in the
network. I.e., if on one workstation the value of a static variable is
changed, this change can be observed from every other workstation. It
is an implementation decision whether this is implemented by remote
method invocations on a singleton or by implementation of fancy
consistency mechanisms for replicated values.

In Voyager, each static variable exists on every host
individually. Therefore, a change on one host cannot be observed from
other workstations.  The same is true for static methods.

Finally, Voyager does not provide any form of synchronization in a
remote context. A Java programmer expects that a synchronized method
or a synchronized block is executed only by one thread at a time.  For
remote objects and static methods there is no support of
synchronization in Voyager at all.  In contrast, in JavaParty both
synchronized methods and synchronized blocks work identically for
local and remote objects and for static methods. (A particular problem
is that Java's semantics prescribe that a thread can acquire a single
lock several times, e.g., in dynamically nested synchronized methods
or blocks. This is hard to get right in a remote environment where
different threads are used to implement method invocations on remote
hosts.)

- Voyager offers asynchronous method invocation, futures and multicast
messaged. All of those are not provided by JavaParty out of the box,
but it is straightforward to add these in library classes, or
implement the behavior with additional threads. The reaon for this
omission is that JavaParty is aimed at general parallel programming in
contrast to message based distributed client-server based or agent
based programming.

- Voyager offers persistent objects. JavaParty does not.

- Voyager offers Agents: Consider the following situation. A
programmer calls x.moveTo(M) to move the agent object x to machine
M. After x has arrived on M, Voyager automatically invokes
x.onM(). I.e., a method is invoked that is specifically targeted to be
run on machine M.

JavaParty does not provide automatic method invocation, because we
think that it is not too much of a burden for the programmer to call
the method explicitly after the move, i.e.: x.moveTo(M); x.onM().

- JavaParty is designed to be used in a network of workstations. One
of the prerequisites is that these workstations are connected within a
common file system. Therefore, if an object is to be created remotely,
the remote class loader must know where to look for the correspomnding
ByteCode. The easiest way to achieve that is by means of a common file
system although other mechanisms migth work as well.

In contrast, Voyager is targeted towards WANs: ByteCode that is needed
remotely can be shipped if it not present on the remote
host. Therefore, Voyager provides a SecurityManager to guard against
potentially dangerous downloads.

- Voyager generates special Stubs and Skeletons, whereas JavaParty is
based on standard RMI. Therefore, JavaParty can be used on any
platform that offers a JDK and, more significantly, JavaParty's
performance will improve automatically with future versions of the
JDK.

Voyager has a home-grown communication mechanism that uses standard
serialization as well. Objectspace currently claims to be faster than
RMI, however, it remains to be seen whether in the long run
Objectspace´s or Sun´s resources result in the best basic
communication mechanisms.