The diagram below shows the complex architecture and message flow of a sample SDP.

• Low latency messaging for quote distribution (red) − Historically, these messaging systems have often been multicast-based in order to satisfy requirements for high rate, low latency and fanout.
• Persistent messaging for order flow (green) − These messaging systems are typically broker-based to provide a guarantee of delivery. 
• HTTP/Web Messaging (gold) − These are typically gateway type products with varying capabilities. Some of these “streaming servers” are simple HTTP gateways, while others provide basic messaging capabilities.

Problems with Multi-platform Messaging Infrastructure

The implementation and integration of these disparate systems introduces technical and operational challenges including:

• It takes a lot of work to tie the various messaging systems together. For example, the web distribution system must be bridged to the internal real-time and guaranteed messaging systems, which requires API/Transport level integration, mapping of topics and subscriptions, and message payload conversion.
• Each messaging system has its own API and interaction idiosyncrasies that must be mastered by the various developers on the project – often requiring applications to use two or more messaging APIs in the same application. This adds cost and complexity to the initial development and ongoing support of applications.
• The resulting system, once built, is complex and fragile due to the many integration points and information mappings. Each integration point must allow as much throughput and resiliency as the messaging or streaming systems it connects.
• Many internet streaming products operate with orders of magnitude higher latency (milliseconds) than messaging to financial applications (microseconds). That’s before considering the latency introduced by the Internet.
• Scalability can be a greater challenge in some cases. For example, if Streaming Text Oriented Message Protocol (STOMP) or a similar protocol is used to communicate to the RIAs and each STOMP connection to a GUI is mapped to a JMS or other connection into the internal messaging system, then the internal messaging system must also scale along with the number of external internet clients.
• The operations challenges are also significant: provisioning, monitoring, troubleshooting and capacity planning systems must be developed and the operations team must be proficient at managing at least three different messaging systems – some of which may be multicast, some are broker based. Then there is the qualification and rollout of periodic upgrades to each of these systems.
• Dealing with internal users and applications is now completely different than dealing with external users and RIAs unless internal users also connect via the web distribution layer, which then places additional demands on the web distribution layer.
• Every aspect of the infrastructure, such as the difference in high availability architectures, security and monitoring, multiplies the complexity of the system since it is typically completely different for each of the three messaging systems.

The Advantage of a Unified Platform

An integrated messaging platform that meets all of the above-mentioned messaging requirements can significantly reduce the cost, complexity, risk and time-to-market of deploying and running an SDP.

The figure below shows an architecture for the same FX SDP as above running on one messaging platform that addresses all three requirements. Note how much less complex the system is in terms of architecture, infrastructure components, applications and administration.

Pricing data flows from ECNs to the internal and external traders via low latency reliable messaging represented by red arrows, and orders flow to the trading platform and back-office through the same appliances using guaranteed transactional messaging represented by green arrows.

Such a solution simplifies deployment and operation in three areas:

• Architecture: Handling all messaging requirements with one platform eliminates integration points and reduces the number of moving pieces required for messaging functionality and high availability. 
• Applications: The use of a single API greatly simplifies the development of applications so developers focus on core functionality without worrying about the receipt or delivery of information.
• Administration: System administrators get a single view of the operations and management of the entire platform.

A single-platform approach offers a number of other advantages beyond just simplifying the architecture and operations.

• Higher Performance: Eliminating the integration points between multiple platforms gets rid of the inevitable latency associated with handing messages off from one system to another. Many assume that the internet introduces so much latency that web streaming performance isn’t all that important, but in context of the internal financial systems where speed is measured in microseconds, saving 5-10 or more milliseconds of latency over the web or to internal RIA applications is important for FX and equities trading.
• Messaging Capabilities: A unified system that handles internal messaging and web streaming is usually capable of offering messaging capabilities to the application developer, such as publish/subscribe and request/reply message exchange patterns.
• Scalability: Ramping up multi-platform systems to accommodate higher throughput or a greater number of clients can be complicated, especially because each platform needs discrete connectivity, capacity planning, high availability, redundancy, etc. A unified platform consolidates all of these issues so IT just has to run, support and scale one environment.

Conclusion
Single dealer platforms can give investment banks and sell-side firms a leg up in their own trading activities, in the service they offer their clients, and their overall profitability and competitiveness. The fastest and most cost-effective way to achieve these benefits is by building them on top of a unified messaging middleware platform that meets all of the relevant information distribution requirements.