Method and apparatus for efficient SQL processing in an n-tier architecture

A method and apparatus for efficiently processing data requests in a network oriented n-tier database environment is presented. According to one embodiment of the invention, certain or all data from the tables of a database server device can be maintained in tables on the client device in a client side database cache server system. This local cache allows the network oriented n-tier database system to eliminate the expense of repetitive network transmissions to respond to duplicate queries for the same information. Additionally, the local client device may also keep track of what data is cached on peer network nodes. This allows the client to request that data from a peer database cache server and off load that burden from the database server device. Moreover, the local client may also keep statistics regarding the frequency of requested data in order to optimize the data set maintained in the local database cache server.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention relates to computer database data request systems, and more particularly to the efficient processing of database requests in an n-tier computer network environment.

2. Related Art

Many companies that utilize computer database systems face the issues of network bandwidth, transaction speed, and client and server performance. These issues are fundamentally related to the current architecture for computer networked database systems.

For example, in the existing architecture, all queries from a client are sent to a database server for execution. The client and the server typically reside on different computers on the network. Thus, each client data request requires a round trip over the network. In the request portion of the round trip, the data request is delivered from the client to the server. On this portion of the round trip, a data request may pass through several tiers or intermediate servers, for example an application server. In the response portion of the round trip, a response is delivered from the server to the client. The performance of a network round trip depends on the stability, bandwidth, and traffic density of the network as well as the load on the server. Several queries sent at once, or a single large data request can potentially slow down the performance.

This type of increased response time is currently experienced notwithstanding the availability of unused computing power on the client computer. Furthermore, as the number of clients on a network increase, the scalability of the server must similarly increase in order to handle an increased number of queries.

SUMMARY OF THE INVENTION

The present invention relates to a method and apparatus for efficiently processing data requests in a computer network oriented n-tier database environment. According to one embodiment of the invention, certain tables from the database server system can be maintained on the client system in a local cache storage system. A local database cache server manages the local cache storage system and allows the n-tier database environment to eliminate the expense of repetitive network transmissions to respond to similar queries for similar information.

Additionally, the local client may also keep track of what data is stored in the local cache storage system of peer client systems residing on the network. This allows the client to route data requests to a peer client system's database cache server, rather than the database server system. Moreover, the local client may also keep a record of frequently requested tables in order to optimize the data set maintained in the client's local cache storage system.

Further details, aspects, objects, and advantages of the invention are described below in the drawings, detailed description, and claims.

DETAILED DESCRIPTION OF THE INVENTION

The present invention is directed toward a method and apparatus for efficient query processing. More specifically, the present invention relates to the implementation of local database cache servers to decrease network traffic and server load in an n-tier database environment implemented over a computer network. After reading this description, it will become apparent to one skilled in the art how to practice the invention in one or more alternative embodiments. As such, this detailed description of one or more alternative embodiments should not be construed to limit the scope of breadth of the present invention.

1. Introduction and Overview

An aspect of the present invention relates to an n-tier database environment implemented over a computer network.FIG. 1is a block diagram illustrating an example n-tier database environment implemented over a computer network according to one embodiment of the present invention. InFIG. 1, there are four client computers, namely client10, client20, client30, and client40. Each client computer is coupled together with the other client computers and the database server50over the network100.

Client10is configured with a database cache server110. Similarly, client20is configured with database cache server120, client30is configured with database cache server130, and client40is configured with database cache server140. To avoid confusion, the client computers10-40will hereafter be referred to singularly as client10and the database cache servers110-140will hereafter be referred to singularly as database cache server110, except where appropriate to call attention to specific aspects of the present invention. Advantageously, client10is configured to communicate with database server50over the network100. Additionally, database cache server110is configured to communicate with the database server50over the network100.

FIG. 2depicts a block diagram of client10coupled with server50over the network100. In one embodiment, client10may be comprised of a database cache server110and a data request generator200. In an alternative embodiment, the client10additionally comprises data request generator210and data request generator220. In this alternative embodiment, client10may have more than one data request generator. A data request generator200may be any well known computer application capable of generating a standard database data request.

