submitting to and monitoring an unreliable webservice

I am building an ASP.NET website which will collect data from a user and submit it to a 3rd party webservice. The webservice is somewhat unreliable and for this reason there is a backup service.

If a call to the primary service fails (timeout or some other error) then I need to flip a bit in a static class which will trip the system to use the secondary service.

At this point, I need to start polling the primary service (with dummy data) to see if it is back up (at which point I will receive an OK code in return). At this point I need to flip the bit back so that the website starts using the primary service again.

I've had a read of this http://stackoverflow.com/questions/990986/should-i-use-a-windows-service-or-an-asp-net-background-thread and I think that separating out the code into a Windows Service would be the cleanest method of performing the polling, but then how would I communicate with the web appication.

One thought I've had is to expose a webservice that the Windows Service could use to communicate into the webapp but this seems both messy and over-kill.

I'd appreciate your thoughts and experiences performing similar tasks.

Thanks

From stackoverflow

• I think the Windows service is the way to go, definitely.

  As for the communication between the service and your web site, the best answer depends on the size and scale of your solution. If you are building something that needs to be reliable, I'd suggest you implement some sort of queue between your ASP.NET site and your Windows service. You have a lot of options here too, depending on budget and ability: BizTalk, MSMQ, and SQL Server queues (SSIS). Alternatively if you are looking for something smaller scale, I'd recommend you just stick it into a database table somewhere.

  I would avoid using files on the file system because you will encounter issues with file locks and multithreading. I would also avoid directly communicating with the service because you risk losing the in-memory queue if the service fails for any reason.

  Edited to add:

  If reliability isn't a concern here, you could use a WPF named-pipes hosted service for communication between your website and your Windows service. This avoids much of the overheads normally involved in classic Web Services and is surprisingly quick. The only down-side is that self-hosting a WPF service is tricky and can be difficult to keep the service up.

  Greg B : Hi John, The 3rd party system is a standard .NET web service (.asmx) and if the request timesout or errors I plan at that point to resubmit the current request to the secondary service

  Jon Grant : Yeah I understand that - I'm saying you still need a reliable transport between your web site and your Windows service. I totally agree that using a Windows service is the right approach, and was answering the "how do I communicate with the web application" part of your question :)