2.4.6. Define Routing Services

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: