This Blog will help with achieving the following
- Learn about synchronous and asynchronous method of communication
- Differentiate between the Pros and Cons of both approaches
- Design PI based interface strategy
- Identify points of failure in design of existing interfaces
- Design better interfaces
Synchronous Communication
Synchronous communication basically means that when a Sender application sends a request; it waits for the Receiving application to send the response. If there is a failure due to some reason, the Sending application is responsible for re-sending the message. It is kind of an online query where you wait until the result is displayed.
There can be multiple points of failure in this type of scenario
- Network level error - Message might just get stuck in between and Sender will wait until timeout.
- Application exception - There an error at receiver in processing the message and Sender does not get to know about it. Sender keeps waiting.
- Error in response reaching the Sender - Response message gets stuck in between due to some issue and Sender keeps waiting.
In all above cases, Sender might resend message after timeout and there might be a possibility of duplication.
This approach is known in PI with Quality of Service as BE(Best Effort). All properties of BE apply here.
Advantages
- Online and Real time - Response is received immediately
- No need to implement response message routing
- No need for Sender to correlate Response to Request. It is implicit in nature.
Disadvantages
- In case of errors, failure is permanent and Sender needs to send the message again. There is no automatic re-send.
- PI does not log success messages by default.
- Receiving system should handle duplicate checks.
- Both Sender and Receiver applications need to be Online during the entire time.
- Possibility of timeout.
- Sender application is blocked unit either response is received or timeout occurs.
- Multiple receivers are not possible.
Recommendations
Good approach for scenarios that are required to perform read operations. Examples: Read Purchase Order, Read Address details etc.
Not recommended for scenarios that are required to perform modify operations. Examples: Create Purchase Order, Modify Address details etc.
Key deciding factor for Modify operations: Implement only if the Sender is an Online User application and User is supposed to know the result in real time. User has the responsibility to check the outcome of previous request before re-trying again. Example: Online Bank transaction.
Asynchronous Communication
Asynchronous communication basically means that when a Sender application sends a request; it does not wait for the Receiving application to send the response. If there is a failure due to some reason, the middleware is responsible for re-sending the message. If required, the receiving system can send a response back to Sender as a separate asynchronous call.
This approach is known in PI with Quality of Service as EO(Exactly Once) or EOIO(Exactly Once In Order). All properties of EO or EOIO apply here.
Advantages
- Real time
- In case of errors, PI will ensure Guaranteed delivery and will automatically re-send the message.
- Loose coupling of applications.
- PI logs all asynchronous messages by default.
- No problem of duplicate messages.
- Both Sender and Receiver need not be Online at same time.
- No possibility of timeout.
- Sender application is free to send more messages after sending the message.
- Multiple receivers are possible.
- Guaranteed Delivery using PI.
- Support for Transport and Application acknowledgements.
Disadvantages
- No immediate response.
- Response message needs to be implemented and routed separately.
- Sender needs to correlate Response to Request on its own. This can be done by Sending some sort of unique identifier and making Receiver return the same as part of response.
Recommendations
Good approach for scenarios that are required to perform modify operations. Examples: Create Purchase Order, Modify Address details etc.
Not So Good approach for scenarios that are required to perform read operations. Examples: Read Purchase Order, Read Address details etc.
Key deciding factor for read operations: Implement only if the Sender is a backed application and response can come and sit in the system in background. Example: On demand synchronization of data.
