The home of Alitheia Core

Data layer

Alitheia Core uses two types of data stores to work with. Depending on the metric to be run, either or both of the data stores are required for Alitheia Core to run. The datastores are:

The Relational Database

The relational database stores metadata about projects and metric results. No actual project data are stored in the database.

The Project datastore

Stores raw project data (in a custom schema). Data in this datastore are only read from Alitheia Core. The datastore must be synchronised with the original project datastores externally.

Processing layer

Contains the necessary components to support the execution of custom analysis tools (plug-ins) and provides abstractions to the underlying data. This is essentially the Alitheia Core tool. Each box corresponds to an OSGi service interface.

DB Service

The DB service is central to the system as it serves the triple role of abstracting the underlying data formats by storing the corresponding metadata, storing metric results, and providing the types used throughout the system to model project resources. It uses ORM (Object Relational Mapping) to eliminate the barrier between runtime types and stored data and has integrated transaction management facilities. ORM facilitates plug-in implementation by transparently converting simple queries to method calls and hiding important queries through method implementations. It also enables navigation by means of method calls among entries in the object graph that feature parent-child relationships.

The main entities used by Alitheia Core are described in the Database schema page. The DB service interface can be found here

Metadata updater

Alitheia Core uses both raw data from the projects it measures, and metadata derived from the raw data. Metadata must be updated every time the raw data are updated. The job of the metadata updater service is to maintain consistency between the raw data and the metadata. The metadata update service is one of the few services that receive external input. It does so in order to get notified by external tools when raw data updates have niched. The processing of the update request is performed by a component that validates input and schedules the appropriate update job depending on the request and underlying data format. In Alitheia Core parlance, this is called an updater.

Source code links: Service Interface, Metadata Updater

Job Scheduler

One of the most important functions Alitheia Core performs is the splitting of the processing load on multiple CPUs. Typically, all plug-in invocations and a considerable number of maintenance tasks are run in parallel. The job scheduler component is required to manage the sharing of processors among tasks as the rate of task generation can at any time be higher than the rate of task consumption, in which case a direct task-CPU assignment using operating system provided semantics would overwhelm the operating system. The job scheduler service maintains a task queue (which holds all jobs which can be immediately executed), a wait queue (which contains jobs that are put on hold due to unsatisfied dependencies) and a confi gurable size worker pool and assigns tasks from the task queue to idle workers. The scheduler does not implement task fairness policies nor does it pre-empt long running tasks.

All tasks in Alitheia Core are modeled as jobs. A job is a generic abstraction of an executable entity. Each job maintains a list of dependencies on other jobs and is assigned a priority level. The scheduler uses this information to order the execution of jobs. A job can be in a fi nite number of states, which can only be modified by scheduling decisions.

Source code links: Scheduler Interface, Abstract Job

Data Accessors (FDS/TDS)

The job of the data accessors is to provide a two way abstraction of the data managed by Alitheia Core. The Thin Data Store (TDS) part of the accessor stack exposes an abstacted view of the raw data formats; this is done by capturing the most of the common characteristics across the processed data into a set of classes and providing drivers that convert the underlying data to the common representation. Its function is reminisent of the VFS layer found in many operating systems. The TDS is fully extensible; currently it abstracts data coming from version control systems, mailing lists and bug databases with drivers for Subversion, maildir and Bugzilla XML respectively.

On the other hand, the Fat Data Store (FDS) encapsulates common (non-destructive, readonly) actions done on data stores. For example, in a version control system, a user might ask for the revision log, check out a revision or update a checkout to a specific revision. The FDS performs those actions on behalf of a plug-in while managing the system resources.

Source Code links: TDS Service Interface, FDS Service

Metric Activator

The job of the Metric Activator service is to hide away the complications of scheduling metrics runs. As Alitheia Core supports the specification of dependencies among metrics, while the metrics are arbitrarily distributed in various plug-ins and are bound to certain activation types, resolving the relationships and starting metric jobs in the correct order when new data arive or when the user initiated a metric synchronisation, can be complex. The metric activator hides this complexity behind a very simple interface.

Source Code links: Metric Activator service

Cluster service

A simple service that assigns projects to machines and ensures that no metadata updates or metric runs are performed outside the machine each project is registered with. Only useful when Alitheia Core runs in a cluster environment.

Plug-in admin

The plug-in admin service is responsible to discover, install, initialise and offer information about metric plug-ins.

Web admin

The web admin component contains the static and dynamic resources used to control Alitheia Core from within a browser.

Auxiliary services

The Alitheia Core platform also defines several auxiliary services, namely:

• Logging: Implements a customisable application logger
• Security: Implements a simple authentication service
• Messaging: (obsolete, to be removed) Implements an extensible messaging service, that in its initial form it sent emails to registered users

Plug-ins

Plug-ins in Alitheia Core define metrics and is where the actual software analysis is being done. You can find more about plug-ins (including details on how to write your own) in the Metric Plugins page.

Presentation Layer

The presentation layer presents metadata and metric results. It allows external clients to connect to the system in order to retrieve metadata and analysis results. The presenation layer was initially implemented as a full-blown web service with a JSP based client, but this implementation has shown its limits. Both the web service and the client code has been removed from the source code base and will be gradually replaced by a REST-based API.