Send Commands to a separate microservice

I want to send some commands to another microservice. Is there a way we can do this in Axon?

Hi Kasun,

In general, you would have to set up a distributed version of the CommandBus, on both sides. If you send a command to the CommandBus (probably through the CommandGateway) on on microservice, but the corresponding @CommandHandler is on the other microservice, the distributed bus will take care of delivery.

There are multiple ways of setting this up, but the easiest by far is using AxonHub:

I’ll be doing some live coding showing this and other stuff this Thursday:—microservices-with-axon-platform—live-coding-webinar

Kind regards,

Thank you. Do you think there is a way we can share commands between non-jvm applications like .Net . Because we develop microservices using both Java and .Net.


Hi Kasun,

In principle, using any type of distributed command bus doesn’t preclude the use of .NET (since over the wire, there’s nothing Java specific). Specifically looking at AxonHub, is uses a gRPC network protocol which there also is a .NET implementation. However, since you don’t have Axon Framework on the .NET side, it would probably be pretty complex to set up. You’d effectively be looking at implementing the CommandBus part of Axon Framework in .NET.

What would be easier instead, is to fully rely on Axon and Axon message distribution within the Java scope, and use the ACL pattern to link to .NET where you don’t have Axon:

  • If you want to send a command from Java/Axon to .NET, your ACL would look like a Java/Axon @CommandHander method which, as its implementation, somehow invokes .NET, e.g. by calling a REST endpoint. Now, within all of your Java code, you can simply dispatch a Command and it would be transparently handled by the .NET side.
  • If you want to send a command from .NET to Java/Axon, you would implement an endpoint in Java to receive the .NET command, which would immediately wrap it into a command object and dispatch it on Axon’s CommandGateway.

Hope this is useful,

I believe that this apply to events also.