Publish-Subscribe Example
If you completed the Quick Start, you completed a publish-subscribe example. A subscriber receives any associated publisher messages as they are published. If a publisher publishes a message and there are no associated subscribers (or a specific subscriber has not yet been started), the messages are not received by the subscribers. Messages are not stored as they are in the Persistent Publish-Subscribe Example in the next section. For more details, see the FTL Administration guide, Publish-Subscribe Models.
Use the tibftlsend
sample application as a publisher to send messages which are received by the subscriber in the tibftlrecv
sample application. Each sample application sends or receives a single message then exits. The applications are solid, well structured, and well documented examples to start your own development from. The examples demonstrate good practices in areas like error and exception handling.
Before you start, open two terminals. Make sure you have run the setup
command and started the FTL server. See the Command Reference.
Perform these steps:
-
To receive messages, from
samples/bin
, run: -
In the other terminal, from
samples/bin
, run:-
In Linux and macOS, the command is:
$. ./tibftlsend localhost:8080
-
In Windows, the command is:
>tibftlsend localhost:8080
-
Check Your Result
In the terminal running tibftlsend
, you will see the following output:
#
# tibftlsend
# (FTL) TIBCO FTL Version <n.n> V<n>
#
# Client name tibftlsend_40314
#
Sending 'hello world' message
In the terminal running tibftlrecv
, you’ll see the following output which is a string dump of the message:
#
Received message
{string:type="hello", string:message="hello world earth"}
In many of these examples, you’ll see some text in the output such as:
Client name tibftlxxxx #####
FTL dynamically generates these human-readable strings to identify each client in an FTL messaging realm. If you use the status display capabilities of the FTL user interface, you’ll see these numbers displayed as the Client Label. For details on Client IDs and Client Labels, see Client Status Details. In this case, there are two fields, type
and message
, both of type string
. The use of typed and named message fields allows for content-based addressing using Content Matchers.