A brief overview of Construct: component by component at Construct

In this post I’ll give a brief overview of the core components in a Construct node. It’ll be of interest to anyone adapting the way Construct works internally and developers of other middleware platforms. This is a good entry point into how we designed and built Construct.

If you want to build your own components I’m about to write some tutorials and blog posts so check back soon (or grab the RSS feed).

The Component Loader

The number and type of components in any given deployment of Construct is customisable. At runtime, each of the components defined in the construct.properties file is instantiated by the Component Loader, and indexed in a Component Registry to allow collaboration between components. The Component Loader is also responsible for the correct shutdown of the components when the software is terminated.

The Discovery Service

All components that interact directly with sensors or applications provide a self-describing manifest that contains information on how to interact with them. These manifests are maintained by the Discovery Service. This service provides the first point of contact for anyone that wishes to contact a Construct node. The Discovery Service advertises itself using Bonjour.

The Data Manager

The Data Manager is responsible for storing and maintaining an RDF model of all received data. It also contains a meta-data model which holds information describing the RDF statements stored in the first model. Currently this meta-model only stores information describing when the statement expires. The current implementation of this data store manager uses Jena to manage both the models.

The DataPort

The DataPort provides the gateway for adding new data to the Construct infrastructure. It takes the simple form of a TCP socket listening on a port for RDF expressed as a String in N-TRIPLE format. Multiple triples may be concatenated, and an expiry time may be appended to the end of the String if desired.

If you want to drop data directly into the DataPort go read the tutorial on our protocol format first.

The HttpPort

The HttpPort is a convenient way to query construct over HTTP. You can do this programmatically or via a web browser. If you ask the component loader to start the HTTP port (see the construct.properties file) and have Construct running try looking at http://localhost:8888/ to find a simple SPARQL query interface. This is a great way to interact with Construct from web applications.

The Query Service

The Query Service component is the interface that the framework provides to applications wishing to query the data store. It accepts a String from an application in the form of a SPARQL query and returns a String of results. The application can then decompose the returned String value into the variables that it queried for. Using the in-built Jena reasoner, the Query Service component first infers implicit triples from the data store contents (represented as RDF triples) so that it returns inferred results as well as explicit data to the application.

The Gossipping Service

The implementation of a gossiping algorithm takes the form of a protocol stack with three layers: the data-layer, which exchanges RDF with the data-manager; the gossiping layer, which drives the process; and the network layer which encapsulates the actual sending and receiving of raw packets of bytes.

The gossiping subsystem can be further decomposed into three components: the core gossiping protocol, the message buffer, and the peer membership manager. The core gossiping protocol is stateless. Gossiping is initiated periodically at each peer by sending their message buffer summary to a randomly selected peer from their contact list. When messages arrive they are identified and processed by type. The gossiping layer handles three types of messages: data messages, message buffer summaries, and individual message requests. Data messages are stored in the message buffer for future gossiping then passed up the protocol stack to the data-manager. Message buffer summaries contain a list of the message IDs present in the remote node’s buffer. On comparison with the local message buffer requests for messages that are not held locally are generated. These requests are fulfilled by return.

[adapted from posts by Graeme and Lorcan]

Bookmark and Share

Close this Window Bookmark and Share This Page

Save to Browser Favorites / Bookmarks