Enterprise Integration Zone is brought to you in partnership with:

Kai Wähner (Twitter: @KaiWaehner, Blog: www.kai-waehner.de/blog) is an IT-Consultant in the Java EE, SOA, Cloud Computing and Big Data world. In his real life, he lives in Erlangen, Germany and works for TIBCO (www.tibco.com). Besides solving huge integration problems for large companies, Kai writes articles for magazines and speaks at international IT conferences such as JavaOne. Feel free to contact him via Twitter, LinkedIn or Email. Kai is a DZone MVB and is not an employee of DZone and has posted 52 posts at DZone. You can read more from them at their website. View Full User Profile

Java / JVM – When to use Multicast (e.g. Tibco Rendevous) instead of Point-to-Point Messaging (JMS Implementations)

  • submit to reddit

Several solutions are available in the Java / JVM environment for messaging. All have in common that they exist for many years and still do its job in mission critical systems: Sending remote messages fast and reliable. There exist two different concepts which compete against each other for enterprise messaging solutions.  This article describes and compares Point-to-Point (diverse JMS implementations) and Multicast (e.g. Tibco Rendevous) messaging  to answer the question when to use which one. Although both solutions are available for many years now, this question is still very important – also for new software!

Point-to-Point Messaging Solutions

Point-to-Point messaging solutions use the hub-and-spoke architetural style. A central broker (or a cluster of brokers) receives messages from a producer and sends them to a consumer.

The most widespread standard is the Java Messaging Service (JMS) which is a part of the Java Enterprise Edition specifications (JSR 914). Version 1.1 is about nine years old (and still does its job very well). JMS 2.0 (JSR 343) will probably be included in JEE 7 and release in 2012. Many different implementations are available, commercial (e.g. WebSphere MQ, Tibco EMS) as well as open source (e.g. ActiveMQ, HornetQ, RabittMQ). Many products also offer APIs for other programming languages to be interoperable.

These solutions are awesome for sending reliable remote messages. Stability is very good and performance is sufficient for most use cases. There is only one problem: Unicast messages are used to deliver information, i.e. each message is transorted on its own from producer to consumer. JMS also supports the publish-and-subscribe pattern, where several consumers can register to a Topic and receive the same message sent by a producer – but this is just a multicast-simulation. Actually, only point-to-point messages are used internally. Thus, performance is sufficient for most use cases, but it is not as good as with the multicast solution Tibco Rendevous.

Multicast Messaging Solutions

Well, although the title says „solutions“, I think Tibco Rendevous (also often called Tibco RV) is the most important and widespread multicast solution. Thus, this article describes Tibco RV. Nevertheless, other products (such as WebSphere MQ or WebLogic) also offer Multicast support.

Contrary to point-to-point solutions, Tibco RV uses a distributed architecture. There is no broker in the middle, each producer broadcasts messages to its consumers directly using UDP as message protocol and a Rendevous Daemon (RVD) which is installed on each host of the network as background process. You can also connect to a remote daemon, theoretically.

This multicast concept delivers information to a group of destinations simultaneously using the most efficient strategy. Each link of the network is only used once until splitting is required. Tibco RV is unreliable by default. Reliable messaging is also possible (called Certified Messaging), deducing a much worse performance. This can be used to simulate point-to-point solutions – but this does not make much sense! If you need reliable messaging using queues (and in most use cases this is what you need), then use a JMS or AMQP product.

When to use Multicast instead of a Point-to-Point Solution?

Tibco RV is perfect if you need to send the same message to several (not just 1, 2, 3 or 10) destinations or if you need very fast near real-time remote messaging. It has much better performance than point-to-point solutions – if you can accept to send unreliable messages. Be aware, that there is no broker in the middle which persists your messages (and redelivers them if your consumer is down).

An advantage of the distributed architecture is that there is no broker cluster to configure and administer, you just define the used network. For example, if you use WebSphere MQ, you have to create a cluster, queues, channels and so on on each server using MQSC commands.

Due to location transparency, you only need to know the topic name (also called subject in Tibco RV) to send a message. There is no physical location of a broker which you have to configure. All consumers which have subscribed to a subject will receive the message without knowing the physical location of the producer.

