// IDL schema definition for Time and Date interface.
interface Time_Date
{
/// Obtain the time and date in binary format.
void bin_date (out long time_date);
/// Obtain the time and date in string format.
void str_date (out string time_date);
};
The time and date can be returned as either a binary number or as a
string. If the number is returned as a binary then you can converted
it into a string and printed to the stdout of the user using the
ctime(3c) C library function. If the number is returned
as a string then you don't need to do any conversions. Note that by
returning the time and date as a long you'll save on network
bandwidth.
You will use a CORBA IDL compiler to translate this specification into
client-side stubs and server-side skeletons. The
client application (which you must write) will use the stubs as a
proxy to access the time and date service implemented by the
server. In addition, you must also write the server, which implements
the bin_date() and str_date() operations
that provide the time and date service.
// Implement the Time_Date interface.
class Time_Date_i : virtual public POA_Time_Date
{
public:
// constructor
Time_Date_i ();
/// Obtain the time and date in binary format.
virtual void bin_date (CORBA::Long_out time_date);
/// Obtain the time and date in string format.
virtual void str_date (CORBA::String_out time_date);
};
To implement the bin_date() operation you'll need to use
the time(2) system call. To implement
str_date() operation you'll need to use the
ctime(3c) library function to convert the time on the
server into an ASCII string representation of the time. I recommend
that you check your OS documentation for more details on using these
functions.
In addition, you'll need to implement a main() function
that defines an instance of Time_Date_i, obtains and
activates the RootPOA, and then calls CORBA::ORB::run()
method to run the server's event loop.
To make your life easy, the server should write its IOR to a file
before it calls the ORB's run method (later, we'll use
more advanced techniques, such as a Naming Service). Thus, when your
server is started, you should create a file called
time-date.ior that contains something like the following
if you use the
IOR:000000000000001649444c3a43756269745...
-ORBObjRefStyle IOR IOR format or
if you use the
iioploc://1.1@tango.dre.vanderbilt.edu:10015/P35ad159600081a38/\0\1server
-ORBObjRefStyle URL IOR format. For more
information on these options, please see the TAO online
options documentation.
time-date.ior file that contains the IOR discussed above.
When the client starts up, it can read the contents of this file using
the CORBA::string_to_object() method to convert the
string into an object reference. In TAO, you can do this with a
single CORBA::string_to_object() call by passing it the
"file://time-date.ior" string. The object reference
returned from this call will then be downcast via
_narrow() to an object reference for the
Time_Date interface. At this point, the client can call
the bin_date() and str_date() operations via
the object reference to obtain the time/date from the server. For the purposes of the assignment, you can make the client-side driver program very simple. The client can read a command from its standard input and send it to the server. For example, you could the following commands to the client:
% ./client
> b
Binary time is 71478939
> s
String time is Thu Nov 14 5:49 1996
Since the client and server communicate via the
time-date.ior file there's no need to indicate the server
name when you invoke the client. In a ``real'' application, we'd use
a Naming Service to remove the need for a shared file between the
client and server.
Once the client application has bound to an object reference for the
Time_Date interface, it can call the designated
operations via the object reference proxy. The client should simply
print out the appropriate exception and exit with a return status of 1
if anything fails to work properly. If everything works correctly,
the program should exit with a return status of 0.
Back to CS 282 home page.