An Overview of Distributed Object Systems

Micheal Hewett
29 March 2000

Why do we need one?

  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
  close_connection(stream);
  (If A and B communicate a lot, the stream could be left open.)

• A and B have to agree on the name of the command and the format of the arguments and results in order to communicate.
• Other programs might need to use the same protocol, but there is no central repository for the protocol.
• The programmers of A and B have to write read_<xyz> and write_<xyz> functions for every type of data that might be passed between A and B.
• Program A must know what port program B is listening on.

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?

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

                                  contact_ORB(anORB);
                                  provide_ORB_service(anORB, MatrixClass);

  contact_ORB(anORB);
  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?

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.

Problems

Standards

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.

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.

Availability

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.

Alternatives

• CORBA-compliant $$$ products like Visibroker
• CORBA-compliant freeware like ILU, ORBit, and Bonobo.
• Non-standard systems like the Robotics 'dobj' system.
• XML, RDF and other emerging Web-related standards. Possibly too verbose (i.e. slow) right now.
• External non-CORBA protocols.
• DCE (Distributed Computing Environment)
• RPC, RMI, and other language-specific alternatives.

Summary

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).

References