FTL Configuration Overview

A cluster of FTL servers provides a single FTL realm (that is, a configuration shared by FTL applications). FTL applications connect to an FTL server, retrieve the FTL realm configuration, and perform messaging within the single FTL realm. Administrative clients connect to FTL server for configuration and monitoring purposes.

You may want multiple FTL realms (e.g., for production and test environments). In that case, you would run separate clusters of FTL servers, one for each realm. FTL realms do not interact with each other.

FTL supports two messaging architectures:

• Broker-based: Publishers send messages to FTL server. FTL server delivers those messages to interested subscribers. Client programs connect to FTL server, not to each other. This architecture can provide delivery assurance and other related features.

• Peer-to-peer: Publishers send messages directly to interested subscribers running in other client programs. Client programs connect to FTL server to receive configuration, but do not send application messages to FTL server. Administrators must ensure that related client programs can communicate with each other.

FTL also supports two messaging models:

• Destinations: In this model, client programs express interest in one or more destinations. Messages are sent to a specific destination and are delivered to any applications that have expressed interest in that destination. This model is designed for ease of use. This model does not support peer-to-peer messaging architectures.

• Content matching: In this model, client programs express interest in the content of messages. For example, an application might be interested in messages that specify a particular field with a particular value, or messages that specify some combination of fields. This model is designed to minimize messaging overhead. This model supports broker-based or peer-to-peer messaging architectures.

Your task is to pick a combination that suits your needs, then configure the FTL realm accordingly.

• Destinations, broker-based: The destinations model is likely to be simplest to use and most intuitive. New users of FTL are encouraged to use the destinations model.

  • Administrators must plan which client programs will use which destinations.

  • Administrators may use the default FTL configuration, or administrators may configure their own persistence clusters, persistence stores, and destinations.

• Content matching, broker-based: This combination is next simplest. New users of FTL are encouraged to use destinations instead.

  • Administrators must plan how to distribute messages, either by content or by separating traffic among different persistence stores.

  • Administrators must configure persistence clusters, persistence stores, durable templates, applications, and endpoints. Administrators may also configure message formats.

• Content matching, peer-to-peer. This combination is for applications that require absolute minimum latency or maximum throughput, but do not require delivery assurance or other broker-based features. This combination may require more complex configuration and applications.

  • Administrators must plan how to distribute messages, either by content or by separating traffic among different transports.

  • Administrators must configure applications, endpoints, and transports. Administrators may also configure message formats.

The sections that follow describe each combination in more detail. Also see Realm Administration Tools for available methods of configuring and monitoring the FTL realm.

You must also consider how to secure FTL servers and FTL applications. Broker-based architectures offer more flexibility in configuring security (for example, the ability to bring your TLS certificates, or to use oauth2 authentication). For details, see Securing FTL: Overview.