Using XML input/output data with RTI DDS

Hi Ryan,

I'm an xml guy.  I've worked at both RTI and Altova GmbH (XMLSpy).

I've written code that did similar.  Instead of using rtiddsgen however, I used the DDS discovery protocol, and DynamicData, to generate an XSD file at runtime.  Given my background, this just seemed the easier way to do it.

With the XSD I would use XMLSpy to generate a binding that allowed me to ingest XML and write DDS.  I used DynamicData to capture instances and write them as XML, because then I could inject faults, etc into the XML and write it back out.  Note that this is all DynamicData -- I'm not doing anything using IDL-generated Types (except watching for them on the bus and reacting).  The xml-writer would be given an XML file that supplied what topic and type (name) to look for, and when it saw it it would map the XML fields to the samely-named DDS Type fields, and then use a DynamicData writer to send the data.

I also used it to remotely control applications on startup and at runtime, by ingesting an XML configuration file and writing it to the C2 domain (either on demand or on startup and allow persistance to make it available to the remote app when it started). 

So yeah, what you are asking about is quite doable without manually-written glue code or IDL-generated types (you need to manually write the DynamicData stuff, but that's generic).

rip

Hello Ryan, 

I am Gianpiero from the research group in RTI. We have developed an experimental toolkit called RTI Data Emulator Toolkit. It enanches an existing tool called RTI Prototyper and it can be used to 

• accelerate RTI Connext DDS application development
• try out realistic scenarios
• model and test a complex distributed system

The tool comes with a simple UI (Scenario Editor) that helps the user define 'time triggered events' (or tasks) and data triggered events. For each task/event you can associate a function (some code to be executed when the event is triggered) and an instance that can be initialized using the UI. 

The ui tool will then produce an XML file that describe your Scenario. The scenario file can then be executed by a data emulator: a command line tool that will triggere events and execute the associated code. 

If you have time and you are interested, I would love to set up a screensharing conference and give you and your group a short demo. You can contact me by email at gianpiero@rti.com.

Best Regards,
  Gianpiero Napoli
  Senior Software Engineer
  RTI

Hi Ryan,

> Thanks for reponding.  I'm going in with a requirement to have a fully defined IDL as we're interfacing with another group. 

The code I had running didn't use the IDL, it used the representation of the Type on the wire (so even if I didn't have the IDL for a defined type, I was still able to work with the data).  This means that the IDL is a sidebar question.  Once the IDL is processed and you have data flowing, that's when the code became usable.  And if the IDL changed, it just meant I had to run the TypeCode-capture application again, to get the XSD.  Note that the XSD itself was not necessary, but it allowed me to use other (XML-) tools like XMLSpy or MapForce, and to write data generators that emitted valid XML files.

As an aside, using MapForce-generated data conversions in the Routing Service was a cool demo.  I'd written a RS plugin that itself took plugins, and then modified the MapForce templates to generate those plugins directly.  I once built an entire artificial horizon indicator for XPlane ... using the Shapes demo as the visualization part.

> So if I did use dynamic types, it would have to match the types defined by IDL.   Not sure if that's possible since the IDL defines the types in the first place.

When an IDL type is generated, part of the generated info is the TypeCode.  The TypeCode is a binary representation of the IDL -- the IDL itself is not shipped on the wire, the binary representation is.  It is the binary representation that is used by tools like rtiddsspy, record/replay, routing service, etc.  The tooling I wrote just did the same process (at discovery, it would inspect the TypeCode on the wire).  The IDL is just used to get to that point.

The tools would listen to the DDS traffic and could be triggered to start recording (dumping XML of samples) or replaying (writing canned XML samples), as described by Gianpiero above.  What you will get with the RTI tool is probably performance and finer-grained control -- I have never seen performance requirements as being part of the design criteria, because I'm a sales engineer -- let's be honest.  I want to quickly show you that it will work in order to get you to buy it...  Performance and other optimizations are other people's problems.

> Do you have any code you could share with your solution above?  I'm curious how you approached the mapping.

Alas, all that was written as part of my job, which means it belongs to the previous employer.  At most I can gin up an example IDL, and the representative XML file that would have been generated/would be ingestible by the tooling, and then we could talk about how to get to that point.  Rewriting it from scratch is possible, but that would be under professional services, and the previous employer would have to agree.  *looks over at RTI*.  Don't want to step on any toes.

Getting the type info off the wire is described/demo code is available in the documentation, and there may be some code in the git repo/file exchange that gets you part of the way there.

The ShapeType IDL is in the distro, I include it here by reference.  Using that, I would generate

<sample type="ShapeType" topic="Triangle">
    <Color key="true">Yellow</Color>
    <x>128</x>
    <y>268</y>
    <shapesize>22</shapesize>
</sample>

There'd be a wrapper element that provided timing information and trigger info (if it was something to write).  Otherwise the tool would just launch, read the XML file and write the data out on the topic requested (once it had seen that there was someone listening).  I used that for remote application configuration; the remote would simply park on the C2 domain waiting for its configuration changes, while the config writer would come up and (transient local) write all the configurations and then lie dormant.  I would have eventually altered it to watch a specific directory for file changes, and any file that changed would get snarfed and barfed for the remotes to see.

hope this helps,

Richard

(edited to replace generic "Type info" with more correct TypeCode)