posted on Friday, October 16, 2009 - 01:59 pm
When using DDS, do I have to model my domain entities in IDL? And does a compliant DDS implementation have to adopt a code generation approach to create a set of classes for each type the user defines?
In finance, all market data systems I have seen define a wire format that can represent some arbitrary composite type - name-value pairs with possibly support for nesting. This format is either self- describing or requires a data dictionary to interpret it.
APIs for such systems do not need types/classes for each domain entity that is being sent. Rather they have a single "Message" type/class that support get and set of attributes by name ( get("PRICE") rather than a specific method getPrice() ). Furthermore, the types and their attributes can then be loaded dynamically.
Could this be supported within DDS?
posted on Wednesday, December 09, 2009 - 01:06 pm
Does anyone have any comments on my question. In summary,is there a way to use DDS without IDL and without code generators.
The structure of the entities my application might want to subscribe to are not known at build time; they are loaded from some directory service at run-time.