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.

Conclusion

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)