As one of my task is also learning TIBCO EMS – here are my notes. You can expect more one this topic;)

TIBCO Messaging provides components to support messaging / communications. From high-performance (millions of messages a second) to low latency (sub-microsecond delivery) to fully transactional enterprise-class distribution, streaming data and open source support.Components of TIBCO Messaging

• TIBCO Enterprise Message Service is a standards-based messaging platform built around supporting the JMS 1.1 and 2.0 standards. TIBCO Enterprise Message Service is TCK certified for both JMS 1.1 and 2.0.
• TIBCO eFTL is the edge node communications system to provide websocket, nodejs, and mobile communication support for the components in the TIBCO Messaging Suite.
• TIBCO FTL is the backbone for high-performance, low-latency communication and is used to provide content-based delivery of data for real-time applications. TIBCO FTL is at the core of TIBCO’s integration communication.
• TIBCO Apache Kafka Distribution is an open source streaming platform providing a distributed approach to data distribution and streaming.
• TIBCO Eclipse Mosquitto Distribution is an open source IoT communications platform supporting MQTT for data distribution.

More info: https://www.tibco.com/

TIBCO support SOA – more info here:

https://www.tibco.com/reference-center/what-is-microservices-architecture

What is TIBCO EMS?

TIBCO EMS Tutorial: What is TIBCO EMS (Enterprise Message Service)?

• Communication types:
• 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.
More than one producer can send messages to the same queue, and more than one consumer can retrieve messages from the same queue. The queue can be configured to be exclusive, if desired. If the queue is exclusive, then all queue messages can only be retrieved by the first consumer specified for the queue. Exclusive queues are useful when you want only one application to receive messages for a specific queue. If the queue is not exclusive, any number of receivers can retrieve messages from the queue. Non-exclusive queues are useful for balancing the load of incoming messages across multiple receivers. Regardless of whether the queue is exclusive or not, only one consumer can ever consume each message that is placed on the queue.

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.

Durable Subscribers for Topics
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. Messages for durable subscriptions are stored on the server as long as durable subscribers exist for the topic, or until the message expiration time for the message has been reached, or until the storage limit has been reached for the topic. Durable subscribers can receive messages from a durable subscription even if the subscriber was not available when the message was originally delivered.
When an application restarts and recreates a durable subscriber with the same ID, all messages stored on the server for that topic are delivered to the durable subscriber.

Shared Subscriptions for Topics
Shared subscriptions allow an application to share the work of receiving messages on a topic among multiple message consumers. When multiple consumers share a subscription, only one consumer in the group receives each new message. This is similar in function to a queue; however, there are no restrictions placed on the type of consumers to the topic, meaning that a topic can have a mix of shared and not shared, durable and non-durable consumers. When a message is published to the topic, the same message goes to all the matching subscriptions.
Shared subscriptions are created with a specific name, and optionally a client ID. Consumers sharing the subscription specify this name when subscribing to the topic. If the shared subscription type is durable, it persists an continues to accumulate messages until deleted. If the shared subscription type is non-durable, it persists only so long as subscribers exist.
For example, the topic foo might have the following subscriptions:
•
not shared, non-durable subscription
•
not shared, durable subscription
•
shared, non-durable subscription called mySharedSub with three shared consumers
•
shared, durable subscription called myDurableSharedSub with two shared consumers
If a message is received on foo, each of the above four subscriptions receive that same message. For the shared subscriptions mySharedSub and myDurableSharedSub, the message is delivered to only one if its respective shared consumers.
If the shared consumers of the shared durable subscription myDurableSharedSub are closed, then the shared durable subscription continues to exist and accumulate messages until it is deleted, or until the application creates a new durable shared consumer named myDurableSharedSub to resume this subscription. If the shared consumers of mySharedSub are all closed, the subscription is removed from topic foo.

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.