Java Reference
In-Depth Information
Benefits of Using an RMI Solution
However, let's be blunt.
For the SCJD exam, scalability and performance are not design con-
siderations
, and as shown in the “Benefits of Using a Serialized Objects Over Sockets Solution”
section earlier, neither solution provides a method of allowing non-Java clients to connect.
We mentioned that a
well-written
sockets solution
might
be easier for a junior program-
mer to understand and maintain. However, as a developer you would be expected to know
both of these technologies anyway so that you can make a valid choice between them (and to
help you, we have devoted Chapter 6 to RMI and Chapter 7 to sockets). Once you know the
two technologies, you may find that your job could actually be a lot less tedious using RMI.
And the assessor is expected to understand RMI, so there is no problem with submitting an
RMI solution. Let's quickly list a few of the advantages of RMI.
Implementing socket servers and socket clients involves creating a custom protocol. A
sockets implementation must send serialized objects across the network that the receiving
socket point must know how to handle at runtime. Thus, a sockets-based application can be a
little more tedious and awkward to write than an RMI program. This can be negated slightly if
you write well-factored code, such that each class has only one responsibility, and the methods
are likewise well factored. However, using the Command pattern for the client-server commu-
nication protocol trivializes building the new protocol.
The details of object serialization and network communication are hidden by RMI,
whereas using sockets you have to implement it all yourself. In other words you will be rein-
venting a basic technology that already exists.
No matter how well you write your code, there is no doubt that you will write more code
for a socket-based solution than an RMI one. And the more code you write, the more chance
of making mistakes—it can be safer to leverage off the code written by the RMI developers,
which has been tried and tested for many years; much of the RMI code base has been around
since JDK 1.1, which was released in September 1997.
RMI provides network transparency, which means that to the client a remote object
seems to behave as if it is a local object. Thus there is no need to implement a handshake pro-
tocol or worry about low-level details such as opening and closing socket connections.
Due to the use of interfaces and remote methods behaving as though they were local,
developing code to call a remote method is usually type safe. The same can apply to a sockets
solution, but unlike RMI there is no requirement to use interfaces. Consequently, it is easy to
end up with a solution that does not provide any form of compile-time (or even runtime) type
safety.
RMI also relieves you of the responsibility of having to write multithreaded servers, which
can be tricky. You are still required to write thread-safe code in either protocol, but the actual
server does not have to spawn threads or manage thread pools.
Thread pooling can provide a significant performance improvement when systems are
scaled to large numbers of simultaneous users, and RMI provides it for free. Yet this comes at
a cost: client identification is slightly more complex if you cannot use cookies.
RMI is also extensively used in Enterprise JavaBean (EJB) technology, so learning and
using RMI for the SCJD assignment will assist you in EJB projects.
