Java Reference
In-Depth Information
A transfer protocol resides above a transport protocol and establishes how information is
trasnferred between hosts. A very common example of a transfer protocol is Hypertext Trans-
fer Protocol (HTTP). HTTP is the protocol for the World Wide Web. Java RMI does not use
HTTP as a transfer protocol but instead uses the Java Remote Method Protocol ( JRMP). One
shortcoming to JRMP is that Java must be understood on both ends, the sending and receiving
end, tying the solution to a Java RMI framework. To alleviate the dependency on Java, CORBA-
related clients can be used by specifying
-iiop
for stub generation with the
rmic
tool. IIOP
ensures the CORBA clients can be used with Java remote object implementations, thus reduc-
ing the dependency on a strictly Java solution.
Table 6-2 summarizes the three choices developers have for choosing a transfer protocol
when using RMI.
Table 6-2.
RMI Transfer Protocols
Protocol
Description
RMI-JRMP
The default transfer protocol for RMI. For client-server applications relying
entirely on Java as the programming language. A Java-to-Java solution.
Java-IDL
For CORBA developers wanting to use Java in conjunction with interfaces
defined in CORBA-compliant applications. Essentially this is a CORBA-to-
Java solution.
Java RMI-IIOP
For Java developers needing to maintain compatibility with legacy applica-
tions. A Java-to-non-Java solution.
Return values and parameters are copies. Objects that are exported, or that implement a
remote interface, are referenced via their stub, or client-side proxy. To export an object, extend
UnicastRemoteObject
or explicitly call
UnicastRemoteObject.export(<remote object>)
.
The Pros and Cons of Using RMI as a Networking Protocol
For the developer exam, the examinee can choose between RMI or serialized objects over sock-
ets for the networking protocol. Here are some of the reasons for selecting RMI over sockets:
Object-based semantics—Remote objects look and feel just like local objects. The com-
plexities of network-aware objects can be hidden from the programs using RMI remote
objects.
No protocol burden—Unlike sockets, when working with RMI there is no need to worry
about designing a protocol between the client and server, a process that is error-prone.
Method calls are type-safe in RMI—RMI is more strongly typed than sockets. Errors can
be caught at compile time.
It's easy to add new objects with RMI or extend the protocol—You can more easily add
new remote object interfaces or add methods to an existing remote object.
IIOP can be used for non-Java end points—You are not explicitly tied to a Java-to-Java
solution.
Generating stubs just got easier with J2SE 5.0—If JRMP is used, there is no need to generate
stubs explicitly with
rmic
any longer. But we will still be required to do so for our project.
