I’m still new to Axon and haven’t tried it in production so far , but i’m standing in front of some architectural decisions and would like to get better picture here.
As far I understood, Axon Server seem to be a (relative performant?) Event Storage Solution - it is designed to be such thing, so an Event Database which supports querying and subscription?
Am I missing some parts? Do I need a companion Service like message broker here?
Some authors use them together with Axon Server:
Can you bring some light on this topic?
P.S.
The simple scenario I have in mind is that some services produce events and some consume by subscribing to them on the Axon Server. Potentially some of them are not written with Axon Framework.
I was about to create a topic similar, I have the exactly same doubt.
Actually I have a architecture which rely on Spring Boot + Cloud Stream + RabbitMQ.
So let’s say that I have to register a Person on Microservice A and ask to Microservice B to store there too and confirm in Microservice A that everything went well.
Microservice A <- produces -> CreatePersonCommand <- consume -> Microservice B
Microservice B <- save person/produces -> PersonCreatedEvent <- consume/active person -> Microservice A
Actually this occurs by RabbitMQ (Consumers/Producers) using topics.
Axon Server could replace this idea?
For example, in that case Microservice A and B could listen e act by Axon Server the same idea?
Or should I still need a broker like Kafka or RabbitMQ?
Axon Server has knowledge about the different types of messages that are being exchanged: events, sent from one service to one or many other services, to notify the services that something has happened, commands, sent to one service to do something, potentially waiting for a result queries, sent to one or more services to retrieve information.
…
Applications connect to the messaging platform and register their capabilities. One application may be able to execute a specific set of commands, another may handle a number of queries. There may be multiple instances of the same application connected to the messaging platform, each instance having the same capabilities.
So essentially it is both an Event Store and a Message Platform.
If message platforms like RabbitMQ and Kafka are used to solely deliver this types of messages (commands, queries, events, …) then Axon Server can safely replace them. That said, often such systems are used for wide variety of other types of messaging that Axon Server may not be able to or well suited to handle. It can however connect to such message platforms which allows you to have the best of both worlds.
Do you have some example of AxonServer as Message Platform?
I tried to implements MessageDispatchInterceptor and MessageHandlerInterceptor, but they aren’t fired.
I’m looking for some examples or documentation, but I didn’t found how to solve my problem.
I would also appreaciate some example where Axon Server is backbone of Heterogeneus Data Driven Event Service Landscape… But maybe it’s not how Axon Server was meant to be used?
@guibernardi I’m not quite sure what do you mean by “example of AxonServer as Message Platform”. If you follow the Quick Start that is essentially what you get. Obviously that’s not a complex, multi-node, multi-app, production-like scenario but IMHO it demonstrates the concept well.
I created a small project following the Quick Start, but now I’m trying to reproduce something more complex than the quick start project, so I started a POC.
Just to explain in case I have expressed myself badly, I already have an architecture with microservices and they communicate using an event-driven architecture Spring + Cloud Stream + RabbitMQ.
Now I have another product to develop and it matches with Axon perfectly, so I’m trying to use AxonServer as also a message broker.
So MS A sends events or commands and MS B and C could consume and react.
If message platforms like RabbitMQ and Kafka are used to solely deliver this types of messages (commands, queries, events, …) then Axon Server can safely replace them.
Guibernardi replied to this:
Do you have some example of AxonServer as Message Platform?
You said that Axon Server can replace a messaging platform, but then you said that you don’t know what he means by “example of AxonServer as Message Platform”.
The term “Message Platform” (IMHO at least) has much broader meaning. A messaging platform generally does not care about the message content (what it is) but about the delivery (where it should go). RabbitMQ, Kafka and others are generic purpose message platforms. They can be used for distributing any types of messages send by various senders to various receivers.
In that generic sense Axon server can NOT replace them. It’s not a generic purpose message platform. However if the messaging platform is SOLELY used to dispatch events, commands and queries - that’s exactly what Axon server is designed to do. In that particular context it’s even better than generic purpose message platform because it does have knowledge of the type of the messages and the capabilities of the respective producers and consumers with regards to those messages.
So the question
Do you have some example of AxonServer as Message Platform ?
is ambiguous at best. If the meaning is “generic purpose message platform” then NO, there are no examples as it’s not a generic purpose message platform. If the meaning is “message platform for events commands and queries” then all the samples available (including the quick start guide mentioned above) are examples of exactly that.
I hope this helps clarify what I meant with my previous comment.
, but i’m standing in front of some architectural decisions and would like to get better picture here.