A new family member: RTI Queuing Service
Written by Javier Povedano Molina
August 10, 2015
Hey, have you heard the news? RTI is glad to announce a new member in the Connext family: RTI Queuing Service. It brings a bunch of cool new features to satisfy more use cases.
With the rise of cloud computing and Software as a Service (SaaS), queuing services have become more popular in recent years. The main purpose of queuing services is to provide a model in which a message is delivered to only one recipient based on certain criteria When using the queue model, message generators (Producers) rely for the delivery of messages on a broker, which delivers messages to Consumers based on predetermined delivery strategy (for example, round robin). This approach makes queuing services the best candidate for load balancing and dispatching tasks among consumers.
Until the arrival of RTI Queuing Service, DDS Connext product family was more focused on publish-subscribe and request/reply scenarios. That doesn't mean it was not already possible to perform one-to-one communications using the request/reply API or even implement round-robin delivery strategies at application level. The difference is that now, with Queuing Service, things become easier: users don't have to worry anymore about implementing their own scheduling/dispatching strategy.
Apart from the one-to-one communication model, RTI Queuing Service brings a lot of new and exciting features and capabilities:
First, it is built using regular Data Distribution Service Topics, so you can still use the same standard API to communicate with Queuing Service including its rich set of Quality of Service (QoS) settings. The use of Connext DDS also brings another advantage: users can use existing Connext tools and services to communicate with Queuing Service.
Second, to make things more natural to users familiar with Queuing Services, RTI also provides a C# wrapper API based on introducing four new entities that are closer to message queuing concepts: QueueProducers, QueueConsumers, QueueRequesters, and QueueRepliers.
Third, it provides a REST-like remote administration API to inspect the status of the queues and samples. With this API, users will be able to create/delete queues, inspect their contents, access stored samples and their delivery status, and flush queues remotely.
Fourth, it provides an extra level of reliability thanks to its persistency capabilities. RTI Queuing Service offers persistence modes that allow undelivered samples to survive system crashes. With this mode, messages are saved on disk until they are delivered and acknowledged by a consumer, so they can be redelivered when the system is restarted after a failure. In addition, the persistent mode also allows the current configuration to persist on disk, so queues created remotely won't be lost if the system is restarted.
Fifth, it provides a one-of-a-kind replication mechanism to support High Availability (HA) scenarios. When using replication, queues and samples are automatically replicated through multiple RTI Queuing Service instances working in coordination, so in case of failure, another replica can continue the delivery of samples to consumers seamlessly.
With all these capabilities, RTI Queuing Service has all the ingredients to satisfy use cases where the load-balancing and round-robin message distribution are important.