Yann’s Blog

Storeables, Schemas, Assets, Storage, CrossReferences: these are all fundamental concepts in the IRM 2. This post is designed to explain some of these key concepts, though the technical verbage here will get somewhat heavy.

Storeable

 Internally, Storeable is simply an interface in IRM 2. It represents no actual object. Storeable objects are special though, they can contain a reference to a Storage subset, which can augment which fields they provide based upon a pre-defined schema. This is a change from the previous IRM 2 view, where a storage entity was an inherited trait. Aggregation simply makes more sense here.

The interface for Storeable exists to  mark classes which have support for Storage containers and provide a common API for accessing them.

Schema

A Schema is a set of fields which exist in every storeage container which utilizes it. Schemas are associated to a type (for instance, Asset), have a name (i.e., “Computer”, “Printer”, “Widget”) and can define fields such as: String name, Decimal purchasePrice, Date purchaseDate.  These can be configured on the fly at runtime, and have limited support for editing (to prevent you from throwing data out of the window :)).

Storage

A storage type presents an interface which maintains actual copies of fields specified by a Schema. There is one storage type per higher-type, such as an Asset. Storage is aggregated into the higher type - not by inheritance.

Asset

Asset is an example of a higher-order part. An Asset is just that, a customizable container which can contain a storage entity backed by a Schema. Assets have a complete user interface around them to make managing Assets easier. Another example of a higher order type is Location, and User (user can only have a single schema assigned to it at this time though). These higher order types can also define their own internal fields and methods which can not be altered by a Schema.

CRI

If you were following Python IRM 2 development, you would notice a core concept of GUID, or the Globally Unique IDentifier. GUID was somewhat over-reaching in that implementation, including odd type-promotion and other strange dynamic feature, and also depended on inheritance, which made them somewhat cumbersome to use. IRM 2 Mk III uses CRI, or Cross Reference Identifier, which is aggregated into types which can benefit from its services (though not using IOC concepts such as Inject, yet anyway). CRIs can be associated as before, allowing a graph of associations (Asset contained in Location, owned by User, etc).