Freigeben über

Real asynchronous vs. Simulated asynchronous

  • Artikel

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:

Real Async picture

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:

Real Async picture

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.

Comments