September 1, 2009 by Rick Warren
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.
Posted in Future directions, Standards | 1 Comment »
July 1, 2009 by Rick Warren
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. Continue Reading »
Posted in Uncategorized | Leave a Comment »
Most of the distributed systems we deal with at RTI have performance constraints at their core. Either the system is pushing the limits of the available resources, or the action-reaction timing is critical for a given event. In other words the constraint might be on throughput or latency (or increasingly latency vs. throughput). In these kinds of systems persisting data is a real challenge. In many systems it is becoming a requirement that the distributed data is persisted. Take for example flight systems and automated trading systems, where persisting data is necessary to adhere to regulatory demands. At RTI we have set out to make persisting distributed data as minimally intrusive, performant and configurable as possible.
Continue Reading »
Posted in Best practices | Leave a Comment »
June 16, 2009 by Supreet Oberoi
Today’s distributed systems are capable of producing a large amount of information, both on the status of their own components and of external components. The challenge with these systems is not the lack of information, but finding what is needed when it is needed.
With this deluge of information, because of the gap between the large volume of data produced and people’s ability to process the information, operators may even be less informed than before. For the information to be processed correctly, it needs to be integrated and interpreted correctly. In addition, the system must provide the operator with the information in a way that is usable cognitively and physically. The system should be designed in such a way so as to support the operator under dynamic operational constraints. This is what Situational Awareness is about — about knowing what important things are going around you.
Continue Reading »
Posted in Applications | Leave a Comment »
June 3, 2009 by Rick Warren
You may have heard system architects talking about “data-centric design,” or you may have attended an RTI training class and heard one of us use that term. Is data-centricity just a new buzzword to make messaging seem cool again? No indeed!
Message-centric design and data-centric design are similar, but they also differ in important ways. Let’s start with some terminology. There’s a reason why DDS says “sample” where JMS says “message”: those words are intended to suggest a different mental model to you. Continue Reading »
Posted in Best practices, Standards | 1 Comment »
So you have a distributed system and you’re happily sending data between nodes in your system. The consumer applications are consuming the data your producer applications are producing, and everything is running smoothly. Now, that doesn’t sound like any system you know does it? Distributed systems are by nature complex. Nodes and applications are not straight producers or consumers; they’re a bit of both. And there’s always some resource contention. This is where Complex Event Processing (CEP) comes on the scene. CEP allows you to run queries on streams of data in real-time, either transforming the data or triggering alerts based on data content. Let me explain by talking about a couple of use cases.
Continue Reading »
Posted in Best practices, Ecosystem | Leave a Comment »
May 21, 2009 by Bert Farabaugh
Anyone who has obtained a software product knows that there will be a learning curve that needs to be traversed before they can become proficient at using that software. This is also sometimes called the “Out of box experience”. And different software products have very different “Getting Started” practices for their software.
For infrastructure software, this “Out of box experience” can be a challenging task because a developer has to learn how to take this generic software that can do many things and apply it to solving his/her problems. For software products that provide access through an Application Programming Interface (API), this usually occurs with a general program called “HelloWorld”.
In the realm of a distributed infrastructure this “HelloWorld” basically shows how to publish and receive a simple text message that contains “Hello World!”. Using an application like this is very useful because it shows a developer what the basic minimum steps are to getting an application that can communicate. And this does provide a little context on how to use their new API. What this doesn’t do, however, is that it doesn’t show them how to get their application specific messages
Here at RTI, we take the concept of “Getting Started” to a new level with our Data Distribution Service (DDS) product. Continue Reading »
Posted in Best practices | Tagged Getting Started | Leave a Comment »
May 14, 2009 by Jan Van Bruaene
When I moved to the US a decade ago, Home Improvement was a popular television sitcom, starring Tim Allen as Tim the tool man Taylor, a host of a made up home improvement show.
Among the support team, when we learn about a new debugging tool, we frequently joke about ‘our network debugging tool belt’. Over the years, this tool belt has grown to a nice variety of debugging tools, especially when you include platform specific debugging tools. We currently support a great variety of platforms: from the enterprise platforms (Linux, Solaris, Windows) to various embedded platforms, (including VxWorks, LynxOS and Integrity).
Below is a list of the tools we frequently use on support. I am leaving out platform specific tools, tools to monitor how a particular network stack is processing network traffic (e.g netstat) and general operating system debugging tools (vmstat, cpustat, lsof, gdb, strace etc.).
Continue Reading »
Posted in Best practices | Tagged Debugging | Leave a Comment »
May 11, 2009 by Rick Warren
A lot of people who have never used RTI’s infrastructure ask, “How do I prioritize my messages so that more important messages arrive before less important ones?” Yet almost no one worries about that once they’ve actually used our software. Why is that?
The reason is that people coming from competing solutions are used to having lots of intermediate hops in between data producers and data consumers. When the producing application sends data, maybe it goes to a per-node messaging daemon, maybe it goes to a central server; the process is then reversed on the way from the daemon or server to the final subscribing application. All these extra message queues have to be ordered somehow, and people want to know that the ordering is under their control. That makes perfect sense.
Continue Reading »
Posted in Best practices | Leave a Comment »
May 7, 2009 by Jan Van Bruaene
In my previous post, I detailed two resources for answers to commonly asked questions or to look up specific known issues. Of course that requires you to at last know what to ask or look for. Before getting there you probably want to find out more about how the middleware is doing, or in the event of a defect, contextual information to provide to the RTI support team. Other than a reproducer, the following configuration, error and status information makes life for a support engineer so much easier.
Continue Reading »
Posted in Best practices | Tagged Debugging | Leave a Comment »
