The decision to use keys (or not) should not be driven by Qos concerns, but rather by the requirements of your information.
What does the information you distrubute represent? If it differentiates between different 'instances' of the same type (like you may have different object instances of the same class in an OO-language), you might consider using keys.
Suppose you want to model a thermostat, that measures room temperature and distributes it to your heating system. The thermostat can make different measurements at different moments in time, but everytime a 'sample' represent the current temperature in that particular room. If that thermostat is the only thermostat you have (let's say in your living room), you could say that all measurements represent the state of the same instance, which is the temperature of the living room, but at different moments in time. In OO-terms, you would have a single object instance (.e.g. livingRoom), whose state would be updated after each new measurement.
Now suppose you add thermostates to all your other rooms as well and distribute those to your heating system. Every sample still represents the current temperature of a room, but different samples might represent the temperature of different rooms. In OO terms, you would now instantiate different objects: one for each room (e.g. bedRoom, kitchen, etc.). This way the heating system can differentiate between the different room temparatures and account for them individually. (e.g. dedide to turn up the heat in the living room, but not in the kitchen).
In a simple messaging middleware all data is delivered in a 1 dimensional FIFO queue, and your heating system will need to read each sample, classify its room, and take the appropriate action. It is possible that the FIFO queue contains several samples of the same room if the thermostat is writing them faster than that the heating system is consuming them.
In DDS, you would typically give each room a unique ID, and then use that ID as a key in your information model, so that each thermostat measurement uniquely identifies the room from which it originates. (This is very similar to how you model information in Relational Databases). The DDS can now distinguish between samples from different rooms, and replace old room temperatures with newer ones from the same room. This way, the heating system can just assume that he always reads the latest temperature from each room.
QosPolicies may infuence whether the DDS should replace old samples with newer samples (KEEP_LAST, which is the default behaviour for the HistoryQosPolicy), or whether no samples are ever replaced by the middleware (KEEP_ALL, which is an alternative setting for the HistoryQosPolicy). In the last case, the DDS also behaves like a FIFO queue, but then on a 'per instance' basis, i.e. every instance will have its own separate FIFO queue).
It is easy to conclude that when you don't use keys and use a KEEP_ALL policy, your DDS system behaves like all other message based middlewares.
Hope this answers your question somewhat.
Regards, Erik Hendriks.
posted on Tuesday, December 01, 2009 - 09:57 pm
Thank you, Erik! Yours and Hans (on OSPL-Dev list) responses are very helpful.