Reputation: 948
I currently have a Windows Service which continually runs throughout the day. It has multiple threads which kick off:
The tasks are not the important part of this question but it gives you the idea that this Windows service has grown to be a monster. It manages the imports of somewhere in the region of 300 million records per day.
It is hectic, but it works.
This iteration of development is giving me a chance to review the service and possibly break it down so that it is more manageable. It is thought that this could be multiple services with one manager service - ideal if a component needs to be updated then the whole thing does not need to grind to a hault.
Does anyone have any experience with this? I am keen to hear about your approach because it is new territory for me.
I have read this SO post which touches on the topic.
Cheers.
Upvotes: 2
Views: 1602
Reputation: 4842
I've done something similar for our background services, there's basically a ServiceHost and "Servlets" which are loaded via appdomains so they don't impact each other.
Upvotes: 1
Reputation: 62157
Why a service? Pretty much none of the things you do- except the 24/7 task for imports - are something I would do as a service.
I would use:
The only thing that may justify a service is the 24/7 XML import - unless you can get away starting it, for example, every 5 minutes.
Upvotes: 0
Reputation: 7210
Your description sounds a lot like the thing I wrote about 2 years ago. A windows service which hosts addins and runs them in multithreaded environment. The architecture used is the .NET addin pipeline introduced in .NET 3.5 (System.AddIn-namespace). It works like a charm as I also integrated live/hot updates. It's so easy to implement new addins and just plug them in whenever I like. So I really recommend using this addin stuff.
See http://msdn.microsoft.com/en-us/library/cc175292.aspx for a quickstart.
Upvotes: 4