Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved


Chapter 3 Destinations : Wildcards

Wildcards
You can use wildcards when specifying statically created destinations in queues.conf and topics.conf. The use of wildcards in destination names can be used to define "parent" and "child" destination relationships, where the child destinations inherit the properties and permissions from its parents. You must first understand wildcards to understand the inheritance rules described in Inheritance.
Wildcards * and >
To understand the rules for inheritance of properties, it is important to understand the use of the two wildcards, * and >.
The wildcard > by itself matches any destination name.
When > is mixed with text, it matches one or more trailing elements. For example:
 foo.>
Matches foo.bar, foo.boo, foo.boo.bar, and foo.bar.boo.
The wildcard * means that any token can be in the place of *. For example:
 foo.*
Matches foo.bar and foo.boo, but not foo.bar.boo.
 foo.*.bar
Matches foo.boo.bar, but not foo.bar.
Overlapping Wildcards and Disjoint Properties
Some destination properties are disjoint, and the server allows that property to be set only once for each destination. If an existing destination includes a value for a disjoint property and you attempt to assign a different value, the action will fail.
Overlapping wildcard destinations can cause conflicts with disjoint properties. For example, consider the following configuration of the channel property:
topic.multicast.> channel=multicast_1
topic.multicast.quotes.* channel=multicast_2
The topic topic.multicast.quotes.tibx would be assigned both channels, multicast_1 and multicast_2. Therefore, the wildcard topics topic.multicast.> and topic.multicast.quotes.* cannot coexist. Their creation would fail.
The disjoint destination properties are:
Wildcards in Topics
TIBCO Enterprise Message Service enables you to use wildcards in topic names in some situations:
If you subscribe to a topic containing a wildcard, you will receive any message published to a matching topic. For example, if you subscribe to foo.* you will receive messages published to a topic named foo.bar.
You can subscribe to a wildcard topic (for example foo.*), whether or not there is a matching topic in the configuration file (for example, foo.*, foo.>, or foo.bar). However, if there is no matching topic name in the configuration file, no messages will be published on that topic.
If foo.bar is not in the configuration file, then you can publish to foo.bar if foo.* or foo.> exists in the configuration file.
On routed topic messages, subscribers must specify a topic that is a direct subset (or equal) of the configured global topic. For more information, see Wildcards.
Wildcards in Queues
TIBCO Enterprise Message Service enables you to use wildcards in queue names in some situations. You can neither send to nor receive from wildcard queue names. However, you can use wildcard queue names in the configuration files.
For example, if the queue configuration file includes a line:
foo.*
then users can dynamically create queues foo.bar, foo.bob, and so forth, but not foo.bar.bob.
Wildcards and Multicast
Messages published to multicast-enabled topics are sent on the multicast channels defined for those topics. A wildcard may cover multiple multicast-enabled topics, each on a different multicast channel.
For example, consider the following configuration:
>
topic.info
topic.quotes
topic.multicast.info channel=channel-1
topic.multicast.quotes channel=channel-2
A message consumer subscribed to topic > will receive messages published to topic.info and topic.quotes over TCP, will receive messages published to topic.multicast.info over the multicast channel channel-1 and messages published to topic.multicast.quotes over the multicast channel channel-2. Note that this means a wildcard consumer may receive messages over both multicast and TCP.
Wildcards and Dynamically Created Destinations
As described in Dynamically Creating Topics and Queues, the EMS server may dynamically create destinations on behalf of its clients. The use of wildcards in the .conf files can be used to control the allowable names of dynamically created destinations.
The same basic wildcard rules apply to dynamically created destinations as described above for static destinations.
Examples
If the queues.conf file contains:
 >
The EMS server can dynamically create a queue with any name.
If the topics.conf file contains only:
 foo.>
The EMS server can dynamically create topics with names like foo.bar, foo.boo, foo.boo.bar, and foo.bar.boo.
If the queues.conf file contains only:
 foo.*
The EMS server can dynamically create queues with names like foo.bar and foo.boo, but not foo.bar.boo.
If the topics.conf file contains only:
 foo.*.bar
The EMS server can dynamically create topics with names like foo.boo.bar, but not foo.bar.

Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved