Method and apparatus for transparently mapping a request to open a data file

[0001] The present invention generally relates to client-server computer systems.

[0002] Computer-based applications often access data which is stored in files. For example, a financial application typically operates on data which is stored in a “company file.” As such applications become increasingly more sophisticated, significant advantages can be gained by moving from a simple company file to a more-sophisticated database system, which is controlled by a database server. Using a more-sophisticated database system can provide improved performance, reliability, and scalability, especially for larger company files and simultaneous users.

[0003] However, it is typically necessary to configure a database server to operate in specific modes depending upon location of the data and the types of file accesses which are desired. For example, it may be necessary to configure the database server to access a remote file, or to support multi-user accesses to a file. This can be a problem because application users are typically used to existing file-based data operations, and are not very knowledgeable about the technical details related to invoking and/or configuring a database server. Hence, the desire to preserve a simple user experience may limit the improvements that can be incorporated into a system.

[0004] One embodiment of the present invention provides a system that transparently maps a request to open a data file. First, the system receives a request from a user or client application to open the data file. Next, the system determines from file meta information that the file is a relational data file, and proceeds to transparently map the file open operation to a corresponding relational database operation by discovering a database service configured to manage the relational data file and then sending a request to open the relational data file to this database service. By transparently mapping the file open operation to the corresponding relational database operation, the system allows an underlying data file to be changed to a relational data file without changing the way the user interacts with the client application and/or data file.

[0005] In a variation on this embodiment, the relational data file and the database service are hosted on the same computing device.

[0006] In a variation on this embodiment, the relational data file and the database service are hosted on different computing devices.

[0007] In a further variation, the client application is hosted on: the same computing device as the relational data file; the same computing device as the database service; or on a computing device that hosts neither the relational data file nor the database service.

[0008] In a variation on this embodiment, instances of the client application can include instances of the database service, potentially leading to multiple simultaneous instances of the database service. In this embodiment, one instance among these multiple instances manages access to the relational data file, and the system discovers this managing database service from among the multiple database service instances. Subsequent requests by instances of the client application to access the relational data file are then handled by this managing database service.

[0009] In a further variation, the system discovers the managing database service by:

• • [0010] determining whether the computing device hosting the relational data file also hosts the managing database service;
  • [0011] determining whether the computing device hosting the client application also hosts the managing database service;
  • [0012] using a configuration file in proximity to the data file to assist in finding the managing database service; and/or
  • [0013] using a network query and/or broadcast request to discover the managing database service.

[0014] In a further variation, the managing database service changes based on the behavior and actions of the user, the client application, and the multiple instances of the database services.

[0015] In a further variation, the request specifies that a given instance of the database service always serves as the managing database service.

[0016] In a further variation, if no managing database service is found, the system configures a local instance of the database service associated with the client application to become the managing database service.

[0022] The following description is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present invention. Thus, the present invention is not limited to the embodiments shown, but is to be accorded the widest scope consistent with the claims.

[0023] The data structures and code described in this detailed description are typically stored on a computer-readable storage medium, which may be any device or medium that can store code and/or data for use by a computer system. This includes, but is not limited to, volatile memory, non-volatile memory, magnetic and optical storage devices such as disk drives, magnetic tape, CDs (compact discs), DVDs (digital versatile discs or digital video discs), or other media capable of storing computer readable media now known or later developed.

Performance and User Interface Trade-Offs

[0024] As mentioned previously, as applications become increasingly more sophisticated, significant advantages can be gained by moving from a simple company file to a more-sophisticated database system controlled by a database server. Using a more-sophisticated database system can provide improved performance and scalability, especially for larger company files and simultaneous users.

[0025] However, typical system users may not be familiar with installing, configuring, and maintaining a more-complex database system. Many applications that incorporate databases are either single-user applications that use a database embedded into an application, with little or none of the database complexity directly exposed to the end-user, or use a heavy-weight multi-user database with an involved set-up procedure typically managed by a system administrator. In the latter case, such heavy-weight databases typically involve multiple files, and are not mobile. The system in one embodiment of the present invention provides the performance and scalability of a client-server database system while maintaining a database-transparent user experience with minimal or non-existent administration needs.

