29 March 2000
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.)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.
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.
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.
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.
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.
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.
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 | http://linas.org/linux/corba.html |
Visibroker ($$$, Linux, Java/C++) | http://www.borland.com/visibroker/ |
ILU (free, Linux, many languages) | ftp://ftp.parc.xerox.com/pub/ilu/ilu.html |
Java RMI (free, many platforms, Java) | http://java.sun.com/products/jdk/rmi/index.html |
Orbacus (free, Linux, C++, Java) | http://www.ooc.com/ob/ |