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 | Leave a 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 »
May 5, 2009 by Rick Warren
If you’re serious about the performance of your distributed system, you probably read with interest the performance claims made by network middleware vendors. And if you’re a network middleware vendor, you’ve probably published your share of performance claims. (RTI has comprehensive performance numbers available for both our DDS and JMS APIs.) But in order to know which claims are meaningful — and more importantly, which are useful to you — it’s important to understand what you’re reading. In the words on one of my coworkers, “many apples are compared to rhinoceroses.”
Continue Reading »
Posted in Best practices | 2 Comments »
May 1, 2009 by Jan Van Bruaene
Leading the support team at Real-Time Innovations, I get to experience first hand how our customers are using our middleware. The type of questions range from simple how-to questions to more involved inquiries on recommended ways of implementing a particular communication pattern. And of course there is the occasional defect. In my maiden blog post I wanted to highlight existing resources to get answers to some of these questions.
Continue Reading »
Posted in Best practices, Product news | Tagged Debugging | Leave a Comment »
April 28, 2009 by Supreet Oberoi
After spending years developing enterprise application and platforms, moving to developing technologies for the “edge” with real-time needs has been very refreshing. One of the more interesting aspects of distributed application development is to be aware of the physics involved in the deployment. Any signal experiences a propagation delay resulting from the finite speed of light, which is about 300,000 kilometers per second, or 1 nanosecond per foot. A signal in a cable or optical fiber travels approximately 2/3 the speed of light in a vacuum. This gets more complicated when routers, satellite links, and other variances in the network topology are introduced.
Continue Reading »
Posted in Applications, Best practices | Leave a Comment »
