GB2347528A

GB2347528A - Object database with caching support

Info

Publication number: GB2347528A
Application number: GB9904831A
Authority: GB
Inventors: David Hostettler Wain
Original assignee: NAXT Ltd
Current assignee: NAXT Ltd
Priority date: 1999-03-04
Filing date: 1999-03-04
Publication date: 2000-09-06
Also published as: GB9904831D0

Abstract

An object database with caching support that provides a framework that can be used to improve access speeds to data objects over low bandwidth, insecure connections. The interface is consistent with a recursive or layered design, allowing functionality to be delegated to a suitable layer. Normal database operations are provided, together with operations for retrieving ObjectSets or VersionSets, and local caching is supported. Classes can receive asynchronous updates to objects, ensuring the cache can be updated in the background. Security of objects can be ensured, and the enforcement implementations can be separated from the bulk of the code.

Description

Object Database with Caching Support Technical Field This invention relates to an object database with caching support.

Background Databases are well known systems that allow the storage and retrieval of data. There are several databases currently that support the versioning of files. There are also several databases that support the storage and retrieval of objects. Most of the details of these databases are too lengthy to be described here.

The usuai arrangement in a cilvent Zerver computer system is to have the database (s) residing on the server. One of more clients can then connect to the server in order to update or read the information within the database. Unfortunately, this means that in a traditional system, when reading data, the information is resent from the server to the client every time it is requested. This is acceptable with high bandwidth, low response time communications lines, but is too inefficient for low bandwidth ones.

The response in the field of Web browsers has been to cache the data whenever read from the server. That is, files (data) are retrieved only once, the first time they are requested. Subsequent requests for the same file will usually be served from the local cache, not from the server.

Other, more advanced caching systems exist for Web pages. These programs download all of the Web pages in a Web site, or those referred to in the current document. The first case is so that a user may download a site completely and may then browse offline. The second case is to attempt to predict the next page requested by the user.

Of course, the above cases refer to Web pages. Most of the innovations in caching over low bandwidth lines have centred on Web access. But Web pages are just one kind of object.

The object database described herein solves the problem of accessing databases over low bandwidth communications lines by caching local data locally, such that the amount of data transmitted may be minimised.

Essential Technical Features According to the present invention there is provided a versioning object database with local caching support comprising the following: 1) A session access interface defining functions or methods to access one or more databases, consistent with the efficient layering of database access functionality.

2) A cached session access interface with support for object caching and asynchronous object refresh.

3) An untrusted session access implementation introducing an abstracted security enforcer interface.

4) A security enforcement interface consistent with the layering of functionality.

5) A remote session access implementation introducing an open connection class for the actual transmission and reception of database requests and results 6) An open connection class for connecting two processes running on different machines, capable of supporting sub-connections recursively.

7) Supporting classes and interfaces.

All of the above are illustrated in Appendix A, with code listings in the Java language, although the underlying principles apply to Object Oriented techniques generally.

The database is designed primarily for the publishing of data objects. Most publishing systems require an approval mechanism to control the process of publishing. The database supports this process by allowing more than one version of each object to be stored at a given time. Also, each version has an associated visibility, which determines to which users it is readable. Thus it is envisaged that although some users will be able to update an object (by creating a new version), that new version will not be globally visible until a suitably privileged user approves it. This is done merely by creating a new version with the object's maximum visibility. This is possible as a privileged user is allowed to control the visibility of a version.

Each Object is uniquely defined by its ObjectReference. Also, each Object has its own permissions, defined by the ObjectPermissions class. It is envisaged that these permissions will define the users that can update or read the object.

Each Version is uniquely defined by its VersionReference. Also, each Version shall have its own permissions, defined by the VersionPermissions class. It is envisaged that these permissions will define the users that can read the version.

VersionPermissions may be integrated with respect to time. The maximum visibility of a version is defined by the visibility of the object. If the visibility of a version is masked by later versions, then it is known as a defunct version, and may be deleted permanently during garbage collection. A generic VisibilityMask is defined for the purpose of integration.

