In This Section |
TODO Redo diagrams in Gliffy |
|
X applications connect to one another and the outside world using the Simple Message Abstraction layer, SMA. SMA defines a simple yet robust messaging API that allows any messaging provider to be seamlessly plugged in the the platform by implementing a bus binding for the provider.
An application's AepEngine 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 in a transactionally atomic fashion. This document outlines the core concepts of SMA as they pertain to an application developer. At a high level a developer thinks in terms of defining the messages that make up an application's interaction grammar and the logical channels on which those messages are transported to wire together the various application participants in the system:
A message bus can be thought of as a messaging sandbox that groups together participants that exchange messages.
A bus user is a messaging participant, An Aep engine will by default use its name as the bus username.
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 Messages for more details.
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, but also provides support for Custom encodings.
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.
Specifying that a channel should be joined indicate interest in receiving messages on a channel. When a channel is configured for join the bus provider issues subscriptions for the topic. When a bus channel is closed the application can elect to 'leave' the channel meaning previously issued subscription would be removed.
SMA supports two qualities of service for a message channel, BestEffort and Guaranteed. With BestEffort it is expected that in the absense of failures in the application or message fabric that 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.
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 Messages
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:
The Talon Application Data Modeler generates Factory objects that facilitate serialization and deserialization of messages. This is largery
