For many software developers, the differences between a mutex and a semaphore is murky at best. This post summarizes and links to several recent articles that clarify the situation. More…
DDS is popular, and addresses a number of important use cases that are not addressed by other specifications, but that doesn’t mean it’s perfect. The DDS community — including both customers and vendors — is active within the OMG to address additional areas in need of standardization. I thought I’d share one of those areas now.
One of the really powerful things about DDS is that it brings to distributed systems the same kind of type safety that you’ll find in local applications. In addition to reducing errors, this deep knowledge of data types can improve performance and resource usage by reducing the number of data copies in the system and easing integration with other field- and type-aware technologies, including relational databases and even Microsoft Excel.
But as systems evolve over time, type definitions can evolve too, and it’s important that applications that are already deployed don’t break as the types used by new applications change. It’s also desirable to ease the development of infrastructure or cross-cutting components — like tools, recorders, generic data routing and transformation facilities, and others — that shouldn’t be tied to specific data types. DDS users have been solving these problems in a variety of ways for some time, and some implementations address them already, but it’s time for a standardized solution.
To that end, the OMG is working on a new specification, Extensible and Dynamic Topic Types for DDS, that will provide additional capabilities for the following:
- A clarified and extended type system that incorporates keys and extensibility as first-class concepts
- An API for the definition of new data types at run-time without code generation
- A reflective API for the construction, inspection, and manipulation of data samples based on dynamic type definitions
- The ability to define data types declaratively using not only OMG IDL but XML and XML Schema (XSD) as well for easier integration with enterprise systems
The proposed specification will be discussed at the OMG Technical Meeting next month and some outstanding open issues addressed. I expect the proposal to be voted on and approved at a subsequent meeting not far in the future.
If your organization is an OMG member, you can access the in-progress specification proposal documents yourself.
I’ve been having a problem with my car, so I brought it in to the shop today. (No, this is not a parable invented for the purpose of this post. This is a true story, I promise.) I brought the problem to the mechanic, who said, “It could be that your [part] is broken. The [part]s are along the back wall; you can buy one at the register there, then bring it around to me, and I’ll put it in for you.”
I don’t know a thing about cars, so it seemed to me that there was a flaw in this plan. More…