The Talon Manual

Versions Compared

Old Version 6

changes.mady.by.user Unknown User (colin)

Saved on

compared with

New Version Current

changes.mady.by.user Girish Mutreja

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
div
idtoc
classtoc
div
classtocTitle

In This Section

div
classtocContents

Table of Contents
maxLevel2
indent8px
stylenone

Overview

Excerpt

In this section, we describe the high-level structure of a Talon application and the basic source code artifacts that you will typically need when starting a new project in Talon.

Info
titleyoutube resource

For a short micro-tutorial on this topic please see: Micro-Tutorial #2: Your first Talon Micro App

 

As described in the The Talon Architectural Building Blocks Concepts and Architecture section a Talon application consistsof consists of the following ingredients: 

  • Modeled Messages: plain old java objects that are generated from an xml XML model that are is used to communicate between apps. 
  • Modeled State: plain old java objects that are generated from an xml XML model that make up your applications persistent state. 
  • A Main Class Entry Point: serves as your application's entry point. This class defines event handlers that perform your application's business logic in response to received messages. The main classA Talon XVM will load this class and introspect it to find annotations that (1) expose your application's event handlers and other objects that are used by the XVM to launch your application and (2) provide the XVM capabilities of injecting objects into your application during its lifecycle. 
  • Config DDL: An xml XML deployment descriptor model that configures applications, message buses, and application containers (XVMs) that together operate as a system of inerconnected interconnected and collaborating agents that provide overall business functions.  

This section introduces each of these ingredients at a high level as it pertains to starting a new project with Talon. Before digging into the sections below be sure to check out:

Project Layout

Assuming you haven't already starting started tweaking the starter app introduced in the Get Started The Starter App section, a good way to get started with developing a new Talon application is to use the Talon maven archetypes which generate bare bones functioning applications and project structure. The folder structure shown below reflects a typical project layout for a Talon as created using the talon-sr-processor maven archetype.

Section
Column
width260px

Column

Breaking it down we can see:

Java Source Folders

  • The main class Application.java which contains the application's business logic in defined Event Handlers
  • Send and Receive drivers which are test applicatons applications used to drive traffic to the main application.

Model Source Folders

  • state.xml Contains the xml XML model defining the application's state
  • message.xml Contains the xml XML model defining the applications' messages.

Test Source Folders

  • A TestFlow class which runs all of the applications in the JVM for easy testing of the entire application in a single process.

Conf Folder

  • Contains the DDL config.xml which defines:
    • Each applications application in the project (in this case Application, Sender, and Receiver
    • The message buses they use to communicate with one another
    • ...and The Talon XVMs, the contains used to launch instances of each application.

Maven Pom

  • The Talon archetypes use Maven to ease build and dependency management.
  • If you are using a different build tool you might have an and additional library folders and build scripts.

...

Messages and State objects are generated by Talon's Application Data Modeler (ADM) from xml models. Continue Reading: XML models. The ADM code generator has a maven plugin which makes it easy to integrate with maven builds and also supports command line and API invocation for integrating with other build tools such as Ant.

See Modeling Message and State to get started. 

Application Event Handlers

From the standpoint of the Talon runtime, your application is, for the most part, seen as a collection of annotated event handle methods that handle message types that it receives. Talon applications typically run within an a Talon XVM and expose an application main class that the XVM loads. For the simplest of Talon application, the application main class may implement all of the message handlers for the application. As your application grows in size in complexity you will likely find it convenient to implement handlers in a variety of classes. In this case, the application main class exposes the additional classes containing handlers to the Talon runtime at startup. 

See the Programming Talon Applications section for more information on writing event handlers. 

Config Deployment Descriptor (DDL)

Talon strives to separate out runtime and deployment details from the application (business logic) that you write. Application developers write message handlers that perform functions based on messages they receive, update state and send outbound messages that are received by other collaborating applications in a loosely coupled fashion. When it comes time to deploy an application the details of where applications are deployed, how they are wired together via message buses, and how they are configured for high availability are configured in XML using the platforms Deployment Descriptor Language (DDL). For example, later on in this manual, the Working with Messaging section discusses how applications are logically wired together over logical messages buses and channels. Config DDL would map the logical messages buses and channels used by application code to a concrete messaging provider. 

See Also: Understanding ConfigurationTo learn more about the underlying configuration mechanism of Talon, see Understanding Configuration.

See Also