Myśli o uruchomieniu aplikacji typu Service Windows na ASP.NET 4 with StartMode= " AlwaysRunning"

Zwykle patrzyłbym na pisanie usługi Windows do zarządzania zadaniami, które nie nadają się do hostowania w aplikacji internetowej. Tego typu zadania są zwykle długotrwałymi procesami lub zaplanowanymi zadaniami. Chociaż jest to zwykle podstawowe podejście do tego typu zadań, Ludzie przyjrzeli się sposobom uruchamiania tego rodzaju procesów w tle w aplikacji internetowej, uruchamiając kilka wątków w zdarzeniu Application_Start wystawionym przez Global.asax. Problem z tym podejście zawsze polegało na tym, że jeśli twój proces roboczy usługi IIS umrze, Twój wątek w tle również zostanie zabity(skutecznie Twoja "usługa Windows" zostanie zatrzymana do czasu otrzymania następnego żądania).

ASP. net 4.0 oferuje rozwiązanie tego problemu. Możesz teraz ustawić StartMode na 'AlwaysRunning', jak opisano w tym blogu Scotta Gu. gdzieś w komentarzach do tego wpisu ktoś zadaje pytanie o opłacalność hostingu zadań typu usługi Windows w IIS od nowa funkcja zapewnia, że proces roboczy jest zawsze uruchomiony. Scott wspomniał, że to zdecydowanie wesprze scenariusz. Ponadto, niedawne wprowadzenie AppFabric oznacza, że Microsoft sam dostarcza proste Hooki do hostingu i monitorowania usług WCF i WF w aplikacji internetowej.

Co to oznacza dla tych z nas, którzy pisali usługi Windows do obsługi naszych aplikacji internetowych? Czy powinniśmy przyjąć ten model? Jakie są pułapki? Z tego co wiem, istnieje wiele zalet hostowania procesów "usługi Windows" w aplikacji internetowej, z których najbardziej przydatna jest łatwość wdrożenia. Ponadto możemy rozpocząć tworzenie prostych interfejsów użytkownika do naszych usług, które dostarczają informacji o tym, co dzieje się w czasie wykonywania.

Gdybym miał iść tą trasą, nie sądzę, żebym hostował funkcjonalność typu "usługa Windows" w aplikacji internetowej klienta. Prawdopodobnie stworzyłbym nowy projekt aplikacji webowej (dużo tak jak w kontekście usługi Windows), który będzie obsługiwał moje długie uruchomione / zaplanowane procesy zadań. Myślę, że jest ku temu kilka powodów.

1. bezpieczeństwo. Może istnieć inny model zabezpieczeń dla interfejsu wyświetlającego informacje o uruchomionych procesach w tle. Nie chciałbym ujawniać tego interfejsu nikomu poza zespołem operacyjnym. Ponadto aplikacja internetowa może działać jako inny użytkownik, który ma podwyższony zestaw uprawnienia.
2. utrzymanie . Byłoby wspaniale móc wdrożyć zmiany w aplikacji hostującej procesy w tle bez wpływu na korzystanie przez użytkownika z witryny front-end.
3. wydajność . Oddzielenie aplikacji od strony głównej przetwarzającej żądania użytkowników oznacza, że wątki w tle nie zmniejszają możliwości obsługi kolejki przychodzących żądań przez IIS. Ponadto aplikacja przetwarzająca zadania w tle może być w razie potrzeby wdrożone na oddzielnym serwerze.

Byłbym bardzo zainteresowany, aby usłyszeć swoje przemyślenia na temat tego podejścia i czy powinienem trzymać się Usług Windows. Bardzo mnie kusi wypróbowanie tego nowego podejścia.