| Prev | Chapter�15.�Kernel Documentation | Next |
|---|
By Pete Su, Michael Yoon, Richard Li, Rafael Schloming
+Before OpenACS 4, software developers writing OpenACS applications or modules would develop each data model separately. However, many applications built on OpenACS share certain characteristics or require certain common services. Examples of such services include:
User comments
Storage of user-defined or extensible sets of attributes
Access control
General auditing and bookkeeping (e.g. creation date, IP addresses, and @@ -32,9 +32,9 @@ object type (e.g. users) to instances of another object type (e.g. groups).
The next section will explore these facilities in the context of the the -particular programming idioms that we wish to generalize.
Related Links
This design document should be read along with the design documents for the new groups system, subsites and the permissions system
The motivation for most of the facilities in the OpenACS 4 Object Model can be +particular programming idioms that we wish to generalize.
Related Links
This design document should be read along with the design documents for the new groups system, subsites and the permissions system
The motivation for most of the facilities in the OpenACS 4 Object Model can be understood in the context of the 3.x code base and the kinds of programming -idioms that evolved there. These are listed and discussed below.
Object identification is a central mechanism in OpenACS 4. Every application +idioms that evolved there. These are listed and discussed below.
Object identification is a central mechanism in OpenACS 4. Every application object in OpenACS 4 has a unique ID which is mapped to a row in a central table called acs_objects. Developers that wish to use OpenACS 4 services need only take a few simple steps to make sure that their application objects @@ -76,10 +76,10 @@ in the new system. Each row in acs_objects stores information about the application object, but not the application object itself. This becomes more clear if you skip ahead and look at the SQL schema code -that defines this table.
Until the implementation of the general permissions system, every OpenACS +that defines this table.
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 -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, +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 book.
In this way, the scoping columns identify the security context in which a @@ -101,7 +101,7 @@ permission to perform action Y on object Z.
The context system forms the basis for the rest of the OpenACS access control system, which is described in in two separate documents: one for the permissions system and another for the party groups system. The context system -is also used to implement subsites.
As mentioned above, many OpenACS modules provide extensible data models, and +is also used to implement subsites.
As mentioned above, many OpenACS modules provide extensible data models, and need to use application specific mechanisms to keep track of user defined attributes and to map application data to these attributes. In the past, modules either used user/groups or their own ad hoc data model to provide @@ -141,7 +141,7 @@ corresponding row in the parent type table). Therefore, applications an use this mechanism without worrying about this bookkeeping themselves, and we avoid having applications pollute the core data model with their specific -information.
As we described above, the OpenACS 3.x user/groups system stored object +information.
As we described above, the OpenACS 3.x user/groups system stored object attributes in two ways. The first was to use columns in the helper table. The second consisted of two tables, one describing attributes and one storing values, to provide a flexible means for attaching attributes to metadata @@ -172,7 +172,7 @@ skinny tables because doing so allows developers and users to dynamically update the set of attributes stored on an object without updating the data model at the code level. The bottom line: Helper tables are more functional -and more efficient, skinny tables are more flexible but limited.
Many OpenACS 3.x modules use mapping tables to model relationships +and more efficient, skinny tables are more flexible but limited.
Many OpenACS 3.x modules use mapping tables to model relationships between application objects. Again, the 3.x user/groups system provides the canonical example of this design style. In that system, there was a single table called user_group_map that kept track of which users @@ -203,9 +203,9 @@ object system could use the meta data in the types table to do useful things in a generic way on all relation types. But this mechanism doesn't really exist yet.
Relation types are a somewhat abstract idea. To get a better feel for -them, you should just skip to the data model.
The OpenACS 4 Object Model is designed to generalize and unify the following +them, you should just skip to the data model.
The OpenACS 4 Object Model is designed to generalize and unify the following mechanisms that are repeatedly implemented in OpenACS-based systems to manage -generic and application specific metadata:
The presence of a framework for subtyping and inheritance always brings up +generic and application specific metadata:
The presence of a framework for subtyping and inheritance always brings up the question of why we don't just use an object database. The main reason is that all of the major object database vendors ship products that are effectively tied to some set of object oriented programming languages. Their @@ -229,7 +229,7 @@ practice. Finally, object databases are not as widely used as traditional relational systems. They have not been tested as extensively and their scalability to very large databases is not proven (though some will disagree -with this statement).
The conclusion: the best design is to add a limited notion of subtyping to +with this statement).
The conclusion: the best design is to add a limited notion of subtyping to our existing relational data model. By doing this, we retain all the power of the relational data model while gaining the object oriented features we need most.
In the context of OpenACS 4, this means using the object model to make our @@ -242,7 +242,7 @@ designed to support, for example, a huge type tree like the Java runtime libraries might define.
This last point cannot be over-stressed: the object model is not meant to be used for large scale application data storage. It is -meant to represent and store metadata, not application data.
Like most data models, the OpenACS Core data model has two levels:
The knowledge level (i.e. the metadata model)
The operational level (i.e. the concrete data model)
You can browse the data models themselves from here:
The knowledge level data model for OpenACS objects centers around three tables +and things like constraint names are not included.
The knowledge level data model for OpenACS objects centers around three tables that keep track of object types, attributes, and relation types. The first table is acs_object_types, shown here in an abbreviated form:
@@ -366,7 +366,7 @@ information about relation types.This part of the data model is somewhat analogous to the data dictionary in Oracle. The information stored here is primarily metadata that describes the data stored in the operational level of the data -model, which is discussed next.
The operational level data model centers around the +model, which is discussed next.
The operational level data model centers around the acs_objects table. This table contains a single row for every instance of the type acs_object. The table contains the object's unique identifier, a reference to its type, security @@ -437,16 +437,16 @@ generic skinny tables.
This table, along with acs_attributes and acs_attribute_values generalize the old user/group tables user_group_map, user_group_member_fields_map and -user_group_member_fields.
The core tables in the OpenACS 4 data model store information about instances +user_group_member_fields.
The core tables in the OpenACS 4 data model store information about instances of object types and relation types. The acs_object table provides the central location that contains a single row for every object in the system. Services can use this table along with the metadata in stored in the knowledge level data model to create, manage, query and manipulate objects in a uniform manner. The acs_rels table has an analogous role in storing information on relations.
These are all the tables that we'll discuss in this document. The rest of the Kernel data model is described in the documents for subsites, the permissions system and for the groups system.
Some examples of how these tables are used in the system can be found in -the discussion of the API, which comes next.
Now we'll examine each piece of the API in detail. Bear in mind that -the Object Model API is defined primarily through PL/SQL packages.
Now we'll examine each piece of the API in detail. Bear in mind that +the Object Model API is defined primarily through PL/SQL packages.
The object system provides an API for creating new object types and then attaching attributes to them. The procedures create_type and drop_type are used to create and delete type definitions.
The two calls show up in the package acs_object_type.
@@ -567,7 +567,7 @@ automatically be hooked into every generic object service that exists. Better still, this code need not be changed as new services are added. As an aside, the most important service that requires you to subtype -acs_object is permissions.
The next important piece of the API is defined in the +acs_object is permissions.
The next important piece of the API is defined in the acs_object package, and is concerned with creating and managing objects. This part of the API is designed to take care of the mundane bookkeeping needed to create objects and query their attributes. @@ -679,7 +679,7 @@ the general services in OpenACS 4 (i.e. permissions, general comments, and so on) are written to work with any object that appears in acs_objects. Therefore, in general these three steps are sufficient to make OpenACS 4 services -available to your application.
The relations system defines two packages: acs_rel_type for +available to your application.
The relations system defines two packages: acs_rel_type for creating and managing relation types, and acs_rel for relating objects.
These two procedures just insert and remove roles from the acs_rel_roles table. This table stores the legal relationship @@ -850,11 +850,11 @@ end; -
The Object Model's API and data model provides a small set of simple procedures that allow applications to create object types, object instances, and object relations. Most of the data model is straightforward; the relation type mechanism is a bit more complex, but in return it provides functionality -on par with the old user/groups system in a more general way.
Pete Su generated this document from material culled from other documents by Michael Yoon, Richard Li and Rafael Schloming. But, any remaining lies -are his and his alone.
| Document Revision # | Action Taken, Notes | When? | By Whom? | ||||||||||||||
| 0.1 | Creation | 9/09/2000 | Pete Su | ||||||||||||||
| 0.2 | Edited for ACS 4 Beta | 9/30/2000 | Kai Wu | ||||||||||||||
| 0.3 | Edited for ACS 4.0.1, fixed some mistakes, removed use of term
+are his and his alone.
|