Java Reference
In-Depth Information
So what's missing? A lot, actually, but odds are that you won't miss most of it:
• Support for RMI request proxying over HTTP
• Support for the RMI multiplexing protocol, which enables multiple JVMs to invoke
remote methods on each other when only a single communication channel exists
• Implementation of the
Activatable
interface, providing a concrete implementation
of objects that can be activated
•
Deprecated methods, classes, and interfaces (which you shouldn't be using anyway!)
• Support for the RMI skeleton/stub protocol, along with the need for the stub and
skeleton compiler
These deficits have some practical consequences, but not as many as you might
think. First, and most limiting, is that RMI OP can only communicate using the original
TCP/IP socket-based RPC mechanism: there's no support for tunneling through firewalls.
This has a direct impact on the network topology under which you deploy your applica-
tion, because you must configure the firewalls that protect your servers to permit Java
RMI traffic. The loss of a concrete implementation of
Activatable
may be an issue for you
if you want the device to host objects that do not persist between activations, but you're
free to provide your own implementation of the interface. And not needing to construct
stub and skeletons is actually a blessing; you only need to do this work for your Java SE
applications.
Applying Java RMI
When writing a distributed application with Java, you must perform the following steps
in concert with the
java.rmi
package:
1.
Write the Java interfaces for the remote services.
2.
Implement the remote services, deriving your implementation from
UnicastRemoteObject
or
Activatable
.
3.
Generate stub classes from the implementation if you're deploying part of the
solution on Java SE or Java EE.
4.
Write a remote service host container that creates and manages your remote services.
5.
Write your Java client, invoking the remote objects on the client.
6.
Install and deploy the client and server.
