Apama 10.7.2 | Connecting Apama Applications to External Components | Standard Connectivity Plug-ins | The Universal Messaging Transport Connectivity Plug-in | Overview of using Universal Messaging in Apama applications | Choosing when to use Universal Messaging channels and when to use Apama channels
 
Choosing when to use Universal Messaging channels and when to use Apama channels
Typically, you want to
*Use Universal Messaging channels to send events from one correlator to another correlator, from adapters to correlators, or from correlators to external receivers. You also might want to use Universal Messaging channels when your application needs the flexibility for a monitor or context to be moved to another correlator. With Universal Messaging, you can re-deploy monitors sending or subscribing to Universal Messaging channels among the correlators connected to the same Universal Messaging realm without having to change any of the configuration for the Universal Messaging connectivity.
*Use Apama channels to send events from one context to one or more contexts in the same correlator.
Consider the case of multiple correlators connected to the same Universal Messaging realm. Specification of a Universal Messaging channel lets events pass between a context sending events on the channel and a context subscribed to that channel, regardless of whether the two contexts are
*in the same correlator, or
*in different correlators on the same host, or
*in different correlators on different hosts.
The first time a channel is used, the default behavior is that Apama determines whether it is a Universal Messaging channel or an Apama channel, and the designation is cached. After the first use, the presence or not of the channel in the Universal Messaging broker is cached, so further use of the channel is not impacted.
Using Universal Messaging channels lets you take advantage of some Universal Messaging features:
*Using a Universal Messaging cluster can guard against failure of an individual Universal Messaging realm server. See the Universal Messaging documentation for more information on clusters.
*Universal Messaging provides access control lists and other security features such as client identity verification by means of certificates and on the wire encryption. Using these features, you can control the components that each component is allowed to send events to.
Using a Universal Messaging channel rather than an Apama channel can have a lower throughput and higher latency. If there is a Universal Messaging channel that contexts and plug-ins send to and that other contexts and plug-ins in the same correlator (or in different correlators) subscribe to, all events sent on that Universal Messaging channel are delivered by means of the Universal Messaging broker. In some cases, this might mean that events leave a correlator and are then returned to the same correlator. In this case, using an Apama channel is faster because events would be delivered directly to the contexts and plug-ins subscribed to that channel.