Define Topic Names in a Single Shared Location

Submitted by rose on Fri, 06/21/2013 - 14:38

Defining Topic names in source code in each application is readable in example code, but is not ideal for a real system. Each duplicate Topic name string added to the code base increases the likelihood of error and decreases maintainability. You can spend significant time debugging problems such as the case-sensitivity of those names.

topic = participant->create_topic("AirTrack", type_name, …);

 

One sensible place to define Topic names is in configuration files that are committed as a part of your project.  The key is a layer of indirection to reference a single string in any location where a Topic name is used. 

topic = participant->create_topic(AIR_TRACK_TOPIC, type_name, …);

 

Note that in a real system, your Topic name usually will not match your type name.  Your Topic name should always represent the meaning of your data, regardless of the type structure that you use to send your data.  It is also common for multiple Topics to use the same type, so restricting your Topic name to be the same as your type name artificially constrains your system.

In versions 5.0.0 and higher, you can define your Topic names in XML.  Note that in 5.0.0 this requires you to use experimental APIs to create your DomainParticpants, DataWriters, and DataReaders.  There are examples of using these APIs available with your installation, located in: NDDSHOME/example/[language]/HelloWorld_xml_compiled

<domain_library name="DomainLibrary">
    <domain name="DataDomain" domain_id="0">
        <topic name="AirTrack"
               register_type_ref="TrackType"/>
    </domain>
</domain_library>

  

Another option is to define your Topic names alongside your types as constant strings. For example, here are equivalent definitions in IDL and XML:

IDL

const string AIR_TRACK_TOPIC = "AirTrack";

XML

<?xml version="1.0" encoding="UTF-8"?>
<types xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
       xsi:noNamespaceSchemaLocation="(ndds home directory)/resource/rtiddsgen/schema/rti_dds_topic_types.xsd">
    <const name="AIR_TRACK_TOPIC" type="string" value="AirTrack"/>
</types>

 

The data types you use are clearly part of the data interface for your application. Less obviously, the Topic names you use are also part of that interface. The benefits of having a clearly defined data interface include easier maintainability, interoperability, and integration between applications.

 
Tags: