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.
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.
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.)
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.
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.
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).