Ushering in the Unified Messaging Platform

History Has Left Us with a Potpourri of Messaging

From the earliest days of distributed computing, the idea that steps in a workflow use a task queue of some kind to pass off information has been a central tenant of information design. Over time, major buckets have emerged, each on their own timelines, and each with a different technology that became the de facto standard.

• Message queuing — Dominated by MQ Series (er… WebSphere MQ), but there have been many imitators along the way: DEC Message Queue, Oracle AQ, Microsoft MSMQ, etc.
• Publish subscribe — Pioneered by Tibco with Rendezvous and its precursors, but also used in SmartSockets, 29West, RTI and others.
• Ultra-low latency — Primarily the same names as publish subscribe, but in a different configuration
• JMS — JMS was the first attempt at an open messaging standard with interoperability defined only at the API level.
• AMQP — A working group that’s defining a standard wire protocol for publish subscribe and message queuing. This is the reverse of JMS as it would focus on multi-vendor interop, but does not (currently) plan to enforce a single API.
• Wide area network — For low volumes, you can use any guaranteed or queue-based messaging to reliably get information across a WAN. For higher volume, most users have custom architectures that batch messages into larger groups and send as either messages or FTP files for greater efficiency.
• Other messaging — You will find a few other messaging types, such as computer to human messaging protocols like XMPP, which was initially developed for use with internet chat programs but has been extended to include additional functionality.

The Messaging World Has Fundamentally Changed

Most enterprises have ended up with a mishmash of all of these types of messaging–often five, ten or even more solutions from a handful of different vendors.  This isn’t usually the result of poor decision making, but of the fact that at the time each one was deployed, it was the fastest, easiest or most reliable way to meet a given requirement. But hardware fundamentally changes what’s possible in middleware.

Today’s limits are either limitations of the interplay between operating systems and software, or the limits of supporting multiple general purpose hardware servers. For any one of these kinds of messaging, hardware leaves these limits in the dust and blows the doors off what’s been possible with software-based solutions:

• Publish subscribe fanout of more than 10 million messages a second (basically saturating a 10 GigE link)
• Fully failsafe message queuing at 130, 000 messages per second
• Ultra-low latency messaging with 25 microseconds of latency and very low jitter
• WAN streaming that exhibits orders of magnitude more throughput than software over the same network

Each one of these represents out-of-the-box performance that surpasses what world-class architects would not be able to get out of software. But what if you could consolidate all of these parallel products into one footprint as well?

All Messaging Under One Roof

The real power of the Unified Messaging Platform is not that it can run circles around software in each of these areas, but that it lets you comfortably use the same equipment for your front, middle and back office capabilities without worrying about one application impacting the performance or stability of another. You don’t build a new IP network for each application, do you? Similarly, it’s time to stop building, scaling and designing redundancy for so many discrete middleware systems.

If you could (over time) replace your MQ and JMS infrastructure, as well as your market data delivery and specialty algo trading infrastructure, in favor of a single network layer that could do all of these better, faster and easier, why wouldn’t you? The ROI is a no brainer. The business gets worry-free headroom and the ability to scale to tens of millions of messages per second. The business gets competitive edge in operational improvements and faster trading.

It’s a game-changing value prop and it was unthinkable just a few years ago. If you ask the really talented architects and infrastructure designers on the street today, they are more likely to call it inevitable than unthinkable.