It has been an exciting year. Little over a year ago, I started developing a framework to make it easier for developers to implement a highly scalable en extensible architecture. The first public Axon release (0.3) came out in April 2010, and was far from feature complete. Now, almost a year later, Axon has proven to be production ready and has been successfully employed in several projects around the world. <\/p>\n
<\/p>\n
Axon Framework aims at making it easier to build scalable and extensible applications. While many other products and frameworks around are doing the same, Axon Framework distinguishes itself by tackling the problem at the root: in the architecture. Axon Framework provides the building blocks and components for developers to easily build an application using the Command-Query Responsibility (CQRS) and Event Driven Architecture (EDA) patterns.<\/p>\n
CQRS is in essence a very simple architectural pattern. All it dictates is that an application should be split into roughly two components: one that processes commands and that performs state changes, and another that provides state information of the application by processing queries. This simple separation of concerns is the basic requirement to build an application that can easily scale, without adding a lot of complexity.<\/p>\n
The command handling component and the query component need to share their data, somehow. CQRS doesn\u2019t 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). <\/p>\n
An Event Driven Architecture is a very clean and simple way to promote scalability and extensibility in an application. Since the publishers aren\u2019t aware of the components that are listening to an event, it is very easy to plug-in extra event handling components. To scale, several identical event handling components can be employed to handle a larger amount of events simultaneously. Whether these components live on the same machine, or inside a cloud environment doesn\u2019t matter, as longs as there is a transport mechanism between them.<\/p>\n
Having all state changes represented using events provides another powerful business opportunity. By storing these events, you have a very reliable and complete audit trail of all the state-changing activity in your application. Even better, you can use this audit trail as the persistence model in your command handling component. This is called Event Sourcing.<\/p>\n
The Axon Framework provides all the building blocks that are required to implement a CQRS and EDA based architecture. The \u201chard parts\u201d, like consistency guarantees, transactional command handling and event publishing as well as complex business transaction management, are all made a lot easier.<\/p>\n
Command Handling starts with a client, a user interface or another system expressing the intent to change state by sending a command. Axon Framework provides Command Bus implementations that will dispatch the command to an appropriate command handler. When required, the command bus will make sure the client is notified when the command has been processed.<\/p>\n
Axon provides a mechanism to publish Events to the interested event listeners. Publishing events is done using the Event Bus. In contrast to the Command Bus, the Event Bus will publish each event to all the listeners. This allows for flexible extension of your application and making it easy to host components on several physically separated environments.<\/p>\n
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.<\/p>\n
Once a model\u2019s state changes, this state needs to be persisted. Whether you prefer Object-Relational Mapping to store the state in a relational database, or want to leverage the power of an Event Store, in Axon Framework it\u2019s just a matter of configuring the right type of repository and\/or event store. Axon provides support for storing models and events using JPA, which means that virtually all relational databases are supported, with minimal learning curve.<\/p>\n
Defining a method as a command handler or event handler is as easy as adding an annotation to it. Axon Framework will process these annotations during application startup and register the appropriate handlers with the command- or event bus. If you don\u2019t like annotations, you can also work without them. <\/p>\n
In some cases, it is desirable to process events in the tread that publishes them. In other cases, it is better to hand off the event to the handler, and continue without waiting. In Axon Framework, that\u2019s as easy as adding an annotation on the Event Listener. 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 \u201cpoison messages\u201d to prevent a single failing event from blocking the entire system.<\/p>\n
Axon also 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. <\/p>\n
Axon never creates a thread on its own. Instead, it relies on Executors to provide execution capacity. This makes it very suitable to run in application servers that provide advanced monitoring and thread management services.<\/p>\n
ACID transactions defy the scalability of an application, especially if the transaction runs over several resources (which typically requires two-phase commit). Furthermore, ACID transactions often provide little more than false security with the great price of availability and performance.<\/p>\n
The principles of CQRS and EDA provide developers the ability to use the published events to manage BASE-transactions. These transactions will make sure that \u201ceventually\u201d, all components are synchronized. Typically, eventually is within milliseconds. However, when certain systems are busy or have failed, BASE transaction provide a much more flexible way to resolve these problems. Typically, waiting for a system to come back up is not a problem, while ACID transaction will inevitably fail.<\/p>\n
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.<\/p>\n
Although using Axon Framework in combination with the Spring Framework is not a requirement, there are features in Axon Framework that are much easier when combined. For example there is namespace support for easy configuration of all Axon components and Axon can be easily connected with Spring\u2019s PlatformTransactionManager to provide transaction support, just the way you\u2019re used to.<\/p>\n
Especially Spring\u2019s Component Scan feature works very well in combination with Axon\u2019s annotation support. To create an Event Handler, for example, only two annotations are required. Spring\u2019s @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.<\/p>\n
When deploying applications on sev
\neral servers, Axon leverages 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\u2019s simple and powerful pipes and filters architecture to dispatch and process events, even remotely.<\/p>\n
Although this 1.0 release is a major milestone and definitely reason for a party, it is far from the end of Axon\u2019s development cycle. The 1.0 release has opened up the road to provide building blocks to enhance scalability even more. <\/p>\n
One thing to expect in upcoming versions is 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.<\/p>\n
We will also be working on support for connecting Event Busses in several application using AMQP message brokers. Work has already been started to set up a connection with SpringSource\u2019s RabbitMQ, a fast, scalable and reliable message broker based on AMQP standards.<\/p>\n
Axon Framework is available under the Apache 2 license. Its libraries and sources are available for download in the Maven Central Repository. Documentation is available on-line at http:\/\/www.axonframework.org\/docs<\/a>.<\/p>\n If you prefer a single download containing all libraries, source code, printable PDF documentation and dependencies, you can download the full package from http:\/\/www.jteam.nl\/products\/axonframework<\/a>.<\/p>\n Axon Framework is open source and free to use and distribute. Generally, questions are answered as soon as possible and bugs are solved within a reasonable timeframe. However, you might benefit from JTeam\u2019s professional services in the form of support contracts and consultancy services. For more information about JTeam, visit www.jteam.nl<\/a>.<\/p>\nTraining and support<\/h2>\n