| Prev | Chapter�17.�Kernel Documentation | Next |
|---|
By Pete Su
+ +A major goal in OpenACS 4 is to unify and normalize many of the core services of the system into a coherent common data model and API. In the past, these services were provided to applications in an ad-hoc and irregular fashion. Examples of such services include:
General Comments
User/groups
Attribute storage in user/groups
General Permissions
Site wide search
General Auditing
All of these services involve relating extra information and services to application data objects, examples of which include:
Bboard messages
A user home page
A ticket in the Ticket Tracker
A photograph in the PhotoDB
In the past, developers had to use ad-hoc and inconsistent schemes to -interface to the various "general" services mentioned above. Since +interface to the various "general" services mentioned above. Since each service used its own scheme for storing its metadata and mapping this data to application objects, we could not implement any kind of centralized management system or consistent administrative pages for all the services. Consequently, a large amount of duplicate code appeared throughout the system -for dealing with these services.
Unifying and "normalizing" these interfaces, to minimize the +for dealing with these services.
Unifying and "normalizing" these interfaces, to minimize the amount of code repetition in applications, is a primary goal of OpenACS 4. Thus the Object Model (OM, also referred to later as the object system) is concerned primarily with the storage and management of metadata, on -any object within a given instance of OpenACS 4. The term "metadata" +any object within a given instance of OpenACS 4. The term "metadata" refers to any extra data the OM stores on behalf of the application - outside of the application's data model - in order to enable certain generic -services. The term "object" refers to any entity being represented +services. The term "object" refers to any entity being represented within the OpenACS, and typically corresponds to a single row within the relational database.
The OpenACS 4 Object Model must address five high-level requirements that repeatedly exhibit themselves in the context of existing services in OpenACS 3.x, @@ -32,13 +33,13 @@ single membership relation.
Also in OpenACS 3.x, many utility modules exist that do nothing more than attach some extra attributes to existing application data. For example, general comments maintains a mapping table that maps application -"page" data (static or dynamic) to one or more user comments on the +"page" data (static or dynamic) to one or more user comments on the page, by constructing a unique identifier for each page. This identifier is usually a combination of the table in which the data is stored, and the value of the primary key value for the particular page. This idiom is referred to -as the "(on_which_table + on_what_id)" method for identifying +as the "(on_which_table + on_what_id)" method for identifying application data. General comments stores its map from pages to comments -using a "(on_which_table + on_what_id)" key, plus the id of the +using a "(on_which_table + on_what_id)" key, plus the id of the comment itself.
All of these composite key constructions are implicit object identifiers: they build a unique ID out of other pieces of the data model. The problem is that their definition and use is ad-hoc and inconsistent. This makes the @@ -47,8 +48,8 @@ mechanism for tagging application objects with unique identifiers.
Support for Unified Access Control
Access control should be as transparent as possible to the application developer. Until the implementation of the general permissions system, every OpenACS application had to manage access control to its data separately. Later -on, a notion of "scoping" was introduced into the core data -model.
"Scope" is a term best explained by example. Consider some +on, a notion of "scoping" was introduced into the core data +model.
"Scope" is a term best explained by example. Consider some hypothetical rows in the address_book table:
| ... | scope | user_id | group_id | ... |
| ... | user | 123 | � | ... |
| ... | group | � | 456 | ... |
| ... | public | � | � | ... |
The first row represents an entry in User 123's personal address book, the second row represents an entry in User Group 456's shared address book, and the third row represents an entry in the site's public address @@ -97,7 +98,7 @@ attributes.
In the PhotoDB data model, the ph_custom_photo_fields table defines attributes for the photographs owned by a specific user, and tables named according to the convention -"ph_user_<user_id>_custom_info" are used to +"ph_user_<user_id>_custom_info" are used to store values for those attributes.
Thus the Object Model must provide a general mechanism for applications and developers to modify or extend data models, without requiring changes to the SQL schema of the system. This ensures that all applications use the same @@ -129,7 +130,7 @@ kinds of schema patterns that are used by many existing OpenACS modules:
Object identification is a central mechanism in the new metadata system. The fact that every object has a known unique identifier means that the core can deal with all objects in a generic way. Thus the only action required of -an application to obtain any general service is to "hook into" the +an application to obtain any general service is to "hook into" the object system.
In OpenACS 3.x, modules use ad-hoc means to construct unique identifiers for objects that they manage. Generally, these unique IDs are built from other IDs that happen to be in the data model. Because there is no consistency in @@ -194,7 +195,7 @@ object (see requirement 10.20 above) and the attribute name.
40.20 Inherited Attributes
The system should allow for the automatic retrieval of inherited attribute values, for an object belonging to a subtype.
40.30. Constraints on Attributes
The system should allow the developer to put down constraints on the values that an attribute may hold, for the purposes of maintaining -application specific integrity rules.
In OpenACS 3.x, there was a notion of "scope" for application +application specific integrity rules.
In OpenACS 3.x, there was a notion of "scope" for application objects. An object could be belong to one of three scopes: public, group or user. This provided a crude way to associate objects with particular scopes in the system, but it was awkward to use and limited in flexibility.
The OpenACS 4 Object Model provides a generalized notion of scope that allows @@ -204,21 +205,21 @@ permissions from its context.
The context data model also forms the basis of the subsites system, and is a basic part of the permissions system, described in separate documents.
The context data model should provide the following facilities:
50.10 Unique ID
Every context should have a unique ID in the system.
50.20 Tree Structure
The data model should support a tree structured organization of contexts. -That is, contexts can be logically "contained" within other +That is, contexts can be logically "contained" within other contexts (i.e. contexts have parents) and contexts can contain other contexts (i.e. contexts can have children).
50.30 Data Model Constraints
All objects must have a context ID. This ID must refer to an existing context or be NULL. The meaning of a NULL context is determined by the implementation.
Note:
The current system interprets the NULL context as meaning the default -"site-wide" context in some sense. I wanted to note this fact for +"site-wide" context in some sense. I wanted to note this fact for others, but there is no need to make this a requirement of the system. I think it would be reasonable to have a NULL context be an error (psu 8/24/2000).
The data model should include a notion of pair-wise relations between objects. Relations should be able to record simple facts of the form -"object X is related to object Y by relationship R," and also be +"object X is related to object Y by relationship R," and also be able to attach attributes to these facts.
The API should let programmers accomplish the following actions:
60.10 Create a New Object Type
The object system API should provide a procedure call that creates a new object type by running the appropriate transactions on the object system data model. This API call is subject to the constraints laid out in the data -model. We call this operation "instantiating" an object.
60.20 Create a New Object Subtype
The object system API should provide a procedure call for creating +model. We call this operation "instantiating" an object.
60.20 Create a New Object Subtype
The object system API should provide a procedure call for creating subtypes of a given type. Operationally, this API is the same as requirement 60.10. Instances of subtypes automatically contain all attributes of the parent type in addition to all attributes of the subtype. This API is subject @@ -231,15 +232,15 @@ an error to delete types that have dependent subtypes. This API is subject to the constraints laid out in the data model.
80.10.10
However, the programmer should also be able to specify that all the subtypes and instances of those subtypes be destroyed before destroying the -object type. This is similar to a "delete cascade" constraint in +object type. This is similar to a "delete cascade" constraint in SQL.
The system must provide API calls to manage the creation and destruction of object instances.
90.10 Create an Instance of an Object Type
The system should provide an API call for creating a new instance of a given object type. The new instance should be populated with values for each of the attributes specified in the definition of the type. In addition, it should be possible to create the new instance with an optional context ID that refers to the default context that the object will live in.
90.20 Delete an Object Instance
The OM should provide an API call for object deletion. Objects can be deleted only when no other objects in the system refer to them. Since it -might not be practical to provide a mechanism like "delete cascade" +might not be practical to provide a mechanism like "delete cascade" here in a reliable way, providing such a facility in the system is optional.
The system must provide API calls to manage the creation and destruction of object relations.
The OM must provide an API call to declare that two objects are related to @@ -257,8 +258,8 @@ another. Since it is important that the largest audience of developers possible adopts and uses the OM, it must be easy to incorporate into applications, and it must not impose undue requirements on an -application's data model. In other words, it should be easy to "hook -into" the object model, and that ability should not have a major impact +application's data model. In other words, it should be easy to "hook +into" the object model, and that ability should not have a major impact on the application data model.
Note: Is the API the only way to obtain values? How does this integrate with application level SQL queries?
| Document Revision # | Action Taken, Notes | When? | By Whom? |
| 0.1 | Creation | 08/10/2000 | Bryan Quinn |
| 0.2 | Major re-write | 08/11/2000 | Pete Su |
| 0.3 | Draft completed after initial reviews | 08/22/2000 | Pete Su |
| 0.4 | Edited, updated to conform to requirements template, pending freeze | 08/23/2000 | Kai Wu |
| � | Final edits before freeze | 08/24/2000 | Pete Su |
| 0.5 | Edited for consistency | 08/27/2000 | Kai Wu |
| 0.6 | Put Object ID stuff first, because it makes more sense | 08/28/2000 | Pete Su |
| 0.7 | Added requirement that knowledge-level objects must be moveable between databases. | 08/29/2000 | Richard Li |
| 0.8 | Rewrote intro to match language and concepts in the design document. Also |