Architecture

The basic structure of a Ubik application is shown below:

Scalability

The current implementation allows for the separation of client, server and database, however only one server may be run. Plans for the future include the separation of the messaging server so that multiple server machines can be deployed.

Key Patterns

Domain Model & Data Mapping

Ubik uses the most abstracted form of business logic representation, where business objects are decoupled from the database and an additional layer is used to load and save them to specific tables (c.f. the Ruby on Rails persistence architecture called 'Active Record,' where the business objects represent a specific table row.)

Identity Object

Ubik maintains a single instance of each persistent object within a session. This is done by tracking the 'identity' of the object through a cache, and ensuring that all requests for the object with a specific identity retrieve the same concrete instance. Identity Object prevents data aliasing problems that result when multiple pieces of code update the same 'logical' object within a transaction through separately-loaded instances, resulting in inconsistent state.

Key Classes

Nearly all code is written client-side in business objects (the exception is described in Server Tasks below.)

The Session Class

A Session is a mutually-consistent subset of the complete persistent business model that is manipulated independently of other sessions. The concept is sometimes called an Object Space.

The Select() and SelectOne() methods on Session are the means by which persistent objects can be retrieved from the database.

BeginTransaction() is the other key method on Session, allowing for the control of object-level transactions.

The Individual Class

Individual is the base class of all business objects. It uses custom classes for persistent properties that allow it to be registered as dirty when changes are made.