FTL Delivery

TIBCO EMS and TIBCO FTL use different mechanisms to receive and process inbound messages in client programs. Understanding the differences can ease your shift to FTL.

In contrast, FTL programs do these completely different steps to receive messages:
  1. Connect to the realm server to obtain configuration information.
  2. Create a subscriber object to express interest in messages.

    The subscriber uses the configuration information to automatically construct a transport bus that can transport messages from publishers (not from the realm server).

  3. Create an event queue object to buffer inbound messages.
  4. Add the subscriber to the event queue, with a callback method to process inbound messages.
  5. Start a dispatch loop to remove messages from the event queue and present them to the callback method.

Differences

Ensure that you understand these crucial differences between the two messaging paradigms:
  • The realm server supplies configuration information, but not messages. The realm server neither stores messages from publishers, nor forwards messages to subscribers. The role of realm server is not parallel to the role of the EMS server.
  • Instead, the physical mechanism that delivers messages from peer to peer is a transport bus. For example, a transport bus delivers a stream of messages directly from a publishing program to a subscribing program. The realm server supplies the configuration of the transport bus, and the peers use that configuration to construct the bus.

    EMS has no analogue for transport buses. You can imagine a transport bus as similar to a TCP connection from a publisher object to a subscriber object, though transport buses can also be more complex than this example.

  • Transport buses are automatic. Programs create subscriber or publisher objects, and those objects construct their transport buses without further explicit program calls. The FTL API does not refer to transports in any way; transports are completely hidden from program code.
  • Messages arrive from the transport bus, and the subscriber buffers them in an event queue.

    You cannot infer anything about FTL event queues from your understanding of EMS destination queues. Despite the similarity of their names (that is, they are both called "queues"), they serve different purposes. FTL event queues are objects within client programs, not within a server.

  • Adding an FTL subscriber object to an event queue associates the subscriber, the event queue, and a callback method. When a message arrives, the event queue stores it as a message event, which is a package that includes all the arguments that the callback method needs to process the message.
  • To invoke the callback method, the receiving FTL program must explicitly dispatch message events from the event queue. Programs usually start a dispatch loop in a thread dedicated for this purpose.
  • The event queue separates message arrival from message processing. Arrival and processing usually occur asynchronously, and in different threads. (The exception to this rule is a latency optimization called inline mode.)
  • EMS offers either synchronous receive or asynchronous delivery.

    FTL offers only asynchronous delivery, as described in this topic.