Chapter 2 Working With Channels and Destinations : Understanding Channels and Destinations

Understanding Channels and Destinations
Channels (other than local channels) represent physical connections to a resource, such as a Rendezvous daemon. Destinations in a channel represent listeners to messages from that resource, and they can also send messages to the resource. All destinations for a particular channel use the same server.
For example, in Figure 2 below, the channel is configured to listen to the flow of messages on Rendezvous. The orders destination directs BusinessEvents to map messages coming in on the subject, orders, to the new_order simple event.
Figure 2 Channels and Destinations
You can choose from the following types of channels:
TIBCO Rendezvous channels  connect TIBCO BusinessEvents to TIBCO Rendezvous sources and sinks.
JMS channels  connect TIBCO BusinessEvents to TIBCO Enterprise Message Service provider sources and sinks
Local channels  connect multiple rule sessions at runtime.
Local Channels
Local channels serve a different function from other kinds of channels. Other kinds of channels pass information into and out of the BusinessEvents application. Local channels are referenced in functions and are used to send events between rule sessions. Local channels are used in applications that have multiple rule sessions (multiple agents) in one node, and that use In Memory object management. They are not required or used with Cache object management.
Local channels pass the same event object between the rule sessions (agents). Consuming the event in one rule session does not affect other sessions that also received the event over a local channel. A use count is maintained for each event to track how many sessions have received the event but not consumed it. The use count of the event is incremented depending on the number of sessions it is routed to. When an event is consumed in one agent, BusinessEvents deletes the reference to the event in that agent and it decrements the use count of the original event instance.
See Creating a Local Destination and Using a Local Destination in a Rule for details on using local channels.
Selecting a Serializer
BusinessEvents uses serializers to convert events to messages and a deserializer to convert incoming messages to events. Serializers and deserializers are provided for JMS and Rendezvous. (Local channels do not require serializers.)
Figure 3 Serializer and Deserializer Behavior
When you configure a destination, you select the appropriate serializer. For JMS messages, header properties are mapped to event properties, and message bodies are mapped to event payloads. Which serializer you choose depends on the type of message body and payload. Similarly, for Rendezvous destinations, you would choose the appropriate serializer, depending on the presence of a payload, and the type of payload if present.
For more details see Selecting a JMS Serializer and Selecting a Rendezvous Serializer
Deploy-time Configuration
The following channel-related configuration tasks are performed at deploy time.
Enabling and Disabling Destination Listeners: You can enable and disable destination listeners when configuring a BusinessEvents archive for deployment. See notes for the Enable field, in the section BusinessEvents Archive Resource Reference.
Message Acknowledgment
When messages come through channels, BusinessEvents creates events using the messages, and asserts the events into working memory. Depending on the message type, BusinessEvents acknowledges the receipt of these messages. Some messages do not require acknowledgement, for example reliable Rendezvous messages do not require acknowledgment.
Message Acknowledgment Timing for Each Object Management Type
The timing of the message acknowledgment is handled differently by each object management type (see Chapter 14, Understanding Object Management and Fault Tolerance for details on each type):
Persistence  All received messages are acknowledged after data is written to disk, during a checkpoint.
Cache  Messages are acknowledged at the end of each conflict resolution cycle, also known as a run to completion (RTC) cycle.
In memory  The message is acknowledged when the simple event is consumed, that is, when consumeEvent(event) is called, or when the event expires (at the end of the time to live period, if set).