Design Notes (0.0.1)

This page is the root of design notes applicable for version 0.0.1 of Omneity.

Note: Version 0.0.1 is a pre-release version of the system carrying very early development, as such it should be used for development and test purposes only.

For current javadocs and other development details, refer to the development snapshot site. This contains reasonably up-to-date details of the current code base.

There are currently no published binaries (I'm working on how best to release these to a Maven repository).

Basics
Omneity is an OSGi system consisting of a number of bundles (up to date details on the development snapshot site).

An agent (the main unit of Omneity) currently consists of:

Adapters
Adapters implement the Adapter interface and provide an OSGi factory that has an associated static propertyscheme and a service property connectionString. The scheme properly is used by the DataSourceManagerImpl to classify the Adapter as suitable for handling URIs of that scheme (e.g. the MVNAdapter's scheme is mvn and the OBRAdapter's scheme is obr)—multiple Adapters may satisfy the same scheme, under theses circumstances the DataSourceManager will attempt to connect to the specified data source using each registered Adapter in turn until one connects successfully.

The connectionString property is set by DataSourceManagerImpl when attempting to start an instance of an Adapter. This connectionString property will contain the scheme specific part of any connection URI requested of DataSourceManagerImpl. Adapters are expected to connect to the underlying data source specified by this connection string during component startup (under iPojo, during @Validate). A failure to connect should result in a failed component startup and no instance should be created.

Update and refresh
All Adapters (even those implementing the direct DataSourceManager interface) respond to update and refresh requests.

An update request is satisfied when the Adapter guarantees that any data that has not previously been loaded into the local database is up-to-date with the source to which the Adapter is connected. Updates are incremental.

An refresh request is satisfied when the Adapter guarantees that any data in the local database is up-to-date with the source to which the Adapter is connected. Unlike an update though, a refresh verifies all data in the local database that is relevant to the Adapters data source. Refresh operations may, therefore, take a considerable time to complete as every datum in the local database must be confirmed against the underlying data source.

Event model
Apart from the normal OSGi lifecycle, Adapters have their own internal event model.

Clients may register listeners (implementing the com.itslm.omneity.data.api.EventListener interface) to receive Event notifications whenever an Adapter changes its state.

Adapter implementers are expected to honour that states specified in com.itslm.omneity.adapter.api.event.UpdateState (ensuring suitable Events are generated appropriately), but are free to implement other states as the see fit.