Is the DDS profile pitched at the right level?

[TSMB]

I was at the UK IBM Rational customer day yesterday, and there are quite a few people interested in Rhapsody/DDS integration.

At the moment there's some discussion about the level that the profile is pitched at (i.e. the fact that you have to create your own structs/publishers/subscribers by hand), and some people feel that all this should be auto-generated based on class structure. The main desire behind this is to decouple the system design from the DDS technology.

We (the IBM customers at the day interested in Rhap/DDS) are trying to present a united front on the improvements that are needed, and I wanted to get a feel from other people using the profile on this particular issue.

I personally feel that the level of the profile is appropriate, and that having to create a data structure independent of classes helps to design a more data centric system, but appreciate that everyone will not share this view - and I am open to any solid counter arguments.

I do, however, feel like the profile does need to be easier to implement - as it feels like hard work building up a system. Also I don't see how the current technique of using structures for the data model will fit in with data inheritance that is coming in with the new x-types standard (which I hear that IBM are thinking about bringing into the profile due to customer interest). Perhaps using specialised class bocks with attributes only would make data model design more user friendly. Perhaps this type of discussion would be better off in a separate thread.

Please share you thoughts and opinions, as we're hoping to start making enough noise for IBM to justify improving the profile.

[IanMac]

I've used the profile. It makes sense if you want to define the IDL explicitly in your model but this would imply a PSM, platform specific model, as DDS is a platform implementation. The value of modelling at that level, i.e. at the implementation level, is what I question.

The purpose of DDS is to distribute data. Data is only part of a model. A model also has behaviours. A PIM, platform-independent-model, is defined with classes (or blocks in SysML). A model should appear the same at either end of the distribution. The provider and consumer should see exactly the same as they would see if talking directly.

In my view it is a waste to spend time modelling the corresponding structs needed to distribute the PIM. The distribution implementation should be generated directly from the classes and interfaces that define it depending on the environment setting, e.g. RTI_VC9. There would need to be rules for mapping the classes/interfaces to IDL but those are easily defined.

The sample I posted on dds-example-t694.html aims to clarify this point. The stopwatch 'service' is modelled but then we have to go to the effort of generating the predictable DDS topic structs.

I'd like to see an SOA profile that allows us to stereotype distribution points. This would need to be coupled with environments that would autogenerate the corresponding carrier implementation. I want to be able to switch my carrier between DDS, MilCAN, CORBA, UDP etc... without having to redo my 'implementation model'. DDS refers to this as a data model but I am suggesting that to be a misleading term.