TIBCO Rendezvous vs SonicMQ

This article is compiled from source available in the WWW, not my own opinion and only used for reference and information purpose.

TIBCO Rendezvous

TIBCO has been one of the leading providers of EAI since its establishment 20 years ago and TIB/RV is one of the most widely used messaging middleware in enterprises.

TIB/RV is implemented in C and based on a distributed architecture. An installation of TIB/RV resides on each host on the network.

Messaging can be delivered in point-to-point or publish/subscribe, synchronously or asynchronously, locally delivered or sent via WAN or the Internet. Rendezvous messages are self-describing and platform independent.

TIB/RV is composed of three main components:
- RV Daemon (RVD) responsible for the delivery of messages within a LAN.
- RV Agent (RVA)
- RV Routing Daemon (RVRD)

In TIB/RV, point-to-point messages sending model is fairly similar to publish/subscribe, The RV Sender program passes the message and destination topic to RVD. RVD then broadcasts this message using User Data Packet (UDP) to the entire network. All subscribing computers with RVDs on the network will receive this message. RVD will filter the messages which non-subscribers will not be notified of the message. Therefore only subscriber programs to the particular topic will get the messages.

SonicMQ

SonicMQ is JMS implementation, and has outstanding performances competitive with existing MOM technologies, such as IBM MQSeries. SonicMQ is written in 100% pure Java, supports XML messaging, and HTTP tunnelling to allow SonicMQ to work over the Internet. The underlying mechanism of SonicMQ is its “broker” that facilitates the movement of messages across the network.

The communication protocols that can be used with SonicMQ include TCP, HTTP and SSL. Since it uses common Internet protocol, SonicMQ can extend its deployment to the Internet. It also provides bridges to many other popular MOMs that allow messages to be sent and received between SonicMQ and other MOMs.

There are three types of configurations a user can choose from:
- Single-broker Configuration: Under this configuration, there is one broker which is being shared across a few nodes.
- Multi-broker Clusters
- Multi-node Configurations

The broker is the most important underlying implementation of SonicMQ. It is responsible for delivering and acquiring of messages within a LAN environment. It is a client-server model, where many clients connect to a single broker. The connection can be via TCP (for LAN), SSL (for security encryption), or even HTTP (to connect to external entities).

The downside with single broker configuration is that scalability is limited by the capabilities of the node machine. Also the system is dependent on the single broker machine (node), hence leading to a bottleneck of the system at the node. The whole system may collapse if the node goes down. To solve this problem a multi-broker cluster must be used.

There exist a benchmark report for SonicMQ by Progress Software. SonicMQ showed outstanding performances compared to IBM MQSeries and Fiorano FioranoMQ, (both are JMS implementations) under WinNT platform.

TIB/RV vs SonicMQ

There is a benchmarking result shows that TIB/RV has exceptional performance compared to SonicMQ.

They are as follows:
- High publish/subscribe and point-to-point send/receive rates
- High scalability:
- Publishing rate not affected by introducing more receivers;
- Subscriber rate increases as more subscribers are introduced.
- Low memory and CPU consumption

The only major downside of TIB/RV is that when there are very few receivers in the network, it could flood the network with many unnecessary UDP packets, introducing congestions.

TIB/RV is using multicast-based publish/subscribe messaging, which is an excellent solution for near-real-time message dissemination when 1 to 'very-many' delivery capabilities matter. It is better for application with high volume, high performance, acceptance of unreliability (nature of UDP), 1 to very many.

However, in most EAI cases the opposite requirements are true: ‘Cardinality’ of message delivery is 1-1, 1-2; 1 to-very-many is a rare case. With exception of ‘consolidated application’ integration model (near real time request reply with timeout heuristics), reliability of message delivery takes priority over performance.

Reference List

Benchmarking Message-Oriented Middleware TIB/RV vs SonicMQ
Tibco RV vs Tibco EMS