Persistence: The Persistent Store component of UME not only supports fault recovery of failed stores gracefully taking up from the last successful transmission, but also 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. Further, 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.

Stores vs. Receivers: UME alleviates stores from being a bottleneck. The inherent design of UME is not to write through stores to get to receivers, but rather UME runs the store and receiver in parallel.

Durable Subscriptions: 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.

Late Join: In many applications, a new receiver may be interested in messages that were sent before it even existed. (Note that this is distinct from the durable subscription case mentioned above that covers the continuation of an existing subscription.) UME provides a late join feature that allows a new receiver to join a group of others already listening to a source. Without the late join feature, the joining receiver would only receive messages sent after the time it joined. With late join, the joining receiver can even receive messages that were sent before it joined the group. The limit on the range of messages available to the late-joining receiver is established by the source in its message retention policy.

Delivery Confirmation: It is often important to provide a positive acknowledgement to the source when the message is delivered. A UME source can be configured so that it will receive an event whenever a message it sent is delivered to any receiver. UME receivers have control over when such an event is generated - for example, when the message is passed to the receiving application, or when the receiving application releases it.

Flexible Framework: In regards to the concept of confirmed delivery mentioned above, UME is flexible enough that confirmation can be configured once the message is read by the application or once the message is processed by the application.

No Single Point of Failure: UME implementations are conceived to feature no single point of failure. Should the primary store become inactive, the secondary store is synchronized to act as the primary store.

Retention Policies: If memory and disk drives had infinite capacity, there might be no penalty for making all messages persist forever. Since storage space is finite and access times are related to the amount of information stored, UME allows administrators to configure retention policies that govern when and where messages are retained. The space that was previously used by messages that are no longer retained may be reclaimed for use by new messages. The retention policies of UME are one of two types: Source Retention or Store Retention.