| div | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||
|
Overview
...
TODO
- Point to Talon Archetypes as a quick start
- Discuss the basics of an application
- Model Messages and State
- Skeletal Configuration
- App with Event handlers.
Overview
Project Layout
The folder structure shown here
| 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 | ||
|---|---|---|
| ||
For a short micro-tutorial on this topic please see: Micro-Tutorial #2: Your first Talon Micro App |
As described in the Concepts and Architecture section a Talon application consists of the following ingredients:
- Modeled Messages: plain old java objects that are generated from an XML model that is used to communicate between apps.
- Modeled State: plain old java objects that are generated from an XML model that make up your applications persistent state.
- A Main Class Entry Point: serves as your application's entry point. A 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 deployment descriptor model that configures applications, message buses, and application containers (XVMs) that together operate as a system of 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 started tweaking the starter app introduced in the 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 application using maven. It was as created using the talon-sr-processor maven archetype.
| Section | |||||||
|---|---|---|---|---|---|---|---|
|
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 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.
To learn more about the underlying configuration mechanism of Talon, see Understanding Configuration.
See Also