XML-Based application configuration and prototyping 3

RTI Connext™ opens a new horizon to make life easier for users. Proof of that is the new and experimental XML-Based application creation feature that allows defining the static part of a DDS system in a XML configuration file. By means of a new set of APIs, all the entities defined in the configuration file can be created automatically at run time so that they can directly be retrieved and used.
XML-Based user perspective
For example, let’s consider the following Participant configuration:

<participant_library ="participantLibrary">
    <domain_participant name="participant">
        <register_type name="myType" type_ref= "typeLibrary::myType">
        <topic name="myTopic" register_type_ref="myType">
        <data_writer name="writer" topic_ref="myTopic"/>
        <data_reader name="reader" topic_ref="myTopic">
            <datareader_qos base_name="qosLibrary::reader_qos">
        </data_reader>
    </domain_participant>
</participant_library>

Essentially it describes a DomainParticipant, which has a Topic, a DataWriter and a DataReader. The following C++ code would create a DomainParticipant from such configuration with entity name "MyParticipant":

DDSDomainParticipant * myParticipant = DDSTheParticipantFactory->create_participant_from_config_exp(
    "participantLibrary::participant",
    "MyParticipant");

The first consequence as result of this functionality is that users don’t need to create programmatically a DDS system anymore. Instead, the system is described in a more readable and understandable format that is interpreted by RTI Connext hence users only have to focus on how to use the entities in such system. For instance, from the previous example, the C++ code to retrieve the DataWriter is as follows:

DDSDataWriter * writer = myParticipant->lookup_datawriter_by_name_exp("writer")

This workflow significantly decreases the deployment time, mainly as the system size increases -it also decreases the number of “copy-and-paste” that programmers love to do with repetitive tasks. In addition, describing a system in a configuration file serves as a mechanism for system designing as well as sharing with other members of the team.

In this context, RTI Connext furthermore helps out to test DDS communications with the also new and experimental utility RTI Prototyper: It is able not to only create the entities but to automatically write and read data on them, providing a zero-coding solution for running DDS

The entry point of these features begins with RTI Connext 4.5f. The default package contains the new set of APIs whereas RTI Prototyper and detailed documentation can be obtained from the downloads section of the RTI Community and Research Portal – everything is contained in the Prototyper package.

3 comments

  1. Pingback: Climbing Mountains « Blogs from RTI

  2. Pingback: Stable as a rock « Blogs from RTI

  3. Pingback: Dynamically Scriptable Distributed Components in Lua using DDS | Blogs from RTI

Submit a comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s