JMS supports these messaging models:

The TIBCO EMS software 5.1 on windows and Solaris
They should be different with TIBCO RENDEZVOUS

Ask a Question TIBCO | Difference between Tibco Rendezvous and TIB EMS server Reply from Rajiv Totlani on 9/3/2004 12:49 PM | Share 0 member votes EMS Server is a tool that acts as a JMS server where JMS is the messaging protocol (and more as we will see later in this note). RV is a messaging protocol from TIBCO, but unlike JMS does not require a server. EMS is also a gateway from JMS to RV (think of a gateway as something where you go from one protocol to another). The reason why Tibco calls it EMS has nothing to do with "Tibco Product architecture tight coupling". There is no tight coupling in messaging if you do things right and use XML for data. The entire idea behind messaging is to remove tight coupling. The reason its called EMS or Enterprise Messaging Server is because it does more than just JMS and calling it just a JMS server does not do it justice. One of the very good ideas behind JMS was to promote inter-operability between different MOM's (Message Oriented Middleware's). In order for this to be possible, the MOM companies provide a tool that converts from their message format to JMS and the other MOM that it needs to interoperate with converts from JMS to its format (JMS is the language they all speak in addition to their languages). EMS is confirming to this idea (and I have seen it being used in this way...for high volume fast transactions use reliable RV messages and where latency is acceptable use JMS). Rajiv Totlani

JMS supports these messaging models:
• Point-to-Point (queues)
• Publish and Subscribe (topics)
• Multicast (topics)
Point-to-Point
Point-to-point messaging has one producer and one consumer per message. This
style of messaging uses a queue to store messages until they are received. The
message producer sends the message to the queue; the message consumer
retrieves messages from the queue and sends acknowledgement that the message
was received.
Publish and Subscribe
In a publish and subscribe message system, producers address messages to a
topic. In this model, the producer is known as a publisher and the consumer is
known as a subscriber.
Many publishers can publish to the same topic, and a message from a single
publisher can be received by many subscribers. Subscribers subscribe to topics,
and all messages published to the topic are received by all subscribers to the topic.
This type of message protocol is also known as broadcast messaging because
messages are sent over the network and received by all interested subscribers,
similar to how radio or television signals are broadcast and received.
By default, subscribers only receive messages when they are active. If messages
arrive on the topic when the subscriber is not available, the subscriber does not
receive those messages.
The EMS APIs allow you to create durable subscribers to ensure that messages are
received, even if the message consumer is not currently running.
Multicast
Multicast messaging allows one message producer to send a message to multiple
subscribed consumers simultaneously. As in the publish and subscribe messaging
models, the message producer addresses the message to a topic. Instead of
delivering a copy of the message to each individual subscriber over TCP,
however, the EMS server broadcasts the message over Pragmatic General
Multicast (PGM). A daemon running on the machine with the subscribed EMS
client receives the multicast message and delivers it to the message consumer.
Multicast is highly scalable because of the reduction in bandwidth used to
broadcast messages, and because of reduced EMS server resources used.
However, multicast does not guarantee message delivery to all subscribers.
JMS messages have a standard structure. This structure includes the following
sections:
• Header (required)
• Properties (optional)
• Body (optional)
JMS_TIBCO_COMPRESS Allows messages to be
compressed for more efficient
storage.
The JMS specification includes a JMSPriority message header field in which
senders can set the priority of a message, as a value in the range [0,9]. EMS does
support message priority (though it is optional, and other vendors might not
implement it).
The EMS client APIs (Java, .NET and C) include mechanisms for handling strings
and specifying the character encoding used for all strings within a message.
TIBCO Enterprise Message Service allows a client to compress the body of a
message before sending the message to the server.
EMS supports message compression/decompression across client types (Java, C
and C#). For example, a Java producer may compress a message and a C
consumer may decompress the message.
To set message compression, the application that sends or publishes the message
must access the message properties and set the boolean property
JMS_TIBCO_COMPRESS to true before sending or publishing the message.
Compressed messages are handled transparently. The client code only sets the
JMS_TIBCO_COMPRESS property. The client does not need to take any other action.

The EMS APIs allow for both synchronous or asynchronous message
consumption. For synchronous consumption, the message consumer explicitly
invokes a receive call on the topic or queue. When synchronously receiving
messages, the consumer remains blocked until a message arrives. See Receiving
Messages on page 320 for details.
The consumer can receive messages asynchronously by registering a message
listener to receive the messages. When a message arrives at the destination, the
message listener delivers the message to the message consumer. The message
consumer is free to do other operations between messages. See Creating a
Message Listener for Asynchronous Message Consumption on page 313 for
details.
You can use wildcards when specifying statically created destinations in
queues.conf and topics.conf. The use of wildcards in destination names can
be used to define "parent" and "child" destination relationships, where the child
destinations inherit the properties and permissions from its parents.