Java Reference
In-Depth Information
calling
function knows the memory address of the
called
function. When the
call is made, the calling function somehow instructs the computer to change the
program counter to point to the called function, and the computer then starts
executing the code at the new location. There are other complications having to
do with the machine stack used to pass function parameters and to hold the
return address, but the point is that
all
the code resides in a single process
or memory space in which all the machine addresses of all the program ele-
ments are known. In a Java program, all the code resides in a single instance of
the JVM.
In a distributed program, some of the code resides in another process, perhaps
on another machine. The calling process has no way of knowing the machine
addresses of methods in a different process or on a remote machine and certainly
has no way to instruct the remote machine to move its program counter to begin
executing code for a called method.
If the two machines have different operating systems or different architectures
(32-bit vs. 64-bit, for example), there can be differences in floating-point format,
integer size, and byte order (big-endian vs. little-endian). For Java programs,
which have automatic garbage collection, there is also the messy issue of remote,
or distributed, garbage collection when an object is no longer needed.
The Java platform easily provides elegant solutions to some of these problems.
For instance, because Java is a cross-platform system, one need not worry about
floating and integer formats or endian order. Java defines consistent sizes and
formats for all the primitives, and the byte order is the same on all Java platforms
regardless of the underlying operating system. Therefore Java application pro-
grammers need not worry about reversing the byte order or dealing with different
int
sizes, a common problem with remote procedure calls (RPCs) using C or
C
.
As has already been seen in Chapters 14 and 15, Java provides low-level
socket-based networking. Socket programming is appropriate for some tasks,
but it is far too complicated for the kinds of distributed computing tasks we're
dealing with here. No one wants to invent his or her own RPC protocol for each
new distributed application.
Fortunately, the Java RMI system handles all the low-level networking tasks.
Using RMI, the semantics for making remote calls is
almost
the same as for
making normal local method calls. RMI is part of the Java 2 Standard Edition, so
it is available on any J2SE platform. Since the programming style is nearly the
same as normal Java programming, it is
almost
as easy to work with as normal
Java programming. Everyone in the large pool of Java developers should be able
to program with Java RMI with little additional training, unlike socket-based
programming or proprietary alternatives like Microsoft's DCOM. Java RMI also
offers ease of deployment. Because of the cross-platform nature of Java, it is even
possible for clients to automatically download the client-side bytecodes as needed,
relieving the developer from having to distribute client-side code. Because of all
++
Search WWH ::
Custom Search