Java Reference
In-Depth Information
It may be easier to propagate changes to remotely accessible methods over a sockets
solution than an RMI solution. Unless you do something major like remove a method that is
being used, or change the port it is running on, you can usually change a sockets-based
server without the clients even being aware of it—they just won't get the new functionality.
In comparison, an RMI solution that has pre-JDK 5 clients or that doesn't allow stubs to be
dynamically generated will require recompilation of the client stubs, and redistribution to
clients if you do not use dynamic downloading. If you do use dynamic downloading, you
may also have associated issues with security and setting the
codebase
option.
A sockets solution should also require less sockets and network traffic between client and
server. A sockets solution for this assignment might need only one socket per client, and the
network traffic can be minimal depending on how minimal you make your solution. An RMI
solution, on the other hand, will always open a listening port for your RMI registry, a listening
port for your RMI server, a connected port between the server and the registry, and one socket
per client between the clients and the server. The RMI solution will also require more network
traffic while connecting (doing the lookup on the registry) and also while idling (performing
distributed garbage collection and sending heartbeat messages).
This brings up another point: with RMI you always have an extra process running (the
RMI server). While most computers are not going to be taxed by this extra process, if you were
using most of the CPU and memory resources of your server, this could become an issue.
A
well-written
sockets solution
can
be easier for a junior programmer to understand and
maintain than an RMI solution. This contradicts the commonly accepted view that RMI is
simpler. But there are several items to consider here. If you write your sockets code well, the
networking code will be hidden from the client and server applications—they will just be call-
ing your sockets API, in the same way that in an RMI solution the clients and servers are just
calling the RMI API. But in this case, the junior programmer does not need to learn about reg-
istries, or how to use
rmic
, or how to deal with the RMI stubs. So there is less of a learning
curve for them. However, there is little doubt that once that learning curve has been passed,
an RMI solution is easier to develop, understand, and maintain. And most likely, the only way
a sockets solution can be clearer than an RMI solution is if the sockets solution is really well
written (and possibly also if the RMI solution is not well written).
General client identification is easier in a sockets solution—you can use the connection's
thread to identify the client. However, if your assignment requires you to use cookies for lock-
ing, unlocking, and modification calls, then you can use the cookie as the client identification.
Likewise, if you decide to use thread pooling for scaling reasons, then you will no longer be
able to use the thread identifier. Regardless, for either RMI or sockets, using a connection fac-
tory will provide a simple client identifier.
There is less chance that somebody will accidentally disable your server. With RMI, if
another server happened to do use the
Registry
class's
rebind
method with the same remote
reference name, they will replace your code. With sockets, once you have bound to a particular
port, no other server can bind to that port. However, this can also work to your disadvantage—
if somebody deployed another server that happened to use the port number, then restarted
the computer, it may not be possible to predict which server will bind to the port first, so you
may not know which server will be accepting connections. This is called a race condition; a
race condition in relation to threads is discussed in Chapter 4.
