The figure below outlines the high level components that make up a Talon application.
From an application developer's perspective authoring an X application involves:
The application data modeler provides an XML based modeling language that is used to generate 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.
<?xml version="1.0"?>
<model xmlns="http://www.neeveresearch.com/schema/x-adml"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
namespace="com.example.helloapp"
defaultFactoryId="1">
<factories>
<factory name="HelloDataFactory" id="1"/>
</factories>
<messages>
<message name="HelloRequest" id="1">
<field name="fromName" type="String" id = "1"/>
</message>
<message name="HelloReply" id="2">
<field name="text" type="String" id = "1"/>
<field name="count" type="Long" id = "2"/>
</message>
</messages>
<entities>
<entity name="MyState" id="100">
<field name="counter" type="Long" id = "1"/>
</entity>
</entities>
</model> |
See Modeling Messages and State
From an application author perspective, a Talon application is essentially a set of event handlers via @EventHandler annotated methods 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 and 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.
@AppHAPolicy(value = StateReplication)
public class HelloApp {
private Repository repository = new Repository();
private AepMessageSender sender;
@AppInjectionPoint
final public void setMessageSender(AepMessageSender messageSender) {
this.messageSender = messageSender;
}
@EventHandler
final public void onMessage(Message message) {
// update state
repository.setCounter(repository.getCounter() + 1);
// send hello message
HelloMessage helloMessage = HelloMessage.create();
helloMessage.setText("Hi There");
messageSender.sendMessage("hello-replies", helloMessage);
}
} |
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 which allows configuring a group of related applications in a singe xml based configuration artifact. This configuration is used by deployment tools such as Robin to seed the the platform's configuration repository where it is then used by Talon VMs when they are launched.
<model>
<buses>
<bus name="hello-bus">
<provider>solace</provider>
<host>192.168.1.100</host>
<port>55555</port>
<channels>
<channel name="hello-requests">
<key>hello/requests</key>
<qos>BestEffort</key>
</channel>
<channel name="hello-replies">
<key>hello/replies</key>
<qos>BestEffort</key>
</channel>
</channels>
</bus>
</buses>
<apps>
<app name="hello-app" mainClass="com.example.HelloApp">
<messaging>
<buses>
<bus name="hello-bus">
<channels>
<channel name="hello-requests" join="true">
<channel name="hello-replies" join="false">
</channels>
</buses>
</messaging>
</app>
</env>
<servers>
<server name="hello-vm">
<apps>
<app name="hello-app" autoStart="true" />
</apps>
</server>
</servers>
</model> |
See Understanding Configuration
Atomic Event Processing refers to the transactional event processing paradigm in Talon application that is implemented by an AepEngine. An AepEngine sits at the heart of every Talon application and 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.
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 simple to write binding implementations. At a high level, SMA exposes the concepts of buses and channels ot an application. An appliction sends and receives messages over bus channels which are mapped through configuration to an underlying messaging provider destination.
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 and is used by an AepEngine in conjunction with SMA to achieve Atomic Event Processing.
Important ODS Concepts include
See Application Storage.
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
See The XVM
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.