The database cache server110is comprised of a request router250and a partial database260. The partial database260may be comprised of database tables containing a portion of the information stored in the database server50. Additionally, partial database260may contain information regarding the peer database cache servers that may exist on client systems that may be accessible via the network100. Furthermore, partial database260may contain information regarding the frequency of data requests from the data request generator200. It may also contain statistics regarding the particular types of data requests that were successfully and unsuccessfully answered by the peer database cache servers. In one embodiment, the statistics may be used by the request router250to determine which peer database cache server to receive requests that may be unanswerable by the local database cache server110.

The request router250may be configured to read data from and write data to the partial database260. Additionally, the request router250may advantageously be configured to communicate with both the data request generator200and the database server50. In one embodiment, the request router is configured to communicate with the data request generator200through a communications channel270.

For example, a data request may originate from a data request generator200. This data request may be sent by the data request generator200to the request router250via a communications channel270. In one embodiment, communications channel270is a programmably created inter process communication pipe. Alternatively, communications channel270may be a commonly accessed area of shared memory or a shared file. Additionally, communications channel270may be a network socket. For example, in one embodiment, the database cache server110may reside on a separate computer on the network100. The communications link270in this embodiment may be a socket that is open on both the client10, where the data request generator200resides, and the computer where the database cache server110resides.

Once the data request is sent to the request router250via communications channel270, the request router250consults the partial database260. The request router250may then execute the data request to determine whether or not the partial database260contains the appropriate tables so that the request router250may provide a response to the data request. If the request router250may successfully respond to the data request, it may then retrieve the data from the corresponding tables in the partial database260. Upon receiving the data from the partial database260, the request router250may then forward that data in a response format to the data request generator200. In one embodiment, the response is sent to the data request generator200through the communications channel270.

Alternatively, the request router250may consult the partial database260and determine that the tables necessary to respond to the data request are not located within the partial database260. Therefore, the request router250may not provide a response to the data request. In one embodiment, the request router250may then forward the data request over the network100to the database server50. The request router250may determine the location of the database server50from the data request. The database server50may then respond to the data request in a standard fashion and send the response back to the request router250over the network100. Once the request router250receives a response from the database server50, the request router250may then forward that response to the data request generator200.

FIG. 3depicts the client10with database cache server110coupled over the network100with client20, client30, client40, and the database server50. Also shown inFIG. 3is database cache server120coupled with client20, database cache server130coupled with client30, and database cache server140coupled with client40. These additional database cache servers are collectively referred to as peer database cache servers. In one embodiment, one or more additional clients with peer database cache servers may be coupled with the client10and the database server50over the network100.

In one embodiment, a state may arise where the request router250is unable to respond to a data request after consulting the tables in partial database260. In this embodiment, the request router250may then forward the data request to the database server50. Alternatively, the request router250may forward the data request to a peer database cache server.

For example, once the request router250receives a data request from the data request generator200via communications channel270, the request router250executes the data request on the partial database260. In one embodiment, execution of a data request on the partial database260determines whether the partial database260contains the tables necessary to correctly respond to the data request. If the request router250executes the data request on the partial database260and determines that it cannot respond to the data request, the request router250may forward the data request to the database server50for processing. Alternatively, the request router250may send the data request to a peer database cache server for processing.

For example, the request router250may send the data request to client20for processing by peer database cache server120. Advantageously, sending a data request to a peer database cache server may reduce the load on the database server50. Additionally, the response time for a data request sent to a peer database cache server may advantageously be less than the response time for a data request sent to the database server50. This may be due to the relative workloads of the peer database cache server and the database server50.

In one embodiment, request router250maintains information in partial database260regarding each peer database cache servers that is coupled with client10over the network100. For example, partial database260may contain information regarding the success or failure of each peer database cache server for a particular type of data request. The request router250may consult this information in partial database260prior to selecting a client to receive the forwarded data request for processing by its associated peer database cache server. For example, request router250may determine from partial database260that client20was unable to successfully respond to a particular type of data request in the past. Therefore, request router250may not forward a data request of that particular type to client20for processing by database cache server120.

