Deployment scenarios often put the server behind firewalls. In such cases, the RMI transport layer that normally attempts to open direct sockets to hosts on the Internet is not allowed to do this. The default RMI transport provides two alternate HTTP-based mechanisms that enable a client to invoke a method on a remote object residing across the firewall. These are:
HTTP tunneling when the RMI call is within the HTTP protocol
Using the default socket factory
To get out of a firewall, the transport layer embeds an RMI call within the firewall-trusted HTTP protocol. The RMI call data is sent outside as the body of an HTTP POST request, and the information returned is sent back in the body of the HTTP response.
The transport layer formulates the POST request in two ways.
While there is no special configuration necessary to enable the client to send RMI calls through a firewall, the client can disable the packaging of RMI calls as HTTP requests. To do this set the java.rmi.server.disableHttp property to the boolean value true.
A client outside the domain of the Server host attempting to invoke methods on remote objects requires to first locate the Server. The remote references that the Server exports must contain the fully qualified name of the Server host.
The host name must not be specified as the IP address of the host. This is because some firewall proxies do not forward the host name in this manner.
On some platforms and network environments, the fully qualified name of the host may or may not be available with the Server VM. If so, the fully qualified name of the host must be specified with the property java.rmi.server.hostname while starting the Server.
For example, to start the RMI server class ServerImpl on the machine docs.pramati.com, run
java -Djava.rmi.server.hostname=chatsubo.javasoft.com ServerImpl
If the Server does not support RMI clients that are behind firewalls and prevents them from forwarding to arbitrary ports, then use this configuration:
HTTP server on port 80
A CGI script located at the aliased URL path /cgi-bin/java-rmi.cgi
This CGI script:
invokes the local Java interpreter to execute a class internal to the transport layer that forwards the request to the appropriate RMI server port, and
defines properties in the VM using the names and values of the CGI 1.0-defined environment variables.
A sample script is supplied in the RMI distribution for Unix, Solaris and Windows operating systems. The script must specify the complete path to the Java interpreter on the Server machine.
Network Address Translation (NAT) or IP masquerading is when the IP of the Server host is mapped to a global IP outside the firewall, so that any request arriving at the global IP is transparently directed to the local IP.
For the Server to receive calls from the global IP across the firewall, point java.rmi.server.hostname to the global IP while starting the Server.
For example if the user's global IP is 196.12.47.7, start the Server using:
java -Djava.rmi.server.hostname=196.12.47.7 com.pramati.J2eeServer
The RMI transport layer extends the java.rmi.server.RMISocketFactory class to provide a default implementation of a socket factory. The implementation provides resources to client and server sockets, and creates sockets that transparently provide firewall-tunneling mechanism.
Client sockets automatically attempt HTTP connections to hosts that cannot be contacted through a direct socket. Server sockets automatically detect if a newly accepted connection is an HTTP POST request, and if so, returns a socket that will expose only the body of the request to the transport and format its output as an HTTP response.
Client-side sockets having this default behavior are provided by the java.rmi.server.RMISocketFactory.createSocket method. Server-side sockets having this default behavior are provided by the java.rmi.server.
Administrators must consider the following points while using Server with firewalls:
The naming service port will always have to be open.
HTTP Tunneling drastically reduces performance of network communication and must be avoided if possible.
To configure Pramati Server or a Cluster Node to run behind a firewall:
Open the HTTP port. In a typical firewall configuration, this is the default port that is open.
Open the naming service port. This is mandatory if naming service lookups have to occur from the client side.
If HTTP tunneling is used, no other ports need to be open.
Open the port on which remote objects are to be exported if HTTP tunneling is not used.
This port is already configured as part of the Server. the tag <export-port> under <server-nodes> in the Server configuration file. The value is by default zero, when it exports remote objects on random ports. Specifying an unused port here exports all remote objects onto this port. Hence to enable the client to talk to remote objects behind a firewall, this port must be open.
To enable dynamic downloading of stubs to clients across firewalls the class file server port must also be open. By default Pramati Server attempts port number 5020 for the class file server. If that port is busy, it moves to the next available port to start the class file server.
The configuration file of the Server must have the global IP of the node specified in the tag <host-ip>. When starting the Server, the following command line argument is given to the JVM:
java -Djava.rmi.server.hostname =
<GLOBALIP> com.pramati.J2eeServer
Some of the typical client-server hosting scenarios are:
Nothing exists in the De-militarized Zone (DMZ) behind the firewall. Pramati Server is on the host machine. Pramati Web Container handles all HTTP requests.
Pramati Web Container and EJB Container are configured in two different zones: the Web Container is in the DMZ and handles all the HTTP requests. The EJB Container is on the host machine and serves EJBs.
An existing HTTP server is configured with Pramati Server. While Pramati Server serves EJBs and JSP pages (dynamic content), HTTP server serves static content. In this scenario, Administrators must install Pramati WebGate, the HTTP server plug-in facility, for Pramati Server to work with other HTTP servers.
HTTP server with Servlet engine serves HTTP requests from the DMZ, while Pramati EJB Container serves EJBs from the host machine. In this scenario, administrators must place Pramati Server-specific client.jar in the classpath of the Servlet engine.
Hosting applications on multiple independent Servers is the simplest of the Server configurations. Each Server is installed on the local host or a remote host. In this configuration, you deploy the complete application on each Server machine. To do this, you use the Deploy Tool in the Console to repeatedly deploy the application on each running Server.
When you deploy an application this way, the session is neither backed up nor shared between two or more Servers. This implies that load balancing and fail over is not available to the application.
To deploy applications across multiple Pramati Servers while sharing a common external HTTP server, install Pramati WebGate, the HTTP Server Plug-in that ships with the Server.