[0026] In typical non-database systems, applications store user data in files, and the user can browse through a file structure to select a data file and/or to invoke a client application related to the data file. This data file may be located on a local computing device, or may be present on a remote computing device but transparently displayed using a file browser run on the local computing device.

[0027] One embodiment of the present invention maintains this experience of “opening an ordinary file” on a local or remote file system using a standard file open user interface, but changes the data file to be a relational data file, and enhances the client applications to interact with a database management system (DBMS) that manages and operates upon the data in the relational data file. Multiple users in this system can continue to think of the relational data file as a “normal” file, as in previous systems, and can perform actions such as individually accessing and copying the file, while the system transparently invokes, maintains, and connects the client applications to a DBMS service that manages the relational data file. Hence, the system hides from the end-user the presence of the client-server database, thereby presenting unchanged system usability and maintaining a user experience of a single-file data management system yet also providing enhanced database functionality.

[0028] FIG. 1 illustrates a client application 104 and DBMS service 106 executing on a computer A 102. The client application 104 interacts with the DBMS service 106, which provides access to a relational data file 108.

[0029] FIG. 2 is a flow chart illustrating the process of opening a relational data file by connecting to a DBMS service. First, the system receives a request to open a relational data file (step 202). This request can, for instance, be generated when a user selects a data file from a file browser, thereby triggering a client application associated with the file type of the data file by the operating system (e.g. Microsoft™ Windows™). Alternatively, the request may also be generated by the user selecting the file from within a client application. Upon determining that the data file is a relational data file, the system then determines a set of parameters for the relational data file and a DBMS service, if present (step 204). For instance, the client application can use an operating system application programmer interface (API) to ascertain whether the relational data file is local to the computer or on a remote server.

[0030] In one embodiment of the present invention, the system uses the location of the relational data file to determine whether an active DBMS service managing the file is already available on the computer hosting the relational data file. Alternatively, the system can also determine whether such a service is already active elsewhere by checking on the machine hosting the client application, using a network query or broadcast, and/or checking a configuration file in proximity to the relational data file.

[0031] If the system finds an active DBMS service for the relational data file (step 206), the client application proceeds to communicate with the DBMS service and attempt to access the relational data file through the DBMS using an appropriate database API (step 210). Note that connecting to the DBMS via the database API may involve additional steps such as the exchange of user credentials and/or other information. In one embodiment of the present invention, if the system does not discover an active DBMS service, the system launches an instance of the DBMS service on the computer hosting the client application (step 208), and then proceeds to access the relational data file by communicating with the newly-launched DBMS service (step 210). Note that some of these steps may vary in complexity depending on usage scenarios.

Single-User Scenarios

[0032] In the simplest usage scenario (shown in FIG. 1), the client application 104, the DBMS service 106, and the relational data file 108 are installed on a single system and accessed by a single user. In this scenario, the system may only search for the DBMS on the local machine (computer A 102), and only launch the DBMS service 106 when the client application 104 actually accesses the relational data file. Note that the system may balance the resource usage of the client application 104 and the DBMS 106 to optimize overall application performance on computer A 102.

[0033] FIG. 3 illustrates a more complex single-user usage scenario in which the relational data file 108 is no longer co-located with the client application 104, but is instead stored on a remote computer B 302. This scenario might occur, for instance, if the relational data file is located on a separate file server with regular backups. In this scenario, the system may again proceed to use or launch a local instance of the DBMS service 106 on the same computer as the client application 106. While remote access to the relational data file may cause degraded performance due to network communication, other benefits from such a system organization may make this a desirable arrangement.

Multiple-User Scenarios

[0034] The system can also transparently manage multiple-user scenarios. FIG. 4 illustrates a system configuration in which multiple instances of client application 104 communicate with one computer A 102 that hosts the relational data file 108 locally.