In an alternative embodiment, request router250may determine from partial database260that client30has successfully responded to a particular type of data request in the past. Advantageously, the request router250may then intelligently determine that client30is the client with the highest likelihood of successfully responding to the data request. In this embodiment, request router250may then forward the data request to client30for processing by database cache server130.

In one embodiment, request router250receives no information from partial database260regarding the relative success of peer database cache servers for responding to a particular type of data request. In this embodiment, request router250may then select a client from a lit of available clients and forward the data request to that client for processing by the client's associated peer database cache server. If the selected client is unsuccessful in responding to the data request, the request router250may select another client from the list and repeat the process.

For example, the request router250may first select client20and forward the data request to client20for processing by peer database cache server120. If client20is unable to respond to the data request, the request router250may then select client30and forward the data request to client30for processing by peer database cache server130. If the clients who receive the data request continue to be unsuccessful in responding to the data request, the request router250may proceed through the list of clients until a successful response is received or until the list is exhausted. In one embodiment, once the list is exhausted, the request router250forwards the data request to the database server50for processing.

Once request router250has received a successful response from a client with a peer database cache server, or the database server50, request router250forwards the response to the requesting data request generator200. In one embodiment, the request router250may additionally update partial database260with information regarding the success of each client in responding to the particular type of data request. Also in this embodiment, the request router may update partial database260with information regarding the failure of each client in responding to the particular type of data request. In this fashion, the next time request router250receives the particular type of request, the request can advantageously be initially forwarded to a client with a successful record for processing data requests of that particular type.

In one embodiment, each of the available peer database cache servers fails to successfully respond to the data request. In this embodiment, the request router250then sends the request to database server50. When the request router250receives a successful response from the database server50, the request router250forwards the response to the requesting data request generator200. In one embodiment, the request router250may additionally update the tables in partial database260with the data from the database server50. In this fashion, the database cache server110may advantageously respond to subsequent queries of that particular type without forwarding the data request to a peer database cache server or the database server50.

FIG. 4illustrates a high level flowchart detailing a process for a database cache server110to efficiently respond to data requests according to one embodiment of the present invention. In step400, a data request is created by a data request generator200. The data request generator200can be any type of standard or customized software application with the capability to generate a database data request. For example, a World Wide Web (“Web”) browser may be a data request generator200because it has the capability to generate search requests for Web search engines.

Once a data request is created by the data request generator200, the request is then sent to the database cache server110through communications channel270. In one embodiment, the communications channel270is implemented by inter process communication. For example, the database cache server110may create a utility and make that utility available to the data request generator200so that the data request generator200may write data requests to the utility. Similarly, the database cache server110may read from the utility, thus creating a unidirectional pipe for communication from the data request generator200to the database cache server110. Additionally, a corresponding unidirectional pipe for communication from the database cache server110to the data request generator200may be created by the database cache server110. Furthermore, the communications channel270may be implemented in alternative embodiments through the use of shared files or shared memory. Moreover, one skilled in the art may employ alternative methods for the communications channel270.

As shown in step420, once the database cache server110has received the data request from the data request generator200, the database cache server110may execute the data request. This execution of the data request serves the purpose of determining whether the database260contains the appropriate tables to satisfy the data request. In step430, the database cache server110analyzes the results of step420to determine if the database cache server110may successfully respond to the data request. If the database cache server110determines that it cannot successfully respond to the data request, the database cache server110may route the data request to the database server50in step440.

If the database cache server110determines that it can successfully respond to the data request, the database cache server110may retrieve the data in step450. For example, the database cache server110may perform a table lookup to generate the data in response to the data request. Once the database cache server110has retrieved the data in step450, the resulting data is returned to the data request generator200. For example, the database cache server110may write the data resulting from the table lookup to the unidirectional pipe for the data request generator200to read.

