Why axon framework does not provide a distributed command bus with an AMQP implementation, like the event bus ?
I would like to solve the problem of “occasionally connected client” in my system using axon framework, so i would like to use two command bus in the system, one command bus for local command, and an other command bus for remote command in order to replicate the system when the “client” (which is in reality a local server, not a gui client) are reconnected to internet.
your question isn’t irrelevant, but for some reason, it was marked as read in my inbox and lost my attention.
The primary reason for not having an AMQP command bus is that I haven’t gotten to it yet. There is however, also a downside to using a message broker for a command bus, and that’s the routing capabilities. For distributed systems to be efficient, the client should route commands to the correct component. A message broker will either always forward to the same one, of (using competing consumers) to whoever is first to read a message. This may lead to concurrency issues on the receiving end. Unless, of course, you have built custom components in your AMQP broker to route consistently.
These might not be issues in your cases. Still, I would consider using a point-to-point messaging protocol (like HTTP or a TCP socket connection) to communicate between your (occasionally connected) client and the server.
An AMQP Command Bus for asynchronous commands, that should be handled
sooner or later no matter if the server is online at the time of the
sending or not makes perfect sense in my world as well. I see it more
like a case of occasionally connected servers : )
As for the routing, you already have the same problem for a event
listener that you want to shard in some way but still have the same
shard handle events from the same aggregates consistently. A solution
could be a single consumer that takes all messages from the queue and
distributes more intelligently than the message broker would, based on
for example an aggregateIdentifier on the message, being it a event
message or command message.
Also for synchronous commands, having a persistent message queue in
between to guarantee delivery on not having to care about where the
servers are seems like something that could work. I guess it's a bit
trickier as you would have to find a way a way back to the sender as
well... Through the broker? One queue per command, command handler or
one global queue for all command responses? Or via a direct TCP or
HTTP connection?
