An Overview of Distributed Object Systems

Micheal Hewett
29 March 2000

Why do we need one?

In a distributed system, many different processes, usually running on different machines, are exchanging data. One way to do this is to set up a protocol by which they exchange data via, say, TCP sockets. Say program A wants to find the determinant of a matrix. It could make the call:
  det = matrix_determinant(myMatrix);

Now, say that program A doesn't know how to do determinants, but program B does. Program A can contact program B and send it the operation and the matrix and get back the result:

  stream = open_connection(programB_port);
  write(stream, "determinant");   // send the command
  write_matrix(stream, myMatrix); // send the arguments
  read(stream, &det);             // get the result
  (If A and B communicate a lot, the stream could be left open.)
This method, although it works, has several problems:

Now, suppose that A and B are both object-oriented systems. No matter what the language, an object is essentially the same: a collection of fields and methods. Transmitting an object between could be made transparent if both sides agree on the definition of the object. The connection and transmission routines could be generated automatically.

What is a distributed object system?

A distributed object system does just that: once an object has been defined in a generic description language, an interface generator produces language-specific definitions of that object and routines for transmitting that object between programs. Each program becomes a client/server for a specific set of objects.

So that each program doesn't have to know details about other programs, each program registers its available object types with an ORB (Object Request Broker). When a program needs a service, it contacts the ORB which puts it in contact with the appropriate provider. Our matrix determinant program would look like this:

    Program A                           Program B

  #include genMatrix.h            #include genMatrix.h

                                  provide_ORB_service(anORB, MatrixClass);

  request_ORB_service(anORB, MatrixClass);

  MatrixClass myMatrix = new (...);
  det = myMatrix.determinant();

Now, the call to 'determinant()' transparently contacts program B, sends the matrix and the method call and waits for the response. The code of both A and B is much simpler.

How does it work?

MatrixClass is defined in a generic object language, which specifies its contents and public methods. This is usually called an Interface Description Language (IDL). As the first step of compilation, the file MatrixClass.idl is translated to each of the required languages (Java, C++, CLOS, ...). Each program then includes the appropriate language-specific file in its program.

The generated code contains not only the class definition but methods for breaking down the class into components (a process called 'marshaling'), sending them across a connection to another program, and reconstituting the object on the other end.


All of this is relatively easy when working with the same language. However, transparently passing objects between, say, Perl and LISP is slightly more difficult because different language generators are needed. Also, there are no standards for data transmission; each ORB has its own protocols. So you must find an ORB that supports the languages you want to use and the network environment that you have.


CORBA (Common Object Request Broker Architecture) from OMG defines the standard for ORB implementations. CORBA 2.3 is the current standard level as of this writing. ORBs which are CORBA-compliant are preferred. Several of these are available: Oracle has one, Borland has Visibroker, another commonly used ORB.

I have also looked at ILU from Xerox PARC. It supports a very large set of languages and is CORBA-compliant. However, I have not yet successfully installed it.

Java has a feature called Remote Method Invocation (RMI) which allows object transmission between Java programs. In the next version of Java, it will be CORBA-compliant, although it isn't right now. It does work in the same way, though.

I should also mention XML and RDF, which have the capability to be universal, if slightly verbose, data interchange formats.


Using the IDL files to generate language-specific interfaces is very fast - there is almost no impact on compilation speed.

Although data transmission rates are dominated by network transmission delays, when large amounts of data are being transferred, the efficiency of the encoding (both speed of encoding and size of the resulting transmittable form) can come into play. One could assume that a good ORB would do a better job of encoding than the average programmer. Java's RMI allows the programmer to determine the "serialization" of an object, if so desired.


The department does not run an ORB. It would be nice if they would get a license for VisiBroker or one of the other systems so that we could use it. In the meantime we must install and run ILU or some other such ORB in order to use a distributed object system.

For our wheelchair, Bill and Rob have developed a non-standard distributed object system (dobj) that supports C++ and Scheme. The interface description files are the ".do2" files and the interface generator is the 'dogen' program.



For a large distributed system, using a CORBA-like programming structure can make programming much simpler. Each program shares a common data language and the low-level routines are automatically generated, saving the programmer much time.

In addition, using a standard CORBA interface allows remote programmers to write programs to access data without having to know the internals of the program providing the data. Thus, remote servers can be more easily utilized.

For our diverse language needs, ILU is the only alternative I have found that supports all the languages we use (and more).


General links to distributed object systems
Visibroker ($$$, Linux, Java/C++)
ILU (free, Linux, many languages)
Java RMI (free, many platforms, Java)
Orbacus (free, Linux, C++, Java)

[Robotics home]

Author: Micheal S. Hewett
Last Updated: Wednesday, March 29, 2000