1176-1178 | Oracle Development Unleashed (3rd Edition)

Previous Table of Contents Next

Page 1176

These are just a few general design strategies that are commonly used, but the possible designs and configurations of distributed object systems are almost endless. In some respects, a distributed object system is never complete. It evolves over time as additional services are made available, network configurations are changed, new tools are developed, and so on. By design, CORBA-based systems are extremely flexible. Most successful implementations use this advantage by starting small, minimizing client-side dependencies, and extending the system in manageable increments .

Communicating with Oracle

Up to this point, Oracle barely has been mentioned. This is because the nature of any discussion of the CORBA architecture places no emphasis on actual object implementations. Oracle provides a number of means for implementing database interfaces in Java. An object implementation could communicate directly with the Oracle8 JDBC driver, through classes developed with the J/SQL preprocessor, PL/SQL wrappers generated with pl2java, or through a custom OCI interface. All these methods are covered in other chapters of this book.

From the perspective of CORBA, the choice is irrelevant. The CORBA architecture is designed to provide a means of developing platform- and language-independent distributed object systems. CORBA clients will be able to access object references from anywhere on the network, on any platform, with implementations developed in any language, completely transparently . This capability is what makes CORBA the driving force behind the next generation of Web applications.

CGI Programming with Perl

The simplest, albeit oldest, method for creating dynamic Web pages is called the Common Gateway Interface (CGI). Dynamic Web pages are constructed (typically, using data from a database) upon their request. This occurs often when users issue searches through their Web browsers. A Web page is sent back to the browser from the Web server, which contains a partial list of other pages that match the search criteria. This kind of functionality seems a bit crude when compared to other methods of creating dynamic Web pages, but CGI currently handles the vast majority of this kind of Web page processing. Unlike Java, CGI cannot update a Web page in real time. Web pages that need to constantly update information, such as financial market data, are best created through the use of Java.

All CGI processing is performed on the Web server. The browser sends a request over to the Hypertext Transport Protocol (HTTP) server. This request may look something like this:

 http://www.advantis.com:8080/cgi-bin/get_cust_info?customer_id=10000

This an example of a user requesting detailed information for a given customer. The Web server calls the CGI script get_customer_info to perform the processing. Information is sent back to the Web browser, which contains the results of the CGI script. These results commonly are in the form of an HTML page such as the following:

Page 1177

 <HEAD> <TITLE> Customer Information </TITLE> </HEAD> <BODY> Advanced Information Systems, Inc. </BODY>

What Are CGI Scripts?

CGI scripts are pieces of code available on the server to handle requests from Web browsers. These scripts can be programmed in various languages, including C, C++, JavaScript, and Perl. CGI is largely a protocol that enables scripts written in these different languages to interface with the Web server. This protocol defines inputs, outputs, and calling conventions between the Web server and the scripts. Parameters to the script are passed from the browser to the Web server as environment variables in the format of variable=value, where variable is the name expected by the script. Variable/value pairs are separated with ampersands when more than one pair is used. The Web server sets operating system environment variables and invokes the CGI script. A set of standard inputs is set by the server prior to invoking the CGI script. Table 52.6 lists the CGI standard inputs.

Table 52.6. CGI standard inputs.

Variable	Specifies
AUTH_TYPE	Authentication method
CONTENT_LENGTH	Size in bytes of an attached MIME stream
CONTENT_TYPE	Type of MIME data
GATEWAY_INTERFACE	Server's CGI version
PATH_INFO	Path information for the script
PATH_TRANSLATED	Translated PATH_INFO by the server to a physical path
QUERY_STRING	URL-encoded query string
REMOTE_ADDR	IP address of the requester
REMOTE_HOST	Domain name of the requester
REMOTE_IDENT	Identity of the requester
REMOTE_USER	User ID of the requester
REQUEST_METHOD	Request method being used
SCRIPT_NAME	Script's path and name being invoked
SERVER_NAME	Server host name
SERVER_PORT	Server port number
SERVER_PROTOCOL	Protocol and version being used
SERVER_SOFTWARE	Name of the server software

Page 1178

The values for these standard inputs are set using environment variables, which makes it easy for the server to interface with almost any language. The scripts simply read these variables using calls to the operating system and set private variables using passed values at runtime. CGI scripts have the option of using these variables or disregarding them.

Request Methods

Most CGI programs conform to one of three types of request methods: GET, HEAD, and POST. Although these three are more common, the CGI specification enables developers to define their own request methods. The GET method is used to request information from the server. An example of this is when a browser requests a particular uniform resource locator (URL). The HEAD method is used when the requester wants to receive information about a particular HTML page without getting the entire page. This method enables the requester to retrieve the HEAD part of the page only. The POST method is used when information originating from a Web user, perhaps for filling out an HTML form, needs to be stored to a central file or database.

Output of CGI Scripts

The main purpose for calling CGI scripts is to get information back to the caller ”typically, a Web browser. The CGI script therefore is responsible for creating information that a Web browser can present. Common output for CGI scripts is standard HTML. Other formats include plain text as well as several image types, including GIF and JPEG. You can use more advanced output in the form of MPEG files to display motion pictures.

Security Issues with CGI

CGI offers very tight security in one respect. Unlike some of the newer techniques used to invoke processing information, such as Java and ActiveX, CGI is not a threat to the client-side system. All CGI programs run on the server and produce output that is sent to the browser and simply displayed. Java and ActiveX programs run on the client workstation and also can invoke remote processes that can span multiple networked computers. The possibility of these programs compromising the integrity of your personal computer is frightening.

The pitfalls of CGI can be numerous . An entire book could be written to cover this topic. A few very common suggestions follow:

Use a quality server. This helps ensure that back doors and security leaks are minimized. Some servers offer encryption techniques and user authentication.
Restrict access to server resources, including files, programs, and databases. Configure the server to limit access permissions by IP, subnet, or domain. These restrictions are particularly important when referencing sensitive data.

Previous Table of Contents Next