This content has been marked as final. Show 5 replies
There is no one, right answer. However, this is my high level take without much to go on.
If the calling system is handling the retries, then the operation from caller to interface should be synchronous. In effect, the interfacing system is acting simply as a bridge or proxy.
If the interfacing system is handling the retries, then the calling system should make an asynchronous request. This is because there might be some decent latency in between the retries, and you don't necessarily want the calling system to block waiting for a response.
Does that help?
First, what is the point of the retry?
*1)* If it is to cope for a temporary unavailability of a system, and provide a guarantee of execution, you likely need more than a retry (this system is temporarily down, let's try later), you merely need failover too (this system is down, let's try this mirror or backup system).
Handling failover at the "interfacing" level makes the interfacing system a SPOF itself (Single Point Of Failure), and you need to manage its own unavailability: to cope for unavailability thereof, the client system needs to be able to failover to a second interfacing instance. If you do that, the interfacing system may not need failover of the back-end system: it could report failure of that latter as a failure of itself, and the client would failover ("retry") to the second interfacing instance.
*2)* If it is a normal application flow (no seat left for LAX, let's try again in one hour in case someone has resigned), it depends on the intended interface impact.
- if the client system is a GUI and you need the user to wait for the request to eventually succeeds, it may be easier to handle applicative retries at the client end.
- if the user wants to be able to leave or close the UI and go watch TV once he has submitted the request, then you need to handle the retries in the "interfacing system"
Essentially, the synchronous/asynchronous distinction ponted by Saish above (but I think this distinction stems more from the functional requirements than from the architecture).
Can you give more details about the functional or technical requirements of your "retry" feature?
GPS7 wrote:That is a business/architecture decision.
There is a calling system and an interfacing system which would connect to the other systems via webservice.
Which system is best to have the the retry mechanish, a calling system or an interfacing system?
First step of course is why retry at all. Why will a second attempt succeed while the first failed? And why will this be the case the majority of the time? And if there are recovery mechanisms in place will they recover quickly enough that an automatic retry is reasonable?