Central database routing for distributed applications

A datum is requested and a location table is searched for an identifier associated with the datum, wherein the location table comprises a location for the datum; further wherein the location is associated with the identifier. A location of a remote database that includes the datum is determined, and a request for the datum is sent to the remote database according to the location.

BACKGROUND INFORMATION

Distributed applications generally use a plurality of databases to supply requisite application data. Under one common data distribution model, a central data repository, generally a database that is physically remote from the computers by which users access the distributed application, contains a complete set of application data. However, in order to provide users with more efficient access to application data, a database local to a user contains a duplicate set of some or all of the requisite application data. Accordingly, this approach requires synchronizing the remote central database with a plurality of local databases on a regular basis. For example, many applications require a periodic, e.g., nightly or daily, download, or replication, of data from a central data repository to local databases. This data replication consumes processing and network overhead and, if interrupted or corrupted, introduces possible errors into the distributed application. In addition, more complex data distribution models are often used, in which the central data repository is itself spread across two or more physical databases, meaning that the central data repository must itself be synchronized or updated before the central data repository can be synchronized with the local databases.

Thus, as is apparent, present data distribution models suffer from significant shortcomings. Particularly in cases where local users accessing data in a distributed application most often require a particular subset of application data, replication of all data from a central data repository results in populating and updating the local database with more data than is necessary and therefore is inefficient for at least two reasons. First, replication of extra data consumes overhead, as noted above. Second, storing extra data in the local database causes the local database to consume more resources, such as storage space and processing resources, than is necessary. On the other hand, if a complete data set is not stored in the local database, then distributed users must seek some application data from a remote data repository, which may not be available or, at a minimum, can likely be accessed only inefficiently and by consuming extra processing and network resources. Particularly where data is distributed in more than one remote database, it can be difficult and inefficient to locate desired data.

Certain distributed applications have addressed the foregoing problems in application-specific ways. For example, it may be known that a certain subset of application data is accessed by local users of the application approximately ninety (90) percent of the times when the local user accesses data. Therefore, only this subset of the application data may be maintained in a local database without undue sacrifices of efficiency and overhead. Alternatively or in addition, it may be known that a certain subset of application data is stored in a particular remote database and may be accessed in a particular manner. Accordingly, the distributed application may employ a specific routine known to efficiently access such data in a remote database. However, these approaches require particular knowledge of a distributed application as well as the data it uses and often also require knowledge of a specific computing environment.

To overcome the foregoing shortcomings in retrieving data in distributed applications, it would be desirable to have a generic solution that provides retrieval of data from a plurality of separately maintained databases. It would further be desirable to avoid regular database synchronizations, and the vast overhead and inefficiencies that result therefrom. Further, it would be desirable to reduce the overall data storage capacity required for a distributed application, and to thereby reduce the costs associated with storing application data.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1is a block diagram showing an exemplary distributed system100, according to an embodiment. Distributed system100uses a network110to link one or more distributed applications115a,115b,115c, etc., included respectively on local computing devices120a,120b,120c, etc., that in turn include or are connected to local databases125a,125b,125c, etc. Remote databases130a,130b,130c, etc. are accessible to the devices120via the network110, as is location database135. Location table140may be included in location database135, although in some embodiments a specialized location database135is not present, and location table140is included in a remote database130, some other database, or a specialized application. Location table140is generally accessed by local computing devices120via the network110.

Network110may any one of, or a combination of a variety of, networks known to those skilled art, and preferably operates according to the well known Transfer Control Protocol/Internet Protocol (TCP/IP). Network110may include, without limitation, a Wide Area Network (WAN), Local Area Network (LAN), an intranet, the Internet, etc.

Distributed application115may be any kind of application capable of running on a computing device120that accesses distributed data. Examples of distributed applications115include, without limitation, document management systems, reporting applications, and the like.

Local computing devices120may be any one of a number of computing devices known to those skilled in the art, including, without limitation, a computer workstation, a desktop, notebook, laptop, or handheld computer, or some other computing device known to those skilled in the art, such as a Java-enabled cellular telephone or similar device. Computing devices120may employ any of a number of computer operating systems known to those skilled in the art, including, but by no means limited to, known versions and/or varieties of the Microsoft Windows® operating system, the Unix operating system (e.g., the Solaris® operating system distributed by Sun Microsystems of Menlo Park, Calif.), the AIX UNIX operating system distributed by International Business Machines of Armonk, N.Y., and the Linux operating system.

