I need to create a service in .NET that maintains (inner) state in-memory, spawns multiple threads and is generally long-running. There are a lot options -
I really don't know which to choose. Most of the functionality is in a library used by this service, so the service itself is rather simple.
On one hand, it's important the service host is as close to "simply working" as possible, which excludes Windows Service. On the other hand, it's important that the service is not taken down by the host just because there's no external activity, which makes WCF kind o' "scary". As for WF, it's strongest selling point is the ability to create processes as, um..., workflows, which is something I don't need nor want.
To sum it up, the plethora of Microsoft technologies got me a bit confused.
I'd appreciate help regarding the pros and cons of each solution (or other's I've failed to mention) for the problem of a stateful, long running service in .NET
Thanks,
Asaf
P.S.,
I'm using .NET 4.
EDIT:
Thanks for all the replies thus far!
Asaf.
EDIT 2:
I'll use a Windows Service, and might host a WCF service inside it to allow other processes to communicate with it.
Thanks,
Asaf
Based on your description, your best bet is #1, a Good Old Windows Service. You can assign work to it, it can run as long as you want, and it can spawn threads. Not sure what you mean by "simply working," or why that puts a Windows Service out of the running.
You could, alternatively, make a simple console app, but you'd have to handle the management (restarts, etc) yourself.
WCF is essentially .NET remoting over the web, it doesn't handle long-running processes by itself. Workflow Foundation can handle long-running workflows, but only that.
According to your requirements "(inner) state in-memory, spawns multiple threads and is generally long-running" there are really two options:
Other two mentioned are derivatives of these. First one is too primitive and let's forget about this. But for ease of debug i recommend in Main
check Environment.UserInteractive
and if true run as console app, else as service. So your choice should be 2nd.
WCF is communication framework and has nothing about long running service. IIS can host WCF apps, but no multithreading and inmemory data there, it is single call as web service. WF is workflow framework and again has nothing about services. It can help implementing complex flow logic.
Both WCF and WF can be used in Windows service.
Since you don't seem to need any workflow-related features, my vote goes out to Durable Services in WCF. This is new in .NET 3.5, and it allows WCF serviecs to persist their state into a provider-based "persistance store", typically a SQL Server backend database (but there's also a filesystem-based provider, and it's extensible - you can write your own if need be).
Check out some excellent blog posts on this topic:
WCF is a great and powerful communication library which frees you from a lot of hassle and details that you'd have to deal with when creating all of this from scratch.
WCF can be hosted in IIS (with all its deficiencies), or you can stick your WCF service into a Windows NT Service and have it start up and run when the machine boots, without anyone being logged on.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With