In This Section

Overview

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.

 

As described in the Concepts and Architecture section a Talon application consistsof the following ingredients: 

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 tweaking the starter app introduced in the Get Started 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.

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 used to drive traffic to the main application.

Model Source Folders

  • state.xml Contains the xml model defining the application's state
  • message.xml Contains the 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 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 additional library folders and build scripts.

 

The above project structure is a good starting point to use when starting to initially develop a single application. As the number of applications you are developing grows, you will likely want to consider separating out your parts of your state and message models into a separate project that is shared between multiple projects.

Message and State Modeling

Messages and State objects are generated by Talon's Application Data Modeler (ADM) from 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 variety of classes. In this case the application main class exposes the additional classes containing handlers to the Talon runtime at startup. 

See the Talon Programming 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 bases on message 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. 

To learn more about the underlying configuration mechanism of Talon, see Understanding Configuration.

See Also