Destination Concepts
A destination must be one of three types. See Destination Types for details.
-
Topics: For publish-and-subscribe messaging.
-
Queues: For point-to-point messaging.
-
Maps: For storage of key-value pairs.
The name of a destination determines its type. Topics have no special prefix. Queue destinations are prefixed by the string “Q:
”. Maps are prefixed by the string “M:
”. For full details, see Destination Name Syntax.
To use a destination in an application program, the administrator must first configure a matching destination in the FTL realm definition. Configured destinations typically incorporate wildcards, representing a group of destinations for possible use by client programs. See Destination Matching and Wildcards. Note that client programs may not use wildcard destinations; only specific destinations are allowed.
See FTL Server GUI: Configuration or FTL Server Web API for details on configuring destinations. Alternatively, client programs may also use the configured destinations in the default FTL realm definition, which is created when starting a cluster of FTL servers for the first time.
A configured destination includes a set of parameters used to initialize subscriptions on that destination. Access control may also be configured for a destination. Finally, a configured destination must also indicate its persistence store and cluster. See Destination Configuration for the full list of properties. See Authorization for information on access control. See also Persistence: Stores and Durables.
Configured destinations may overlap (that is, a destination used by an application program may match more than one configured destination). See Inheritance for details on how destination properties and access control lists are merged for overlapping destinations. Overlapping destinations must always use the same persistence store and cluster.