prevent application / non-standard ports from being opened up in a
public network, we can use HTTP tunneling to get RMI working.
Tunnelling is essentially wrapping up the RMI calls inside an HTTP POST
Its the responsibility of the Transport layer to do this wrapping. There are two ways to do this :
- HTTP to port : Used
when the client of an RMI service is behind a firewall. The JRMP call
data is automatically wrapped in an HTTP POST and sent to the proxy
server on the client. This proxy server is the http proxy server the
client uses to connect to the public network. The only config required
to do this is to set the proxy server settings via java system
- HTTP to CGI : is used when the the server is behind a firewall and cannot accept incoming connections. Here the transport layer redirects http wrapped JRMP calls to a CGI script running in a webserver. This CGI script is java-RMI and is a part of the JDK ( see bin directory). A servlet version of the CGI is also available. The CGI intercepts requests coming on 80, which is intended for a non-default port (the client transport layer embeds this info if its wrapping up the JRMP call in http) and forwards the call to the local port.
Although tunnelling is a very attractive solution to the problem of firewalls, they should be carefully used because there will be severe performance degradation, and the CGI script is actually a security hole and tunneled applications cannot use callbacks.
RMI-IIOP : CORBA InteroperabilityRMI-IIOP was designed to make RMI applications interoperable with CORBA applications. This involves supporting both the RMI's own wire protocol JRMP s well as CORBA's wire protocol IIOP. The interoperability is achieved by letting java developers use a Java interface and the CORBA developers use the IDL for coding. With an RMI-IIOP server, the remote interface can be used to generate the corresponding IDL for a CORBA C++ client application. The clients can also use a IDL to Java conversion to convert IDL to a Java Interface, enabling the RMI-IIOP client to connect to a CORBA server.
CORBA compliant remote objects are derived from the PortableRemoteObject and they need to be rmic'd with the -iiop option to tell the compiler to generate Stubs and skeletons that can speak RMI-IIOP. They form the foundation for the enterprise level distributed computing in java and the heart of the EJB programming model, though EJBs would make most of this transparent to the developer. Another crucial difference is that unlike in a plain vanilla RMI-IIOP environment, the RMI registry is replaced by JNDI using a COS Naming Service like tnameserv or an LDAP server. Distributed garbage collection is not supported by CORBA, which means objects have to be created and destroyed explicitly. This means the object management remains in your hands, and you need to be pretty careful about it; again one of the reasons that fuelled the creation of the EJB spec. The RMI activation system is replaced by the PortableObjectAdaper and the remote references have to be down cast using the PortablRemoteObject.narrow() method and not using a normal java cast.
We have barely scratched the surface of RMI, the underlying plumbing behind today's enterprise java technologies. I hope this serves to whet your appetite on the behind the scenes work that we take for granted everyday with modern frameworks. RMI alone is not what makes enterprise java the behemoth that it is, its a host of other enabling technologies which we shall examine in the future.