Link to the DIT Home Page

Dublin Institute of Technology, School of Computing
Ciarán O'Leary

  Home -> Teaching -> DT249-4 Distributed Systems -> Notes -> Week 04
  DT249-4 Distributed Systems

Week 04


Learning Outcomes:

Upon completion of this class, you should be able to:

  1. Explain what is meant by an object oriented system.
  2. Explain how objects are referenced and how their methods are invoked.
  3. Distinguish between single process and multi-process object based systems.
  4. Demonstrate a clear understanding of how important aspects of object oriented systems can be handled in a distributed object system.
  5. Use sample scenarios to show how event based systems are an extension of simple object oriented systems.
  6. Distinguish between the various semantics for method invocations.
  7. Provide a brief explanation of the important differences between competing technologies for remote method invocation.
  8. Implement client - server applications using CORBA.
  9. Implement client - server applications using Java RMI.
  10. Use security in distributed object applications.
  11. Use dynamic class loading in distributed object applications.
  12. Implement distributed object systems with callback invocations.

Tasks

1. Download the code from here.

 

2. Go to folder 01.

 

3. Generate helper code with the following command:

idlj -fall -oldImplBase Quote.idl

This command will generate a sub-directory named SimpleCORBAExample, in which will be put code generated from the module defined in Quote.idl. These files include:

  • Quote.java: The Java version of the IDL interface
  • QuoteHelper.java: Code to narrow, or cast CORBA references into Java references.
  • QuoteHolder.java: Would contain methods to read or write arguments - although in this example we have no arguments.
  • QuoteOperations.java: Methods signatures for all operations in the interface.
  • _QuoteImplBase.java: Server skeleton - basic CORBA functionality for the server - all servants must implement this.
  • _QuoteStub.java: Client stub - contains CORBA functionality for the client.
4. Compile the client and server:

javac -classpath . QuoteClient.java QuoteServer.java QuoteService\*.java

 

5. Run the naming service in one window:

tnameserv

 

6. Run the client and server:

java QuoteServer

java QuoteClient

 

7. Do the same for the code in folders 02 (several remote objects) and 03 (serialisation of objects).

 

8. Compile all the code in folder 04.

 

9. Run the following command:

rmic -v1.2 -classpath . QuoteImpl

Note how a new file has been created named QuoteImpl_Stub.class

 

10. Start the naming service:

rmiregistry

 

11. Run the client and server:

java QuoteServer

java QuoteClient

 

12. Do the same for the code in folders 05 (several remote objects) and 06 (serialisation of objects).

 

13. Note how the code in folder 07 has been divided into three folders. Note the presence of each compiled class.

Run the various services from their respective folders.

 

14. Change to folder 08. Stub class files can now be downloaded at runtime by the naming service and the client.

 

15. 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.

 

16. 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.

 

17. Restart the server with the following command:

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

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.

 

18. Start the client as follows:

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

 

19. We are now going to implement a number guessing game. Players join a game and make guesses. A game object on the server side makes a callback to all the clients involved in the game to tell them about the guess. We do this by putting a remote object on the client side (GamePlayer). This object will implement all the code that was previously implemented by the (non-remote) GameClient, and will also support two remote methods.

The first remote method allows an object to be passed from server to client. This object encapsulates some information about the game. For the moment all it contains is the status of the game (boolean over / not over) and a message about the last move made. Since this object is non-remote, it must be serialisable so that it can be copied between processes. These objects are instances of the GameInfo class (which is not shown in the diagram).

The second remote method on the client side allows the server to ask the client what the name of the player is.

A diagram of the architecture is shown here.

 

20. All the code is available zipped in folder 09.

The code we have is as follows:

For the GamePlayer:

  • Interface: GamePlayer.java
  • Implementation: GamePlayerImpl.java
  • Stub: Automatically Generated

For the GameFactory:

  • Interface: GameFactory.java
  • Implementation: GameFactoryImpl.java
  • Stub: Automatically Generated

For the Game:

  • Interface: Game.java
  • Implementation: GameImpl.java
  • Stub: Automatically Generated

Additionally, we also have:

  • GameInfo.java: The class whose objects get copied between processes.
  • GameClient.java: Instantiates a GamePlayer
  • GameServer.java: Instantiates a GameFactory

Compile all this code, generate the stub classes for the remote classes and run the program by running a server and a few clients.

Examine the code carefully.

21. Examine the additional code on Java Reflection in folder 10.

 


Further Reading

Chapter 5 of Coulouris, Dollimore and Kindberg book

Java Tutorial

Jim Waldo, Geoff Wyant, Ann Wollrath and Sam Kendall. A Note on Distributed Computing. Sun Microsystems. 1994

 

Hit Counter  [Home][School of Computing][Dublin Institute of Technology]