Endpoints, Publishers, Subscribers, and Transports
Endpoints and transports are usually less familiar concepts than publishers and subscribers for new users shifting to TIBCO FTL from TIBCO EMS. This topic explains all four of these concepts within a three-layer framework.
Summary Overview
This table briefly summarizes the main ideas. The sections that follow it present the ideas in greater depth.
| Application Layer | Program Layer | Transport Layer | |
|---|---|---|---|
| Message Flow | Messages flow between endpoints. | Messages flow from publishers to subscribers. | Messages flow through transports. |
| Key Concept | Messages enter and exit applications through named endpoints. | Programs create publishers and subscribers on endpoint names.
Publisher send messages. Subscribers express interest in receiving messages. |
At run time, programs automatically establish
transport buses that can move messages from publishers to subscribers.
Even when messages make an intermediary hop through a message broker or persistence service, transport buses do the work of moving messages. |
| Your Task | Configure endpoints in the applications grid of the FTL server GUI. | Create publishers and subscribers in program code. | Define and configure transports in the transports grid of the FTL server GUI.
Bind transports to endpoints in the applications grid of the FTL server GUI. |
Endpoints
Endpoints are names. An endpoint denotes a place within an FTL program where messages can enter and exit the program.
At the application layer of abstraction, messages flow between endpoints. Messages exit the sending application program at its endpoint, and enter the receiving application program at its endpoint.
The following diagram depicts the endpoints (E) in blue.
You can define applications and their endpoints in the applications grid of the FTL server GUI. Many programs require only a single endpoint, and can use the default application definition and its default endpoint.
Programs use endpoint names only to create publishers and subscribers. Programs can create several publishers and subscribers on a single endpoint.
Publishers and Subscribers
Publishers are objects within FTL programs that send messages. Subscribers are objects within FTL programs that express interest in receiving messages.
At the program layer of abstraction, messages flow from publishers to subscribers.
Programs create publishers and subscribers on endpoint names. That is, the calls that create a publisher or a subscriber accept an endpoint name as an argument. When a publisher sends messages, they go out through that endpoint. When a subscriber receives messages, they have entered through that endpoint.
The following diagram depicts the publishers (Pub) and subscribers (Sub) in purple.
The FTL server does not configure publisher and subscriber objects, nor even refer to them. They exist only within programs.
Transports
Transports are data pipes connecting endpoints to endpoints. Transports move messages between running programs.
At the transport layer of abstraction, messages flow through transports.
At run time, programs automatically construct transport buses using configuration information supplied by the FTL server. Publishers and subscribers automatically use these transport buses to move messages directly from a publisher in one FTL client program to subscribers in other FTL client programs.
In its most simplified definition, a bus consists of a wire and protocol for using it. You can understand a transport bus in this way too. Its wire can include network objects, file objects, special hardware. FTL library code within the program processes implements a variety of protocols.
The following diagram depicts the parts of the transport bus in various orange colors. Notice that the transport bus is conceptually located outside and between the application program processes (the wire). In actuality, the bus also extends to transport objects (T) inside each of the processes (the protocol implementation).
You can define and configure transports in the transports grid of the FTL server GUI. You can bind application endpoints to transport definitions in the applications grid of the FTL server GUI.
Transports are transparent to programs. Program code does not refer to transports. You can modify transport definitions in the FTL server without modifying programs. Modifying the transport definitions changes the way FTL moves messages among programs, but program code is independent of this change in behavior.
Transports are also transparent to programmers. Programmers cannot access transport objects, which are internal to the TIBCO FTL library. Programmers do not need to concern themselves with the details of transport definitions. The default transport definition is sufficient for many programs. During program development, you can run programs using the default definition. During deployment, testing, and production, application administrators can modify network behavior by substituting different transport definitions.
For simplicity, the preceding diagrams depict only two application programs, with one publisher and one subscriber in each program. However, FTL supports any number of communicating processes with any number of publisher and subscriber objects, as the following diagram depicts.
