sharing axon queries across services

I have three different services(A,B & C) running and all are connected to axonserver 4.3.3. Apart from them i an api service which contains all events so that it can be shared among all services. when an event is fired(lets say by service A) it is being listened by other services(B & C) and they react accordingly.

Now i want to share queries as well so that when a service(Lets say A) wants some information which belong to another services(lets say B), it can directly fire corresponding query which will listened by service B and will return the info.

1. Is it allowed in axon(i.e., sharing query among services, like we do for events)?
2. If allowed, does it follow axon best practices ?
3. If not allowed/doesn't follow best practices, what is alternate solution ?

> UPDATE

I simply added queries to the common-api service and fired it from Service A as follows:

1. when i used queryGateway.query( findCourierByIdQuery, responseType): i got queryhandler not found exception
2. when i used queryGateway.subscriptionQuery( findCourierByIdQuery, initialResponseType, updateResponseType): i got nothing
3. when i used queryGateway.scatterGather( findCourierByIdQuery, responseType, timeout, timeUnit): i got an empty stream

when i fired the findCourierByIdQuery from service B itself, the queryhandler was invoked and i got the proper response.

My observation is that, the query-handler only gets called if the query has been fired from the same component(service B in this case), it is not getting called if i fire the query from some other component(service A).

Note that all services are running independently on different hosts and ports, but connected to the same axonserver and the queryhandler is written in service B.

so basically the implementation is something like this:

• findCourierByIdQuery is defined in common api service.
• Service A and B has the dependency of common api service.
• service A does the query for findCourierByIdQuery.
• Service B has the findCourierByIdQuery query handler implementation.

This is totally fine in my opinion!

Axon is using three types of messages: commands, events, and queries. They represent the API of your services.
Downstream service (in your case B&C) can send Commands, subscribe to Events, or send (and subscribe) to Queries of the Upstream service (in your case A). Simply, B&C are depending on A. It is important to make this dependency unidirectional (the only B is depending on A, but not the other way around) if possible.

Usually, you want to have an anti-corruption layer component at the edge of the Downstream services (B&C). It can translate events from Upstream service (A) to its own commands and it can translate its own events to the command of the Upstream service (A). This is a Saga or a regular Event Handler (Processor).

If you are interested in Queries than your anti-corruption layer component will be using a query gateway to issue (subscribe to) queries from the Upstream service (A) and hopefully translate the response to Commands in an automated fashion, similar to Saga/Event Handlers I have mentioned. Usually, this integration over the Query API is not fully automated: translation from the query to command involves the user. In this case service B (downstream) is using query response (of service A) to render the view from which the user can issue next command (service B)

Having the anti-corruption layer component in the downstream system will make your services autonomous.

Best,
Ivan