The Routing Service view allows you to define the configuration of an
execution of Routing Service.
To add a new Routing Service to your model, click the button
while Routing Services is selected or right-click Routing Services in the tree
and select Add Routing Service…:
A pop-up window will appear, where you can enter the Routing Service name, and
the file where the Routing Service is going to be saved:
When a Routing Service is selected, you can set all the different aspects of the
configurations of a Routing Service in the Structured view:
See Routing Service Tag in the RTI Routing
Service User’s Manual for more information on the configuration available for
an execution of Routing Service.
Once you have your Routing Service defined, you can select one of them and add
a Domain Route. A Domain Route defines a mapping between different data domains,
data available in any of these data domains can be routed to other data domains.
See Domain Route in the RTI Routing Service User’s
Manual for more information on the configuration available for a mapping
between different data domains.
When a Domain Route is selected, you can define Connections, Participants,
and/or Sessions by clicking on the button while the Domain
Route is selected, or click on the in the Connections, Participants
& Sessions table:
Next, we’ll explain the elements that are configurable inside a Domain Route:
Connections: A Connection requires a name, which will be used by the
Route to select input and output domains, and a plugin_name, which
will be used to associate a Connection with an adapter plugin defined
in the Plugin Library view.
System Designer will display the adapter plugin defined in the Plugin Library view if
you press the Key Down in the plugin_name field, or you start typing for
suggestions.
Participants: Routing Service comes with a builtin implementation of a
DDS adapter. A Participant corresponds to exactly one DomainParticipant.
Sessions: A Session defines a multi-threaded context for route
processing, including data forwarding. The data is routed according to
specified Routes and AutoRoutes.
Each Session will have an associated thread pool to process Routes
concurrently, preserving Route safety. Multiple Routes can be processed
concurrently, but a single Route can be processed only by one thread at
time. By default, the session thread pool has a single thread, which
serializes the processing of all the Routes.
Sessions that bridge domains will create a Publisher and a Subscriber from
the DomainParticipants associated with the domains.
When a Session is selected, you can define Routes or Auto Routes by clicking
on the button while the Session is selected, or click on
the in the Routes & AutoRoutes table:
Routes & Topic Routes: A Route explicitly defines a mapping between
one or more input data streams and one or more output data streams. The
input and output streams may belong to different data domains.
Route events are processed in the context of the thread belonging to
the parent Session. Route event processing includes, among others, calls
to the StreamReader read and StreamWriter write operations.
See Route in the RTI Routing Service User’s Manual
for more information on the configuration available for a Route.
See Topic Route in the RTI Routing Service
User’s Manual for more information on the configuration available for a
Topic Route.
Input/Output: Inputs and outputs in a Route or TopicRoute have
an associated StreamReader and StreamWriter, respectively. For DDS
domains, the StreamReader will contain a DataReader and the
StreamWriter will contain a DataWriter. The DataReaders and
DataWriters belong to the corresponding Session Subscriber and
Publisher.
System Designer will display the Connection defined in the Routing Service view
if you press the Key Down in the connection field, or you start
typing for suggestions.
See Route Inputs/Outputs in the RTI Routing
Service User’s Manual for more information on the configuration
available for a Route Inputs/Outputs.
A TopicRoute is a special kind of Route that allows defining mapping
between DDS topics only.
System Designer will display the Participants defined in the Routing Service
view if you press the Key Down in the participant field, or you
start typing for suggestions.
See Topic Route Inputs/Outputs in the
RTI Routing Service User’s Manual for more information on the
configuration available for a Topic Route Inputs/Outputs.
Auto Routes & Auto Topic Routes: An Auto Route defines a set of
potential Routes, with single input and output, both with the same
registered type and stream name. A Route can eventually be instantiated
when a new stream is discovered with a type name and a stream name that
match the filters in the AutoRoute. When this happens, a Route is
created with the configuration defined by the AutoRoute.
The generated Route has a name constructed as follows:
[auto_route_name]@[stream_name]
where [auto_route_name] represents the name of the AutoRoute and
[stream_name] the name of the matching stream.
DDS inputs and outputs within an AutoRoute are defined by clicking on
the Auto Route (DDS inputs/outputs), whereas Input and outputs from
other data domains are defined by clicking on the
Auto Route (non-DDS inputs/outputs).
An AutoTopicRoute is a special kind of AutoRoute that defines a
mapping between two DDS domains.
See Auto Route in the RTI Routing Service User’s
Manual for more information on the configuration available for an Auto
Route.
See Auto Topic Route in the RTI Routing
Service User’s Manual for more information on the configuration
available for an Auto Topic Route.
The XML view allows you to check the XML results and manually edit each XML file: