Given: Wednesday, September 12, 2001
Due: Monday, September 24, 2001
Weight: 5% of Final Grade
Overview:
In this project, you will create a simple client and two simple servers. The client will be able to communicate with each of the servers. The purpose of this project is to give yourself an idea how CORBA actually works and get you familiar with TAO. This first project shouldn’t cost you more than five or ten hours but just get you started a little bit, and get over the initial learning curve in using CORBA in general and TAO in particular.
Additional information will likely come by email to the class list, so please be sure that you are on it. The IDL file and a Makefile that works given the interface/class names below will be provided.
Problem setting:
Design and implement a simple CORBA system, using TAO. Suppose we have three kinds of objects in our system: Forecaster, Temperature, and Barometer (do use these class/interface names, please).
The given IDL interface Weather.idl is like:
//Weather.idl
module Weather {
interface Temperature {
float
current_temperature(in string city);
};
interface Barometer {
float current_pressure(in string city,
in
float altitude);
};
};
The two servers simply return the requested variables to the client, printing out the value they are going to send back. Upon receiving the responses, the client prints them out.
You might wonder how do the two servers get current temperature and pressure. In fact, you can create some random figures and send them back to the client. It would be nice if you maintain a list of cities and corresponding temperatures, and you may even take the date and time into consideration. But it is not the purpose of this project to run into this kind of details. So you may just use a random function on the server side.
Students enrolled in Cpts 564 should add an exception to their program indicating that the city name is invalid, and use it in both methods. The servers should check if the city name passed in is one of those from a small table of known cities. If it is not, then the exception should be thrown by the server. That exception should of course be caught by the client (that is, assuming you want full credit).
This is only 20% of your grade, so we strongly suggest you get the base program going first, and then add the exceptions. Once you get the rest going, it should not take more than a few hours.
Implementation steps:
It is strongly recommended that you carefully read and study the handouts of the last lecture (Monday, September 10) before you start. The steps below are very much like those in the handout.
Don’t forget to “source” before you work on your programs. Just type in “source /net/corba/tao.csh” to setup necessary environment variables.
2. IDL and IDL compilation
In page 1, the objects are specified for you as well as the IDL file. Compiling the IDL will result in several files generated on client-side and server-side.
3a. Create the client-side code (Forecaster).
Remember that the Forecaster will need to access two servers. (Hint: you might want to use two IOR files).
3b. Create the server-side code (Temperature & Barometer).
This is the majority of the work you need to do, but you can gather/borrow details from your working MessengerServer example.
3c. Create the Object Implementation Code.
This is where you plug in your random number generator (or other mechanism for the given servers).
As a starting point you could use the Makefile from the Messenger example, but you’ll need to extend the Makefile so that two servers are supported (i.e., add additional rules).
When you’ve got everything right, make the
forecasting client call each of the servers and print to the screen the
information it gets.
Turn-ins:
Turn in hardcopy of all your created files. Note, the “created” files are not all those “generated”. In addition, turn in the sample output when your program is correctly running. (That is, the client sends request to the two servers and gets responses from both.) You only need to copy the output from the screen (or send it to a file) and print it out. Finally, do not modify or otherwise change the last accessed dates on your created files after the submission date, in case we need to check the files. These final files should reside somewhere underneath your EECS home directory.