The original pages are no longer available on Sun's Java website. They were retrieved using the WaybackMachine as of Feb
04, 2003.
Back to the RMI
Plug-in for Eclipse
Java Remote Method Invocation
(RMI)
Guest Speakers: Ann Wollrath and Mike Warres
Moderator: Edward Ort (MDR-EdO)
This is a moderated forum.
MDR-EdO: Welcome to JavaTM Live! Today's session is on Java Remote Method Invocation (RMI), a Java technology for distributed applications. Our guests today are two key members of Sun's RMI development team: Senior staff engineer Ann Wollrath, and technical staff member Mike Warres. They're ready to answer your RMI questions. So let's begin.
rmick: What RMI extensions are you considering for the future?
Ann Wollrath: In the next feature release of J2SETM, we will be adding dynamically generated proxies as remote stubs. This will also allow you to export remote objects that are themselves dynamic proxies.
rmick: Is there a way to encrypt data passed between an RMI stub and skeleton?
Mike Warres: You can encrypt RMI call data by using custom socket factories. For instance, you could export an object specifying client and server socket factories that created JSSE sockets.
godcomplex: With the emergence of so many CORBA providers offering their ORB for free, how do you feel about the continued support of RMI, and what are your thoughts on CORBA versus RMI right now?
Ann Wollrath: Well, RMI is free, too. Do you mean "support" in terms of maintenance or new features? RMI will continue to be supported in J2SE as a core API. As far as RMI vs. CORBA, they have a similar core feature set with some minor differences (for example, RMI/JRMP has distributed GC and allows the use of custom socket factories while currently, CORBA does not).
Andy: Can you tell me what happened to the RMI security JSR (JSR-76)?
Mike Warres: The RMI security JSR did not pass the JCPSM due to conflicting goals among those in the executive committee. Work in that area has continued, however, and similar security mechanisms are now available as part of the Davis project, at www.jini.org.
Jim Uzdarwin: Do you see RMI ever phasing out, with the uprising of Java technology like JMS?
Ann Wollrath: RMI is a core J2SE API and will continue to be supported. JMS is a different model for remote communication; RMI has an RPC-style model, whereas JMS is a messaging model. Different applications have different needs, and these technologies address those varying needs.
AgileBob: When the client requests a remote object from the server, how long does the socket stay open? Can the client elect to keep it open for as long as the remote object reference is retained? Can the server make a callback to the client? This is an important feature, to allow the client to tunnel through firewalls without needing to set up HTTP forwarding. Is this still an option for RMI clients today?
Mike Warres: There isn't a direct connection between possessing a remote reference and opening/maintaining a connection to the server. Do you mean when a call is active?
AgileBob: When someone asks the registry for a stub, he or she must make a connection to the server. Does that open socket remain open for any length of time, and can the programmer keep it alive so that all traffic to that RMI server rides over that socket? I'm talking about two-way communication between client and server. I have a consumer-level application that I want to operate behind a firewall. I don't have access to the firewall, and setting up a WWW server is not an option in this space.
Mike Warres: RMI attempts to recycle connections under the covers, which involves maintaining a cache of (open) recently used connections. So if you make a call to the registry, the connection used for that call will remain open for a short period of time afterwards, assuming the connection is still "healthy." However, subsequent calls to the registry or through the stub obtained from the registry are not guaranteed to use that connection, and callbacks from the server to the client will not use that connection in the current implementation of RMI.
AgileBob: Well, then how do you do two-way communication between client and server?
Mike Warres: I assume you're asking how does RMI handle concurrent calls between client and server? In this case, RMI will open additional sockets as necessary to send data for the additional calls. A given connection can only handle one call at a time, but may be reused for later calls.
davids: I have a specific problem. On a particular computer, my RMI application compiled OK, but there was unmarshaling and the "stub class not found" exception. Then I created another RMI application on the same computer, and it worked fine. Why? When I searched the Java forums, I saw that this is a common problem.
Mike Warres: I don't have enough information to tell what's causing your problem. It may simply be that you're not setting your codebase properly on your server VM. I'd recommend that you check out the rmi-users mailing list. It's an excellent resource for general questions about RMI and serialization. You can post more details about your problem there -- the complete stack trace, code snippets, and so forth.
AgileBob: What changed in RMI for 1.4?
Ann Wollrath: The major change was the introduction of the new
class java.rmi.server.RMIClassLoaderSpi, which is a service
provider interface for RMI class loading. Another key feature is
retaining server-side stack trace information in remote exceptions.
Information about these features and others can be found in the 1.4
RMI release notes.
rcme: I tried using custom socket factories for SSL with RMI when using JiniTM, but without success. Can you point me to some literature on this?
Mike Warres: Click here for a recent thread on jini-users discussing the use of custom socket factories with SSL.
godcomplex: Related to my earlier question, it seems that CORBA and RMI are providing the same service. So why is it necessary to support both RMI and CORBA, when CORBA supports languages besides Java and is more widely used in the industry?
Ann Wollrath: Here's an important difference between RMI and CORBA: RMI allows dynamic loading of classes at runtime. In a multi-language CORBA environment, dynamic class loading is not possible. The important advantage to dynamic class loading is that it allows arguments to be passed in remote invocations that are subtypes of the declared types. In CORBA, all types have to be known in advance. RMI (as well as RMI/IIOP) provides support for polymorphic parameter passing, whereas strict CORBA does not. Both models are useful. CORBA does have support for multiple languages which is good for some applications, but RMI has the advantage of being dynamic, which is good for other applications. One model need not fit all needs.
xxx: It seems like the Web services implementation relies on RMI technology. Can you shed some light on the relationship between RMI and JAX-RPC?
Ann Wollrath: JAX-RPC, like RMI, is an RPC-style model.
JAX-RPC uses some of the same APIs as RMI (such as java.rmi.Remote),
but it uses a different marshalling format for the data, with different
marshalling semantics.
Gary Palmer: When providing a custom socket factory, do you have to implement the three-stage setup (direct connect, socks-proxy, http-tunneling) in a proprietary manner as part of the implementation, or does the RMI system use the socket factory provided and perform these functions itself?
Mike Warres: RMI's default behavior when attempting to establish a connection is to first attempt a direct connection and then fall back to HTTP tunneling; however, you do not have to implement this behavior in your own custom socket factories. Your factories simply need to provide sockets capable of initiating/receiving connections and sending data.
IH: I was just given an assignment to research RMI. Are there any known security issues associated with RMI and firewall tunneling?
Ann Wollrath: The short answer is "no"; we know of no security
issues associated with RMI and firewall tunneling. In making a
connection for a remote call, RMI uses a fallback strategy. First it
attempts to make a direct connection. If that fails, it attempts to make
the call inside an HTTP request/response if there is an HTTP proxy
configured on the client (that is, the http.proxyHost
property is set). Finally, it falls back to making an HTTP request to a
well-known URL on port 80. For the last case, a Web server must be
configured to forward such a request to the RMI server, which involves
some security considerations. Some people just open ports in their
firewalls for RMI communications, but of course that should be done with
careful consideration.
AgileBob: After the client makes a call to the server, is there a way the server can make calls back to the client when the client is behind a firewall and there is no HTTP server to forward tunneling?
Mike Warres: You might be able to craft a solution using custom socket factories, though it would depend on your specific situation. Presumably, the client is itself exporting a remote object, which it is handing back to the server for the server to call. The client could specify a socket factory that can create client sockets capable of connecting back to the client through the firewall. It's also worth noting that the Overture release of the Davis project (mentioned earlier in this chat) includes an extensible implementation of the RMI programming model called JERI (Jini Extensible Remote Invocation), which allows you to customize RMI behavior to a greater degree.
Ann Wollrath: JERI features interesting enhancements beyond what is available in J2SE RMI, such as allowing customizable invocation and dispatch behavior and customizable transports. We'd like to hear any feedback people have on this evolving technology.
rcme: Are you guys working on any books or articles about RMI?
Ann Wollrath: There is an existing tutorial on RMI in the book called "The Java Tutorial Continued." There are also other RMI books available, and on the way (stay tuned).
Gary Palmer: Did I hear that RMI in 1.4 can cancel remote calls programmatically (when a user clicks a Cancel button, for example), or am I confusing this with Davis's JERI?
Mike Warres: 1.4 RMI does not support call cancellation, nor does JERI (since there does not appear to be any single notion of call cancellation appropriate to all applications); however, one of the JERI examples included in the Overture release shows how to use custom remote references to implement one particular call cancellation scheme.
rcme: What are the shortcomings of the current RMI design? If you had to start over, what would you change?
Ann Wollrath: If we could do RMI over, it would probably look
a lot like the Overture release I mentioned earlier. Some things that
come to mind are: (1) eliminate impl to stub replacement during
marshalling; (2) require that objects be explicitly exported rather than
implicitly exported (upon creation of, say, UnicastRemoteObject);
(3) eliminate the java.rmi.Naming API; and (4) make
firewall tunneling explicitly controlled. I guess the big lesson is:
Remove the implicit under-the-covers magic in RMI in favor of explicit
actions that are more straightforward and easier to understand.
Gary Palmer: I would like to be able to predict the
failure time of remote calls (to calibrate a graphical progress bar). I
believe the SOTimeout socket option is pertinent to this
and various system properties (java.rmi.server.disableHttp
and any proxy host settings -- and subsequently the *responsivity* of
such proxies/gateways). I expect that such a timeout can only be guessed
within a certain tolerance. Are there any other properties or settings
that should be taken into account when trying to predict call failure
time?
Mike Warres: I'm not sure exactly what you mean by "predicting failure time," since failures are usually unpredictable; as far as system properties for controlling connection parameters, though, take a look here.
MDR-EdO: Well, we've quickly come to the end of our hour. I'd like to thank everyone who participated today. I thought we had a nice mix of questions. And, of course, I'd especially like to thank Ann and Mike for their answers. Look for a transcript of today's session to be posted on the JDC in a day or two.
Ann Wollrath: Thanks for the questions, all. Please feel free to post any further questions to the RMI users forum, rmi-users@java.sun.com. And you can also subscribe to rmi-users.
Mike Warres: Thanks for the questions! For a peek at cool new RMI features, such as RMI security and the use of dynamic proxies as stubs, don't forget to check out the Overture release.
MDR-EdO: Last moderator (me) signing off. The forum is now unmoderated.