Active Data Framework
The Active Data Framework (ADF) is software enabling the use of data. This is the first publication. Requirements and the design are here.
Requirements
- The Active Data Framework must be free (as in freedom).
- The Active Data Framework must grow.
- The Active Data Framework must help people.
- The Active Data Framework may help businesses.
- The Active Data Framework is *NOT* for sale.
Design
ADF models data with precise object orientation. Rather than the traditional blob, data fields are represented as a cube. Methods are six: create, read, update, relate, replicate, and move. Methods are represented as pyramids from each face. This is the complete model and methods may be omitted on any implementation.
Data is understood as the regular information one finds today. ADF extends this information by metadata (e.g. indexes) and relationships. All methods, then, operate on this data.
The approach is similar to the Java Architecture for XML Binding. That is data is modeled and compiled into code prior to runtime. The ADF provides interfaces. So, every data is normalized to the same set of operations.
And now for the example. Information exists regarding t-shirts, size and color. To display t-shirts we would first compile from a data model. Then, use the code like (please excuse my Java):
TShirts[] tshirts = TShirts.read();
To create a new TShirt, use:
TShirt tshirt = TShrits.create();
To update our TShirt, do:
tshirt.set( TShirt.Size, TShirt.SMALL );
tshirt.set( TShirt.Color, TShirt.BLUE );
tshirt.write();
or:
tshirt.write( TShirt.SMALL, TShirt.BLUE );
ADF configures all data base concerns, concurrency concerns, index defaults, fields defaults, and such at compile time. Yes, this would be changeable at runtime, too. In our example, we hope to perform ‘live’ reads using good persistence techniques and automatic insertion and updates.
Finally, ADF provides multiple implementations. Data entry is create only. Regular is all methods excepting the move method. Full is all methods. As-is utilizes the existing data structure and indexes and omits impossible operations. Full builds an entire set of unique indexes and any required meta data based on user configuration. Active is live updates as mentioned. Offline would defer actual updates between the software and the data store to a controlled and/or manual step.
A basic architecture is : user <--> interface <--> { eventual domain functions } <--> ADF <-- ODBC --> data base
Note any data model is mapped to a specific database implementation. We hope to cross the bridge of ODBC pioneers to make this easy.
The next eventual step is a demonstration, planned for 2010, so please God.
Please be free to comment here and to ismailfaljones@tusojos.com . Peace.