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 that 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:

1. To receive messages, from samples/bin, run:

   • In Linux and macOS, the command is:
     

     $./tibftlrecv localhost:8080

   • In Windows, the command is:
     

     >tibftlrecv localhost:8080

     The host is ready to receive messages sent by the publisher.

     

2. 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 can 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 will 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 content-based addressing using Content Matchers.