Local databases125and remote databases130each generally comprise a relational database management system (RDBMS) as known to those skilled in the art. However, it is to be understood that databases125and130, in particular local databases125, may be some other kind of database such as an application database in a proprietary format. Each local database125is generally, although not necessarily, included within the respective local computing device120to which the database125is local, or are otherwise locally connected to local computing devices120, e.g., via a local network connection. It should be understood that local databases125may, but are not necessarily, included within distributed applications115. Remote databases130, on the other hand, are generally accessed by applications115running on computing devices120via network110. Remote databases130generally include a computing device employing a computer operating system such as one of those mentioned above, and are accessed via network110in any one or more of a variety of manners known to those skilled in the art.

Further, embodiments are possible in which a local database125also serves as a remote database130; for example, a local computing device120amay be associated with a local database125a, which also serves as a remote database130for local computing devices120b,120c, etc. In such a case, the local database125acould be accessed by local computing devices120b,120c, etc. via network110.

In general, those skilled in the art will recognize that the various systems and methods described herein, including without limitation distributed applications115, may be implemented as instructions executable by one or more computing devices. Such instructions may be compiled or interpreted from computer programs created using a variety of programming languages and/or technologies known to those skilled in the art, including, without limitation, and either alone or in combination, Java™, C, C++, Visual Basic, Java Script, Perl, etc. In general, a processor (e.g., a microprocessor) receives instructions, e.g., from a memory, a computer-readable medium, etc., and executes these instructions, thereby performing one or more processes, including one or more of the processes described herein. Such instructions and other data may be stored and transmitted using a variety of known computer-readable media.

In preferred embodiments, location table140is a conventional table in a relational database, and contains data that may be accessed in a conventional manner. However, location table140is accessed by distributed applications115not to obtain actual application data but rather to obtain the location(s) for requested application data.FIG. 2illustrates the contents of a location table140, according to an embodiment. As can be seen inFIG. 2, location table140contains location information, e.g., addresses, associated with identifiers, e.g., data keys210, used by distributed application100.

A data key210is generally a primary key such as is known for use in a relational database. Accordingly, it is to be understood that, althoughFIG. 2shows key210as a simple key, i.e., key210occupies a single column of table140, embodiments are also possible, even likely, in which key210is a compound key occupying two or more columns of location table140. Embodiments are also possible in which key210comprises a range of keys all associated with the same addresses220and230.

Primary addresses220and secondary address230are addresses for accessing data associated with a key210. The purpose of specifying both a primary address220and a secondary address230associated with each data key210is to account for redundant network connections, as will be understood by those skilled in the art. However, it is to be understood that embodiments are possible in which location table140includes a column for primary addresses220, but not secondary addresses230, and also that embodiments are possible in which location table140includes more than two columns for specifying addresses associated with each data key210. In one embodiment, addresses220and230are Internet Protocol addresses such as TCP/IP addresses for locating the remote database130that contains data associated with a key210. However, addresses220and230could also comprise a data source name (DSN), a computer name, a database name, a network path, or any other way of identifying a database known to those skilled in the art.

Because the actual data for distributed application115is maintained in databases125and/or130, location table140requires little updating and is therefore easy to maintain. Generally, table140is updated only when a key210is added to or deleted from a local database125.

FIG. 3depicts a process300for retrieving data in a distributed application115, according to an embodiment.

In step305, a request for data is received in a local computing device120. It should be understood that this request is received as part of the processing of a distributed application115, and may or may not be the result of input from a user. The requested data is associated with an identifier, generally a key210.

Next, in step310, distributed application115determines whether the key210can be found in the local database125associated with the local computing device120. If yes, control proceeds to step315. Otherwise, control proceeds to step320.

In step315, the requested data is retrieved from the local database125, and returned to the distributed application115. Following step315, the process300terminates.

Steps310and315are optional, but preferred in embodiments in which it is likely that a requested key210will be present in the local database125. However, in embodiments where local database125is not present, or in which the requested key210is unlikely to be found in local database125, these steps may be omitted.

In step320, the distributed application115sends its query for the key210to location database135.

Next, in step325, location database135determines whether the data key210is in location table140. If not, control proceeds to step330. However, if the data key210is present in the location table140, control proceeds to step335.

In step330, location database135returns a message to application115indicating that the requested data key110was not found in location table140. Following step330, the process300terminates.

In step335, location database135sends a query to an address220associated with the requested key210in location table140. This query includes information concerning the location of the local computing device120and the instance of the application115that requested the key210so that a response to the query may be returned to the proper location in the network110. Alternatively, embodiments are possible in which location database135returns the address of the remote database130containing the requested key210to the local computing device120associated with the instance of the application115that requested the key210. The distributed application115may itself be programmed to request the desired data associated with the key210directly from the appropriate remote database130.

Next, in step340, the remote database130to which the query of step335was sent returns the requested data to the requesting application115.

Following step340, the process300terminates.

CONCLUSION