Overview

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:

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 Messages 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, but also provides support for Custom encodings. 

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. 

Join and Leaving Channels

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. 

Channel Qos

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. 

Channel Keys

A channel key serves as an abstraction around a message bus provider destination (typically a topic). 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 of channel with a dynamic key of "Orders/${OrderState}/${Region} that has getOrderOrderState() == "New" and getRegion() = "EMEA" would be sent on a topic Orders/New/Emea. 

See Sending 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 Receiving Messages

Serialization and Deserialization

Expression of Interest