When two applications are trying to exchange information with each other, this is a form of communication. When two components of an application are working together, calling methods and passing data between them, this is another form of communication. There are basically two methods of communication. These methods are defined by what the initiator of the conversation does once it stops sending. These two methods are synchronous and asynchronous communication.
In a synchronous communication, when the initiator of the conversation stops sending their information to the receiver, it goes into a waiting mode. It will remain in that waiting mode until it receives a response back from the receiver with the information that the receiver is sending. Only once it receives this information will the initiator continue on with its processing.
Synchronous communication is like making a function call. When you make a function call in an application, you package up the information that you are sending to the receiver and call the function. Then you wait. Your program will not continue to execute until the function returns the results of the function call to you.
In an asynchronous communication, the sender in the conversation will send its information and then go on its merry way. It will not wait for any response from the receiver in the conversation. In many cases, there is no response that is ever sent back to the sender. If there is a response that is sent back, then the original sender can decide for itself when and even if to process the response.
Asynchronous communication is similar to event handling in Visual Basic. In Visual Basic, you can cause something to happen that will fire an event. But while you are waiting for that event to fire, you are free to go off and do whatever other processing that you want to do. When that event is fired, you can choose to handle the event using an event handling routine, or just ignore the event and continue processing.
There are three primary reasons that you would want to use asynchronous communication over synchronous communication in your applications. If your sender always has to wait for a response then the system will spend a lot of time waiting for something else to happen, rather than on running the application. Asynchronous communications will make the system seem faster to the user, since it can devote the majority of its time to processing rather than waiting.
There may be instances where the sender really doesn't care when the receiver will deal with the message. It's like delegating a task to someone. An efficient manager will not wait for that task to complete before going on to other tasks. This is being asynchronous. If a manager has to wait for the task to complete before doing anything else, first of all they are not an efficient delegator, and second, they are performing synchronously.
If your application is running in an environment where the connection between the two applications is not reliable, or if one of the applications is running on a disconnected computer, like a laptop, then asynchronous communications can be a real benefit. Also, if one of the applications only ran during off-hours, then without asynchronous communications, the sender would have to wait until the next day to complete its processing.