Abstract: In the asynchronous world, we can talk about Real async and Simulated async. Each one has its own pros and cons. Let’s see a simplified sample of each case.
Sample scenario, let’s assume two systems, A and B:
1.- A sends a message to B.
2.- B processes the request from A.
3.- B returns a response to A.
Constraint: The processing of the request (step 2) takes some unpredictable time, so we cannot afford A to have an open connection waiting for the response from B at step 3. We need an asynchronous model, but it can be a real async or simulated async.
Real Async
In a Real async scenario all the communications are one-way, fire-and-forget. A sends the request to B and closes the connection. Once the processing is finished, B starts a new connection with A and sends a new message, the response.
The characteristics are:
- Each message goes in a true one-way communication.
- Both client and server must implement listeners –> from the communications point of view, both are client and servers.
- Both A and B must be aware of the other system’s endpoint.
- Bandwidth and CPU are optimized, and there are no blocking points.
here is a sample picture. Arrows shows who start the communications:
Probably, the most important issue is the second point: both A and B are clients and servers (or consumers and providers). Both systems must implement a listener or message sink. This is not suitable in many cases when A is a client app. So we can go for a simulated async.
Simulated Async
In the simulated approach, almost all the communications are still one-way, but B never starts a new connection; instead, B just puts the response available for A. It’s A responsibility to get the response, doing some polling.
The characteristics are:
- All the communications are started by A. B does not deal with communications issues.
- B is not even aware of A. If there are many As, B does not need to know.
- Easy to implement. Or at least, easier than Real Async.
- Bandwidth overload, because of the polling, as well some CPU consumption on A.
Here is the sample picture, modified showing simulated async via polling. Arrows shows who start the communications:
In this case, the response is not sent (PUT); it’s retrieved (GET), so it’s not a one-way communication.
These two models can extend to the infinite with many variations, but I think here are the two most basic ones.