Alternatively, if the database cache server110determines that it cannot successfully respond to the data request, the database cache server110may route the data request to the database server50, as illustrated in step440. Once the database server50has received the data request, the database server50may then retrieve the data in step470. In step480, the database server50may send the resulting data to the database cache server110of client10. Once the database cache server110has received the resulting data from the database server50, a response is returned to the data request generator200. For example, the database cache server110may write the data resulting from the table lookup to the unidirectional pipe for the data request generator200to read.

FIG. 5depicts a flowchart illustrating a process for request router250to efficiently route data requests according to one embodiment of the present invention. The routing process begins once request router250has determined that the database260does not contain the appropriate tables to successfully respond to a data request. In step500, the request router250may determine if there are any peer database cache servers available to process the data request.

In one embodiment, the database cache server110maintains a table in database260that includes a list of available peer database cache servers. The list may be maintained as a simple text file or as a data record entry in a database. Additionally, the list may contain various types of information germane to operation such as node names, computer names, peer database cache server names, historical lists of queries, success/failure rates for each query and for each peer database cache server, routing information, IP addresses, ethernet addresses, and the like. If there are no peer database cache servers available, in step440the request router250may route the data request to database server50. Once the database server50has received the data request, the database server50may then retrieve the data in step470. In step480, the database server50may send the resulting data to the database cache server110of client10. Once the database cache server110has received the resulting data from the database server50, a response is returned to the data request generator200. For example, the database cache server110may write the data resulting from the table lookup to the unidirectional pipe for the data request generator200to read.

Alternatively, when peer database cache servers are available to process the data request, the request router250may intelligently route the data request to a peer database cache server, as illustrated in step510. In one embodiment, the database cache server110maintains information in database260regarding the available pool of peer database cache servers, In one embodiment, a list of available peers may be provided to the system by an administrator and maintained manually or dynamically. Alternatively, each peer on the network may broadcast its presence and a list may be initially populated and perpetually maintained by receipt of such information broadcast over the network. This additional information may comprise statistics for each peer database cache server regarding each database cache server's ability to successfully respond to a data request of a particular type. Furthermore, the information in the tables may be periodically synchronized at regular intervals using standard database replication technology that is well known in the art.

For example, if peer database cache server120had successfully responded to a particular data request from client10in the past, a record of that successful response may be present in the database260of database cache server110. In such an example, request router250may advantageously route subsequent data requests of that particular type to database cache server120. Alternatively, database260may also contain information regarding the queries for which each peer database cache server failed to respond successfully. For example, if peer database cache server130had failed to successfully respond to a data request from client10in the past, a record of that failure may be present in the database260of database cache server110. In such an example, request router250may advantageously refrain from routing subsequent data requests of that particular type to database cache server130.

Once the data request has been routed to a peer database cache server in step510, the peer database cache server executes the data request in step520. Execution of the data request may determine whether the peer database cache server contains the appropriate tables to satisfy the data request. In step530, the peer database cache server may analyze the results of the data request execution to make this determination. In one embodiment, if the tables in the peer database cache server do not contain the appropriate data to respond to the data request, the peer database cache server sends a failure notice to the originating peer.

Once a failure notice has been received by client10, the process iterates and request router250may then determine if there are additional peer database cache servers available to process the data request. If there are no additional peer database cache servers, the request router250may route the data request to the database server50for processing, as shown in step440.

However, in step530if the peer database cache server executes the data request and determines that it has the appropriate tables to satisfy the data request, the peer database cache server retrieves the data in step550. The resulting data from the table lookup is then returned as a response to client10in step560.

Once the client10has received a successful response to the data request from a peer database cache server or the database server50, the database cache server110may send the resulting data to the data request generator200through the communications channel270. For example, the database cache server110may write the resulting data to the unidirectional pipe for the data request generator200to read.

FIG. 6depicts a flowchart illustrating a process for database cache server110to maintain routing tables and statistics in database260to facilitate the efficient routing of data requests according to one embodiment of the present invention. As stated above, the database260may contain information regarding the success and failure of each peer database cache server's prior responses to particular types of data requests. For example, each time the request router250routes a data request to a peer database cache server, the database cache server110may store the success or failure of the response to the data request in a table in database260. The resulting table may contain extensive data regarding the ability of each peer database cache server to successfully respond to a particular type of data request. This data may then be used by the request router250to intelligently select a peer database cache server to subsequently receive a particular type of data request.

