Axon 2 has hit an important milestone today, as we have published the first Release Candidate. This release marks a major milestone towards the final 2.0 release, expected early January. All features on the roadmap have been implemented in this release. The coming weeks, these features will be refined and fine-tuned for optimal performance and reliability to ensure Axon 2.0 helps meet the demands applications face today.
What’s new in Axon 2
Axon 2 provides a large number of new features and comes with a number of API changes to make it easier to develop applications.
Easier, more powerful API
Axon tries to minimize the amount of Axon specific code in your domain model. In Axon 1, Command objects were merely pojos sent over a Command Bus. Events, however, needed to extend from an Axon class. In Axon 2, Events are pojo’s as well. When published, they are wrapped in messages, on which Axon specific information is attached. Despite the advantages, you don’t have to work with these messages.
Methods annotated with
@EventHandler are now much more flexible. Not only can you have the payload of a message (i.e. your actual Command or Event object) passed as a parameter, you can also inject specific meta data values or the message’s timestamp. If you’re a Spring Framework user, you can even inject Spring Beans in your methods, simply by adding them as a parameter. The resolution process of these parameters is customizable, allowing you to simply write your own parameter resolvers.
The CommandBus provides a low-level API to dispatch Command Messages to your command handlers. Axon 2 allows you to define a
CommandGateway, which acts as a higher level interface towards a Command Bus. To create a gateway, all you need to do is provide Axon with an interface. The implementation is automatically generated based on the method signatures. This way, you can easily define meta-data values to be added to the command, as well as dispatch-and-wait-for-result style operations.
Axon 2 comes with a much more powerful and yet easier to use API for Event Upcasting. You can choose the representation of the serialized Event you prefer to work with, such as an
byte or a Dom4J document. The available formats depend on the serializer you use (e.g. using Dom4J requires an XML-based serializer), but can easily be extended by implementing custom Data Converters. Axon 2 will automatically combine available Converters to translate one representation to another, even if that cannot be done by a single converter.
Some applications have performance needs that simply outgrow the characteristics of the
SimpleCommandBus. For those applications, Axon 2 comes with a high performance Command Bus that uses a lockless algorithm to process commands using multiple threads. This implementations is capable of processing 4 times more commands than the
SimpleCommandBus implementation, using 2 or 3 threads.
When reading Events, either from the Event Store when reconstructing aggregate state, or a remotely invoked Event Handler, Axon will automatically determine whether it is necessary to deserialize the Event Message. This greatly reduces the amount of processing needed to reconstruct aggregates that don’t require all events. The same is valid for upcasters, they are only invoked when Axon detects that the result of their transformation is actually needed.
When processing Commands, the generated events are often written to an Event Store and published to an Event Bus. When both use the same serializer, Axon can ensure that serialization is done only once, using the same result for both operations. Your application specific code is completely unaffected. All you need to do is enable the feature in your configuration.
Replaying large numbers of events (>10 Million) is now much faster. Furthermore, it is also possible to define a selection of events to replay, such as events that occurred within a certain period of time, or Events that have been applied on a specific type of aggregate. Improvements in the queries executed as well as the deserialize-when-needed algorithm will make replaying events drastically faster.
Axon generates unique identifiers for all messages. By default, the generated values are
java.util.UUID instances. While they generate as-good-as-never-colliding identifiers, the performance is not great. For applications requiring high-performance, it is possible to hook in a custom identifier generator. For example one that generates version 1 UUIDs.
Out of the box scalability support
Besides the basic implementations of building blocks, Axon 2 comes with some out-of-the-box implementations that allow you to horizontally scale an application.
The Distributed Command Bus with the JGroups Connector allows you to not only scale horizontally, but to do so completely at runtime. Scale you command handlers up and down to match the load on your application. Axon takes into account that some machines may be more powerful than others, spreading the load accordingly.
Events can be distributed over AMQP by using the Spring AMQP terminal. It will ensure that Events are transported to the Event Listeners over AMQP . While this implementation requires Spring, another implementation will soon be available that uses a plain AMQP client.
MongoDB Event Store
MongoEventStore is now a full member of the Axon family. This means you can safely use a Mongo Database, which is built to store large amounts of data, as an Event Store.
Migrating from Axon 1
For the current users of Axon 1, we are writing a Migration Guide to help migrate your codebase. The guide will explain what changes you will need to make to ensure that the application runs on Axon 2 as it did in Axon 1 (maybe just a bit faster). Next to the guide, we’ll also provide some tools that help convert an Axon 1 Event Store to the new Axon 2 format. This tool is designed to run in the background on production environments, making it safe to convert even large Event Stores while the application is being used.
This release candidate marks the imminent final release of Axon 2. We’ll be fine tuning and testing the components in Axon 2 to make sure everything meets production requirements. Finally, we want to provide some quick start guides to new users of Axon 2. These guides will take you through the process of creating an Axon 2 based application step-by-step.
But while we’re developing Axon 2.0, plans and ideas for future versions are already there. Some features are expected for the 2.1 version, while others may be postponed a little longer. Some features we foresee for 2.1 are, for example, Aggregates without extending Axon classes and a plain AMQP based connector, which doesn’t require any Spring. A distributed Saga Manager is also on our wish list.
Recently, the Axon Insight Plugin has been removed from Axon’s codebase. Maintenance of that plugin has been transferred to VMware, who’s going to include the plugin in their vFabric stack. That means Axon monitoring support will be provided out-of-the-box in products like TC-Server. VMware will maintain the plugin to ensure the plugin works keeps working for new releases as well.
Training and Support
Trifork is the company backing the Axon Framework. If you want to learn about the little things in Axon that make life easier, or want a jump-start in building CQRS-based applications, consider attending a Training or Workshop organized by Trifork. If you prefer some information or help specifically tailored to your needs, don’t hesitate to contact Trifork.
If you want to get started using Axon, visit www.axonframework.org. In the downloads section, you’ll find the 2.0-rc1 download package. If you use Maven, you can simply update your dependencies to use version 2.0-rc1. While we’re working on the quick start guide, the reference guide is the best place to get started.
If you have any questions, you can ask them on the Axon Framework User Mailing list (firstname.lastname@example.org). If you have found bugs, or want to report a feature request, don’t hesitate to let us know through the Issue Tracker.