Overview

The Talon programming model is quite straightforward: all business logic in a Talon application is performed 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. 

There are however several general high level principles that developers must follow when working with the platform. These are summarized below. 

Messaging

Inbound Messages

An application may not modify inbound messages. Aside from being good practice, the platform relies on this immutability to do parallel inbound message journalling and replication. 

See Receiving Messages

Outbound Messages

Once an application sends an outbound it must not attempt to modify or reuse the message. This implies that any particular message instance can only be sent once. Applications may copy a message that has been sent and send it elsewhere. 

See Sending Messages

Messages Scoped to Handlers

In general, it is bad practice to hold onto a message or its embedded entity fields beyond the scope of a message handler. This is because the platform pools these messages and their underlying contents can be reset after return from a handler. This means that if applications intend to hold onto a message or a portion of the message in application state, it should copy the pieces it needs. 

In advanced use cases where an application must hold onto a message or one of its embedded entities for a short period of time copy can be avoided by aquiring a reference to the message, but this should be done with extreme care. 

See Working with Advanced Features for more information. 

Threading

State is not Thread Safe

The micro app and micro service models espouse a model where state is private to the application. Talon applications take this concept even further by making application state private to a single application processing thread. This restriction is key to Talon's ability to scale as contended access to state is one of the main bottlenecks in any computing architecture. 

This means:

• Accessing an application's state objects outside of a message handler is forbidden. Any change to an applications state must be performed for the underlying dispatch thread in an application event handler triggered by either receipt or injection of a message.
• Applications should be designed to scale horizontally by partitioning state. 

No Blocking In Application Handlers

Talon micro apps are optimized for stream oriented message processing. This means that message handlers should never perform blocking operations. Additionally, as Talon applications have a single threaded state model Talon is not optimized for long running compute intensive operations.

In practice this is generally not an issue for the class of applications targets by Talon:

• Talon handles I/O operations for applications so applications should not be working with blocking I/O source. 
• Generally, if an application needs to make a blocking callout to interact with a remote resource the interaction should be done over messaging.
• For compute intensive tasks triggered by processing a message, applications may schedule the work on another thread and inject the results back into the engine to update application state. 

Event Sourcing Consideration

Of State Replication and Event Sourcing the latter is the more advanced of Talon's two High Availability models. The Event Sourcing model is best suited to applications that require ultra low latency, but it does impose some additional programming restrictions. An applications using Event Sourcing must be able to exactly reconstruct the same state and outbound messaging stream by replying the same sequence of inbound events. This implies that business logic that updates state must not rely on any environmental state when making updates to its recoverable state or outbound messages. For example setting the system time in an outbound message would not produce the same outbound message when the event stream is replayed at a later date or on a different system. 

See Event Sourcing and Environment Replication