It is clear that we do not know how to program--how else can you explain why so many people around the world spend so much time doing it? Clearly we need a better approach to software. We need to be able to assemble components, configure them and interconnect them in interesting ways. But assemble may be the wrong term here, as we need systems which are fluid and which can be reorganized on-the-fly to meet ever changing requirements.

What we need to do to achive this is to introduce another level of granularity. Current practice is to create objects and use them to assemble a program. Rather we need to assemble components from objects and then interconnect those components in interesting ways to create the initial configuration of a larger system. But when working with a group of such components, the constituant objects need to be accessible, as this allows for a deeper interaction between them. Components can then operate on each other and utilize the internal structures of other components as resources. And this mandates the standardization of the internal structures of those components.

In [CowDb], which COODBMS builds on, we introduced roles, which are super objects composed of 3 different kinds of objects. This gives us 3 independent class heirarchies. It works a lot like C++ mixins and allows us to create very powerful roles with a minimum of code. CowDb is all about raw capabilities, but provides few clues as to how best to use that capability and how to organize them into interesting systems. I would call CowDb a good step in the right direction, but only one step on the path to building the kind of software that we need.

The next step is to organize roles into entities, which we will call Rolons, and to organize these Rolons into larger systems which support interesting relationships between its Rolons. But the internal structure of a Rolon and the relationships a Rolon has with other Rolons need to be able to change over time.

Rolons themselves are simple trees and each rolon can have four sub-nodes, which we will call Units:

1. The Classifier Unit (CU) manages the relationships of a Rolon. The nodes under a CU are called Classifier Sections (CSecs). COODBMS introduces 3 special CSecs: Parents, Children and Keywords.
   

2. The Descriptor Unit (DU) manages the behavior of a Rolon. The nodes under a DU are called Descriptor Sections (DSecs) and are "executible".
   

3. The Ledger Unit (LU) manages the Rolon's content or state. The nodes under a LU are called Ledger Sections (LSecs).
   

4. The Journal Unit (JU) manages the Rolon's history. It tells us what happened, when and by whom. The nodes under the JU are called Journal Sections (JSecs).
   

Sections form the internal nodes of the four sub-trees under the Rolon, with the Units being the root nodes of these sub-trees. Sections are always under a Unit or under another Section. In addition there are Entries (Ents), which are always leaf nodes.

Think of rolons as high-level components that are build from a limited (but extensible) set of roles, and which can themselves be operated on. Which means that the behavior of a Rolon, and its relationships to other Rolons, can change over time. The intention then is to enable the creation of the fluid systems which I mentioned eariler.

COODBMS can tracks all transactions in a branch journal. Further, the JSecs in each rolon holds symbolic links to the transactions which have been applied to that Rolon.

A scripting language, RoleML is used to specify the behavior of a transaction. RoleML is transformed into the Descriptor Unit of a Transaction Rolon and then executed.

A Brief Introduction to Rolons

COODBMS adds a powerful organizational structure to [CowDb]: Rolons.

You can think of a Rolon as a simple tree structure. There are four subtrees (or Units):

• Classifier Unit - Specifies the relations the Rolon has with other Rolons.
• Descriptor Unit - Defines the Rolon's behavior.
• Ledger Unit - Holds the Rolon's state.
• Journal Unit - Tracks the activities in which the Rolon has participated.

The nodes under each Unit are called Sections and the leaves of the tree are called Entries.

Rolons themselves are organized as a non-cyclic graph or bush structure, similar to a family tree where a Rolon can have multiple parents and multiple children. The resulting structure can be quite arbitrary and is only intended to make it easy to locate Rolons of interest (one means, anyway), but useful structures tend to be ontological in nature. Keyword access is also supported.

Now the power of COODBMS does not derive from the implementation, but from the fact that its organizational structure is universally applicable to all applications. This allows us to develop generic operations which would otherwise be application-specific.

We can reduce OO to this: Data + Logic -> Objects. But in rolonics we look at things this way: Relations + Behavior + State + Activity -> Rolons. Rolonic theory then divides meta data into Relations and Behavior, while adding the history of the activities the Rolon has participated in. It is this comprehensive and structured way of looking at things which makes Rolonics so powerful.

Context

Another difference between OO and Rolonics is Context. In Rolonics, every Rolon, Unit, Section and Section Entry has access to the environment it operates in. This is implemented using an Inversion-Of-Control (IOC) method which provides every object with information about its context. COODBMS extends the context provided by CowDb with the methods rolon() and unit(), among others.

Implementation

In CowDb terms Rolons are always First Class Objects, which means they are under an Index. Rolons, Units, Sections and Entries all subclass PNode.

To join Rolons into a larger structure, each Rolon [optionally] contains a Parents and a Children Classifier Section. These CSecs hold a list of PHandles which have the names of other Rolons in the same Index. The reference counting logic is also modified so that a Rolon which is not well known and which has no parents will be deleted. And as Rolons are organized as a non-cyclic graph, reference counting works quite nicely.

Pathnames and pathname resolution is also augmented, though note that a rolon can be accessed via multiple pathnames. When a pathname is created for a rolon, the first parent in the Parents CSec is used.

Rolonic elements are created using the same methods as are used in CowDb, but note that a Rolon can only be created in an Index (Rolons being First Class Objects), Units can only be created in a Rolon, Sections can only be created in a Unit or another Section and Entries can only be created in a Section.

Rolons can be located via their pathname or by keyword. Navigation to a well known Rolon, as well as navigation down the internal tree structure of a Rolon are achieved using the usual CowDb methods.

The following Ents are included in COODBMS:

Role	App Subclass	Description
BOOLEAN_ENT	BooleanAttributeApp	Boolean Entry
BYTES_ENT	BytesAttributeApp	Byte Array Entry
INT_ENT	IntAttributeApp	Integer Entry
LONG_ENT	LongAttributeApp	Long Entry
STRING_ENT	StringAttributeApp	String Entry
TEXT_ENT	TextAttributeApp	Text Entry
SERIALIZABLE_ENT	SerializableAttributeApp	Serializable Object Entry