This section and its subsections provide details on how to write Talon application code. Here we'll cover the basic programming restrictions that application developers should obey, discuss the coding differences between coding for Talon's HA Models and introduce, the annotations used for your application code to interface with the Talon runtime. 

Basic Programming Rules

The Talon programming model is quite straightforward: all business logic in a Talon application is performed by event handlers that are invoked by Talon on response to received messages. The event handlers update state and generate outbound messages to interact with the outside world as a result of the business logic processing. Before diving into more details this section describes the high level rules that developers must obey when working with Talon.

Working with State Replication

State Replication is the simpler of Talon's two High Availability models. With State Replication, Talon replicates changes to state and the outbound messages emitted by your application's message handlers. In the event of a failover to a backup or a cold start recovery from a transaction log your application's state is available at the same point where processing left off, and the engine will retransmit any outbound messages that were left in doubt as a result of the failure.

Working with Event Sourcing

Of Talon's two High Availability models, Event Sourcing requires more discipline to use but can yield better performance particularly for latency sensitive applications. In event sourcing, rather than replicating changes to state object and outbound messages, an application's inbound messages are replicated and replayed to produce the same application state and outbound messages. This section discusses the anatomy of an application coded for Event Sourcing.

Talon Annotations

In the preceding sections the usage of the EventHandler annotation was shown as a means of exposing message handler method to the Talon. Talon provides several other annotations that can be used on your applications main class. This section introduces some of the additional annotations that your application's main class can use to expose the rest of your application to the runtime.

Working with Talon Transactions

An AEPEngine handles processing of each inbound message it receives in an atomic fashion - the acknowledgment of message receipt, application changes to state and outbound messages constitute an atomic unit of work. Each such atomic unique of work is considered an AEP transaction. Transactions are, for the most part, handled transparently from an application's standpoint. Application developers simply write message handlers with the assurance that the processing done therein will be atomic.