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.

FTL programs do these steps to receive messages:
  1. Connect to the FTL server to obtain configuration information (the realm definition).
  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 FTL server (through its realm service) supplies configuration information to application programs.
  • In peer-to-peer messaging, messages do not flow through the FTL server. The FTL server neither stores messages from publishers, nor forwards messages to subscribers.

    In the message broker pattern, messages do flow through the FTL server.

  • A transport bus is the physical mechanism that delivers messages among peers, or between client and broker. For example, a transport bus delivers a stream of messages directly from a publishing program to a subscribing program. The FTL server supplies the configuration of the transport bus, and the peers use that configuration to construct the bus.

    Similarly, a transport bus delivers a stream of messages from a publishing program to the message broker, and another bus delivers a stream of messages from the broker to a subscriber.

    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 these examples.

  • 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 a 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.