After a steady, year long march to 1.0 from 0.3 in March 2010 , the Axon Framework has been released. The Axon Framework attempts to provide the building blocks and components for developers to easily build an application using the Command-Query Responsibility (CQRS) and Event Driven Architecture (EDA) patterns. CQRS is a very simple pattern; it dictates that an application should be split into two components: one that processes commands and that performs state changes, and another that answers queries about the application's state. This separation of concerns helps facilitate scale, as costly writes can be scaled independently of the service that handles reads.
The command handling component and the query component need to share their data, somehow. CQRS doesn't specify how this is done. One way to do this, is by writing to a (replicated) persistent model (e.g. database), on which the query component executes its queries. Another way is by generating events from the command component, which are picked up by the query component(s).
An Event Driven Architecture publishes state changes as self-describing events that any number of event-listeners can process as they choose. The clients that consume these events can process them as they're able to, but don't slow down the event publisher. Events can be stored, and provide a reliable and complete audit trail of all the state-mutations in an application. This durable record of events also makes for a convenient persistence model in your command handling component. This is called Event Sourcing.
The Axon Framework provides all the building blocks that are required to implement a CQRS and EDA based architecture. The "hard parts," like consistency guarantees, transactional command handling and event publishing as well as complex business transaction management, are all made a lot easier. To support command handling, the Axon framework provides command bus implementations that dispatch the command to an appropriate command handler. When required, the command bus ensures the client is notified when the command's been processed. Going the opposite direction, the Axon framework provides a mechanism to publish events to all interested event listeners, using the event bus.
Commands need to be processed. Typically, this is done using a domain model that implements the business process and rules defining what should be done based on an incoming command. Axon Framework provides the base classes needed to help you implement such a model, including support for using an ORM or an event store.
Event listeners can be synchronous, or asynchronous. The distinction is a matter of configuration. The listener will automatically be wrapped in order to handle events asynchronously, while keeping the opportunity to handle the events within a transaction. Axon can automatically detect and discard "poison messages" to prevent a single failing event from blocking the entire system. Axon allows developers to define a sequencing-policy, which defines that specific events need to be processed sequentially, in order to prevent concurrency issues in a backing data-store. Axon never creates a thread on its own; instead, it relies on Executors. The Spring framework features numerous adapter Executors that let you take advantage of managed thread pools in applications servers, on the client or in any other environment.
Transaction Management
The Axon framework supports eventual consistency - the model eventually reflects the mutations applied to it. Under high load, the delay may increase, but will not fail, where the same can't be true of highly contended, traditional transactions - especially those involving multiple resources.
Axon Framework provides components that allow developers to build these transaction managers, which are called Sagas in CQRS. In combination with annotation support, creating a Saga just requires adding an annotation on the methods that need to be invoked when specific events occur. Axon will ensure that the correct Saga instances are invoked with the correct Events. Therefore, a single Saga instance will only need to manage a single business transaction.
Spring Framework Support
Although using Axon Framework in combination with the Spring Framework is not a requirement, there are features in Axon Framework that are much easier to use with the Spring framework. For example, there is namespace support for easy configuration of all Axon components and Axon can be easily connected with Spring's PlatformTransactionManager to provide transaction support.
Spring component scanning picks up Axon Framework annotations. To create an Event Handler, for example, only two annotations are required. Spring's @Component will tell Spring to wire an instance as a Spring Bean, while the @EventHandler annotation on a method will tell Axon to register that handler on the Event Bus. When deploying applications on several servers, Axon leverages the Spring Integration as a transport mechanism for Events. This is done by subscribing an adapter on the event bus that forwards Events to a Spring Integration Channel. From there on, you can use Spring Integration's pipes and filters architecture to dispatch and process events, even remotely.
Roadmap
Upcoming versions will have command bus implementations that support routing and remoting. This allows you to deploy command handling components on several machines and have the load balanced between them. We will also be working on support for connecting Event Busses in several applications using AMQP message brokers. Work has already been started to set up a connection with SpringSource's RabbitMQ, a message broker based on AMQP standards.
Obtaining the Axon Framework
The Axon Framework is available under the Apache 2 license from JTeam, which provides support, workshops, training and consulting services. The Axon framework libraries and sources are available for download in the Maven Central Repository, as well as from the website. Documentation is available at documentation.