The database query mechanism provides interfaces for the generation of ObjectSets and VersionSets. These sets are collections of ObjectReferences or VersionReferences that reference each other. That is they are self-referential subsets of data. Filters such as a TimeFilter may be applied to the set generated in support of local object caching.

These sets are designed to be used by a client that wishes to construct a"to-do"list of objects or versions that need to be downloaded in order to update a local cache.

The database supports the layering of functionality. This means that the enforcement of security may be performed at any layer, allowing critical security enforcement to be performed on the servers. Hence users on client machines do not have access to security upholding code and are therefore not able to subvert the security model. Hence, it allows only machines with the correct level of trust to uphold security.

The layering of functionality also means that any implementation can be designed to minimise bandwidth requirements, consistent with the aim of reducing database access times.

The connection mechanism introduced by the remote sesson access class is designed to support security integrity. It allows the connections to create sub-connections in either direction, allowing any design to be firewall friendly. This means that firewalls may be configured in simple and secure fashion, reducing the potential for illegal access to secure machines.

The caching mechanism is asynchronous. ObjectObservers register their interest in various objects using the interfaces presented in the CachedSessionAccess interface.

Whenever new versions become available, or existing information is confirmed as out-ofdate or up-to-date, the observer is informed or the value or state change via the interfaces defined in ObjectObserver. Objects thus can have three states, namely, potentially-out-of-date (before the to-do"information has been received), definitely-outof-date (when there are new, visible versions on the server) and definitely-up-to-date (when all visible versions have been cached).

Client-Server Example A specific embodiment of the invention will now be described by way of example with reference to the accompanying code listings in which : Appendix C, class CacheTestClient shows an implementation of a caching client.

Appendix C, class UpdateTestClient shows an implementation of an updating client.

AppendixC, class ClientSessionAccess shows an implementation of a client's CacheSessionAccess.

Appendix C, class ClientSessionAccessProvider shows an implemtation of a client's SessionAccessProvider.

Appendix C, class ClientSecurityEnforcer shows an implementation of a client's SecurityEnforcer.

Appendix C, class CacheDefinition shows an implementation of a cache definition Appendix C, class CacheState shows an implementation of a cache state.

Appendix D, class CatalogServer shows an implementation of a server.

Appendix D, class CatalogServerRequestListener shows an implementation of a server's RequestListener supporting reversed sub-connection support for networks containing firewalls.

Appendix D, class CatalogServerSessionAccessProvider shows an implementation of a server's SessionAccessProvider giving access to the local database through a UntrustedSessionAccess object.

Appendix D, class CatalogServerSecurityEnforcer shows an implementation of a server's SecurityEnforcer.

Appendix D, class CatalogServerSessionRequestListener shows an implementation of a server sub-connection (or session) RequestListener.

Referring to the listings the two client examples comprise a main method which acts as a test script for the checking of the ClientSessionAccess class.

The CacheTestClient is designed to test the ability of a client object cache to correctly identify the minimum amount of downloading required to bring it up to date and to inform object observers of those changes asynchronously. The key functionality takes place in the ClientSessionAccess class.

The ClientSessionAccess class is designed to be able to access a CD-ROM cache, a Hard Drive cache and the remote server when required.

If there is a hard disk cache, the ClientSessionAccess runs a thread in background which, on connection to the server, requests a"to-do"list of versions in the form of a VersionSet. This VersionSet is filtered using a TimeFilter based on the time recorded within the CacheDefinition object reTating to the cache of the hard disk (or permanent mass storage device). This means that only those versions that have been created after the last time the"to-do"list wa updated are to be returned, even though the entire selfreferential set of versions is to be traversed. The VersionSet returned therefore contains those versions"under"the top objects that were created after the"to-do"list was updated.

Once the new"to-do"list has been obtained, it is merged with the existing"to-do"list, as the existing list may not have been completed. The combined list is then saved as the existing"to-do"list to ensure that if the client closes or exits unexpectedly, the information is retained on the hard drive. All of the object observers are then informed as to whether the objects in which they have registered an interest are up-to-date or out-ofdate.

The background thread then sequentially goes through the"to-do"list, getting the new versions specified. As each version is downloaded, the"to-do"list is"checked off'and resaved in case of a crash. Thus the versions are gradually downloaded into the local cache. Of course, as later visible versions of observed objects are downloaded, their observers are duely informed of the change.

When an ObjectObserver registers an interest in a database object, both the hard disk cache and the CD-ROM cache are first checked to see whether a version of an object is present. If there is a local copy present, the ObjectObserver is informed of the latest visible version and, if the object is not covered by the background cache thread, a background ReadObjectRequest is sent to the server requesting the object. When the ReadObjectResult returns, the observers are informed if the version retrieved from the cache has been superceded by one from the server.

The UpdateTestClient is designed to test the update functions of the database. It creates and updates several objects by logging on to the server with system privileges so that updates are allowed. The detail of the updates are not important except that they generate new versions on the database within the self-referential sets that are cached, and hence this client is used to change the database as a prelude to the cache test.

Referring to the listings the CatalogServer comprises a main method or entry point which creates a CatalogServerRequestListener which listeners for ConnectionRequests. It then logs into the RouterServer, and spawns sub-connections in response the user sessions being requested. Those sessions contain session data that changes in response to the session protocol between the RouterServer and the CatalogServer. The session state reflects the user's information required to enforce security. The session state is used by the CatalogServerSecurityEnforcer to determine the ability of users to change or create objects. The CatalogServerSessionRequestListener listens for session database requests applying the security rules using the security enforcer.

The example contains two clients and one server. They do not constitute a complete working system. At least one other server is required, referred to above as the RouterServer. The inclusion of this server in this example is not required for the illustration of the Invention.

Claims

Claims 1. A session access interface comprising methods or interfaces for database session access.
2. A session access interface as claimed in Claim 1, wherein interfaces are provided that allow for a recursive or layered design allowing efficient and secure delegation of functionality in low bandwidtfi ana insecure environments.
3. A session access interface as claimed in Claim 1, wherein interfaces are provided for the control of user sessions within a generic security framework.
4. A session access interface as claimed in Claim 1, wherein interfaces are provided for the update of database objects.
5. A session access interface as claimed in Claim 1, wherein interfaces are provided for the reading of objects and their versions.
6. A session access interface as claimed in Claim 1, wherein interfaces are provided for the querying of the database in support of caching operations.
7. A session access interface substantially as described herein with reference to the source code listing of interface SessionAccess in the accompanying Appendix A.
8. A cache session access interface comprising methods in addition to those methods inherited from the session access interface.
9. A cache session access interface as claimed in Claim 8, wherein object observers are permitted to register their interest in objects and can receive updates to them asynchronously.
10. A cached session access interface substantially as described herein with reference to the source code listing of interface CachedSessionAccess in the accompanying Appendix A.
11. An untrusted session access class comprising an implementation of a session access interface as claimed in Claim 1.
12. An untrusted session access class as claimed in Claim 11, wherein the security enforcement portion of functionality is abstracted into a security enforcer interface.
13. An untrusted session access class as claimed in Claim 11, wherein the functionality is consistent with the layering of functionality as suggested by the session access interface as claimed in Claim 1.
14. An untrusted session access class substantially as described herein with reference to the source code listing of class UntrustedSessionAccess in the accompanying Appendix A.
15. A security enforcement interface comprising methods or interfaces for security enforcement.
16. A security enforcement interface as claimed in Claim 15, wherein interfaces are provided for the enforcement of security consistent with the layering of functionality as suggested by the session access interface as claimed in Claim 1.
17. A security enforcement interface substantially as described herein with reference to the source code listing of interface SecurityEnforcer in the accompanying Appendix A.
18. A session access provider interface comprising methods or interfaces for the request of session access objects that are instances of implementations of the session access interface as claimed in Claim 1 consistent with the layering of functionality.
19. A session access provider interface substantially as described herein with reference to the source code listing of interface SessionAccessProvider in the accompanying Appendix A.
20. A remote session access class comprising an implementation of a session access interface as claimed in Claim 1.
21. A remote session access class as claimed in Claim 20, wherein methods calls are converted into request objects suitable for remote transfer.
22. A remote session access class interface substantially as described herein with reference to the source code listing of class RemoteSessionAccess in the accompanying Appendix A.