Now is the Time to Migrate from PrismTech OpenSplice to RTI Connext DDS.
Written by Gerardo Pardo-Castellote
January 18, 2016
With the recent acquisition of PrismTech by the Taiwanese company ADLINK, we are seeing increased demand for porting from OpenSplice to RTI Connext DDS. One of the benefits of going with a standard like Data Distribution Service for Real-Time Systems (DDS) is that you have options if your middleware supplier becomes unreliable for any reason. That's why the DDS community went to so much trouble to develop more than just a wire protocol standard. The DDS specification also includes API definitions, with the explicit goal of making it easier to port.
In particular, DDS specifications include both a PIM (platform independent model) and a set of language PSMs (platform specific models). The PIM defines all the important user-visible API concepts including the DDS Entities (DomainParticipant, Topic, Publisher, Subscriber, etc.), their operations and behavior, the QoS, the listeners, and so on. All DDS implementations use the PIM. That means that the structure and major options in your code will translate unchanged to a different DDS implementation.
The PSMs are much newer and they are only unambiguously defined for C++ and Java. Other programming languages come from the IDL-derived mappings (also standard). If you used one of the new standard language PSM APIs, it's even easier to port your application. Even if you didn’t, the common PIM makes it a straightforward process. Of course, in general, there are some differences between versions, both API variability and "non standard" options, features, and configuration. Still, compared to porting to a new middleware architecture, the work required to port is minimal.
How hard is it to port an existing application from OpenSplice DDS to the RTI Connext DDS in practice?
It's not trivial, but it's not that bad, either. One significant difference between these two SDKs is in the IDL syntax. Although most of the IDL syntax is identical, there is a difference in how “key attributes” are indicated. Connext DDS uses the DDS-XTYPES standard format consisting of a “
@Key” annotation placed inside a comment. OpenSplice uses a (non-standard) “
#pragma keylist” directive. We can see this difference in the example below.
|OpenSpliceDDS IDL||Equivalent Connext DDS IDL|
The first step in the migration is to modify the IDL files replacing
#pragma keylist with the
//@Key annotation, as shown above.
Once the IDL file(s) have been migrated, the rtiddsgen tool can be used to generate all the network marshaling/unmarshaling code. This allows the data to understood by any computer, independent of processor architecture, operating system, and programming language. The rtiddsgen tool is included with the Connext DDS SDK. In addition to generating the network marshaling code, rtiddsgen can generate example code and makefiles / build projects for the programming languages and platforms of your choice.
Beyond this there are a few application code edits that may be required. These affect the initialization of the TypeSupport, the use of the ReturnCode_t type, the use of the length() operation on types String and Sequence, and the way sequences are passed to the DataReader read/take operations.
RTI has experience doing this! Some RTI customers, including many of our largest and happiest customers, started with OpenSplice before they discovered the performance, quality, tools, and top-flight support from RTI. So, before you start this effort, contact us. We have a migration SDK including compatible headers, examples, and more. Better yet, we can offer you a cost-effective service to help you transition quickly and correctly.