Running the RMI examples
Server Smalltalk includes several PingPong-based examples of clients and servers written in Java. These interact with Smalltalk via RMI or IIOP. They can be run with Java systems based on JDK 1.1.7b or later. If you are using a JDK version earlier than 1.2.2, then you need to set the RMI marshaling configuration to utilize Java 1 stubs. To do this, send the stubProtocolVersion: @constant message to the instance of SstRmiMarshallingConfiguration that is associated with your invocation handler. The value of @constant should be SstRmiStubVersion1. The acceptable values for @constant are located in the SstRmiConstants pool dictionary.
The Java code is in the file sstjava.zip. When unzipping the file, ensure that the directory structure and long file names are preserved. Add the unzip destination directory to the Java classpath. Alternatively, it is often convenient to simply add '.' (a period) to the classpath and then change your working directory to the root Java code directory when running the examples. If you are running from within VisualAge for Java, the file must be unzipped and imported into your Workspace. Add the Project into which the code was loaded to the classpath for the Workspace (see the Workspace>>Options menu). Note that running in VisualAge for Java is only practical for the RMI-based examples as the third-party IIOP products may or may not be integrated with VisualAge for Java and so may not use Java code directly from the repository.
Below is a description of how to run the SST Java RMI PingPong examples. The typical case is where one of Ping or Pong is running on a JDK VM and the other is running in VA Smalltalk with SST loaded. It is assumed that the Java code to be run (i.e., the contents of sstjava.zip) is in the Java package directory structure in the <vast> install directory and that the JDK bin directory is on the command path.
Smalltalk ping, Java pong
Smalltalk is used to run Ping and Java to run Pong. As usual, the example is started from Ping (in this case, Smalltalk).
1. [pong] The example runs with the java security manager installed, so a security policy may need to be created. For this example, save the file as sstjava.policy. The contents should look like:
grant {
permission java.security.AllPermission;
};
2. [pong] Ensure that in addition to the standard paths, your classpath includes the current directory (e.g., classpath=<standard directories>) or the absolute path to the directory containing your code.
3. [pong] At a command prompt, change to the Java directory containing your code
cd d:\<vast>\java
4. [pong] Run the RMI registry on Pong:
start rmiregistry
Note that this does not need to be shutdown and restarted each time. You must ensure that no one else is running an RMI registry or using port 1099 on your machine. Use netstat -an before running the setup code and see if port 1099 is allocated. If so, find the program using it and stop it. RMI defaults to port 1099.
5. [pong] Run the PingPongFactory on pong and tell it to create instances of the desired PingPong class.
java -Djava.security.policy=<path to sstjava.policy> com.ibm.sst.examples.rmi.PingPongFactory
com.ibm.sst.examples.rmi.PingPong
6. [ping] Setup the SST infrastructure. For example,
SstPingPongRmi setupPing
7. [ping] Create the ping and pong objects and start the example:
(SstPingPongRmi createPingAndPong: 'rmi://pong.com') start: 6 with: 'test'
Where pong.com is the IP address or host name of the machine running Pong. Change the arguments to #start:with: to suit your needs.
8. Look at the output on both sides and confirm expected behavior.
9. Run the example as many times as you like by repeating step
6.
10. [ping] Clean up the created SST infrastructure:
SstPingPongRmi cleanUpPingPong
Java Ping, Smalltalk Pong
Java is used to run Ping and Smalltalk to run Pong. As usual, the example is started from Ping (in this case, Java). Remember the languages used for Ping and Pong are reversed below.
1. [pong] Setup the SST infrastructure, an RMI naming service and the PingPongFactory. For example:
SstPingPongRmi setupPong
Note that this does not need to be shutdown and restarted each time. You must ensure that nothing else is running an RMI registry or using port 1099 on your machine. Use netstat -an before running the setup code and see if port 1099 is allocated. If so, find the program using it and stop it. RMI defaults to port 1099.
2. [ping] Ensure that in addition to the standard paths, your classpath includes the current directory (e.g., classpath=<standard directories>) or the absolute path to the directory containing your code (e.g. your <vast> installation directory).
3. [ping] At a command prompt, change to the Java directory containing your code:
cd D:\<vast>\Java
4. [ping] Start the example by running the appropriate Java class:
java com.ibm.sst.examples.rmi.PingPong
rmi://pong.com/pingPongFactory 6 test
Where pong.com is the IP address or host name of the machine running Pong. Change the arguments to suit your needs.
5. Look at the output on both sides and confirm expected behavior.
6. Run the example as many times as you like by repeating step
4.
7. [pong] Clean up the created SST infrastructure:
SstPingPongRmi cleanUpPingPong
Other RMI PingPong examples
The other RMI Ping Pong examples (e.g.,
PingPongExceptional) are run by substituting the corresponding example class names wherever an example class name is provided. That is, in steps
4,
5 and
6 of the Smalltalk Ping, Java Pong configuration and steps
1 and
4 of the Java Ping, Smalltalk Pong configuration.
Of course, both the Java and Smalltalk examples can be run completely within their respective languages (e.g., Java Ping, Java Pong and Smalltalk Ping, Smalltalk Pong) by combining the above configurations accordingly.
Applets
To run the applet version of the client, start the registry and factory as above (or in Smalltalk) and open the file ppapplet.htm in an AppletViewer. Note that the HTML file assumes the root of the PingPong code hierachy is in the same directory as the HTML file itself.
Due to security restrictions, the applet must be signed to run inside the Netscape Browser. To sign an applet you need to download and install the signtool utility (v1.0) available from Netscape Developer website. You also need to have installed a copy of Netscape Communicator on your system.
1. Generate a Test Certificate
If you already have a certificate from a Certificate Authority then you can bypass this step. Otherwise you can use the command below to generate a test certificate to be used for development purposes
signtool -G <certificate nick name> -d <Communicator's cert.db directory>
Follow the prompt and at its completion, 2 files x509.cacert and x509.raw will be generated. Note: By specifying the directory of where the cert.db file is, the new certificate is automatically imported into your Communicator's certificate database so no extra steps are needed to import it.
2. Requesting extra privileges
To enable RMI callback, the applet class must import the package netscape.security.* and include the following line in its init() method before any RMI call has been made.
netscape.security.PrivilegeManager.enablePrivilege("UniversalConnect");
To compile the applet you will need to include java40.jar in your classpath. This file is part of Netscape Communicator distribution.
3. Creating a signed jar archive
Make a temporary directory into which you place all the codes that your applet needs. To make a single signed jar file use the command:
signtool -k <certificate nick name> -Z <jarfile name>.jar
-d <Communicator'scert.db directory> <temporary dir>
where <temporary directory> is the place where all your applet code resides. This will create a signed jar archive which can be downloaded by the client browser. You will need to add the following parameter ARCHIVE=<jarfile name> in the ppapplet.htm file following the CODE parameter. This is to ensure the client will get the required classes to run the applet.
4. Making your certificate available to other people
Before other people can grant extra privileges to your applet, they need to have your certificate in their communicator databases. One way to do this is to place the x509.cacert generated earlier in a web page as a web link. Your web server must be able to export this file as the MIME type application/x-x509-ca-cert.
On the browsers which will download and run the signed applet, they need to click on the certificate link. This will bring up a prompt which they will need to follow to import it into their certificate database. Be sure to select Accept this Certificate Authority for Certifying software developers when that question pops up.
5. Running the applet
When a browser downloads and runs a signed applet, a security dialog box will appear which tells you whether to grant certain privileges which the applet has asked for. The applet is identified as belonging to a certain organization whose certificate is in your certificate database. You can then decide whether to grant or deny that privilege.