Some example types of data that may be stored in database260include the frequency of execution of particular queries, a list of which peers have successfully responded to the query, a list of which peers have not successfully responded to the query, and a user and query combination of success and failure, just to name a few.

Once the client10has received a response from a peer database cache server, in step600the database cache server110may update the appropriate tables in database260regarding the particular peer database cache server and the particular type of data request. In this fashion, the database cache server110is able to compile statistics regarding the success and failure rates of peer database cache servers.

Additionally, the database cache server110may also maintain tables in database260to reflect the frequency of particular data requests. This information may allow the database cache server110to intelligently determine which tables should be stored locally in database260. For example, if a certain data request is repeatedly requested by data generator200, a table in the database260may reflect the frequency of that request. In step610, the database cache server updates the tables in database260to reflect the frequency of particular data request requests. In this fashion, the database cache server110may record statistics regarding the most frequent data requests and maintain the tables in database260accordingly.

In one embodiment, if the frequency of a particular type of data request reaches a certain threshold, the database cache server110may intelligently decide to store in database260the tables necessary to successfully respond to a data request of that particular type. Additionally, if the database260is limited to a finite size, the database cache server110may remove certain tables from database260that have a diminished frequency of request. This may be done by the database cache server110in order to create the necessary space for the more frequently requested tables.

For example, in step620, the database cache server110may update the tables in database260with tables received from the database server50or a peer database cache server. In one embodiment, if the database cache server110did not have the tables in the database260to successfully respond to a data request, the data request may be sent by the request router250to the database server50. When the client10receives the response data from the database server50containing the necessary tables, the database cache server110may advantageously save the received tables in the database260. In this fashion, the next data request of that particular type may be successfully processed by the database cache server110. Advantageously, the processing of data requests by the database cache server110reduces the overall data request response time and also decreases the overall load on the database server50.

Below, an example implementation of the present invention is described to provide further detail of alternative applications of the present invention. The recitation of this example embodiment is included to provide additional description and in no way should be construed to limit the broad scope contemplated by the present invention.

FIG. 7is a block diagram showing the network oriented n-tier database system used for the purpose of the illustrated example. Items from previous figures are like numbered to avoid confusion. Therefore, the system has a client10and a client20, coupled with a database server50over network100.

Client10is comprised of a data request generator200programmably communicating with a database cache server110via a communications channel270. The database cache server110is comprised of a request router250and database260.

Client20is similarly comprised of a data request generator700in operative communication with a database cache server710via a communications link770. The database cache server710comprised of a request router750and database760.

The clients10and20may be configured to start with a particular initialization state. The initialization process that leads to the initialization state may be modified to achieve the desired initialization state. For example, in one state, the request router250is not engaged. In this embodiment, the database cache server110is disabled and the client110sends each data request generated by the data request generator200directly to the database server50.

Alternatively, the request router250may be engaged during initialization. For example, an environment variable or system flag can be set to indicate to the client10that the request router250should be engaged. In one embodiment, the environment variable may be called ORA_OCI_CACHE and set to a true value.

The request router250may also be engaged by starting up the database client in cache mode. For example, this may be accomplished by the use of a flag or a switch supplied to the database client application when that application is executed. In one embodiment, the switch OCI_CACHE is supplied as a command line argument when the database client application is executed. The presence of this switch on the command line may then cause the database client application to engage the request router250.

When the initialization state engages the request router250, the database cache server110is enabled and data requests from data request generator200are handled by the database cache server110. The database cache server110may respond to the data request directly, from the tables in database260, or the database cache server110may route the data request to a peer database cache server or the database server50.

