Open Hypermedia Systems Working Group

Beans, RMI, Voyager

This document is organised as follows:

1. What is Voyager?
2. Voyager architecture
   1. Definition - how is a remote object defined?
   2. Naming - how is a remote object located and refered to?
   3. Transport - how are arguments and results passed back and forth?
   4. Security - what security measures exist?
   5. Transparency - how transparent is it in use?
   6. Persistence - does the server store the remote objects?
3. The Voyager future

Voyager is a full blown Java ORB architecture from ObjectSpace. It has been written to allow the Java programmer to easily create powerful distributed computing systems. Voyager uses the ability of the Java Virtual Machine to load classes at runtime to create mobile objects and autonomous agents.

Seeking to provide a 'neutral solution' to the battle between Corba and DCOM, Voyager 2.0.0 today provides the tools to automatically turn existing Java code (even .class-files) into a Corba server. IDL files are created to allow the interface to shared. Likewise, Voyager can take a IDL file and create Java interfaces which then can seamlessly work with Corba servers.

Voyager 3.0 is expected to provide similar support for DCOM, so that Java programmers can write code once and then use it with Corba, DCOM or Voyager.

It should be noted that the above two paragraphs are the claims of ObjectSpace - as I do not work with Corba, I have not had the opportunity to try out the Corba integration. Furthermore I have mainly worked with Voyager 1.0.0, as Voyager 2.0.0 Beta 1 was released only recently.

One of the interesting sides of Voyager is the ability to turn any Java class into a remote enabled class, regardless whether the source is available or not. This feat is performed by the tool vcc, which creates the 'virtual' classes (which are always named 'V' + the original name: MyClass thus becomes VMyClass). The virtual class handles all communication with the actual class running on a Voyager server. There is therefore no need for IDL or interface files. However as mentioned above if one should so desire, IDL is supported.

Objects residing on Voyager servers can be refered to by various means. They are known by their machine:port/alias (in the form 'my.host.edu:8000/myObject', and their GUID, a 16 byte Globally Unique ID. If an object moves from one Voyager server to another it leaves a Forwarder, which will forward future messages to it transparent. Directories can be distributed and arranged in a hierarchical naming scheme.

Voyager uses serialisation and ordinary socket for communication, but one can easily specify that a server should use another Socket Factory (e.g. secure sockets), if one so desired. Furthermore IIOP is supported as transport layer. The standard form of messaging between object is synchronous with no time out. There are however several possibilities, such as Future (asynchronous), OneWay (no return value is required), OneWayMulticast (sending a one way message to a group of objects or to objects who satify a certainly criteria) and finally the default Sync (synchronous). These messengers are essential small agents who for instance takes care of the above mentioned forwarding resolving, so that the messenger updates the virtual reference to the current location of a remote object. The messengers can also behave smart with regards to net problems etc. While a lot of functionality can be build into these messengers, this requires source code licenses from ObjectSpace.

In this respect Voyager is very much like RMI, as they both have inherited a lot of security functionality from the general Java model. As RMI Voyager also uses a special security manager to secure the system (this is especially important in a mobile object architecture such as Voyager where ones server may receive visits from hostile agents). As noted above, Voyager also allows for the addition of on the wire encryption.

The ability of Voyager to remote enable all Java programs makes for great ease in programming, especially as events and listener interfaces are also remoted enabled (thus Java Beans can remote enabled). This also means that a programmer can take a third party library, remote enable it and use it a distributed setting.

Voyager servers support a light weight persistent store and they can store their objects in this store when instructed so or for memory conservation. All remote enabled objects have 'saveNow' and 'flush' for respectively saving to disk and moving to disk. If a flushed object is later referenced, it is restored automatically. ObjectSpace indicates that future versions of Voyager will support 'leading databases'.

Please send feedback to Niels Olof Bouvin. Last modified: Mon Dec 15 06:09:41 1997