Destinations : Destination Overview

Destination Overview
Destinations for messages can be either Topics or Queues. A destination can be created statically in the server configuration files, or dynamically by a client application.
Servers connected by routes exchange messages sent to temporary topics. As a result, temporary topics are ideal destinations for reply messages in request/reply interactions.
Table 8 summarizes the differences between static, dynamic, and temporary destinations. The sections that follow provide more detail.
 
Static destinations let administrators configure EMS behavior at the enterprise level. Administrators define these administered objects, and client programs use them—relieving program developers and end users of the responsibility for correct configuration.
Dynamic destinations give client programs the flexibility to define destinations as needed for short-term use.
Temporary destinations are ideal for limited-scope uses, such as reply subjects.
Scope of Delivery
Static destinations support concurrent use. That is, several client processes (and in several threads within a process) can create local objects denoting the destination, and consume messages from it.
Dynamic destinations support concurrent use. That is, several client processes (and in several threads within a process) can create local objects denoting the destination, and consume messages from it.
Temporary destinations support only local use. That is, only the client connection that created a temporary destination can consume messages from it.
However, servers connected by routes do exchange messages sent to temporary topics.
Administrators create static destinations using EMS server administration tools or API.
Client programs create dynamic destinations, if permitted by the server configuration.
Client programs create temporary destinations.
Client programs lookup static destinations by name. Successful lookup returns a local object representation of the destination.
A static destination remains in the server until an administrator explicitly deletes it.
A dynamic destination remains in the server as long as at least one client actively uses it. The server automatically deletes it (at a convenient time) when all applicable conditions are true:
Topic or Queue  all client programs that access the destination have disconnected
Topic  no offline durable subscribers exist for the topic
Queue  queue, no messages are stored in the queue
A temporary destination remains in the server either until the client that created it explicitly deletes it, or until the client disconnects from the server.
Destination Names
A destination name is a string divided into elements, each element separated by the dot character (.). The dot character allows you to create multi-part destination names that categorize destinations.
For example, you could have an accounting application that publishes messages on several destinations. The application could prefix all messages with ACCT, and each element of the name could specify a specific component of the application. ACCT.GEN_LEDGER.CASH, ACCT.GEN_LEDGER.RECEIVABLE, and ACCT.GEN_LEDGER.MISC could be subjects for the general ledger portion of the application.
Separating the subject name into elements allows applications to use wildcards for specifying more than one subject. See Wildcards for more information. The use of wildcards in destination names can also be used to define "parent" and "child" destination relationships, where the child destinations inherit the properties from its parents. See Inheritance of Properties.
Static Destinations
Configuration information for static destinations is stored in configuration files for the EMS server. Changes to the configuration information can be made in a variety of ways. To manage static destinations, you can edit the configuration files using a text editor, you can use the administration tool, or you can use the administration APIs.
Clients can obtain references to static destinations through a naming service such as JNDI or LDAP. See Creating and Modifying Destinations for more information about how clients use static destinations.
Dynamic Destinations
Dynamic destinations are created on-the-fly by the EMS server, as required by client applications. Dynamic destinations do not appear in the configuration files and exist as long as there are messages or consumers on the destination. A client cannot use JNDI to lookup dynamic queues and topics.
When you use the show queues or show topics command in the administration tool, you see dynamic topics and queues have an asterisk (*) in front of their name in the list of topics or queues. If a property of a queue or topic has an asterisk (*) character in front of its name, it means that the property was inherited from the parent queue or topic and cannot be changed.
See Dynamically Creating Topics and Queues for details on topics and queues can be dynamically created by the EMS server.
Temporary Destinations
TIBCO Enterprise Message Service supports temporary destinations as defined in JMS specification 1.1 and its API.
Servers connected by routes exchange messages sent to temporary topics. As a result, temporary topics are ideal destinations for reply messages in request/reply interactions.
For more information on temporary queues and topics, refer to the JMS documentation described in Third Party Documentation.
Destination Bridges
You can create server-based bridges between destinations of the same or different types to create a hybrid messaging model for your application. This allows all messages delivered to one destination to also be delivered to the bridged destination. You can bridge between different destination types, between the same destination type, or to more than one destination. For example, you can create a bridge between a topic and a queue or from a topic to another topic.
See Destination Bridges for more information about destination bridging.