We’ve been working busily away this year on trying to make it easier to get started with RTI Connext DDS. Anybody who uses RTI Connext DDS knows that it’s a powerful tool – but, like any powerful tool, you can do amazing things when you use it effectively or you can cause yourself trouble by using it the wrong way.
Of course, what is the “wrong way?” Nobody wakes up in the morning thinking about the effects of creating DDS entities in the write() loop. (Okay, I’m lying – I can think of at least one person who wakes up thinking about creational patterns for DataWriters and DataReaders.) But the key point is that with a tool as powerful as RTI Connext DDS, it’s not always obvious what the best way is to design your application or architect your system.
Sometimes design tradeoffs make themselves obvious immediately, and sometimes they are subtle and you only discover them when you start to test high-performance or large-scale systems. We don’t want you to discover these best practices accidentally – we want you to be able to get started with the confidence of knowing that you are building your applications and your system the right way.
So, we’re consolidating a set of Best Practices Documents, and adding them to the Community Portal. The first documents we have added are concerned primarily with application design – RTI Connext DDS best practices for object creation, object deletion, for reading data, and for writing data.
Over time, we are going to be adding new architectural patterns to model data that goes over the network, for people who are concerned with the larger system architecture.
And the best part? You don’t just have to learn from our experiences – if you join the community, you can comment on the documents we create, and contribute your own best practices.
Building a real-time distributed system is a hard problem – but we’re doing everything we can to make it easier.