Connecting to a 4D Server Using an Applet
By Jonathan Baltazar, 4D, Inc. Technical Support
Technical Note 00-48
Technical Notes for Technical Notes for 00-10 October 2000
Introduction
The most common ways to connect to a 4D Server are through a 4D client or through a web browser. However, 4D now offers a new way to connect to a 4D server. 4D has developed a Java API (Application Programming Interface) for people who wish to connect to a 4D Server from a Java program. This library is called 4D Open for Java. The Java program can be either a standalone or an applet (i.e., run from a browser).
According to the security policy defined by Sun, an Applet has limited privileges in order to prevent any applet downloaded on the Internet to have too much control on the host machine. One of these restrictions is that, by default, an applet can only open a remote connection with the originating server — the one who sent the .class file. To connect to another server, the company developing the applet has to apply for a Sun certificate to gain new privileges. Further information on this subject can be found at the following sites:
http://developer.java.sun.com/developer/onlineTraining/Security/Fundamentals/Security.html
NOTE : A standalone does not have these restrictions and can open a connection with any remote server.
This tech note discusses how to connect a client interface, written in Java, to a 4D server using an applet. In particular, we will see how to use 'policytool', a small utility provided by Sun to change the applet's privileges (for testing purpose only). This tech note will also discuss installation of the 4D Open for Java classes.
Installation of 4D Open for Java Classes
Before you begin to write an interface with 4D Open for Java, you need to place the 4D Open classes in the correct directory. In this example, the database name is "Athletes". Therefore, the absolute path of the 4D Open class should be of the form:
Windows: C:\par
Macintosh: Main:Athletes:Aci:
Once everything is in its correct folder, you can to write code that can be compiled. Everything should be kept in the Athletes folder — the database and the Java files (.java, .html, .class).
NOTE: If the class files are not placed with the .java file, you will get many errors when you compile. Many of which are to the effect that the 4D Open commands are not recognized. This is why it is very important to keep the Aci folder, which contains all the 4D Open classes, with the .java file.
The Connection
Once the Java interface has been written and compiled and database has been created, you can connect the client to the server. As stated in the introduction, there are three ways of connecting to a server, but this tech note discusses only one: connecting through an applet or the appletviewer.
To get the applet started, do the following:
Windows:Type this command: appletviewer filename.html
Macintosh: Drag the filename.html file over the Appletrunner
The filename is the name of the .java file. In this case, it is named Athletes.java, which has two other files, Athletes.class and Athletes.html.
If you were to run the appletviewer and try to connect to the server, you will see that a connection is not made to the server. You probably wonder why the connection is unsuccessful. The IP address is correct, and if you were to have the server on the same machine as the Java client (client and server on one machine), and use the IP address 127.0.0.1 (or whatever the IP address of that machine is) everything works fine. This is where the importance of this tech note comes in. When everything is on one machine you are able to connect, but why cannot a connection be made by a Windows computer to a Mac or Windows server? The answer is you need to set the Policy Tool.
The Policy Tool is a utility used to grant permission to a specific file. The reason applets are not allowed to connect to a specific file is due to the SecurityManager. The SecurityManager allows you to establish a security policy such that you can trust or restrict the operations of a Java program. The reason why browsers are able to connect to a specific file is because they come with a default SecurityManager predefined by the browser manufacturer. Therefore, the SecurityManager is already set when connecting through a Web browser. But, if you do not wish to connect through a Web browser, the Policy Tool must be set. The main reason for using the Policy Tool is to test the Java program.
Settng the Policy Tool
Macintosh: Macintosh does not require a policytool to make a connection. The policytool is needed only if the Java application is being run on a Windows machine.
Windows: From the DOS prompt, type the command: Policytool
NOTE: If this results in a Bad command or file name error message, try entering:
| C:\>cd jdk1.2.2 | ||
| C:\>jdk1.2.2>cd bin | ||
| C:\>jdk1.2.2>cd bin>policytool |
When you first run the policytool, the policytool dialog will display an error message indicating that it cannot fine the .java.policy file.
The message that first comes up will, of course, be different for each user and for each platform. But the general idea that follows is the same no matter the user or platform.
The message above states the policytool cannot find the .java.policy file. Therefore you must create this file in the directory in which it is looking. In this case the .java.policy file cannot be found in my home directory. My home directory is:
C:Baltazar\par
This is the directory to create and place the .java.policy file.
Once the .java.policy file has been created, go back to the DOS prompt and open the policytool once again.
The policytool dialog should now like this:
Click on the Add Policy Entry button, and the Policy Entry dialog box should appear.
In the Policy Entry window, click the Add Permission button. The Permissions window will appear.
In the Permissions window, click on the Permissions drop down menu and select AllPermission.
After you have selected AllPermission, the screen should now look like this. Then click on OK.
The Policy Entry window should now have an entry in the permissions box. In this case it says, "permission java.security.AllPermission;".
Click on Done and this should bring you back to the original policytool window.
Once the policyfile is directed to the correct policyfile, which in this example is:
C:Baltazar/.java.policy
And the permission box has: CodeBase <ALL>
It is time to save the file. Once the file has been saved, it will display a message.
NOTE: If you DO NOT want to name your policy file .java.policy, and/or DO NOT want to put it in the home directory, you must make changes to the java.security file. The java.security file can be found in this directory:
C:.2.2\par
Here you will have to add a line of code, ONLY if you did not save the .java.policy file in the home directory, or if you named it something other than .java.policy.
Example: If I did not create a .java.policy file in the home directory, but created a 4D.policy file in the test directory:
C:\test\4D.policy
In the java.security file, you would have to enter this line to make sure that there is a path to the new 4D.policy file. Adding this new line of code to the java.security file ensures that the security file will be able to recognize any .policy files that are outside the home directory and are named something other than, .java.policy.
...
policy.url.1=file:${java.home}/lib/security/java.policy
policy.url.2=file:${user.home}/.java.policy
policy.url3=file:/test/4D.policy
...
You will notice that there is already a path set for the .java.policy file, which is in the home directory. This is why when you first open the policytool, you get the message:
Once you have set the new path, the policytool will continue to look for the .java.policy file, but simply click on OK, and open the new policy file you have just created. In this case, the new .policy file you would want to open is 4D.policy.
NOTE: To make things easier, simply create the .java.policy file in the home directory.
Once the policy tool has been set, you can now run the applet. Click on the Connect button and the java interface is now ready to communicate to a 4D server. This message will appear if a connection has been made:
Successful Connection
From there you can display all the records in the database by simply clicking on the Display button. Without the Display button, you can tell if a connection has been made from the server. Simply go to the server and see if a there is a connection; if there is, you know that you are able to connect successfully to the server.
Conclusion
The main purpose of this tech note is not to teach you how to create a Java application using 4D Open for Java, but to simply show you how to connect the client and server. Connecting through a web browser or through the DOS prompt are other ways of connecting, but there are some minor disadvantages to these types of connections. The biggest issue is time. Without using the policy tool, you will always have to type the IP address of the server. With an applet, you simply run the applet and click the Connect button. This saves you, the user, the time of having to type the IP address. Also, the biggest advantage of using the policytool is that it makes the connection faster. Otherwise, you would have to wait for the interface to load, which in some cases takes ten seconds or longer.