Compile and run the various programs in folders 1 and 2, observing the behaviour commented upon in the notes. Examine the file named bounds.dat which is created by the SaveSerialisedBoundsObject program and read by the ReadSerialisedBoundsObject program.

javac ShowWhatHappensWhenYouPassAPrimitiveTypeAsAnArgument.java

java ShowWhatHappensWhenYouPassAPrimitiveTypeAsAnArgument

javac ShowWhatHappensWhenYouPassAnObjectAsAnArgument.java

java ShowWhatHappensWhenYouPassAnObjectAsAnArgument

javac SaveSerialisedBoundsObject.java

java SaveSerialisedBoundsObject

javac ReadSerialisedBoundsObject.java

java ReadSerialisedBoundsObject
					

Compile the code for the random number service, which is located in folder 3.

This is the same type of program as the one from the previous class, with the exception that it passes an object of type Bounds to the remote method, rather than the two primitive values passed previously.

Use the following commands:

1. To compile...

javac *.java
					

2. To generate the stub class (if you don't want the source code for the stub class, omit the -keep switch)

rmic -keep RandomNumberImpl
					

3. Start the naming service at a separate command prompt

rmiregistry
					

4. Start the server at a separate command prompt. This will create the remote object in the server process, and bind the remote object to the naming service.

java RandomNumberServer
					

5. Run the client at a separate command prompt. Provide the upper and lower bounds for the random numbers.

java RandomNumberClient 0 100
					

Compile the code for the next random number service, which is located in folder 4.

This is the same type of program as the one from the previous class, with the exception that it passes a stub for a client-side remotre object to the server side, in addition to the other paramters. The server side is then able to call methods back on the client side, in what's called a callback. To compile and run this, it is necessary to generate stub classes for both remote classes.

Use the following commands:

1. To compile...

javac *.java
					

2. To generate the stub classes (if you don't want the source code for the stub class, omit the -keep switch)

rmic -keep RandomNumberImpl

rmic -keep ClientPrinterImpl
					

3. Start the naming service at a separate command prompt

rmiregistry
					

4. Start the server at a separate command prompt. This will create the remote object in the server process, and bind the remote object to the naming service.

java RandomNumberServer
					

5. Run the client at a separate command prompt. Provide the upper and lower bounds for the random numbers.

java RandomNumberClient 0 100
					

Have a look at the code in folder 5, but there's probably no point in compiling and running it since it doesn't do anything interesting. Nonetheless, if you want to be underwhelmed feel free to compile and run with:

javac *.java

java DatabaseClient.java
					

Compile the code for the more complex number guessing game application in folder 6.

This program uses a server-side GameFactory object to create Game objects. The client has its own GamePlayer remote objects, which it passes references for to the server side.

Use the following commands:

1. To compile...

javac *.java
					

2. To generate the stub classes (if you don't want the source code for the stub class, omit the -keep switch)

rmic -keep GameImpl

rmic -keep GameFactoryImpl

rmic -keep GamePlayerImpl
					

3. Start the naming service at a separate command prompt

rmiregistry
					

4. Start the server at a separate command prompt. This will create the remote object in the server process, and bind the remote object to the naming service.

java GameServer
					

5. Run the client at a separate command prompt. Provide the upper and lower bounds for the random numbers.

java GameClient
					

6. Run several other clients. The clients can play the same game as eachother or different games.

Folder 8 again contains all the compiled code for the game application. In this case, the code for the stub classes will be downloaded at runtime from a web server, taking advantage of Java's dynamic class loading facility.

Locate the batch file named run.bat in the web server folder. Execute this. Open a web browser and point it to http://localhost:8008/. This will show you the contents of the htdocs directory.

Start your rmiregistry from the root of your c: drive. Do not set the classpath. The rmiregistry will get the stub class from the web server.

Start the server with the following command:

java -Djava.security.policy=server.policy -Djava.rmi.server.codebase=http://localhost:8008/ GameServer
					

Note how we give the codebase for the stub so that this can be provided to the rmiregistry.

Observe the log for the web server (this is echoed to the terminal window for the web server). Notice how requests were made for each of our classes.

Start a client or two or three as follows:

java -Djava.security.policy=client.policy GameClient
					

In all cases, note that the client and server do not have any of the stub classes available to them until runtime, when they are downloaded from the server. The client can be compiled and written using only the interface, and can then access the stub class, which can be typed as the interface type, at runtime. Show the remote object be changed, requiring a new stub class version, this will not affect clients which programmed to the interface provided.