The figure below outlines the high level components that make up a Talon application. 

Design Time Components

From an application developer's perspective, authoring an X application involves:

• Modeling application messages.
• Optionally, modeling of application state.
• Writing the event handlers that respond to messages, operate on state and emit outbound messages. 
• Configuration that wires together applications via messaging.

ADM: The Application Data Modeler

The application data modeler provides an XML based modeling language that generates messages and state as plain old java objects. ADM modeled objects are highly optimized and shield application developers from concerns around serialization, transport and persistence of these objects. 

See Modeling Message and State

Application Event Handlers

From an application developer perspective, a Talon application is essentially a set of event handlers via @EventHandler annotated methods that are bound together by an application entry point class. The application's event handlers are invoked in response to Messages or other platform events. Event Handlers are single threaded and generally must be non-blocking. A typical event handler will consume a message, perform business logic, may update state, and/or send outbound messages. The Talon runtime handles the underlying plumbing to ensure that the operations of receipt, state updates and outbound sends are atomic and reliable. 

The following shows a minimal Talon application

For more information on writing event handlers, see the Talon Programming section. 

DDL Config : Domain Descriptor Language

X Application code doesn't work directly with the underlying infrastructure components. For example, binding of an application to a particular message bus implementation is a configuration concern. The platform's Domain Descriptor Language (DDL) is the platform's configuration schema. It allows developers to configure a group of related applications in a singe xml-based configuration artifact. Deployment tools such as Robin use this configuration to seed the the platform's configuration repository, where it is then used by Talon VMs when they are launched. 

Because the platform handles much of the non-functional operational aspects under the covers, many of the knobs it exposes don't have an impact on application code. Therefore, an application developer often won't need to work with much more than the configuration specified above.

See Understanding Configuration

Key Runtime Components

AEP

Atomic Event Processing refers to the transactional event processing paradigm in Talon application that an AepEngine implements. An AepEngine sits at the heart of every Talon application. An AepEngine orchestrates the processing of inbound messages, business logic processing, replication and persistence of state changes and outbound messaging. This relieves application event (message) handlers from the non-functional concerns of interfacing with messaging providers, persistence layers and transaction coordination. 

See What is an AEP Engine?

SMA

Talon's Simple Messaging Abstraction layer provides a generic messaging API that encapsulates the set of messaging primitives required by the platform. This allows the platform to inter-operate seamlessly with any messaging provider by proving binding implementations that are simple to write. At a high level, SMA exposes the concepts of buses and channels of an application. An application sends and receives messages over bus channels which are mapped via configuration to an underlying messaging provider destination. 

See Working with Messaging

ODS

AEP engines rely on Talon's Operational Data Store. An ODS Store provides HA capabilities for an application via memory-memory multi-peer replication, disk-based persistence, or both. An ODS store provides high performance asynchronous transaction facilities that an AepEngine uses in conjunction with SMA to achieve Atomic Event Processing. 

Important ODS Concepts include:

• Replication: The primary means of achieving persistence for an ODS Store is by pipelined, memory-memory replication of transactions to one or more hot backup peers. If a primary application instance fails the backup takes over with no loss of data.
• Transaction Logs: An ODS Store can also log to binary transaction logs as a secondary persistence mechanism if the connection to the backup is lost or a cold restart is required. 
• CDC: To allow asynchronous yet transactionally consistent syphoning of application state to back end or legacy systems, ODS supports the ability to perform Change Data Capture with a simple callback-based mechanism to push state changes. 
• ICR: Inter-Cluster Replication allows replication of the store's recovery stream to another data center over messaging, providing an asynchronous and transactional consistent disaster recovery mechanism. 

See Application Storage. 

XVM

 A Talon XVM serves as a container for Talon micro apps and provides management capabilities for the XVMs that it contains. Key features of the Talon XVM include:

• Lifecycle management of applications.
• Alerting and Lifecycle Event emission. 
• Emission of heartbeats that contain detailed system, platform and application exposed statistics for low-impact remote application monitoring.
• Emission of application trace for low-impact remote application monitoring.
• Command and Control; XVMs provide capabilities for exposing and invoking commands that are out of band with application messaging. 

See The XVM

Discovery

The platform's discovery facilities provides plugin mechanisms for ODS store's to discover one another, and for tooling to discovery running instances of applications. Out of the box, the platform supports discovery of multicast and over messaging.