Concepts and Terms¶
Before configuring and using Integration Service some concepts and terms should be known before reading the rest of the documentation.
- Integration Service: Integration Service can be named as IS.
- ISWriter: An
ISWriter(or Writer) is a component able to write data to a destination protocol.
- ISReader: An
ISReader(or Reader) is a component able to read data from a source protocol.
- Transformation Function: A Transformation Function is a function that converts between data types.
- Transformation Library: A Transformation Library is a library that contains Transformation Functions.
- Endpoint: An Endpoint is a Writer or Reader.
- Connector: A Connector is a component that relates a Reader with a Writer and optionally a Transformation Function.
- ISBridge: An
ISBridgeis a component that holds a set of connectors and manages them.
- Bridge Library: A Bridge Library (or Bridge) is a library that provides Writers and Readers to support additional protocols and optionally more complex Bridges.
Fast-RTPS’s Concepts and Terms should be known too.
Integration Service allows user interaction at two different levels:
- As a stand-alone application.
- As a library.
When using IS as a library, a configuration XML file must be programmatically provided.
Integration Service architecture¶
IS provides three interfaces that must be implemented by any new custom bridge to allow new protocols. These classes are ISBridge, ISWriter, and ISReader. There is an RTPS-Bridge implementation as default, that uses Fast RTPS libraries.
IS is intended to communicate Fast RTPS with others protocols when using bridges, so any Connector must have at least one endpoint configured as a Fast RTPS participant.
ISBridge derived classes, the following points must be taken into account:
ISWriter::writeis mandatory to implement.
- When a reader receives data, its
on_received_datafunction must be called with the data properly converted into
- The default behavior can be overridden but isn’t recommended in general. This behavior follows this diagram:
When the reader calls to its method
on_received_data, it will call all the bridges it belongs,
calling the method
on_received_data of each bridge.
Then the bridges will apply each respective transformation functions
to the data and will call the
write method of each of their writers.
Note that there are two flavors of these called methods that must be coherent between them
depending on the use of dynamic data or not.
This behavior will only occur with the declared connectors in the XML configuration file.