Skip to content.
Personal tools
You are here: Home » Features » The TReCX toolkit for distributed tracking

The TReCX toolkit for distributed tracking

Alexis O'Connor and Adam Marshall
Last modified 27 Nov, 2006
Published 27 Nov, 2006
Alexis O'Connor and Adam Marshall introduce the TReCX (Tracking and Reporting in e-Learning Contexts) toolkit project which has developed interfaces and libraries to allow educators to gather tracking data from a range of e-learning toolks including blogs and wikis.

TRECX logo


Tracking the actions of learners through e-learning tools is important in many situations. If a system is not recording the actions of the users then it is not possible to tell what activities are being undertaken or which resources are being used. There are more complex examples of scenarios for tracking, but a couple of simple easily understood use cases would include:

  • examining how much one or more resource(s) are being used / accessed.
  • examining the use of an individual's use of a number of resources.

Providing services to learners through a set of distinct applications and tools is already happening. It is now the case that as well as using the internal facilities within a VLE, external tools such as discussion forums, assessment engines, blogs and wikis can become part of a loose collection of resources used to deliver a course. This allows institutions to pick the applications that best suits their needs. However, often these applications either each maintain their own store of information about the progress of users through the system, or do not store this information at all. This makes tracking the overall progress of students at any point in time difficult as the information is distributed though separate systems. Therefore, what is required is set of interfaces and libraries that enable tracking behaviour to be added to existing heterogeneous applications in a consistent and useful way and allow for this information to be collated via a single point of contact.

Distributed Tracking

The following scenario is intended to illustrate the necessity for a library like TReCX and where it fits in with existing systems.

Say we have a course which is delivered via the internal multiple-choice tool and logbook facilities of a monolithic VLE, a standalone blog resource and a standalone wiki resource. The first two tools might capture their tracking information in the common tracking store of the VLE. These last two are best-of-breed standalone tools, which were not originally designed with e-Learning in mind. An educator wishes to examine the efficacy of her teaching, e.g. did those who made good use of the suggested learning materials do better as measured via the assessments. If all the tools capture tracking information (which they might well not!) the educator needs to interrogate each of these applications in turn and then some how collate and create reports from this information. This is shown in the diagram below:

Distributed Tracking without TRECX

Distributed Tracking without TRECX

The diagram below shows how the situation described above has been modified via use of TReCX libraries. In order to participate in a tracking federation the blog and wiki tools have been augmented so that they intercept and then publish noteworthy tracking events using a common event schema, to a shared standalone tracking store. Instead of needing to interrogate two or more stores independently, she is offered a single point of contact via the reporting application in which to analyse all this tracking information in one place.

Distributed Tracking with TRECX

Distributed Tracking with TRECX


TReCX stands for Tracking and Reporting in e-Learning Contexts. At the most abstract level TReCX is a set of web-service interfaces that allow for communication by sending XML over the HTTP protocol. Often this kind of system is implemented by using SOAP and WSDL (a machine-readable description of the interface). Due to their complexity these can sometimes be hard for developers to use in practice. So, as an alternative, many people prefer to use simpler so-called REST style interfaces, where the interface is simply described in human-readable text form, such as used by Yahoo! We chose this latter style in order to lower the barrier to entry.

These TReCX interfaces are:

  • a publish interface which describes the way in which a tracking store should receive one or more events.
  • a reporting interface which describes how a tracking store can be queried for events.
  • an XML schema (in XSD form) which describes the format of tracking events.

In order to make it more likely that other developers would actually incorporate TReCX style tracking behaviour into their applications, we wrote the following software artefacts that implement the interfaces described above. As our development team was most familiar with Java (and in fairness many web-applications are written in that language) this was the language they were implemented in.

  • a store implementation that can be deployed as a web-application to a servlet container.
  • a publish library to assist a developer in adding tracking behaviour to an existing application (this includes a command-line client).
  • a reporting library to assist a developer in writing a reporting application (this includes a command-line client).

The diagram below is intended to illustrate how a federation of co-operating e-Learning applications might interact regarding their tracking behaviour, with functionality provided by the outputs of the project.

TRECX working in a federation of e-Learning Applications

TRECX working in a federation of e-Learning Applications

Whilst it is fair to say that the publish and reporting libraries could only really be used by applications that were themselves written in Java, it should be stressed that the store component is a first-class standalone TReCX module. As it has web-service interfaces, the applications that talk to it could all in practice actually be written in, for example, PHP.

Event Schema

Events are intended to be simple, fine-grained and atomic. Within the XML schema that describes an event, several of the sub-elements pertain to where the event occurred (applicationID, service, servicePart & systemID). A sub-element capturing the what is operationType which consists of an enumeration of possible values. Here we borrowed from the database world with what is known as CRUD - CREATE, READ, UPDATE, DELETE, in other words, does the event pertain to something being created, read, updated (modified) or deleted. The what can also be captured via the optional use of a message sub-element, which is intended to be human-readable, and has an attribute to hold the language used for the message. The who is captured via the userID element. The when is captured via the timestamp element (which includes the timezone and is to the millisecond).

Capturing Events

There are a number of ways for a given e-Learning application to conform to the web-service interfaces and event schema specified by TReCX. In particular, if they are written in Java a developer can leverage the libraries that were created as outputs of this project. What ever language the application was written in, pertinent events need to intercepted and then published to an associated tracking store (or saved locally). As an individual event is intended to be simple and fine-grained, we offer advice as to how more complex events should be captured.

Taking the example of replying to a post within a forum application, this could be captured as the following related events (all with the same timestamp value):

  • a CREATE event for the actual post itself.
  • an UPDATE event to the associated forum thread.
  • an UPDATE event to the forum instance itself.

The section below shows how the corresponding XML would look, sent as a single event list.



Once a developer has incorporated the TReCX libraries within one or more e-Learning application, certain parameters can be tweaked to improve runtime performance and to determine who can talk to what (this is largely achieved through the use of servlet filters). These are specified in various plain text and XML configuration files.

  • the IP addresses of publishers that a tracking store will accept events from.
  • the IP addresses of reporters that a tracking store will send events to.
  • The parameters below are used specifically by the dispatch handler of publishers (these parameters are used in conjunction with one another): - the minimum number of events to wait for prior to dispatch.
  • the maximum time interval between dispatches.

Possibilities for future work

We would like to demonstrate the use of aspect-oriented programming to attach tracking behaviour to existing applications. For example, we would have loved to have shown the use of AspectJ used in conjunction with the libraries in this project.

It would also be good to create a machine-readable descriptor for the existing interfaces. A standard called WADL (Web Application Description Language) is emerging that is intended to describe REST style interfaces that use XML over HTTP like those already present in this project.


Where an e-Learning course is delivered through multiple heterogeneous applications, TReCX can be used to assist in the capture of tracking information as it consists of a set of interfaces and an event XML schema with concrete implementations provided to integrate with existing applications.


[1] The TReCX project web site

[2] The TReCX project Wiki

[3] The wikipedia entry for REST


Supported by JISC Supported by CETIS
Powered by Plone