Question

I have a decent sized chunk of .NET code that now needs to be accessed by an ASP web page. Transactions need to be sent at regular instances to this “server” for processing. Processing takes less than a second and there are maybe 100-1000 such transactions a day

I’ve really only worked with COM and windows services before, so my normal approach would be to have a windows service will all the necessary data in memory running and a client GUI would connect and send the request and receive the answer.

From what I can make out about ASP is that a DLL or a web service is the way to access the server nowadays.

My issue with the DLL is, is that the DLL would have to load information out of a database to build up the latest information before a transaction could be checked. Should only take a second as well, but is additional overhead as opposed to a constantly running windows service. On the other hand the windows service needs to be more error tolerant.

There are only 3-4 APIs that need to be called and it is unlikely to change in the future.

So the question: Windows service + WCF/Sockets/… OR DLL OR Webservices?

Answer 1

I would go with the DLL/Web service(or WCF Service) myself. ASP.NET has caching available, and you can also create some singleton type objects that live for the lifetime of the application (which can be adjusted via IIS). Something like this would basically allow you to have that persistent state that you would also have in a windows service.

The only real benefit that I can offer up is that using DLL/Web Service requires a lot less configuration/permissions than a windows service; and with a windows service you’d also have the issue of IPC to deal with (and all the security fun that goes along with that).