So far we have seen three different techniques (RMI, CORBA and JDBC): in each case, a Java application running on one computer has contacted another computer. When a WWW user wishes to download a Java applet from a WWW server, there is no problem if that applet wants to access a program running on the same computer as the WWW server. For example, it is reasonably easy to provide a WWW page that runs a Java applet which uses JDBC to connect to a database server (e.g., the MSQL server) if the database server is on the same computer as the WWW server that delivers the WWW page.

However, if the WWW server and the database server are on different computers:

Java's security restrictions are such that the applet is not allowed access to the database server unless the applet is a trusted applet. An applet is trusted if the owner of the applet has added a digital signature to the applet and the visitor to the WWW page has signified to their WWW browser that they trust the person described in the digital signature.

In order for you to add a digital signature to an applet you need to know about JDK's javakey command in order to generate keys, certificates and signed applets. Furthermore, in order to use javakey, your applet's class must be stored in a Java Archive, and so you will also have to know about JDK's jar command (in order to create a Java Archive). Although the jar and javakey commands of JDK 1.1.x enable you to generate signed applets, these signed applets are not understood by Netscape Navigator 4.03. So in order for a visitor to your WWW page to run your signed applet, he/she will have to use the appletviewer that comes with JDK 1.1.x. In a later version of the JDK (maybe as late as JDK 1.2), the security aspects of the JDK will allow those used by Netscape Navigator 4.03 and so hopefully the two will interoperate.