How to model in idl for DDS

Question

I am new to DDS and IDL, and i hope that somebody can provide some advice on how to model the following in IDL.

This is based on a model from a OO perspective, and it is just intended as a quick example:

And this is my initial datamodel in IDL - is done correctly? How do I "model" inheritance and dependencies in IDL? a lot of the examples online are very simple - too simple the ones I have found...

module test{
struct carpool{
    long id; //@key
    string name;
    sequence<car> cars;
};

struct car{
    long id; //@key
    string color;
};
////the following inherits from car
struct sedan{
    string extra_equipment;
};

struct station_car{
    integer number_of_doors;
};
};

This is just a made up example of inheritance, and properly not the best ;o)

Is this correct or is there a better way of modelling the same - can anyone provide a link to a good "HOWTO" for working with IDL for DDS? Note: I am working with RTI Connext DDS

Answer 1

There are two aspects in your IDL that deserve some attention.

First there is the inheritance mechanism, which was traditionally not supported by DDS, but is now by virtue of the Extensible and Dynamic Topic Types specification. The snippet below shows how to use that. However, whether or not you actually need that inheritance mechanism depends on how you are going to use the data. Do you ever intend to subscribe to the base-class car, or will you only subscribe to the derived classes? In the first case, you will need the true inheritance. In the second case, you can model inheritance by means of embedding the car base-structure into all derived cars.

Then there is also the matter of your one-to-many relationship between the carpool and car classes. Using a sequence is typically not the best approach. Suppose that you add single car to your carpool, then as a result the whole carpool structure, with all its cars, will need to be republished. This might be what you want, but typically, it is better to use a "foreign key" on the car class to refer to the carpool it belongs to. This is much like the way regular database designs work as well. With this approach, the application is responsible for re-constructing the full carpool with the cars by relating them via the carpoolId attribute. Updates to the carpool then happen via the car structures. This does require the car to be aware of the carpool it belongs to though.

Possible example snippet:

module test {

  struct carpool {
    long   id; //@key
    string name;
  };

  struct car {
    long   id; //@key
    long   carpoolId; // refers to carpool this car belongs to
    string color;
  };

  struct sedan : car {
    string extra_equipment;
  };

  struct station_car : car {
    integer number_of_doors;
  };
};