A growing number of stock exchanges, data aggregators, trading
and investment firms are being challenged with the problem of
distributing ever-increasing message volumes, while at the same
time trying to reduce end-to-end distribution and trading
latency. This problem, further exacerbated by the very nature of
the financial markets - where the right answer delivered too late
becomes the wrong answer, and where the difference of a
millisecond could be worth millions of dollars - is motivating
firms to find new and innovative ways of reducing latency while
simultaneously increasing the number of messages handled per unit
In fact, the need for ultra-low latency and high throughput messaging technologies has been widely accepted and is starting to receive an increase in attention within the industry. Messaging technologies that promise the extra-low latency and high throughput are already available, but a complete solution to the problem requires the provision of low latency and high throughput along with the proper level of control, stability, usability and expressiveness, thus addressing the need for increased performance as well as reduced time to market.
"… as messaging technologies don't live in isolation, it is becoming increasingly important to have seamless and optimised integration with key technologies, …"
Specifically, the real quest is for messaging technologies that
can distribute from hundreds of thousands to millions of messages
per second, while maintaining extra-low and predictable latency,
while also providing:
• Stability in overload conditions;
• High availability;
• Control over the latency/throughput trade-off;
• Support for traffic engineering - such as hardware filtering, traffic shaping and traffic prioritisation;
• Data persistence; and
• Event processing - such as content-based distribution, data correlation and data aggregation.
Moreover, as messaging technologies don't live in isolation, it is becoming increasingly important to have seamless and optimised integration with key technologies, such as database management systems (DBMS) and complex event processing (CEP) engines. Data distribution service (DDS) for real-time systems, a standard-based publish/subscribe middleware defined by the Object Management Group1, optimally addresses these challenges by providing: a very powerful data distribution and event processing model; extremely high performance; and a rich set of non-functional properties fully tunable by means of a set of Quality of Service (QoS) policies, used to control properties such as resource usage and reservation, data prioritisation and data availability.
DDS for real-time systems
The data distribution service (DDS) for real-time systems2 is a standard data-centric, topic-based publish/subscribe middleware that has been designed to address the data distribution challenges of highly distributed real-time business- and mission-critical applications. Over the past few years, DDS has extensively and successfully proved itself in fields such as air traffic control and management, combat management systems, large-scale supervisory control and data acquisition, and financial services.
As shown in Figure 1, DDS is a publish-subscribe technology based around the simple yet very powerful concept of a fully distributed global data space in which publishers and subscribers asynchronously produce and consume data. The global data space can be further divided into partitions in order to segregate information as well as traffic flows. When compared with other publish/subscribe technologies, DDS stands out because of: its powerful support for data modelling, event filtering and processing; and its support for a very rich set of QoS policies which allow it to configure the most important properties of data distribution, such as its temporal properties, its availability and its presentation. In particular, the ability to support data modelling, event filtering and processing, and network traffic engineering is key to DDS's successful application in the financial markets.
DDS perfectly blends and extends the most useful features found
in real-time messaging middleware and relational databases. From
real-time messaging middleware, DDS draws efficiency in data
distribution, low latency, predictability and throughput. From
relational databases, it draws the ability to define relational
data models and operate on them via SQL92 expressions to specify
content-based subscriptions, join, projection, filters and
queries (see Figure 2). DDS allows the application programmer to
create object views from a relational information model. This
ensures that the applications logic can focus completely on the
business problem, while delegating to the middleware the
mechanics of data distribution. Another typical use of the
object-oriented view is to reconstruct and manage relationships
out of the messaging data, perform complex filtering and
correlation. As shown in Figure 2, DDS can perform data filtering
and correlation by relying on either SQL92 expressions or
All these capabilities are provided via a fully distributed architecture that ensures performance, predictability, availability and scalability, and which can be controlled and fine-tuned by a set of QoS policies that allow traffic prioritisation, traffic shaping, hardware and software filtering, and persistence.
The native support for relational information modelling makes it very efficient to seamlessly integrate DDS implementations with databases. Moreover, the combination of data filtering (by means of content-based subscriptions) and event processing (by means of filter-objects) allows the execution of arbitrary complex event filtering and correlation in the middleware, thus providing the application with only the events it is really interested in.
DDS and complex event processing
Complex event processing is being used in a growing number of financial markets applications. CEP engines are being used to implement growing portions of trading algorithms, for example, and for checking in real-time regulatory compliance. CEP engines that are integrated into trading systems are often flooded with events fed from multiple sources,
such as databases and messaging middleware, and then asked to extract complex event patterns from this incoming flood. Although this approach seems to work, the problem is that some, perhaps many, events reaching the CEP are not necessarily needed, and could be pre-filtered to improve overall throughput.
With its support for relational data modelling, object views and filtering, DDS is ideally suited to work in combination with CEP. First, the DDS is able to feed CEP engines with either relational data, or objects, or both (as shown in Figure 3). If, for example, the CEP engine works with Java or C++ objects, the DDS object-view could be used to automatically reconstruct Java or C++ objects out of the relational data streamed from publishers, or from a DBMS (alternatively, the CEP engine could be fed with relational data). Second, some of the filtering and correlation can be pushed from the CEP engine to the DDS to optimise overall resource usage, as well as to improve the total number of relevant messages processed by the CEP engine per unit of time. Third, the DDS can be used to publish complex events and present them to other applications.
Gaining control via Quality of Service
To support mission- and business-critical systems, any middleware must control and optimise its use of resources, such as network bandwidth, memory and CPU time. As such, DDS is equipped with QoS policies that provide firm control of properties such as data timeliness, priority, reliability and persistence. Two key sets of DDS QoS policies that are particularly relevant to financial markets applications are those controlling data timeliness and data availability.
The following QoS policies control the timeliness properties of distributed data, the trade-off between latency and throughput, and data prioritisation:
• The LATENCY_BUDGET QoS policy provides a means for applications to inform the DDS of the urgency associated with transmitted data. The latency budget specifies the time period within which the DDS must distribute the information. This time period starts from the moment the data is written by a publisher until it is available in the subscriber's data-cache ready for use by reader(s).
• The TRANSPORT_PRIORITY QoS policy allows applications to control the importance associated with a topic or with a topic instance, thus allowing a DDS implementation to prioritise more important data relative to less important data.
• The DEADLINE QoS policy allows applications to define the
maximum inter-arrival time for data. DDS can be configured to
automatically notify applications when deadlines are missed.
These QoS policies make it possible to ensure that the system is tuned to operate in the right latency/throughput trade-off point and that important data is always able to pre-empt less important data, thus ensuring that, even in overload condition, the temporal properties of critical data are preserved.
"… middleware must control and optimise its use of resources, such as network bandwidth, memory and CPU time."
The following QoS policies control the availability of data to
• The DURABILITY QoS policy controls the lifetime of the data written to the global data space. Supported durability levels include:
• - (1) volatile - which specifies that once data is published it is not maintained by DDS for delivery to late-joining applications;
• - (2) transient local - which specifies that publishers store data locally so that late-joining subscribers get the last published item if a publisher is still 'alive';
• - (3) transient - which ensures that the global data space maintains the information outside the local scope of any publishers for use by late-joining subscribers; and
• - (4) persistent - which ensures that the global data space stores the information persistently so it is available to late joiners even after the shutdown and restart of the system.
• The LIFESPAN QoS policy controls the interval of time during which a data sample is valid. The default value is infinite, with alternative values being the time-span for which the data can be considered valid.
• The HISTORY QoS policy controls the number of data samples (i.e. subsequent writes of the same topic) that must be stored for readers or writers. Possible values are the last sample, the last n samples, or all samples.
These policies control the degree of time decoupling between publishing and subscribing applications, as well as the historical data that the middleware should keep on behalf of the application. Other QoS policies exist to control both the replication of publishers (thus greatly simplifying the implementation of Hot-Swap and Hot-Hot replication styles) and the use of computational resources, such as main memory and buffer sizes.
out for its powerful support for data modelling, event filtering
and processing, …"
QoS-driven traffic engineering
In addition to the DDS QoS policies that control the temporal
properties of data, it is worth investigating how these policies
are leveraged by advanced DDS implementations to enforce specific
network traffic properties:
• Latency/Throughput Trade-off - Advanced DDS implementations rely on the LATENCY_BUDGET QoS to bundle data across topics and applications to ensure optimal throughput and reduce CPU utilisation.
• Data Prioritisation - The TRANSPORT_PRIORITY QoS is used in combination with network channels to enforce message priority even on non-priority-preserving transports, such as the TCP/IP or UDP/IP.
• Traffic Shaping - For each channel, it is possible to define the traffic profile to ensure that the network utilisation never exceeds a user-specified value.
• Traffic Partitioning - DDS partitions are mapped to IP
multicast addresses to segregate different traffic flows and rely
on hardware filtering capabilities provided by modern routers,
switches and network cards.
The combination of these architectural features and QoS ensures that DDS applications have full control over the characteristics of generated traffic. As a result, the system can be properly tuned and configured to operate at the right performance point, while retaining stability during overload conditions.
Data distribution through power and control
Designed to address the data distribution challenges of mission-
and business-critical systems where the right answer delivered
too late becomes the wrong answer, data distribution service
(DDS) for real-time systems represents a leap forward with
respect to existing publish/subscribe technologies. DDS stands
out for its powerful support for data modelling, event filtering
and processing, and its support for a very rich set of QoS
policies which allow it to configure the most important
properties of data distribution. DDS implementations have also
proved to be extremely high performance, delivering
ultra-low-latencies and extremely high throughput. DDS provides
the power and control for addressing the most challenging data
distribution problems faced in the financial market.
Firms that should be seriously consider deploying DDS include:
• Automated trading firms, for upgrading their internal data distribution and taking advantage of the event filtering and processing capabilities of DDS;
• Stock exchanges, for internal data distribution and QoS-enabled data distribution to aggregators and trading firms - allowing the enforcement of service level agreements;
• Feed handlers, for dealing with massing message volumes, efficiently aggregating and filtering them, while minimising latency;
• Large banks which are struggling to maintain performance in their back-ends; and
• Risk management solution providers that want to achieve better performance while at the same time relying on the powerful programming model provided by DDS's object views along with event filtering and processing capabilities.
1. OMG is an international, open membership, not-for-profit
computer industry consortium that develops enterprise integration
standards for a wide range of technologies.
2. See the following for more details: "Data Distribution Service for Real-Time Systems Specification" (www.omg.org/docs/formal/04-12-02.pdf); OMG DDS SIG Portal (http://portals.omg.org/dds); and OMG DDS Forum (www.dds-forum.org).