During the initialization stage, the tables of database260may be enhanced to contain information regarding the availability of peer database cache servers on the network100. For example, database260may contain a table that contains a list of available peer database cache servers. The list may also include the network address of the peer database cache server. Additionally, the list may include the set of data that each peer database cache server maintains. In the present embodiment, an administrator may edit the peer database cache server table in database260on client10to update the list of available peer database cache servers to include client20, the network address of client20, and the set of tables maintained by client20. When the client10is subsequently initialized and the request router250is engaged, client10may route particular requests to client20for processing.

In the present illustrated embodiment, a data request may be created by the data request generator200. Following this request through the network oriented n-tier database environment, the request is sent by the data request generator200to the database cache server110. The data request generator200sends the data request through communications channel270. In one example, the communications link may be implemented through the use of inter process communication.

When a data request is passed to the database cache server110, it is received by the request router250. The request router250then executes the request to determine whether the cache110may successfully respond to the request. For example, the request router250determines if the database260contains the appropriate tables to allow the cache110to respond to the data request. If the necessary tables are present in database260, a table lookup is performed on database260and the resulting response is sent back to the request generator200by the request router250. The resulting response is sent to the request generator200through the communications channel270.

In the case where the database260does not contain the necessary tables to respond to the data request, the request router250may forward the data request to the database server50or the client20, which is a peer database cache server. For example, when the client10was initialized, the database260may have contained a table that referenced client20as a peer database cache server. In this embodiment, the request router250may then send the data request to client20, for processing by request router750.

When the client20receives the data request from client10, the database cache server710handles the request. Specifically, the request router750determines if the database760contains the appropriate tables to allow the cache710to respond to the data request. If the necessary tables are present in database760, a table lookup is performed on database760and the resulting response is sent back to the client10by the request router750. When the client10receives the successful response from peer database cache server client20, the database cache server110handles the resulting data. Specifically, the request router250sends the resulting response back to the request generator200. The resulting response is sent to the request generator200through the communications channel270.

After the response has been received, the request router250may update the tables in database260to reflect the successful response from peer database cache server20for this particular type of data request. Additionally, the request router250may update the tables in database260to reflect the increased frequency of this particular type of data request. Furthermore, the request router250may add the tables from the response to the database260. In this fashion, the database cache server110will be able to directly respond to subsequent queries of this particular type.

Alternatively, if the necessary tables are not present in database760, client20is unable to successfully respond to the request. In this embodiment, the request router750sends a failure notice back to client10indicating the failure. When the client10receives the failure notice from peer database cache server client20, the database cache server110handles the response. For example, after the failure notice has been received, the request router250may update the tables in database260to reflect the unsuccessful response from peer database cache server20for this particular type of data request. Additionally, the request router250may update the tables in database260to reflect the increased frequency of this particular type of data request.

Once the request router250has processed the failure notice from peer database cache server client20, the request router250determines the next available server that may process the request. In this illustrated example, the remaining available server is the database server50. Therefore, the request router250next sends the data request to the database server50.

The database server50receives the data request from client10and processes the request. The resulting data is sent by the database server50back to client10. When the client10receives the successful response from the database server50, the database cache server110handles the resulting data. Specifically, the request router250sends the resulting response back to the request generator200. The resulting response is sent to the request generator200through the communications channel270.

After the response has been received, the request router250may update the tables in database260to reflect the increased frequency of this particular type of data request. Additionally, the request router250may add the tables from the response to the database260. In this fashion, the database cache server110will be able to directly respond to subsequent queries of this particular type.

FIG. 8is a block diagram illustrating an exemplary computer system350which may be used in connection with various embodiments described herein. For example, the computer system350may be used in conjunction with a client, a database server, a data warehouse, a database management system, or to provide connectivity, data storage, and other features useful for effectuating efficient SQL processing in an n-tier architecture. However, other computer systems and/or architectures may be used, as will be clear to those skilled in the art.

The computer system350preferably includes one or more processors, such as processor352. Additional processors may be provided, such as an auxiliary processor to manage input/output, an auxiliary processor to perform floating point mathematical operations, a special-purpose microprocessor having an architecture suitable for fast execution of signal processing algorithms (“digital signal processor”), a slave processor subordinate to the main processing system (“back-end processor”), an additional microprocessor or controller for dual or multiple processor systems, or a coprocessor. Such auxiliary processors may be discrete processors or may be integrated with the processor352.

