Why Axon Server?

Purpose-built for Axon Framework applications

More traditional forms of integration haven't been designed with the specifics of Axon Framework, or more generally, CQRS/ES architectures in mind. When you're using such general-purpose integration techniques, you'll find yourself in a constant effort to make everything work properly and efficiently. For instance, plain HTTP/REST calls are commonly used in microservices architectures but have very clear drawbacks: they're verbose and slow, synchronous in nature, while load balancing is possible on the HTTP level, consistent routing based on aggregate id is complicated. Another example is problems associated with using an RDBMS table as an event store: you may be fighting global sequence number gaps, delays in event processing due to polling, and scalability issues related to the number of events. Axon Server has been designed from the beginning to support the CQRS/ES architectural style, implementing optimized routing and storage algorithms.

Client-initiated connections

Axon Server uses HTTP/2 for its connections, specifically Google's gRPC protocol, which adds a binary Protobuf-based RMI layer on top of HTTP/2. This is a very efficient protocol supporting two-way communications. Importantly, in the Axon Server model, all connections are initiated by the client. After the connection has been established, the client can send messages to Axon Server and vice versa. This approach has a clear benefit: the only service location that has to be managed is the location of Axon Server, which must be made known to the application clients. Other than that, no discovery or registration mechanisms are needed: Axon Server will be able to reach the clients simply because the clients reach out to Axon Server.

Handler-aware

Your Axon Framework-based application will have several @CommandHandler, @EventHandler, and/or @QueryHandlers methods. Axon Framework registers those with whatever implementation of the Axon buses is present. If you're using the Axon Server version of the buses, this is taken one step further: the Axon Server client will be relaying the information about the handlers present in this application to Axon Server. As a result, Axon Server knows which components are available to handle which types of messages. This allows it to configure routing fully automatically.

Easy to Integrate

Axon Server can be easily integrated with your applications in some ways. Starting from Axon 4, Axon Server integration is enabled by default in Axon Framework, and all you need to configure is the network location of Axon Server. For Axon 3, or non-Axon applications, there's an open-source Axon Server client (available on GitHub and Maven Central). It offers drop-in implementations of Axon Framework's CommandBus, EventBus/EventStore, and QueryBus interfaces. If you're using Spring Boot, you can use the axonhub-spring-boot-autoconfigure dependency, which will wire these buses automatically. If you need more freedom, like using AxonHub from another programming platform, you could communicate with AxonHub directly via the open HTTP+JSON and gRPC interfaces.

Distributed as a JAR File

Axon Server is distributed as a stand-alone jar file that you can run in any environment you like, on-premise, or in the cloud. There are two versions of the jar file: the free Axon Server and the commercial Axon Server Enterprise, which requires a license key to use. Axon Server can be configured to run as a messaging platform (previously called “AxonHub”), as an event store (previously called “AxonDB”), or both at the same time. Axon Server can run well directly on a (virtual) machine but has also been tested extensively in a Docker/Kubernetes containerized setting.