The License Plate Game (Assignment 3)

Overview

This document describes the activities you'll perform as part of a two-part assignment associated with the license plate game. In this assignment, you'll enhance the game so that it uses CORBA. In addition, you'll get to use more of the TAO ORB, which provides an implementation of the CORBA 3.0 specification.

Part One of the Assignment

In the first part of the assignment, you'll enhance your previous license plate game program to use a CORBA architecture that supports multiple clients and a reactive server architecture. Each client will have its own session, in which it will read commands from standard input and display the results from the server on its standard output. The commands will be sent to the server process, which will use a reactive concurrency architecture to run commands and return results to each game session.

The license plate game server will be defined using two OMG IDL interfaces that should appear in the Game module. These two interfaces should be defined as follows:

LP_Game -- This interface defines the following operations that implement a particular instance of the license plate game:
- void initialize (in string filename) raises (Invalid_File, Already_Initialized) -- Allow a player to designate a dictionary of valid words for use with a particular session.
- void configure (in string letter_set) raises (Invalid_Letter_Set, Not_Initialized, Already_Configured) -- Set the current letter set for a session to the desired three letter string of letters from a license plate.
- boolean query (in string word) raises (Not_Configured) -- Allow a player in a particular session to query whether the designated word contains the current letter set in order in the word and also exists in the dictionary. Whenever a query "matches" a word in the dictionary, the player receives 1 point - if the query doesn't match a point is subtracted.
- Word_List list () raises (Not_Configured) -- List all the words in the session's dictionary that match the current letter set. The list should be returned as an unbounded sequence of strings (i.e., typedef sequence<string> Word_List, one for each matching word.
- Player_Results results () raises (Not_Configured) -- Return the current results for all players in a particular game, where Player_Results is defined as a sequence of Player_Result structs containing information on each player.
- oneway void quit () -- A oneway call that informs the server that the client is done playing the game. Only when all players in a game have called quit() should the resources for that game be reclaimed. It's possible that this method will need to shutdown the ORB if LP_Game_Factory::shutdown() had been called and this is the last player to quit the last game on the server.
The initialize() and configure() methods can only be called once for a particular game. Subsequent calls on this game will raise the Already_Initialized or Already_Configured exception, respectively. The query(), list(), results(), and quit() commands can be invoked multiple times by players of the same game, but can only run when no other commands are executing concurrently on a game.
LP_Game_Factory -- This interface defines the following factory and management operations:
- LP_Game join (in string game_name, in string player_id) raises (Duplicate_ID, Game_Shutdown) -- Allows a player to join an instance of the LP_Game interface (or create and join the game if it doesn't already exist). This operation is passed a game_name, which is a string that identifies the game. If the game hasn't already been created, then allocate and activate a new LP_Game object containing the resources (e.g., dictionary, score table, etc.) associated with this particular instance of the game. Each player is identified by their unique player_id (the Duplicate_ID exception is raised if the player_id is not unique). This command returns an object reference to an LP_Game, which allows the client to uniquely identify the game.
- oneway void shutdown () -- A oneway call that shut downs the server process, ultimately leading to exiting the process. Only when all players and games have quit, however, should the server process actually exit. After shutdown() has been called, however, no further calls to join() should be allowed, i.e., it should raise the Game_Shutdown exception.

For the first part of the assignment you need to do the following:

Implement the IDL files as described above and run them through TAO's IDL compiler to make sure they are correct.
Create the servant classes that implement the servant skeletons generated by the IDL compiler. You don't need to actually implement the methods in these servant classes yet, however - that's what you'll do in Part Two. You might check out the -GI flag supported by TAO's IDL compiler.
Create "dummy" files for all the rest of your program, i.e., these don't need to do much of anything yet, though it would help you if they at least compile.
Create the appropriate Linux Makefile or MSVC++ project build file that can successfully build the dummy files and generated files, etc. You should start by looking at the example GNUmakefile for program 2 and simply "cut and paste" it and replace/add the necessary files.

Part Two of the Assignment

In the second part of the assignment you'll actually implement the client and server application programs that actually perform the license plate game using CORBA. Below, we discuss the general behavior of these client and the server programs. See the course notes, the TAO online manual pages, and the Advanced CORBA Programming with C++ book for additional details.

Server Application

The license plate game server program should perform the following activities:

Initialize the ORB, get a locality constrained object reference for the RootPOA, and activate the POA manager.
Create and activate an instance of the LP_Game_Factory object and write its object reference to a file. If you are a graduate student, please replace the use of the file to exchange object references with the CORBA Naming Service, which is implemented in TAO.
Run the ORB's event loop, which will perform the appropriate operation designated by the type of operation received from the client.
You'll need to carefully reference count the number of threads that are accessing session resources so that your server behaves correctly when clients send quit() and shutdown() commands.

Client Application

The license plate game client program should perform the following activities:

Initialize the ORB.
Read the object reference for the LP_Game_Factory from a file and narrow it properly. If you are a graduate student, please replace the use of the file to exchange object references with the CORBA Naming Service, which is implemented in TAO.
Read commands from the user's standard input, convert these into the appropriate operation calls to the LP_Game_Factory and LP_Game objects, wait for the reply, and display it to the standard output of the client.
When a client is finished playing the license plate game, it should call quit() so the server has a chance to reclaim the game resources.

You should use the Makefile Project Creator (MPC) to generate the Makefiles or MSVC++ project files for the second part of the assignment.

If you're a graduate student, you should ensure that your server works with either the thread-per-connection or thread pool concurrency models supported by TAO. If you are an undergrad you simply need to make sure things work with the reactive model, which is the default in TAO. Please look here for more details on these concurrency models.

Concluding Remarks

I strongly encourage you to use, develop, and apply reusable C++ components based on the code you wrote for the earlier programming assignments.

Please see the online help for information on how to setup your development environment on Vanderbilt University's Linux computing system.

Last modified 12:52:03 CDT 23 October 2007