A first trip with ObjectSpace Voyager

Introduction

Overview

This started out as a case study of our first experience with ObjectSpace Voyager at my company, Partner Software. Upon consideration, however, I have decided to throw that over in favor of a "howto" based approach, which better fits my goal - to show others just how easy it has become to implement distributed systems in Java, and to enable them to go out and start using this power in their own projects and products.

Getting enough to play with

1. First off you need Voyager. (OK, first you need to know Java and have a reasonably flexible development environment set up for yourself. You also need to be able to operate a command-line shell and understand instructions in English. So much for prerequisites.) Find it at ObjectSpace's home page, http://www.objectspace.com. There are currently two versions to choose from, the 1.01 production release, and the 2.0b1 beta release. I'll be using the 2.0b1 for this presentation; my company's product uses the stable 1.01. The differences in use are minor, though there are some significant functionality differences (2.0 features full CORBA integration, for example).
2. Download the Voyager library (~400KB in tgz format for unix; ~1.2MB InstallShield executable for MS Windows) and the User Guide (in Adobe Acrobat format, 1.2MB). The user guide presents much of the theory and high-level design of the product, some of which I'll describe, but I'll defer to it in most cases. It is an excellent resource.
3. Install the pieces as makes sense for your environment.I develop under Linux, so don't know all the details of the InstallShield installation. At the least, you need to make sure that the Voyager executables (vcc and voyager) are in your path (or menubar, or whatever) and that the voyager class jar file is in your classpath. Also included in the distribution is some documentation (including javadoc API) and some examples.

A simple example

My example is a simple chat program. It's a peer-to-peer design, rather than client-server. The classes are:

• ChatApp, the entry point to the program and also the registered object which other ChatApps contact to, well, chat. Also has the responsibility of setting up the UI and connecting up all the plumbing.
• ChatEvent is the messaging workhorse of the system. Each chat program produces and consumes these during a conversation.
• Can't have a ChatEvent without a ChatListener, can we?
• A ChatLog displays both parts of the conversation for each user in a scrolling list. It is the ChatListener in the system.
• A MessageConsole is where each user enters their name and a message. It produces ChatEvents.
• A Connector allows the calling user to enter the Voyager address of another ChatApp with which the user would like to chat. It emits ConnectionEvents with the VObject reference of the remote ChatApp when a successful contact is made. The ChatApp, upon receiving such an event via its ConnectionListener interface, connects itself to the remote ChatApp and sets everything up so that both ChatApps listen to each others ChatEvents.

We use the vcc utility on the ChatApp and ChatLog classes so that we may use virtual references to their corresponding instances. This creates two VObject wrapper classes, VChatApp and VChatLog

Feel free to pull down the complete source.

Writing your own distributed app

Voyager makes implementation of distributed systems very simple, just as JavaBeans makes implementation of reuseable components very simple. However, just as with JavaBeans, good design is still a challenge. Distributing a system creates additional design stresses, as the vagaries of networks, remote computers, multithreading, etc. rear their ugly heads.

However, I dare say that writing a distributed app has never been easier. I turned our standalone product into a client-server product using Voyager in around three days. I was amazed at how simple and straightforward the implementation was. Using an encapsulated design, I was able to restrict the dependency on Voyager to about four classes. Applications which are by nature distributed should be able to take serious advantage of Voyager at many levels; they have a simple and effective implementation of agents, and 2.0 is supposed to include full transparent CORBA and DCOM support. Applications which just need a simple network module, as mine did, can do so without subjecting their systems to total overhaul. And, best of all, Voyager is free for most uses (including commercial software).

As you start to disperse your own system, keep these things in mind:

• Decide which classes will be accessible remotely. Each needs to have a VObject wrapper generated using the vcc tool.
• Decide which classes will be transferred over the network. This may include some of the accessible objects, and definitely includes any complex object sent as an argument to a remote method or received as a return value from one. These all need to be serializable.
• Consider the role that the distributed architecture takes in your system. If it is central, then much of your system may revolve around VObjects. If it is a lesser player, you may want to consider encapsulating the Voyager logic within a constrained set of collaborations.