12.3 Comparing Communications 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 communications
layers used in those sections.

Table 12-1. Comparison of different communications layers

Executing three separate methods

Executing one combined method

Time taken

Bytes written

Overhead time

Time taken

Bytes written

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 communications
layers using the tests defined in the "Message
Reduction" section. 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 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.