Fluxion Stack Architecture

The Fluxion stack is divided into three main layers (not including the datasources being integrated). These seperate the concerns of integration so that each layer performs just one task.

We provide tools to make interaction with each of these layers as easy as possible. This allows you as a user to focus on the knowledge which needs to be captured during the integration process, rather than worrying about the actual details of build and manipulating the stack itself.

The main layers of the stack are...

• Pussycat - this is the interface that Consumers will interact with. Pussycat provides a pluggable interface for rendering a uniform view of the knowledge exposed by the fluxion system. Pussycat will typically acquire data from multiple Data Services, exposing the federated data as if it was present in a single location.
• Runcible - this layer dynamically transforms data from local representations into a global ontology, and publishes the transformed data in turn. A Runcible service is constructed from some Mapping Rules, and are responsible for converting from domain-specific views of data into concepts that conform to the shared understanding of the domain. The data that is transformed will typically be obtained from a DataPublisher. Runcible exposes itself as a webservice, meaning that its data can be viewed in Pussycat.
• DataPublisher - this publishes an OWL version of raw data. The OWL schema will typically very closely resemble the underlying database schema or file format. It may be augmented with extra information not captured in the underlying database, such as default Species, or equivalence and uniqueness constraints. Publishers expose the data through a Data Service, and typically will consume data from a Raw Data Source.

Finally, there is the underlying datasource, which can be thought of as a fourth layer in the Stack

• Raw Data Source - this exposes the raw data, using a data-specific protocol. For example, this may be an SQL database, XML files or tab-delimited text.

The following diagram shows three distinct datasources exposed via the Fluxion Stack, being integrated into a single Pussycat instance. Communication between the layers is acheived via a common Fluxion webservice interface.

Developer Information

The fluxion developer modules provide many of the components needed to build, assemble and configure an integration stack. We rely on Maven 2 to provide a unified and consistent environment for building, testing and deploying components.

• Core Modules - these modules contain the code that you will either extend, or use directly to implement components of the stack. There are classes describing the Java5 annotations to mark up generated classes, utility classes for manipulating OWL, datasource interfaces, web-service interfaces and so on.
• DBMS Modules - these are implementation modules which act as Database management system "plugins" and the meta models for the various schema. The Fluxion stack needs a meta-model describing the schema, and a plugin for the DBM, in order to communicate with the datasource and publish it as OWL. The currently available supported DBM types are here.
• Fluxion plugins - plugins that augment the maven build system to automate development tasks. The plugins which perform the OWL generation from the datasource schema, code generation to perform queries and other publisher automation tasks are present here.

To use the available tools to generate a new Publisher for a datasource, you need to use these modules. Potentially, you will need to develop new implementations of a meta-model and a DBMS support module for your datasource schema (see Exposing a Datasource). The dependency sturcture of the Fluxion stack looks something like this: