There are several high-performance messaging solutions widely deployed in the market today. We are frequently asked what makes the design of LBM and UME different from EMS™ RV™, Triarch™/RMDS™, or SmartSockets™. (Note: EMS™, RV™ and SmartSockets™ are trademarks of TIBCO Software Inc. Triarch™ and RMDS™ are trademarks of Reuters.)

The team at 29West has been at the forefront of high speed messaging from the design of the first digital trading systems. As we looked at the marketplace and the solutions available in 2003, it became clear that most of the very highest performance messaging problems were being solved with daemon based messaging models that could trace their design roots back to the mid 1980s. We felt that by leveraging the intelligence built into the modern network stacks, switches, operating systems and infrastructure, we could provide a real jump in performance. We also felt that as we focused on performance and configurability at every design decision point, we would be able to provide the application developer with a lightweight, but highly tunable solution to allow them to choose the tradeoffs that best fit their application.

It was clear early on that to achieve a real performance breakthrough, we would have to eliminate software based messaging routing where possible, and remove all message handling processes that exist in legacy messaging designs between the sender and receiver of data. Be they daemons, or message servers, these extra hops in the data delivery flow reduce scaling and increase latency. The key design breakthroughs in the 29West messaging solutions are finding a way to provide true application-to-application dataflow, with full publish/subscribe message semantics. By reducing the tasks and processes that have to run for a message to be delivered, we greatly increase efficiency and reduce latency.

Specifically, our design has pioneered the following key architectural advancements, which directly improve our performance:

We reduce latency by eliminating hops. Each time a message has to be received and re-transmitted by an intermediary daemon or server, significant penalties are incurred by data copies, context switches, process scheduling, and (when the hop goes off-box) network delays. Our design eliminates the need for messaging routers and intermediate messaging daemons. It is purely sender to receiver (application to application).

We designed from the start with modern OS and hardware capabilities taken into account. By leveraging the modern OS designs, we are able to create a messaging layer that can share the application's user space and not require special daemon processes. Most of traditional messaging systems on the market today were originally developed 10 or 20 years ago when networks and machines were not nearly as capable as they are today.

Our messaging design does not duplicate the routing capabilities of network infrastructures. We let the network route messages where possible.

We allow you to choose the underlying transport protocols to best suit individual application needs. Applications can select the best mix of TCP, Reliable Multicast, Reliable Unicast and Latency-Bounded TCP.

Our messaging solutions are highly configurable, allowing the application to fine-tune our behavior according to its specific needs. For example, applications that do not need a guarantee of in-order delivery can reap latency and throughput improvements by configuring arrival order delivery. Rate limits, controls over NAK transmissions, and retry limits provide network stability, even under high load and fault conditions.

The Persistent Store component of UME allows messaging applications to decouple the lifetime of message streams from the lifetimes of the sources sending and receivers receiving them. The UME Persistent Store allows a message stream to live on even after the source that sent it is gone. Furthermore, a source need not wait till a receiver is ready before sending messages. In short, sources and receivers need not be running at the same time in order to pass messages.

Decoupling the lifetime of a message stream from the lifetimes of sources and receivers offers the additional benefit that a new source or receiver can pick up where an old one left off. An obvious application of this is a "durable subscription" for a receiver. In this case, a receiver process can stop and restart with no loss of messages, even if new messages were sent while the receiver was stopped. The durable source case can also be beneficial. A source can stop and restart without receivers even knowing.

Our pricing structure, support options, and straight-forward licensing provide a business model that we think our customers will find refreshing.