Server to client communication

[cgokey]

I've got an old RMI based client/server application that desperately needs to be updated to the modern world.   One thing the old code does is utilizy callbacks where the server sends messages to the clients.

I'm trying to get away with not having to rewrite the server logic and wondering if errai-bus might be able to help with this use case below:

{code}

Client                                 Server

--------------------------------------->calls a service on the server to validate some object's data

                                         looks through the data and discovers it already exists in the system                       \

already found,

update?<-------------------------------- identifier already exists, ask client if they want to update

----------------------------------------> client returns the value YES to the server

                                           so server continues processing

<----------------------------------------  during processing,

                                            found issue with data, send piece of it back to the client to fix.

client responds

with fixed data --------------------------> continue processing.

<----------------------------------------  during processing,

                                            found another issue with data, send piece of it back to the client to fix.

client responds

with fixed data --------------------------> continue processing.

etc..   until finished

{code}

Notice this synchronous communication with the server waiting for a response from client.. (and vice versa)

Any way to make something like this happen with errai..   Much of the docs talk about asychronous communication,

any work arounds without having to change around the server much to deal with this kind of synchronous communication???

Thanks,

Chris

[csa]

Hi Chris,

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.

Cheers,

Christian

[cgokey]

Thanks Christian. 

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.

Chris