You can implement a protocol like this using Errai bus. However, you can not do it using synchronous communication.
Relying on synchronous communication on the client (in the browser) would freeze your user interface until the response arrives (you don't get to use mutliple threads in the browser). On the server, synchronous communication will also block a thread.
So, I would advice against this. I am sure the usability will improve by allowing for asynchronous communication between the client and the server.
What you say makes a lot of sense. RMI server is threaded, so blocking the thread isn't an issue. But client side you are correct, which makes sense why it has to be asynchronous.
So, we will probably have to change the server logic based on what you say, as right now the server waits for a response from the client before it continues execution. Server currently makes the callback, waits for an answer. This answer now needs to come asychronously which regardless which way I look at it breaks the current logic in the code. This code is very old anyway and probably should also be replaced. It performs two-way socket communication through RMI to hande callbacks, so there was some hacks RMI layers to handle firewalls and such anyway.
Thanks for the feedback.