Prominent used cases for multicast solutions such as Tibco RV are present in the financial sector (e.g. for providing stock prices) or for logistic support (e.g. showing the current location of components or vehicles). Unlike e.g. a bank transfer, unreliability of messages does not matter in these uses cases. A new message is sent every few seconds. Redeliverung messages would implicate outdated messages.

Disadvantages of Multicast Solutions

Besides being unreliable, some other disadvantages exists for multicast solutions such as Tibco RV:

  • Transactional messaging is difficult to realize (but not impossible)
  • Simulating queues is possible but deduces worse performance
  • Monitoring is much tougher than with queueing solutions (e.g. there is  no queue browser where you can remove stuck messages)

Alternative Messaging Concepts

The Advanced Message Queuing Protocol (AMQP) is an open standard application layer protocol for message-oriented middleware which tries to abstract from the API layer (which is used in JMS) to offer a real interoperable standard. Some of the above JMS products already implement AMQP, too.

Besides, several other messaging solutions exist. Programming with sockets is one of several low level alternatives for realizing communication. Actors are reviving especially due to modern JVM programming languages such as Groovy or Scala and also offer leightweight remote messaging.

But at the moment, I would say that Tibco RV and JMS implementations are the two most important and widespread enterprise messaging solutions in the Java / JVM environment.


In most use cases, a JMS implementation using the point-to-point concept will be the right tool for the right job!

Use Tibco RV (or other multicast products) if you need a very fast, near real-time messaging solution and if you can accept unreliable messages. You should at least know, that this product exists. If you do performance tests with several JMS implementations because you need high performance, you probably should also evaluate Tibco RV.

So, do you have any other experiences or important information that I missed. I appreciate every comment…

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

[Content from my blog: Kai Wähner's IT-Blog: Java / JVM Messaging Solutions – When to use Tibco Rendevous instead of a JMS Implementation such as WebSphere MQ or ActiveMQ]

Published at DZone with permission of Kai Wähner, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Java Guy replied on Fri, 2011/05/20 - 4:25am

Sounds like a tibco sales pitch with no disclosure...

Kai Wähner replied on Fri, 2011/05/20 - 5:37am

Hm, it is definitely not! If you can tell me some other good middleware for multicast messaging, I will immediately add them to this article...

Best regards,

Kai Wähner (Twitter: @KaiWaehner) 

Jerome Raduget replied on Fri, 2011/05/20 - 7:18am

I'm rarely a fan of proprietary solutions, but i agree with your post about tibco RDV.

I work on highly stressed systems, with JMS weblogic implementation / websphere MQ / and Tibco RDV, and I must confess that RDV is really interresting and reliable (performance, reliable , simplicity, scallable (distributed queue))...

Only one comment when you said "Use Tibco RV .... if you can accept unreliable message" : You can have reliable and efficient message distribution with RV (certified in RV term). Certified message use a simple ledger file for persistence on both side (publisher and subscriber)

The drawback of multicasting solution: it can be a headache for your network...

Mark Priest replied on Fri, 2011/05/20 - 8:38am

I don't believe anything in the JMS specification precludes the use of multicast with JMS pub-sub. As long as the provider follows the API they can implement it however they see fit. A quick google search turns up this for Oracle weblogic, for example. http://download.oracle.com/docs/cd/E11035_01/wls100/jms/multicast.html

Kai Wähner replied on Fri, 2011/05/20 - 10:44am in response to: Jerome Raduget

For the point of "slow performance with certified messages", I can only talk about the experiences our architects made when evaluating several JMS implementations (including Websphere MQ and some open source products) and Tibco RV about 3 years ago for their project: Certified Tibco messages were much slower than not certified ones. But honestly, unreliable messaging was very acceptable for our use case, so maybe they did not evaluate Certified Tibco messaging a lot...

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

Kai Wähner replied on Sat, 2011/05/21 - 3:45am in response to: Mark Priest

@Mark: You are right! I was not aware that e.g. WebLogic or WebSphere MQ also offer Multicast support. Although I think that Tibco RV is most widespread for multicast solutions, I changed the title and some content to make this clear. Thanks for your feedback.

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

Alex(JAlexoid) ... replied on Sun, 2011/05/22 - 5:54am

There is also ZeroMQ for brokerless MQ system.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.