- 270 - The RMI server-object implementation is the same as the CORBA version, except that it extends
UnicastRemoteObject
, implements
ServerObject
, and defines the methods as throwing
RemoteException
. All the support classes are generated using the rmic utility. For JDK 1.3, this generates skeleton classes
ServerObjectImpl_Skel
and
ServerObjectImpl_Stub
. In addition, I define a
main
method that sets a security manager and installs an instantiation of the server object in the name service. All classes are defined in the
tuning.distrib.rmi
package. Once again, the result is that the single method call requires one-third of the network transfers and
takes one-third of the time, compared to the triple method calls see Section 12.3
.
12.2.3 Proprietary Communications Layer
A distributed system can be defined with sockets and serialization. I have implemented a simple generator that provides all the basic stub and skeleton behavior for a distributed application
tuning.distrib.custom.Generate
class; see Proprietary Communications Infrastructures
. The server object is defined as before, with the interface:
package tuning.distrib.custom; public interface ServerObject
{ public abstract void setBooleanboolean flag;
public abstract void setNumberint i; public abstract void setStringString obj;
public abstract void setAllboolean flag, int i, String obj; }
This server-object implementation is the same as the CORBA version, though without the need to extend any class: it implements only
ServerObject
. Yet again, the result is that the single method call requires one-third of the network transfers and
takes one-third of the time, compared to the triple method calls see the next section.
12.3 Comparing Communication Layers
In the previous sections, we saw how reducing the number of messages led to a proportional reduction in the time taken by the application to process those messages.
Table 12-1 compares the
performance between the different communication layers used in those sections . Table 12-1, Comparison of Different Communication Layers
Executing Three Separate
Methods-Time Taken
Executing Three Separate
Methods-Bytes Written
Executing Three Separate
Methods- Overhead Time
Executing One Combined
Method-Time Taken
Executing One Combined
Method-Bytes Written
Executing One Combined
Method- Overhead Time
CORBA 512 291
194 175
106 66
RMI 356 136
181 113
54 56
Proprietary 293 40
80 100
20 31
Here, I detail the measurements made for the three communication layers using the tests defined in Section 12.2
. The first three columns list measurements taken while executing the three updating methods together. The second three columns list the measurements taken when the single updating
method updates the server object. Within each set of three columns, the first column lists the round trip time taken for executing the methods, with all times normalized to the proprietary
- 271 - communications layer time in the combined method case. The network round trip overhead is a 10-
millisecond ping time in these tests. The second column lists the number of bytes written from the client to the server to execute one set of methods, and the third column lists the time taken to run
the test with no latency i.e., client and server on the same machine, using the same time scale as the first column.
As you can see, CORBA has more overhead than RMI, which in turn has more overhead than the proprietary system. For simple distributed applications such as those used in the examples, using a
proprietary-distribution mechanism is a big win. If you include optimized serialization, which can be easily done only for the proprietary layer, the advantages would be even greater. See
Section 8.4
, for examples of optimizing serialization. However, the proprietary layer requires more work to support the distribution mechanisms, and the more complicated the application becomes, the more
onerous the support is.
There is some evidence that CORBA scales significantly better than RMI as applications grow in any dimension number of clients, number of servers, number of objects, sizes of objects, etc.. RMI
was designed as a relatively simple distributed-application communications layer for Java, whereas CORBA has a much more complex architecture , aimed specifically at supporting large enterprise
systems. Given this difference, it is probably not surprising that CORBA has the better scaling characteristics. RMI uses significantly more resources to support certain features such as distributed
garbage collection, which can impose heavy overhead at large scales. CORBA directly supports asynchronous communications at the method-definition level by allowing methods to be defined as
one-way message transfers.
It appears that for simple distributed applications, a proprietary communications layer is most efficient and can be supported fairly easily. For distributed applications of moderate complexity and
scale, RMI and CORBA are similar in cost, though it is easier to develop with RMI. For large-scale or very complex distributed applications, CORBA appears to win out in performance.
12.4 Caching