[0035] In one embodiment of the present invention, an instance of the DBMS service 106 can be installed in combination with each installed instance of the client application 104. Such a configuration allows different instances of the DBMS service 106 to manage access to the relational database file depending on access patterns, system operations and failures, and other factors. Note that typically only one instance of the DBMS service can actively manage access to the relational data file at a time, leaving most of the DBMS service 106 instances in FIG. 4 inactive or un-launched during operation.

[0036] In one embodiment of the present invention (shown in FIG. 4), a user or system administrator can decide to select one computer (such as computer A 102) to permanently host the relational data file 108 and the managing DBMS service 404 for this file, for instance by selecting an option of “host my company files for multiple-user access” in the instance of the client application 104 local to computer A 102. Other instances of the client applications 104 attempting to access the relational data file 108, such as those on computer B 302 and computer C 402, then follow the process shown in FIG. 2. When these client applications attempt to open the relational data file, they check whether the computer hosting the relational data file (computer A 102) also hosts a managing DBMS service 404 for the file, and proceed to find and communicate with computer A's 102 DBMS service 106. Note that the system can bias the resources or system parameters of computer A 102 to improve the performance of the DBMS service 106 if computer A 102 is expected to primarily provide data services, and not actively run an instance of the client application 104.

[0037] In a further embodiment, the first client application 104 to open the relational data file 108 and thereby activate a managing DBMS service 404 on the computer (hosting the prompting client application) takes charge exclusively of managing the relational data file 108, until such time that the managing client application 104 is terminated, the corresponding computer (hosting either the relational data file or the managing DBMS service) fails, and/or some other prompt for release occurs.

[0038] FIG. 5 illustrates a system configuration in which multiple users access a remote relational data file 108 through a DBMS service 106 on a separate computer A 102. If the client application 104 on computer A 102 attempts to access the relational data file 108 on computer B 302 first, the DBMS service instance 106 on computer A 102 activates to provide access to the relational data file 108. A subsequent access attempt by the client application 104 on computer C 402 finds that the file is already managed by the managing DBMS service 404 on computer A 102, and results in a connection from the client application 104 on computer C 402 to the managing DBMS service instance 404 on computer A 102. If at some later point computer A 102 fails, the client application 104 on computer C 402 might proceed to launch or activate the DBMS instance 106 on computer C 402 and take over the management of the relational data file 108 on computer B 302.

[0039] Note that preserving a transparent non-database user experience in the previous configuration may involve a performance penalty. For instance, the configuration in FIG. 5 may involve substantial time delay and network traffic, because data accesses by the client application 104 on computer C 402 need to travel first through the DBMS service 106 on computer A 102, then to the actual file on computer B 302, and back. Note also that while no assumptions can be made about where an active DBMS service may be running, users do need to know the location of the data file to properly access their data and thereby invoke the DBMS system. However, since knowing the location of the file follows with the existing single-data-file-based user experience, this presents no additional overhead.

[0040] Note that the technique in the present invention differs from an approach in which the data file is replaced by a stub file that contains information for locating a DBMS server. The relational data file in the present invention still includes the actual data used by the DBMS service, and thus can be copied and used transparently as a normal file, for instance when transported to a home computer using a portable storage medium. In the case of the stub file, if only the location information data is copied, the data may not be accessible without a network path to the DBMS server, thereby violating the abstraction of a normal file experience.

[0041] In summary, the present invention provides the performance and scalability of a client-server database system while maintaining a database-transparent user experience with minimal or non-existent administration needs. The system allows a user to invoke a file that triggers transparent access to the improved functionality and efficiency of the hidden client-server system. Note that the approach described in the present invention is not limited to data files mapped to relational data files, but can also be used generally to transparently map between other types of data files as well.

[0042] The foregoing descriptions of embodiments of the present invention have been presented only for purposes of illustration and description. They are not intended to be exhaustive or to limit the present invention to the forms disclosed. Accordingly, many modifications and variations will be apparent to practitioners skilled in the art. Additionally, the above disclosure is not intended to limit the present invention. The scope of the present invention is defined by the appended claims.