Overview

Because Talon applications communicate with one to one another (and external applications) exclusively using Talon's Simple Message Abstraction layer (SMA), it is important to understand the basic abstractions and concepts that SMA provides in order to best author scalable applications that can evolve over time. This section and its subsections will familiarize you with the messaging facilities in Talon in more depth.

SMA defines a simple yet robust messaging API that allows any messaging provider to be seamlessly plugged into the platform by implementing a bus binding for the messaging provider. The AepEngine underlying a Talon application handles much of the interaction with SMA on behalf of the application. It manages the lifecycle of an application's message bus bindings, provides send methods and performs dispatch of received messages to application handlers in a transactionally atomic fashion with respect to the application's state updates.

Below we discuss the core concepts of SMA as they pertain to an application developer. At a high level, application developers model messages using the Application Data Modeler, and map those messages to logical message buses and channels over which they will flow. Via configuration, the logical bus is bound to actual message bus implementation that will be used at runtime (e.g. a url of a message broker), and the message channels are mapped to topics on that message bus.

Core Concepts

Message Bus

A message bus can be thought of as a messaging sandbox that groups together participants that exchange messages. 

Message Bus User

A bus user is a messaging participant. An Aep engine will by default use its name as the bus username. 

Message (View)

The MessageView interface defines the interface for a message - the unit of exchange between messaging participants. A Message is a Plain Old Java Object that implements MessageView and provides accessors to message's underlying fields and handles encoding and decoding of the message for transmission. Messages are modeled using ADM.

See the Modeling Message and State for more details. 

Message Encoding

SMA transports MessageViews as bytes encoded according the message view's encoding. The platform natively supports generation of messages that can be encoded as Json, Protobuf, or Xbuf. The platform currently has limited support for Custom encodings which can be useful for sending and receiving in formats that are not native to the platform. At this time Custom encoding is only available in custom message bus bindings, but broader support is anticipated in the near future. 

Message Channel

A message channel serves as a named conduit for messages between messaging participants. A sender sends messages on a message channel, and a receiver expresses interesting in receiving those messages by joining a channel. Channels are mapped to a physical message bus provider destination such a topic via a channel key, which allows the channel to mapped to different message providers via configuration. 

Join and Leaving Channels

Specifying that a channel should be joined indicates interest in receiving messages on a channel. When a channel is configured for join the bus provider issues subscriptions for the associated topic. When a bus channel is closed the application can elect to 'leave' the channel, meaning previously issued subscriptions would be removed. 

See Sending and Receiving Messages

Channel Qos

SMA supports two qualities of service for a message channel: BestEffort and Guaranteed. With BestEffort, in the absence of failures in the application or message fabric, messages won't be dropped. With Guaranteed, a messaging provider must support at least once delivery of messages even in the presence of message fabric or application failures. An AepEngine working with Guaranteed Qos can support exactly once processing of messages by filtering out duplicates providing the message bus provider provides appropriate ordering guarantees.

Channel Keys

A channel key serves as an abstraction around a message bus provider destination (typically a topic). The channel key allows the channel to be localized to a specific bus provider type via configuration. Message keys can be either static or dynamic. A dynamic key allows substitution of a variable portions in the topic by a sender or receiver at runtime where the dynamic components are sourced from fields on a message being sent or a channel filter.

For example, a message sent on a channel with a dynamic key of "Orders/${Region}${Firm}/${Symbol} that has getRegion() == "EMEA" and getRegion() = "BOA" and getSymbol() would be sent on a topic 'Orders/EMEA/BOA/MSFT'.

See Sending and Receiving Messages

Channel Filter

A channel filter is used to filter subscriptions issued for a channel that has a dynamic key. 

For example, a channel that is joined with a dynamic key of "Orders/${OrderState}/${Region} and a filter of "OrderState=New|Canceled;Region=US" would issue subscriptions for:

• Orders/New/US
• Orders/Canceled/US

See Sending and Receiving Messages