Hi,
In a distributed system (as in, many thousand user interfaces, like on
the web), what do you recommend to issue commands ?
The CommandBus has no implementation that listens on a message broker,
I guess there is a reason for that. I am investigating using a REST
api over my command bus to create the commands, but I am not entirely
sure if it is a good approach.
Thank you
Hi Nicolas,
it depends a bit on the architecture you’re thinking of. If you have a central server (or command processing node) and multiple clients sending messages to it, simple HTTP might do the trick. Usually, I use a standard controller as a facade in front of the command bus. The controllers are bound to different URL’s with parameters and create the commands.
It is, however, also feasible to use rest to have the client push commands directly to the central command bus using e.g. REST. The command bus would be a resource on which you push (PUT ?) messages. If you’re async, you could reply with a URL on which the client can poll for the result. Otherwise, you could just send the result (if any) in the response of the request.
The broker (AMQP / JMS) based distribution of commands will not be a standard Axon component. Command dispatching over AMQP will only work if you have exactly 1 component handling commands. Generally, you’ll need a more direct point-to-point communication, to make sure commands have been dispatched to their destination. As always, there are exceptions to this rule…
To summarize, your idea of a REST interface towards the command bus looks like a good idea, if you want the dispatching logic in your client.
Cheers,
Allard
The axon trader also contains code for a rest based client. Which is easy to accomplish when using spring.
https://github.com/AxonFramework/Axon-trader
We are in the middle of converting the sample to axon 2.0, which is still work in progress.
regards Jettro
Hi Allard & Jettro,
Thank you for taking the time to answer.
Using Spring MVC to interface between the command bus and the outside world, what would be the best practice to provide a response or an error to a caller if the process is not long (hence, no need to be asynchronous) ?
In Axon 2, one of the two dispatch methods of the CommandBus has a callback. What procedure would you recommend to “wait” for the answer, and hence being able to provide it to the client ?
Thank you,
Hi Nicolas,
if you want to have a thread waiting for a callback before moving on, you can use the FutureCallback. It implements both Axon’s callback and Java’s Future interfaces. You would use it like this:
FutureCallback callback = new FutureCallback();
commandBus.dispatch(command, callback);
callback.get(); // this will block the thread until the callback is invoked.
The get() method is defined by the Future interface, and is quite ugly. You can also use the getResult() to avoid the try/catch hell forced by get().
If an error occurs, get() will throw an exceptoin, otherwise you get the result of the command processing.
There is also a CommandTemplate class to make sendAndWait processes a bit easier.
With this approach, the REST implementation using Spring MVC is just plain and simple.
Alternatively, you can choose to use Servlet 3.0 async support and use a callback that simply commits a response to the client. Then you don’t have a blocking thread per connection. I am not sure Spring supports Servlet 3 async, though.
Cheers,
Allard
Support from spring for async is coming in the next release 3.2. I thing some beta’s are available and there are a few blog posts from the creators available as well:
and
Jettro