Universal Messaging 10.11 | Concepts | Deployment | Server | Data Routing using Channel Joins
 
Data Routing using Channel Joins
Joining a channel to another channel or queue allows you to set up content routing so that events published to the source channel will be passed on to the destination channel/queue automatically. Joins also support the use of filters, thus enabling dynamic content routing.
Please note that while channels can be joined to both channels and queues, queues cannot be used as the source of a join.
Channels can be joined using the Universal Messaging Enterprise Manager GUI or programmatically.
When creating a join there is one compulsory parameter and two optional ones. The compulsory parameter is the destination channel. The optional parameters are the maximum join hops and a filter to be applied to the join.
Joins can also be created in several configurations:
*A join may be created between a channel on a realm and a channel or queue on another realm federated with the source realm (see Federation Of Servers for related information about setting up federation between two realms);
*A join can be created from a channel on a clustered realm to a channel or queue within the same cluster. A non-clusterwide channel can be joined to a cluster-wide channel or queue, but not vice versa;
*A channel can be joined from a channel on one cluster to a channel on another cluster by using an inter-cluster join (see Inter-Cluster Joins).
*Universal Messaging supports joins where the destination (incoming) is a queue. Universal Messaging does not support joins where the source of the join is a queue.
Hop Count
Joins have an associated hop-count, which can optionally be defined when the join is created. The hop count allows a limit to be put on the number of subsequent joins an event can pass through if published over this join. If a hop count is not defined for a join, it will default to 10.
The hop count is the number of intermediate stores between the source channel and the final destination. As an example, imagine we have 10 channels named "channel0" to "channel9" and all these channels are joined sequentially. When we publish to channel 0, if the join from channel0 to channel1 has a hop count of 5 then the event will be found on channel0 (the source channel), channels 1 to 5 (the intermediate channels) and channel6 (the endpoint).
Event Filter
Joins can be created using filters , so that only specific events published to the source channel that match certain search criteria will be routed to the destination channel.
Loop Detection
Joins allow the possibility of defining a loop of joined channels. To prevent channels receiving multiple copies of the same event, Universal Messaging implements loop detection on incoming events. To illustrate this, imagine a simple example with two channels (channel0 and channel1) and we create a loop by joining channel0 to channel1 and channel1 to channel0. If we publish to channel0 the event will also be published to channel1 over the join. But channel1 is joined to channel0 too, so now the event would get published to channel0 again. Without Universal Messaging's loop detection, this cycle would repeat until the maximum hop count has been reached.
To prevent this, Universal Messaging detects when a message which has already been published to a channel or queue and will not publish it a second time.
Multiple Path Delivery
Universal Messaging users can define multiple paths over different network protocols between the same places in Universal Messaging. Universal Messaging guarantees that the data always gets delivered once and once only.
Archival Joins
An archival join is a specific type of join made between a channel and a queue, where events will not be checked for duplication. Events that are published to the source channel will appear in the destination queue. This may result in duplicate events in the queue if the queue has multiple sources.
A typical scenario for using this feature is if you have multiple routes that messages can take to reach the same destination, and you want to retain all duplicates at the destination. For example:
*if an event is duplicated at the source.
*if an event is copied from channel A -> B -> C and from channel A -> D -> C.
*if you define multiple paths over different network protocols between the same source and destination.
Without this feature, the duplicate detection would ensure that only one copy of the message is delivered to the destination queue.
Inter-Cluster Joins
Inter-cluster joins are added and deleted in almost exactly the same way as normal joins. The only differences are that the two clusters must have an inter-cluster connection in place, and that since the clusters do not share a namespace, each channel must be retrieved from nodes in their respective clusters, rather than through the same node.
See the section Inter-Cluster Connections for related information.
Related Links
For a description of how to set up and manage channel joins, see the section Creating Channel Joins in the Administration Guide. The description details the usage based on the Enterprise Manager, but the same general principles apply if you are using the API.