// IDL schema definition for Web server interface.
interface Web_Server
{
typedef sequence<octet> Content_Type;
struct Metadata_Type
{
// Status of the <get> operation. These
// values should map onto the normal HTTP
// status values, e.g., 200 means success, 404
// means "file not found," etc.
short status_;
// Modification date.
string modification_date_;
// Type of content.
string content_type_;
};
// Download the <contents> associated with <pathname>.
// The <metadata> reports information about the <contents>.
void get (in string pathname,
out Content_Type contents,
out Metadata_Type metadata);
};
The get operation is passed an in parameter
pathname, which is equivalent to the pathname you passed
to the Web server in assignment 1. The get operation
returns a pair of out parameters. The first one is an
octet sequence that contains the contents
identified by the pathname. The second is a
struct containing metadata that describes
certain information, such as the MIME type and return status, about
the contents. If an error occurs, the
status_ field of metadata will contain a
non-success value and the contents parameter will be
undefined.
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 request the server to download the content. In
addition, you must also write the server, which implements the
get operation that downloads content to the client.
To implement the
// Implement the Web_Server interface.
class Web_Server_i : virtual public POA_Web_Server
{
public:
// Download the <contents> associated with <pathname>.
// The <metadata> reports information about the <contents>.
virtual void get (const char *pathname,
Content_Type_out contents,
Metadata_Type_out metadata)
throw (CORBA::SystemException);
};
get operation you'll need to use OS
filesystem APIs, such as open(2), close(2),
and read(2). I recommend that you check the UNIX manual
pages for more details on using these functions.
In addition, you'll need to implement a main function
that defines an instance of Web_Server_i, obtains and
activates the RootPOA and then calls the ORB's run method
to start its 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 that contains something
like the following:
if you use the
iioploc://1.1@newport.ece.uci.edu:10015/P35ad159600081a38/\0\1server
-ORBObjRefStyle URL IOR format or
if you use the
IOR:000000000000001649444c3a43756269745...
-ORBObjRefStyle IOR IOR format. For more
information on these options, please see the TAO online
options documentation.
string_to_object() method
to convert the string into an object reference. This object reference
will then be downcast via _narrow() to an object
reference for the Web_Server interface. At this point,
it can call the get operation via the object reference to
download the file.
get returns successfully, write the contents
into a temporary file created in your WWW cache (e.g.,
/tmp/yourloginname) on the local host [creat,read/write].
Then, spawn an external viewer [fork/exec] to display the file. You
can determine the type of viewer to spawn by examining the the
content_type_ metadata returned by the server.
Back to ECE 255 home page.
Last modified 10:35:49 CST 08 January 2003