US 5,809,506 AGrant
Method for Creating an Object Base of Persisent Application Objects in an Object Oriented Programming Environment and Apparatus Related Thereto
Issue Date:1998-09-15
•19 Claims
•3 Drawing Sheets
Abstract
A method for building an objectbase of persistent objects, includes naming an objectbase collection of objects, naming each object relative to a first collection of objects using a first key, assigning, to each new object to be added to the objectbase collection, a second key, generating a third key from the first and second keys, storing each object with the associated keys generating a reference to each object in the objectbase collection from the third key and one or more system identifiers, creating an instance of an object collection in a database client, identifying a class of each object in the object collection to the instance collection, generating a stream class for persistence of element objects, identifying to the instance collection a mapping between its attributes that are persistent and the corresponding database fields, identifying to the instance collection access control information in the form of one or more predicates, and activating the element objects using the stream.
Metadata
Assignee
- International Business Machines Corporation
Inventor
- George Prentice Copeland
Application Information
Application Number:US 5892309
Filing Date:1996-01-22
Priority Date:1996-01-22
Art Unit:276
Classifications
IPC:
G06F 1730
Field of Search:
395707614;705;702;500103
Patent Drawings (3 sheets)
Description
Background of the Invention
1. Technical Field of the Invention
The present invention relates to information handling systems, methods and articles of manufacture, and more particularly to information handling systems, methods and articles of manufacture including an objectbase of persistent application objects.
2. Background of the Invention
Although object modeling has many customer advantages over data modeling, the objects world has much to learn from the data world with respect to how large numbers of entities are managed.
Objects allow the following significant improvements for end users:
Objects allow applications to be built from off-the-shelf binary objects (for example OpenDoc parts) which can significantly reduce development cost (by a factor of 10 or more) and time to market.
Objects allow a much more direct model of an enterprise's entities and policy constraints.
Objects allow skinny client machines that only support a distributed Object Request Broker (ORB) for all client-server activity.
Databases are the only kind of computer system that has successfully dealt with managing very large (e.g., 10**9) numbers of things (collections of records).
3. Prior Art
In the prior art there are many techniques for improving object oriented programming systems (OOPS).
The following are examples of the prior art.
U.S. Pat. No. 5,093,914 generally teaches a method used by a digital computer in controlling execution of an object oriented program to effect a defined action, for example, stopping the program when a specified virtual function is invoked on a specified object during execution of the program.
Although the patent generally deals with methods for controlling execution of object oriented programs, the patent does not teach nor suggest construction of an objectbase of persistent application objects as is taught and claimed herein with reference with the present invention.
U.S. Pat. No. 5,343,554 teaches a computing system in which problems are solved by a process which includes creating objects of first and second classes wherein the second class objects are externally invocable and where the externally invocable sub-class objects include an indication of an internally invocable sub-class object and executing the class of objects wherein one externally invocable sub-object invokes the internally invocable sub-object and a new object of the first class is generated in response to the results.
Although the patent deals generally with the use of object oriented systems including classes and sub-classes for solving problems, the patent does not teach nor suggest construction of an objectbase of persistent application objects as is taught and claimed herein with reference with the present invention.
The best of both worlds can be achieved if the objects world learns several crucial lessons from the experiences found in the data world.
Summary of the Invention
Therefore, it is an object of the present invention to construct and use an objectbase of persistent application objects in an object oriented information handling system.
Accordingly, a system, method and article of manufacture include one or more processors, a storage system, a system bus, a display sub-system, for displaying information, a cursor control device, an I/O subsystem, an operating system program, and an object base containing one or more persistent application objects.
Brief Description of the Drawings
FIG. 1 is a block diagram of a system for executing the method according to the present invention.
FIG. 2 is a block diagram showing the operating system platform and system object model program supporting the present invention.
FIG. 3 illustrates an objectbase environment according to the present invention.
FIG. 4 is a flow chart of a naming process for objects in an object base in accordance with the present invention.
Detailed Description of a Preferred Embodiment of the Invention
In the prior art data world, a database record collection (e.g., an SQL table) serves as a home for the computer model of the enterprise entities. That is, presence of the entity's record in the home table implies its existence in the enterprise. For example, if the employee record is in the EMPLOYEE table, then the employee works for the enterprise, and if the employee record is not in the EMPLOYEE table, then the employee does not work for the enterprise.
These record collections are named (e.g., the EMPLOYEE table), and the records are named relative to their home collection via a primary key (e.g., a social security number). This compound name serves as both a user name and as the identity of the record. This mechanism is much more practical than having a flat name or identity space for all records.
These record collections are instance managers (IM) or ORBs for the records. That is, a user asks the record collection to:
Create a new record to add to its collection.
Either find or bring into memory an existing record in its collection given its primary key.
Destroy an existing record from its collection.
For a particular application, a query language can be used to define a subset collection of a home record collection:
A subset of one of these home record collections via a predicate.
A subset of the fields of these home records via an enumerated list.
Such a subset record collection is defined via the home collection plus a predicate and a list of the fields. To get at this subset of records one at a time, an iterator is associated with the query. For example, the subset collection of all employee records whose office is on the second floor can be defined as an iterator which can be iterated through in an application. Using embedded SQL, a C program might be as follows:
Databases support concurrent access to records by different users. Their concurrency control offers some flexibility in locking. One dimension of flexibility is when locks are obtained:
On-demand locking: Locks are automatically obtained on behalf of the user's current transaction context on records as they are accessed. This is the typical default.
Early locking: A user can lock records earlier than the records are accessed.
Another dimension of flexibility is when locks are released, called the isolation level which can be chosen for each iterator (i.e., cursor):
Two-phase locking: This automatically gets locks on behalf of the user's current transaction context on records as they are accessed and holds these locks until the end of the transaction. This guarantees serializability of concurrent transactions regardless of the application semantics. This is the typical default.
Cursor stability: This automatically gets locks on behalf of the user's current transaction context on records as they are accessed and holds these locks while a cursor is currently on the record and, if the record is updated, until the end of the transaction. This can greatly reduce lock contention. It is up to the application to determine whether this weaker isolation level is acceptable.
Dirty read: This is only used by read-only applications. Locks are not held on records. While data is being read, access to the physical page is serialized.
For security, a subset collection can be associated with a user or user group. The subset predicate is ANDed with the application-specific predicate to restrict which records are accessed. To further restrict the user to a subset of the record fields, the list of field names are also included. This list is also checked during an application-specific query. This predicate-based approach to access control is much more reasonable than either enumerating the element record keys for each user or user group, or attaching an ACL to each record. It typically increases query performance because:
When an index exists on part the access control predicate, performance is improved by orders of magnitude.
Even when an index does not exist on part the access control predicate, checking the predicate against each record is much faster than checking record membership in a record access control group.
These home record collections (the database) are kept in a reliable and physically secure server. The applications can either run in the server machine or in a separate client machine. In either case, the address space accessing the data is separate from the address space running user-written application code. These applications process only cache records.
Referring now to FIGS. 1 and 2, on information handling system 10 and an operating system environment for the present invention will be described.
Information handling system 10 may be a graphics work station or the like with a powerful processor 12, a storage system 14, a system bus 16, display sub-system 18 controlling a display device 20, a cursor control device 22, and an I/O controller 24, all connected by system bus 16. The information handling system 10, shown in FIG. 1 may be operated by a commercially available well known multitasking operating system such as OS/2* (OS/2 is a registered trademark of International Business Machines Corporation). Among many tasks which the OS/2 operating system controls an operating information handling system 10, is execution of a program SOMObjects, which is a commercially available product of International Business Machines Corporation.
The method and article of manufacture of the present invention may be incorporated in the SOMObjects program.
Description of An Objectbase According to the Present Invention
In the object world, an objectbase collection serves as a home for the computer model of the enterprise entities. That is, presence of the entity's object in the objectbase collection implies its existence in the enterprise. For example, if the employee object is in the employee collection, then the employee works for the enterprise, and if the employee object is not in the employee collection, then the employee does not work for the enterprise.
These objectbase collections are named using the Name Service (see FIG. 4). For example, an Acme Corp. user might have a machine root NamingContext (an object directory) containing the name "employees" bound to the objectbase collection containing all employees. The records are named relative to their home collection via a primary key (e.g., a social security number), so a user can ask the collection to find an employee with a given key. This mechanism is much more practical than having a flat name space for all objects.
Each of these objectbase collections is either an object instance manager or an ORB for its element objects. As one of these, it is responsible for the following:
A user asks the objectbase collection to create a new element to include in the collection.
It provides an element object's component key that is unique within that instance manager. An objectbase collection instance manager would use the database record key for this. This component key is used in generating the full key that is unique within the server by adding the instance manager's key. This full key is used in generating the full stringified reference that is made globally unique by adding the server id and a tag. Exploiting the database record identity (i.e., the record's key) prevents the instance manager from having to persistently store something else for each object to support object identity.
Given the component key, it either finds (if cached in memory) or activates (if not cached in memory) the element object.
A user asks the objectbase collection to destroy an existing element in the collection.
For a particular application, a query language can be used to define a subset collection of an objectbase collection:
A subset of one of these home record collections via a predicate.
Such a subset object collection is defined via the home collection plus a predicate. To get at this subset of objects one at a time, an iterator is associated with the query. For example, the subset collection of all employee objects whose office is on the second floor can be defined as an iterator which can be iterated through in an application. Using SQL for the query predicate, a C++ program might be as follows:
An objectbase should support levels of isolation that correspond to the underlying database system. For each query, the isolation level is specified. The corresponding iterator behaves accordingly.
For security, a subset collection can be associated with a user or user group. The subset predicate is ANDed with the application-specific predicate to restrict which element objects are accessed. To further restrict the user to a subset of the methods, the list of method names are also included. This list is also checked during an application-specific query.
These objectbase collections (the objectbase) are kept in a reliable and physically secure server in a database client address space. An application includes both these objectbase collections and their clients, which may also be objects. The clients can either run in the server machine or in a separate client machine. Typically, the clients run in a separate address space from the objectbase, so security and integrity can be enforced. These application processes can either cache the objectbase objects or forward operations to the objectbase machine.
FIG. 3 illustrates an objectbase environment according to the present invention.
Collection Class Products
A collection class product should be supplied for each database system application program interface (API).
The customer of one of these objectbase collection classes does the following to make a new instance collection:
1) Makes an instance of this collection in a database client.
2) Tells the instance collection what class its elements objects have.
3) Tells the instance collection what Stream class to use for persistence of its element objects. This Stream class might be generated via the DAX GUI tools for schema mapping between the database schema and the element class's externalize schema.
4) Tells the instance collection the mapping between its attributes that are persistent and the corresponding database fields, so that queries can be efficiently supported via database indexes.
5) Tells the instance collection access control information in the form of predicates.
An implementation of a collection class that is the same for all database system APIs does the following:
It has a cache manager of a fixed small number of objects. This includes a fixed number of objects preallocated, a hash table to find objects in the cache based on the database key, and an least recently used (LRU) algorithm to find a cache victim.
It activates the objects using the provided Stream. This reuses already allocated memory found via the LRU algorithm. It initializes the object, sets the record key in its Stream object that includes the schema mapping, and tells the object to internalize itself from the Stream.
An implementation of the collection class that is unique for each database system API does the following:
It ensures that a connection exists with the database containing the correct record collection.
For a query on the collection to find the qualifying element objects, the collection translates any part of the predicate onto a database query that filters records. The remaining records are activated and the remainder of the predicate produces an iterator with the final results.
During activation, it ANDs the correct access control predicate with the query predicate.
Overhead is reduced, because the collection and its elements are in the database client, and the collection knows the correct database and does the database connect.
It will be appreciated that although a specific embodiment of the present invention has been described herein for the purposes of illustration, various modifications may be made without departing from the spirit or scope of the invention.
Accordingly, the scope of this invention is limited only by the following claims and their equivalents.
Claims
What is claimed is:
1. A method for building an objectbase of persistent objects, comprising the steps of: binding an objectbase name to a persistent collection of objects; associating a component key with each new object to be added to the persistent collection of objects, said component key being unique within said persistent collection; generating for each new object a full key unique within a server containing said persistent collection from the component key and said objectbase name; and storing said new object and component key.
2. A method according to claim 1, wherein said generating step further comprises the step of: generating a globally unique reference to an object in the persistent collection of objects from the full key and one or more server identifiers.
3. A method according to claim 2, wherein the server identifiers comprise a server ID and a tag.
4. A method according to claim 1, further comprising the steps of: storing said persistent collection of objects as an instance collection in a database having a plurality of database fields; identifying a class of the objects in the persistent collection of objects to the instance collection.
5. A method according to claim 4, further comprising the step of: assigning a stream class to said instance collection to use for persistence of element objects.
6. A method according to claim 5, further comprising the step of: activating the element objects using the stream class.
7. A method according to claim 6, wherein the step of activating further comprises the steps of: initializing the element objects; providing a component key for said object to said stream object; and instructing each element object to internalize itself from the stream.
8. A method according to claim 4, further comprising the step of: identifying to the instance collection a mapping between its attributes that are persistent and said plurality of database fields.
9. A method according to claim 4, further comprising the step of: identifying to the instance collection access control information in the form of one or more predicates.
10. A method according to claim 1, wherein the objectbase further comprises a home collection of previously added objects to which the new objects are added.
11. A computer readable medium, comprising: computer program product means for causing a computer system to bind an objectbase name to a persistent collection of objects; computer program product means for causing a computer system to associate a component key with each new object to be added to the persistent collection of objects, said component key being unique within said persistent collection; computer program product means for causing a computer system to generate for each new object a full key unique within a server from the component key and said objectbase name; and computer program product means for causing a computer system to store said new object and said component key.
12. A computer readable medium, according to claim 11, further comprising: computer program product means for causing a computer system to generate a globally unique reference to each new object in the persistent collection of objects from the full key and one or more server identifiers.
13. A computer readable medium, according to claim 12, wherein the server identifiers comprise a server ID and a tag.
14. A computer readable medium, according to claim 11, further comprising: computer program product means for causing a computer system to store said persistent collection of objects as an instance collection in a database having a plurality of database fields; computer program product means for causing a computer system to identify a class of object in the persistent collection of objects to the instance collection.
15. A computer readable medium, according to claim 14, further comprising: computer program product means for causing a computer system to assign a stream class to said instance collection to use for persistence of element objects.
16. A computer readable medium, according to claim 11, further comprising: computer program product means for causing a computer system to present a subset of said persistent collection in response to a predicate defining a property of said subset collection.
17. An information handling system, comprising: processor means for processing computer readable instructions; storage means for storing data and instructions; an operating system program; and an objectbase containing one or more persistent objects, the objectbase comprising: means for binding an objectbase name to said objectbase; means for associating a component key with each new object to be added to the persistent collection of objects, said component key being unique within said persistent collection; means for generating for each new object a full key unique within a server containing said persistent collection from the component key and said objectbase name; and means for storing said new object and component key.
18. An information handling system, according to claim 17, further comprising: a cache manager for controlling storing a fixed small number of objects in a cache.
19. An information handling system, according to claim 17, wherein said cache contains one or more preallocated objects, and said information handling system further comprises: a hash table to find objects in the cache based on a first key; and means for finding a cached object to be replaced by a next stored object when said cache is full.
Patent Citations (53)
| Patent | Date | Inventor | Cited By |
|---|---|---|---|
| US4525780 | 1985-06-01 | Bratt et al. | |
| US4566078 | 1986-01-01 | Crabtree | |
| US4814971 | 1989-03-01 | Thatte | |
| US4853842 | 1989-08-01 | Thatte et al. | |
| US4989132 | 1991-01-01 | Mellender et al. | |
| US5008786 | 1991-04-01 | Thatte | |
| US5016162 | 1991-05-01 | Epstein et al. | |
| US5043871 | 1991-08-01 | Nishigaki et al. | |
| US5047925 | 1991-09-01 | Kun et al. | |
| US5075845 | 1991-12-01 | Lai et al. | |
| US5093914 | 1992-03-01 | Coplien et al. | |
| US5095480 | 1992-03-01 | Fenner | |
| US5111413 | 1992-05-01 | Lazansky et al. | |
| US5136712 | 1992-08-01 | Perazzoli, Jr. et al. | |
| US5161225 | 1992-11-01 | Abraham et al. | |
| US5163148 | 1992-11-01 | Walls | |
| US5185885 | 1993-02-01 | Dysart et al. | |
| US5261052 | 1993-11-01 | Shimamoto et al. | |
| US5265221 | 1993-11-01 | Miller | |
| US5276872 | 1994-01-01 | Lomet et al. | |
| US5280610 | 1994-01-01 | Travis, Jr. et al. | |
| US5283830 | 1994-02-01 | Hinsley et al. | |
| US5287453 | 1994-02-01 | Roberts | |
| US5291283 | 1994-03-01 | Kondo et al. | |
| US5291583 | 1994-03-01 | Bapat | |
| US5295256 | 1994-03-01 | Bapat | |
| US5297279 | 1994-03-01 | Bannon et al. | |
| US5297283 | 1994-03-01 | Kelly, Jr. et al. | |
| US5301286 | 1994-04-01 | Rajani | |
| US5301316 | 1994-04-01 | Hamilton et al. | |
| US5303375 | 1994-04-01 | Collins et al. | |
| US5315709 | 1994-05-01 | Alston et al. | |
| US5321841 | 1994-06-01 | East et al. | |
| US5325524 | 1994-06-01 | Black et al. | |
| US5335323 | 1994-08-01 | Kolnick | |
| US5341478 | 1994-08-01 | Travis, Jr. et al. | |
| US5343554 | 1994-08-01 | Koza et al. | |
| US5363313 | 1994-11-01 | Lee | |
| US5369702 | 1994-11-01 | Shanton | |
| US5369778 | 1994-11-01 | San Soucie et al. | |
| US5379432 | 1995-01-01 | Orton et al. | |
| US5404506 | 1995-04-01 | Fujisawa et al. | |
| US5404508 | 1995-04-01 | Konrad et al. | |
| US5404529 | 1995-04-01 | Chernikoff et al. | |
| US5408649 | 1995-04-01 | Beshears et al. | |
| US5412774 | 1995-05-01 | Agrawal et al. | |
| US5414840 | 1995-05-01 | Rengarajan et al. | |
| US5421012 | 1995-05-01 | Khoyi et al. | |
| US5421015 | 1995-05-01 | Khoyi et al. | |
| US5437027 | 1995-07-01 | Bannon et al. | |
| US5499365 | 1996-03-01 | Anderson et al. | |
| US5499371 | 1996-03-01 | Henninger et al. | |
| US5615362 | 1997-03-01 | Jensen et al. |
Non-Patent Literature (1)
- Fishman, D. H., "An overview of the Iris Oject-Oreinted DBMS", COPCOM, Apr. 1988.