RV is like a radio broadcaster and EMS is like a telephone.

If you want to send a message to everyone in town (e.g. the weather forecast for today) then a radio is good because one message goes to everyone simultaneously. Telephone is bad because it takes a long time to call everyone and you pay 20c a call.

If you want to tell someone your credit card number you would use the telephone because you can be sure you are talking to the right person. Radio is bad because then everyone in town knows your credit card number.

RV uses a reliable multicast protocol so it supports fast high fan-out messaging capabilities like sending stock ticks to a large number of trading desks (what it was originally designed for). But the tradeoff is poor security and some limits on administration. There are also special considerations for communication across multiple LAN segments or WANs.

EMS is a JMS provider which communicates in a point-to-point fashion much like a telephone. Security is better and administration tasks are easier. EMS is server based (vs RV s peer-to-peer architecture) so store and forward type activities are easier than with RV.

You can mix and match the two to get the best of both worlds. I think later versions of EMS have a multicast capability for Topics, but I haven t used that.

To build on above answers:

1. Use EMS when you are looking for persistence of messages.
2. EMS is based on JMS whereas RV protocols and APIs are proprietary.

• EMS is a broker that supports standard protocols (JMS), TCP
• RV has focus on low latency, like ZeroMQ or maybe Akka
  • point-to-point over TCP or
  • point-to-point over UDP or
  • multicast over UDP
  • licensed per server
  • messages are sent via topic
  • supports topics with wildcard (*) segments, that don t require specific routing rules or explicit subscriptions to receive data from new topics
• after Tibco acquired 29West, RV seems to be evolved from the 29West low-latency message bus/broker

For any fans of low-latency messaging (29West and/or Rendezous/RV) I would recommend taking a look at ZeroMQ (a.k.a. 0MQ) or Akka. I ve never put it in production at work, but I ve built prototypes with 0MQ that were blazing fast. Their new server offerings (new in 2018) are interesting.

API Note

• in RV, to create a new/guaranteed unique topic use: CreateInbox()