submitting to and monitoring an unreliable webservice

Question

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

Answer 1

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.