The processor352is preferably connected to a communication bus354. The communication bus354may include a data channel for facilitating information transfer between storage and other peripheral components of the computer system350. The communication bus354further may provide a set of signals used for communication with the processor352, including a data bus, address bus, and control bus (not shown). The communication bus354may comprise any standard or non-standard bus architecture such as, for example, bus architectures compliant with industry standard architecture (ISA), extended industry standard architecture (EISA), Micro Channel Architecture (MCA), peripheral component interconnect (PCI) local bus, or standards promulgated by the Institute of Electrical and Electronics Engineers (IEEE) including IEEE 488 general-purpose interface bus (GPIB), IEEE 696/S-100, and the like.

Computer system350preferably includes a main memory356and may also include a secondary memory358. The main memory356provides storage of instructions and data for programs executing on the processor352. The main memory356is typically semiconductor-based memory such as dynamic random access memory (DRAM) and/or static random access memory (SRAM). Other semiconductor-based memory types include, for example, synchronous dynamic random access memory (SDRAM), Rambus dynamic random access memory (RDRAM), ferroelectric random access memory (FRAM), and the like, as well as read only memory (ROM).

The secondary memory358may optionally include a hard disk drive360and/or a removable storage drive362, for example a floppy disk drive, a magnetic tape drive, an optical disk drive, etc. The removable storage drive362reads from and/or writes to a removable storage unit364in a well-known manner. Removable storage unit364may be, for example, a floppy disk, magnetic tape, optical disk, etc. which is read by and/or written to by removable storage drive362. The removable storage unit364includes a computer usable storage medium having stored therein computer software and/or data.

In alternative embodiments, secondary memory358may include other similar means for allowing computer programs or other instructions to be loaded into the computer system350. Such means may include, for example, a removable storage unit372and an interface370. Examples of secondary memory358may include semiconductor-based memory such as programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable read-only memory (EEPROM), or flash memory (block oriented memory similar to EEPROM). Also included are any other removable storage units372and interfaces370, which allow software and data to be transferred from the removable storage unit372to the computer system350.

Computer system350may also include a communication interface374. The communication interface374allows software and data to be transferred between computer system350and external devices, networks or information sources. Examples of some types of components that might comprise communication interface374include a modem, a network interface (such as an Ethernet card), a communications port, a PCMCIA slot and card, and an infrared interface, to name a few. Communication interface374preferably implements industry promulgated protocol standards, such as Ethernet IEEE 802 standards, Fibre Channel, digital subscriber line (DSL), asymmetric digital subscriber line (ASDL), frame relay, asynchronous transfer mode (ATM), integrated digital services network (ISDN), personal communications services (PCS), transmission control protocol/Internet protocol (TCP/IP), serial line Internet protocol/point to point protocol (SLIP/PPP), and so on, but may also implement non-standard interface protocols as well. Software and data transferred via communication interface374are generally in the form of signals378which may be electronic, electromagnetic, optical or other signals capable of being received by communication interface374. These signals378are provided to communication interface374via a channel376. This channel376carries signals378and can be implemented using wire or cable, fiber optics, a phone line, a cellular phone link, a radio frequency (RF) link, or other communications channels.

Computer programming instructions (i.e., computer programs or software) are stored in the main memory356and/or the secondary memory358. Computer programs can also be received via communication interface374. Such computer programs, when executed, enable the computer system350to perform the features relating to the present invention as discussed herein.

In this document, the term “computer program product” is used to refer to any media used to provide programming instructions to the computer system350. Examples of these media include removable storage units364and372, a hard disk installed in hard disk drive360, and signals378. These computer program products are means for providing programming instructions to the computer system350.

In an embodiment that is implemented using software, the software may be stored in a computer program product and loaded into computer system350using hard drive360, removable storage drive362, interface370or communication interface374. The software, when executed by the processor352, may cause the processor352to perform the features and functions previously described herein.