Browse Prior Art Database

System and method for managing external resources as relational database tables Disclosure Number: IPCOM000198658D
Publication Date: 2010-Aug-11
Document File: 4 page(s) / 29K

Publishing Venue

The Prior Art Database


Disclosed is an invention for representing various external resources and content stored in them as relational database tables within a program while allowing the external resources to be managed by their native resource managers. This allows systems to manage different incoming resources with varying access controls, languages, etc., without having to incorporate new resource managers and allows programmers to use a familiar technology to access and control various resources. Note: Here the term "resource" is used to represent the characteristics of the resource otherwise known as its meta-data and all content stored as part of that resource.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 34% of the total text.

Page 1 of 4

System and method for managing external resources as relational database tables

Modern software programs need to manage resources from various sources in order to perform their task. It is not uncommon for an application to open a network connection, spawn a process, access a database, and access a flat file, all to perform a single task. In each case, engineers need to code the application to switch the contexts to use the specific interfaces of these varying technologies. For instance, if a Java* language application wants to access a database it uses Java class from the JDBC packages; to access a file system file it uses a class from the I/O package, and for a network socket it uses a NET package. Each resource may have its own access control, nuances of create/read/update/delete operations, states of being, etc., that the application may need to configure. In some cases it might need to dynamically manage the various configurations to meet its need.

Also, current industry direction attempts to have a resource manager that is aware of each of the specific resources and other resource managers as the way to represent these resources. This requires the representation to be replicated in each new language when it is different from the previous.

To perform more efficiently, systems need the capability to represent and manage these widely different resources via a common interface, and do so without requiring new resource managers.

The disclosed invention proposes representing such external resources as relational database tables while keeping the external resources to be managed by their native resource managers.

Addressing the need for applications to access resources in both file system files and databases, current known solutions and their drawbacks include:

• Option 1: Use DB2**'s DATALINK option to store the location and meta-data about the file and have the working application use this meta-data to locate and access the file using the file system API. While this solves locating the file, it still requires the application to use resource-specific language.

• Option 2: Copy in the contents of the file into a database column as a binary large object (BLOB). This allows applications to use structured query language (SQL) to access data from the file by selecting the column that contains the entire file. However, this means any future updates to the table column or the file system file will not be dynamically reflected in the other. Also, it still requires the application reading the BLOB data to parse through the bytes with the knowledge of the format to interpret or modify the data.


Page 2 of 4

• Option 3: Let the DB resource manager collaborate with the file system resource manager. One solution allows applications to access resources in the database and file system as part of a single transaction. However, the application will not be resource agnostic. It still requires the execution of specific code for each type of r...