Page #492 (36.5. Developing Three-Tier Applications Using RMI)
36.6. RMI Callbacks
In a traditional client/server system, a client sends a request to a server, and the server processes the request and returns the result to the client. The server cannot invoke the methods on a client. One of the important benefits of RMI is that it supports callbacks , which enable the server to invoke methods on the client. With the RMI callback feature, you can develop interactive distributed applications.
In §25.9, "Case Studies: Distributed TicTacToe Games," you developed a distributed TicTacToe game using stream socket programming. The following example demonstrates the use of the RMI callback feature to develop an interactive TicTacToe game.
All the examples you have seen so far in this chapter have simple behaviors that are easy to model with classes. The behavior of the TicTacToe game is somewhat complex. To create the classes to model the game, you need to study and understand it and distribute the process appropriately between client and server.
Clearly the client should be responsible for handling user interactions, and the server should coordinate with the client. Specifically, the client should register with the server, and the server can take two and only two players. Once a client makes a move, it should notify the server; the server then notifies the move to the other player. The server should determine the status of the game, that is, whether the game has been won or drawn, and should notify the players. The server should also coordinate the turns, that is, which client has the turn at a given time. The ideal approach for notifying a player is to invoke a method in the client that sets appropriate properties in the client or sends messages to a player. Figure 36.7 illustrates the relationship between clients and server.
Figure 36.7. The server coordinates the activities with the clients.
All the calls a client makes can be encapsulated in one remote interface named TicTacToe (Listing 36.7), and all the calls the server invokes can be defined in another interface named CallBack (Listing 36.8).
Listing 36.7. TicTacToeInterface.java
(This item is displayed on pages 1256 - 1257 in the print version)
1 import java.rmi.*; 2 3 public interface TicTacToeInterface extends Remote{ 4 /** 5 * Connect to the TicTacToe server and return the token. 6 * If the returned token is ' ', the client is not connected to 7 * the server 8 */ 9 public char connect(CallBack client) throws RemoteException; 10 11 /** A client invokes this method to notify the server of its move*/ 12 public void myMove( int row, int column, char token) 13 throws RemoteException; 14 } |
Listing 36.8. CallBack.java
1 import java.rmi.*; 2 3 public interface CallBack extends Remote { 4 /** The server notifies the client for taking a turn */ 5 public void takeTurn( boolean turn) throws RemoteException; 6 7 /** The server sends a message to be displayed by the client */ 8 public void notify(java.lang.String message) 9 throws RemoteException; 10 11 /** The server notifies a client of the other player's move */ 12 public void mark( int row, int column, char token) 13 throws RemoteException; 14 } |
What does a client need to do? The client interacts with the player. Assume that all the cells are initially empty, and that the first player takes the X token and the second player takes the O token. To mark a cell, the player points the mouse to the cell and clicks it. If the cell is empty, the token (X or O) is displayed. If the cell is already filled, the player's action is ignored.
From the preceding description, it is obvious that a cell is a GUI object that handles mouse-click events and displays tokens. The candidate for such an object could be a button or a panel. Panels are more flexible than buttons . The token (X or O) can be drawn on a panel in any size , but it only can be displayed as a text on a button.
Let Cell be a subclass of JPanel . You can declare a grid to be an array Cell[][] cell = new Cell[3][3] for modeling the game. How do you know the state of a cell ( marked or not)? You can use a property named marked of the boolean type in the Cell class. How do you know whether the player has a turn? You can use a property named myTurn of boolean . This property (initially false ) can be set by the server through a callback.
The Cell class is responsible for drawing the token when an empty cell is clicked, so you need to write the code for listening to the MouseEvent and for painting the shape for tokens X and O. To determine which shape to draw, introduce a variable named marker of the char type. Since this variable is shared by all the cells in a client, it is preferable to declare it in the client and to declare the Cell class as an inner class of the client so that this variable will be accessible to all the cells.
Now let us turn our attention to the server side. What does the server need to do? The server needs to implement TicTacToeInterface and notify the clients of the game status. The server has to record the moves in the cells and check the status every time a player makes a move. The status information can be kept in a array of char . You can implement a method named isFull() to check whether the board is full and a method named isWon(token) to check whether a specific player has won.
Once a client is connected to the server, the server notifies the client which token to use; that is, X for the first client, and O for the second. Once a client notifies the server of its move, the server checks the game status and notifies the clients.
Now the most critical question is how the server notifies a client. You know that a client invokes a server method by creating a server stub on the client side. A server cannot directly invoke a client, because the client is not declared as a remote object. The CallBack interface was created to facilitate the server's callback to the client. In the implementation of CallBack , an instance of the client is passed as a parameter in the constructor of CallBack . The client creates an instance of CallBack and passes its stub to the server, using a remote method named connect() defined in the server. The server then invokes the client's method through a CallBack instance. The triangular relationship of client, CallBack implementation, and server is shown in Figure 36.8.
Figure 36.8. The server receives a CallBack stub from the client and invokes the remote methods defined in the CallBack interface, which can invoke the methods defined in the client.
Here are the steps to complete the example.
| 1. | Create TicTacToeImpl.java (Listing 36.9) to implement TicTacToeInterface . Add a main method in the program to register the server with the RMI. Listing 36.9. TicTacToeImpl.java(This item is displayed on pages 1258 - 1260 in the print version)
| |
| | ||
| 2. | Create CallBackImpl.java (Listing 36.10) to implement the CallBack interface. Listing 36.10. CallBackImpl.java
| |
| 3. | Create an applet TicTacToeClientRMI (Listing 36.11) for interacting with a player and communicating with the server. Enable it to run standalone. Listing 36.11. TicTacToeClientRMI.java(This item is displayed on pages 1261 - 1264 in the print version)
| |
| 4. | Follow the steps below to run this example.
|
Figure 36.9. Two players play each other through the RMI server.
TicTacToeInterface defines two remote methods, connect(CallBack client) and myMove(int row, int column, char token) . The connect method plays two roles: one is to pass a CallBack stub to the server, and the other is to let the server assign a token for the player. The myMove method notifies the server that the player has made a specific move.
The CallBack interface defines three remote methods, takeTurn(boolean turn) , notify(String message) , and mark(int row, int column, char token) . The takeTurn method sets the client's myTurn property to true or false . The notify method displays a message on the client's status label. The mark method marks the client's cell with the token at the specified location.
TicTacToeImpl is a server implementation for coordinating with the clients and managing the game. The variables player1 and player2 are instances of CallBack , each of which corresponds to a client, passed from a client when the client invokes the connect method. The variable board records the moves by the two players. This information is needed to determine the game status. When a client invokes the connect method, the server assigns a token X for the first player and O for the second player, and only two players are accepted by the server. You can modify the program to accept additional clients as observers. See Exercise 36.7 for more details.
Once two players are in the game, the server coordinates the turns between them. When a client invokes the myMove method, the server records the move and notifies the other player by marking the other player's cell. It then checks to see whether the player wins or whether the board is full. If neither conditions applies and therefore the game continues, the server gives a turn to the other player.
The CallBackImpl implements the CallBack interface. It creates an instance of TicTacToeClientRMI through its constructor. The CallBackImpl relays the server request to the client by invoking the client's methods. When the server invokes the takeTurn method, CallBackImpl invokes the client's setMyTurn() method to set the property myTurn in the client. When the server invokes the notify() method, CallBackImpl invokes the client's setMessage() method to set the message on the client's status label. When the server invokes the mark method, CallBackImpl invokes the client's mark method to mark the specified cell.
TicTacToeClientRMI can run as a standalone application or as an applet. The initializeRMI method is responsible for creating the URL for running as a standalone application or as an applet, for locating the TicTacToeImpl server stub, for creating the CallBack server object, and for connecting the client with the server.
Interestingly, obtaining the TicTacToeImpl stub for the client is different from obtaining the CallBack stub for the server. The TicTacToeImpl stub is obtained by invoking the lookup() method through the RMI registry, and the CallBack stub is passed to the server through the connect method in the TicTacToeImpl stub. It is a common practice to obtain the first stub with the lookup method, but to pass the subsequent stubs as parameters through remote method invocations.
Since the variables myTurn and marker are defined in TicTacToeClientRMI , the Cell class is defined as an inner class within TicTacToeClientRMI in order to enable all the cells in the client to access them. Exercise 36.7 suggests alternative approaches that implement the Cell as a non-inner class.
EAN: N/A
Pages: 503