How the Tunnel Feature Works
A common problem in deploying Java applets is the configuration limitations
that are imposed when applets must communicate with machines other
than the Web server from which they were downloaded. The tunnel feature
eliminates this problem by using HTTP (Hypertext Transfer Protocol)
tunneling to allow applets to communicate with remote systems through
a CGI program running on the Web server.
The following figure
illustrates how a request (a SAS statement or SQL statement) is sent
from a Java applet to a SAS/CONNECT or SAS/SHARE server when you use
the tunnel feature:
Initially, the Web browser
(on the client machine) loads the applet HTML file from the Web server,
which causes the required Java classes to be downloaded from the Web
server as well. The Java classes (the SAS/CONNECT driver for Java,
the SAS/SHARE driver for JDBC, or both) then communicate directly
with the Web server (using HTTP) to pass a request from the applet.
Once the Web server has received the request, it passes
it to the Message Router (shrcgi), one of the tunnel feature's server
programs. The Message Router is a CGI program that passes the request
on to the SAS server, provided the statement or request meets certain
criteria. By checking the tunnel feature's configuration file (which
is created by the system administrator), the Message Router can determine
whether the request is
Once the Message Router has determined that the statement
or request is acceptable, it creates a detached process called the
Session Agent (shrproc), which communicates with the SAS server machine.
Based on the statement or request from the applet, the Session Agent
either starts a SAS/CONNECT session on the SAS server machine or establishes
a connection to a SAS/SHARE server. Then, the Message Router passes
the statement or request to the Session Agent, and the Session Agent
passes it directly to the SAS/CONNECT or SAS/SHARE server.