TPM (2)
Carlos Coutinho Dan Bendas (VTT)

About Third Party Mediator

Intro

The C2NET Third Party Mediator (TPM) module implements an interface for other components to access external services and data sources. In particular, its role is to access web services located outside of C2NET cloud, to fetch data according to predefined parameters, perform extraction operations if needed, and deliver it to interested C2NET components.

Functionality

In the C2NET architecture valid as of Oct 2016 TPM is not used or activated by other components, but it periodically self-activated by a timer defined by a human user via the management UI.

By itself TPM does not perform any reasoning or interpretation of data. The only operations supported are extraction and re-structuring:

  • extraction - finding relevant information from documents (either structured, like XML, JSON, etc. or unstructured like HTML) and removal of un-required content.
  • re-structuring - transformation of structure

One example proposed in the project is fetching weather forecasts from the site AccuWeather in form of human-readable HTML, and extracting next month's forecast in a structured format.

Scripts

Fetching and transformation processes are specific to each individual service and data source, and they are specified through scripts. Those are specified as Python modules which implement a certain interface and follow a coding convention. If other scripting langauges/methods are required, TPM's architecture allows adding additional script execution engines.

Architecture

The internal design of TPM is presented in the picture:

architecture

Dependencies

Requires: Resource Manager Backend (RMBackend). TPM periodically fetches data from external services and pushes it to the RMBackend, where it will be stored. LL-CEP (Low Level Complex Event Processor) is triggered, analyses the data and, in case that abnormal patterns are detected, it sends a notification to Mobile Application and UCP.

The data provided by TPM is not part of STables. From RM's perspective, TPM is similar with a hub (same as IoT Hub and Legacy Systems Hub). Each active TPM timer is mapped to a RM resource.

The communication mode with RMBackend is described here

Dependents: User Collaboration Portal (UCP). TPM exposes a management user interface in UCP.

Channels

TPM's channels

Module Development:

Development Status: TPM: Third-Party Mediator
Responsible: VTT
Other Participants: (none)

Features: (none)

Note As of Oct 2016 those features are obsolete as they don't accurately represent neither the module's functionality or structure. Should be updated.
TPM-001: Access to structured 3rd-party services
TPM-002: Support for formats/​protocols
TPM-003: Different access modes: query, timed, listener
TPM-004: Data source adaptors defined declaratively via RM
TPM-005: Data delivery via client-defined formats/​protocols
TPM-006: Output adaptors defined declaratively via RM>

About this page

This page includes two Git repositories:

  • Public Code relates to the code developed to implement this module, and
  • UI is code that will be integrated with the UCP for the User Interface.

Additionally, it includes a Tickets entry to handle specific issues regarding this module as a whole (which may include management, integration, new features, etc.).

Attachments
TPM Architecture - 2016-10-04.png (21165 bytes)

Related

Wiki: TPM - Data Storage Interaction
Ticket: #3
Ticket: #69
Ticket: #70
Ticket: #71
Ticket: #72
Ticket: #73
Ticket: #74