Communicate two DDS applications

The domain field is used to define the local space where participants exist. With this information, several DDS applications that use different domains can’t communicate between them, even if they use compatible types and configurations. To make this communication doable it could be possible to change the domain of one application to move all of them to the same domain, but this modification may be undesired. In these cases, Integration Service can create a bridge between them, keeping each application with its configuration.

_images/DDS_NO_COMS.png

Integration Service can configure two endpoints to establish the communication with the rest of applications directly and without changing its configuration, sending the packages of one domain to the other one.

_images/DDS_WITH_IS.png

Routing usage and configuration

To solve the previous situation, Integration Service must be configured through its XML Configuration file with one endpoint able to write and read to each DDS world. Depending on the Topic Data Type of each DDS world, a Transformation Library could be needed to provide transformation functions that will convert the data from DDS World A to DDS World B and vice versa. See Data transformation to see a scenario with transformation functions.

In this example, a file named config.xml needs to be created.

The endpoints must be configured in the Fast-RTPS profiles section.

    <profiles>
        <participant profile_name="DDS World A">
            <!-- DDS World A participant attributes -->
        </participant>

        <participant profile_name="DDS World B">
            <!-- DDS World B participant attributes -->
        </participant>

        <subscriber profile_name="subscriber A">
            <!-- DDS World A subscriber attributes -->
        </subscriber>

        <subscriber profile_name="subscriber B">
            <!-- DDS World B subscriber attributes -->
        </subscriber>

        <publisher profile_name="publisher A">
            <!-- DDS World A publisher attributes -->
        </publisher>

        <publisher profile_name="publisher B">
            <!-- DDS World B publisher attributes -->
        </publisher>
    </profiles>

And the Connectors are declared below:

    <connector name="A_to_B">
        <reader participant_profile="DDS World A" subscriber_profile="subscriber A"/>
        <writer participant_profile="DDS World B" publisher_profile="publisher B"/>
        <transformation file="libtransformationData.so" function="transformA_to_B"/>
    </connector>

    <connector name="B_to_A">
        <reader participant_profile="DDS World B" subscriber_profile="subscriber B"/>
        <writer participant_profile="DDS World A" publisher_profile="publisher A"/>
        <transformation file="libtransformationData.so" function="transformB_to_A"/>
    </connector>

It’s important to associate the correct participant with the correct publisher or subscriber, in this case: publisher A and subscriber A endpoints belong to DDS World A participant, and publisher B and subscriber B endpoints belong to DDS World B participant.

The root tag of the config.xml file must be <is> as described in the Configuration.

Routing with Integration Service

As both DDS Worlds use the same protocol, and Integration Service supports it out-of-the-box, the protocol level doesn’t need any change to perform the communication.

Once the file config.xml has been created, IS is able to run and start the communication of both DDS Worlds.

$ integration_service config.xml

Creating new routes

Integration Service supports several connectors at the same time, so it could be possible to create connectors to bridge more than two DDS Worlds.

_images/DDS_ROUTES.png

Domain Change Example

This example shows how IS can communicate two participants that belong to different domains. IS must be already installed to execute the example.

To properly execute the example, it’s mandatory to compile it from the domain_change example location.

Linux:

$ mkdir build
$ cd build
$ cmake ..
$ make

Windows:

$ mkdir build
$ cd build
$ cmake -G "Visual Studio 14 2015 Win64" ..
$ cmake --build .

The compilation will generate an example application named DomainChange in the build directory. After executing DomainChange as a publisher, it will create its participant in domain 0, and after launching DomainChange as a subscriber, it will create its participant in domain 5.

The command to launch DomainChange as a publisher is:

$ ./DomainChange publisher

And to launch it as a subscriber:

$ ./DomainChange subscriber

As both instances are bound to different domains, the applications will not communicate. But once after launching IS with the config.xml that comes with the example, both DomainChange instances will begin to communicate.

In another terminal:

$ cd <path_to_is_source>/examples/domain_change
$ integration_service config.xml

This schema shows the internal flow of this example:

_images/DomainChange.png