Message Transports


Adapter messages can be delivered using either the TIBCO Rendezvous transport or the JMS transport. This section introduces the transports and explains the quality of services available under each.

To fully understand the TIBCO Rendezvous features used by adapters, you should read TIBCO Rendezvous Concepts. The book is available in the TIBCO Runtime Agent installation area in the <install-path>/tibco/tibrv/doc folder.

Before configuring an adapter service with the JMS transport, you should be familiar with JMS concepts, which are explained fully in the TIBCO Enterprise for JMS User’s Guide. The book is available from the machine on which the TIBCO Enterprise for JMS software is installed in the <install-path>/tibco/jms/doc directory.

TIBCO Rendezvous

TIBCO Rendezvous integrates distributed applications by providing a common, message-based communication mechanism. One main component is the TIBCO Rendezvous daemon, which runs on each participating computer on your network. All information that travels between adapter instances passes through the TIBCO Rendezvous daemon as the information enters and exits host computers. The daemon also passes information between adapters running on the same host. Many hardware and software platforms are supported, so programs on different kinds of computers on a network can communicate seamlessly.

TIBCO Rendezvous software uses subject-based addressing™ technology to direct messages to their destinations. An adapter configured with a publication service sends that information on a well-defined subject name. Each adapter configured with a subscription service listens on a subject name. The TIBCO Rendezvous daemon handles the network messages corresponding to the peer-to-peer communication between the publication adapter and the subscription adapter. This allows adapters to communicate without knowing the details of network addresses or connections. Subject-based addressing conventions define a uniform name space for messages and their destinations.

Publication and Subscription Services Interactions

The publication and subscription services interactions are driven by events (usually the arrival or creation of data). An adapter publication service makes information available for general distribution. Communication is in one direction (publisher to subscribers), and often one-to-many as shown in the next diagram. The complete interaction consists of one multicast message, published once, and received by all subscribers.

Figure 14 Event-driven publication and subscription interaction

In publication and subscription services interactions, data producers are decoupled from data consumers—they do not coordinate data transmission with each other, except by using the same subject name. The adapter publishes data to the network at large.

Request and Response Services Interactions

Demand for data drives request response interactions. An adapter requests data from a vendor application; the application computes an individual response and returns it to the adapter. Communication flows in both directions, as shown in the next diagram. The complete interaction consist of two point-to-point messages—a request and a response.

Figure 15 Demand-driven request and response interaction

In request interactions, data producers coordinate closely with data consumers. A adapter does not send data until a request is made by a vendor application. Each program sends its message to a specific inbox name within the other program.

The adapter sends its response specifically to the vendor application that requested the data. The requesting application listens until it receives the reply, and then stops listening (unless it expects further installments of information).

Reliable and Certified Message Delivery Modes

If your adapter uses the TIBCO Rendezvous transport, the reliable and certified delivery protocols are available. Table 2 compares the two delivery protocols.

Table 2 Comparing Reliable and Certified Message Delivery (Sheet 1 of 2)
Aspect
Reliable Delivery
Certified Delivery
Protocol Information
TIBCO Rendezvous daemons inform programs when data is lost. No information about the lost data is available.
The library presents advisory messages to inform programs of every significant event related to certified delivery. Advisories identify specific messages by correspondent name, subject name and sequence number.
Ledger
None.
The certified delivery library records outbound messages in a ledger, either within the program process storage, or in file storage.
Time Limit
Outbound messages are retained for 60 seconds.
The certified delivery library retains outbound messages in the ledger until either delivery is complete or the time limit (set by the adapter) expires.
Effective Range
60 seconds, or when the TIBCO Rendezvous daemon process terminates—whichever is first.
With persistent correspondents, certified delivery can extend beyond program process restart. It is not affected by TIBCO Rendezvous daemon process termination.
Network Bandwidth
Minimal network overhead beyond the message itself.
Additional network overhead to confirm delivery of each certified message.
File Storage
No file storage overhead.
Optional file-based ledgers consume file storage for each message until delivery is complete (or the time limit expires).

Transactional Message Delivery Mode

The transactional delivery mode requires an additional component, TIBCO Rendezvous TX. The mode provide transaction control over messages, store-and-forward messaging, and exactly-once delivery. Note that distributed transactions are not supported.

Distributed Queue Mode

This mode allows multiple adapters to distribute the load among the distributed queue members. The service is used for adapters configured with the subscription service or request response to provide process level load balancing.

Note that a distributed queue cannot be used for adapters configured with the publication or request response invocation services. See the TIBCO Rendezvous Concepts book for more information.

Wire Formats

The adapter can be configured to send messages in one of the following wire formats.

The TIBCO Rendezvous wire format should be chosen to communicate with a native TIBCO Rendezvous application while the TIBCO ActiveEnterprise wire format should be chosen to communicate among TIBCO applications that use TIBCO ActiveEnterprise Operations for their service configurations.

TIBCO Enterprise for JMS

This section provides an overview of TIBCO Enterprise for JMS product. See the TIBCO Enterprise for JMS User’s Guide for more information.

JMS is based on creation and delivery of messages. Messages are structured data that an adapter sends to another adapter or vendor application. An adapter publication service produces messages that are consumed by an adapter subscription service. The TIBCO Enterprise for JMS server acts as an intermediary for the message and sends it to the correct destination.

The next diagram shows an adapter publication service producing a message, sending it by way of the server, and an adapter subscription service receiving the message.

Figure 16 JMS message delivery

JMS supports publish and subscribe (topics), and point-to-point (queues) interactions.

Publish and Subscribe Interactions

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.

The next diagram shows publish and subscribe messaging. Each message consumer subscribes to a topic. When a message is published to that topic, all subscribed consumers receive the message.

Figure 17 JMS publish and subscribe messages

There can be a time dependency in publish and subscribe mode. By default, subscribers only receive messages when they are active. If messages are delivered when the subscriber is not available, the subscriber does not receive those messages. The JMS API provides a method to remove part of the timing dependency by allowing subscribers to create durable subscriptions. Messages for durable subscriptions are stored on the server until the message expires or the storage limit is reached. Subscribers can receive messages from a durable subscription even if the subscriber was not available when the message was originally delivered.

Point-to-Point Interactions

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 wish for 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 retrieve each message that is placed on the queue.

The next diagram shows point-to-point messaging using a non-exclusive queue. Each message consumer receives a message from the queue, acknowledges receipt of the message, and the message is taken off the queue so that no other consumer can receive it.

Figure 18 JMS point-to-point messages
Wire Format

JMS messages use the XML Message wire format that conforms to specifically constructed and fully compliant XML Schema (XSD) based on the existing definition of the TIBCO ActiveEnterprise schema.

Connection Type

The following delivery modes can be specified when using the JMS transport:

Delivery Mode

A JMS message is marked as persistent or non persistent.


TIBCO Adapter™ Concepts
April 2005
Copyright © TIBCO Software Inc. All rights reserved
www.tibco.com