Guaranteed sending of a request to a web service

Question

We need to guarantee sending of web service request. Steps are the following:

1. Try to send request to a web service. Sync or async request doesn't matter.
2. If the service doesn't acknowledge the request for some reason(e.g. the service in not available) we try step #1 again in some time (i.e. there is some kind of polling).

The problem is in implementation of step #2 (i.e. polling). This use case looks rather common and I think there should be already solutions ready. So I expect to send just a request to a web service all other logic (i.e. its guaranteed delivery) will be performed by some framework.

Do you know such solutions?

There is "Guaranteed delivery" EIP pattern and Camel supports it. But I didn't find any information how Camel supports it and whether it suits our case.

Our requirements - Java, SOAP, open source solutions. We planning to use Apache CXF but it's not critical.

Final words: 2 great answers were provided:

1. Spring Retry from Brian Agnew. That is rather general approach that works not only with web services.
2. CXF Failover from Ashok Nanda. The solution is in terms of web service and perfectly suites our needs.

Unfortunately I cannot choose both answers as final so I chose Brian’s one as it was the first one and he provided a really great explanation that helped me to see another possible problem:-) Thanks guys!

Answer 1

Leaving aside simply writing your request in some sort of loop, you could look at frameworks such as Spring Retry.

It will allow you to define your retry strategy to take account of backoff strategies, timeouts and when/when not to attempt a retry. The final element is crucial. If you can't connect in the first place, then a retry is feasible. On the other hand, if you connect and send a request but fail to get an acknowledgement, then you need to understand if a retry is appropriate. The concept of idempotency of requests is important in this scenario.

An idempotent HTTP method is a HTTP method that can be called many times without different outcomes. It would not matter if the method is called only once, or ten times over. The result should be the same. Again, this only applies to the result, not the resource itself. This still can be manipulated (like an update-timestamp, provided this information is not shared in the (current) resource representation.