Quelles sont les utilisations pratiques des services Windows? [fermé]

Je suis nouveau dans le travail avec les services Windows. Bien que j'aie appris à créer des services Windows dans VS2010, j'aimerais savoir comment utiliser les services Windows de manière pratique?

J'ai essayé de googler avec le contexte actuel à l'esprit uniquement pour trouver plus de tutoriels sur la façon de créer des services Windows.

EDIT sur l'offre Bounty:

Toutes les réponses sont excellentes mais je cherchais des exemples plus pratiques sur les services Windows et leurs implications? Cela aidera les développeurs à savoir quand il est approprié de les utiliser avec l'étude de cas.

Un service s'exécute en arrière-plan, même si personne n'est connecté à la machine. Tout ce que vous pouvez imaginer vouloir faire sans compter sur une personne pour démarrer une application et cliquer sur un bouton est un bon candidat pour un service. Par exemple, surveiller un dossier et chaque fois qu'un fichier y est écrit, traitez-le d'une manière ou d'une autre. Tout «serveur» auquel vous pouvez penser - serveur Web, serveur ftp, serveur de messagerie - est un service, tout comme de nombreux processus d'arrière-plan auxquels vous ne pensez pas souvent.

Certaines choses qui étaient autrefois écrites en tant que services (fichiers de sauvegarde à 2h du matin, envoyer des e-mails de rappel à 3h du matin, etc.) sont probablement mieux exécutées aujourd'hui en tant que tâches planifiées, qui offrent une flexibilité considérable sur Windows 7 et versions ultérieures, mais si le développeur ne les a jamais apprises, ou le système doit prendre en charge XP, vous trouverez également des services effectuant ce genre de tâches.

Les services sous Windows sont essentiellement des programmes qui s'exécutent sans interface graphique. Les serveurs Web (tels qu'apache), les serveurs de bases de données (tels que les serveurs mysql et sql), les moteurs antivirus et les serveurs d'application / 'middleware' sont tous des exemples pratiques d'applications qui s'exécutent souvent en tant que services. Il peut y avoir un client GUI pour vous permettre d'interagir avec le service, mais le service lui-même n'en a pas. Il fonctionne simplement «en arrière-plan» et fait son travail. De plus, comme les services s'exécutent avec les droits d'utilisateur qui leur sont attribués, ils peuvent s'exécuter en tant qu'utilisateur attribué.si oui ou non un utilisateur est réellement connecté à la machine. Un serveur de base de données aurait donc les mêmes droits d'accès quelle que soit la personne connectée à la machine à l'époque, le cas échéant. Ainsi, vous pouvez voir pourquoi cela serait important - vous ne voulez pas avoir à garder un utilisateur connecté pour garder un serveur Web en marche, par exemple.

Ils sont l'équivalent de Windows (de la manière la plus pratique) aux démons sur * nix.

Un service

Un programme, une routine ou un processus qui exécute une fonction système spécifique pour prendre en charge d'autres programmes, en particulier à un niveau bas (proche du matériel). Lorsque les services sont fournis sur un réseau, ils peuvent être publiés dans Active Directory, ce qui facilite l'administration et l'utilisation centrées sur les services.

Je voudrais savoir de quelle manière pratique les services Windows pourraient être utilisés?

Selon la définition du service, Window Service et d'autres types de services font beaucoup de fonctionnalités. Dans ce contexte, les moteurs de recherche sont votre ami .

Les services Windows sont normalement utilisés lorsqu'une application doit s'exécuter en continu. Vous devez créer un service Windows pour exécuter du code en arrière-plan, sans interaction de l'utilisateur .

Un service Windows s'exécutera même si personne n'est connecté. Le service Windows peut commencer à fonctionner dès que la machine est allumée , ce qui est idéal pour fonctionner en tant que serveur, serveur http par exemple. Personne n'est requis pour se connecter.

Par exemple, s'ils doivent:

1. Attendez les demandes entrantes. (Comme à distance ou wcf)
2. Surveillez une file d'attente, un système de fichiers, etc. Si un programme doit simplement être exécuté périodiquement, comme une fois par jour. Il est normalement plus facile de créer une tâche planifiée.
3. Tout serveur qui accepte les connexions (comme un serveur de messagerie, Web ou FTP) doit généralement être un service Windows.

J'utiliserais un service pour les raisons suivantes:

• Vous n'avez pas besoin d'avoir une session en cours. Ceci est bon pour la sécurité et réduit également les frais généraux sur le serveur.

• Vous obtenez gratuitement certaines des commandes de gestion intégrées
  o Démarrer
  o Arrêter
  o Pause
  o Continuer

• Vous pouvez gérer les événements du serveur tels que l'arrêt.

Liens avec des informations supplémentaires sur ces services:

Sur Asp.net - // TODONT: Utilisez un service Windows uniquement pour exécuter un processus planifié À
quoi sert le service WIndows

Un programme interactif, comme un Winform ou un WPF, est quelque chose que vous voulez qu'un utilisateur ouvre, interagisse et ferme. Une tâche planifiée est quelque chose que vous souhaitez exécuter en arrière-plan à des moments spécifiques - peut-être simplement démarrer, faire quelque chose et arrêter. Un service Windows est quelque chose que vous souhaitez exécuter tout le temps en arrière-plan.

Certains avantages d'un service Windows sont qu'il fonctionne quel que soit l'utilisateur connecté (ou même si aucun utilisateur n'est connecté) et qu'il peut être configuré pour démarrer dès que l'ordinateur démarre, ce qui peut être très utile si le le système est redémarré.

J'ai généralement utilisé des services lorsque je dois surveiller quelque chose comme un dossier ou une boîte de réception de courrier électronique.

Puisque vous avez ajouté la note sur les exemples pratiques à votre question, je vais vous donner quelques exemples de services que j'ai écrits pour les applications d'entreprise (vous ne dites pas si vous êtes un programmeur d'applications d'entreprise, mais je suppose que la plupart des programmeurs C # VS2010 le sont) . Je pense que vous cherchez une idée de ce que les développeurs qui ne travaillent pas pour Microsoft pourraient écrire.

Un service de moniteur de pulsation qui vérifiait si d'autres programmes étaient toujours en cours d'exécution (cela pouvait également fonctionner comme une tâche planifiée, mais a été implémenté en tant que service).

Un service de rédaction de rapports qui a fonctionné dans les files d'attente de demandes de rapports, a exécuté les rapports et les a envoyés à différentes imprimantes en fonction de l'imprimante qui était occupée. Cela a aidé à décharger une bonne partie du travail d'une application héritée et a permis au rapport en cours d'exécution d'être partagé par plusieurs boîtes bon marché exécutant le service.

Il a été implémenté en tant que service afin qu'il s'exécute en continu, démarre automatiquement au redémarrage et puisse utiliser l'interface de services Windows standard pour démarrer, arrêter, suspendre, etc. De plus, s'il s'agissait d'une tâche planifiée, il faudrait initier l'obtention de données à partir d'autres programmes ou d'une source persistante (une file d'attente, un fichier, une base de données) plutôt que d'être disponible pour d'autres programmes à appeler (socket, pipe).

La partie serveur d'une que l' application client / serveur a également été mis en œuvre en tant que service afin qu'il redémarre sur un redémarrage, etc. Il y avait un autre projet avec un .exe qui a eu lieu le même programme pas en tant que service, pour le rendre plus facile à débogage sur les machines de développement.

J'espère que ça aide. Cependant, les autres réponses sont de meilleures réponses générales, en particulier l'idée que les tâches planifiées sont probablement plus faciles à écrire et à administrer pour la plupart des applications maintenant.

Il existe de nombreuses utilisations pratiques d'un service. Une utilisation pratique principale est l'interaction entre l'interface utilisateur et les programmes de service (ou démon sous Unix), qui est, dans ce cas, la différence entre un client et un serveur. Un serveur reçoit des demandes, traite la demande et renvoie généralement une réponse. En d'autres termes, il sert une demande. Pensez à SQLSERVER, IIS ou telnet. Un client utilise généralement un serveur en envoyant des demandes au serveur, puis en affichant ou en traitant la réponse. c'est-à-dire une application de saisie de données, une application web ... Le serveur est presque toujours installé en tant que service dans Windows (ou un démon sous Unix) et le client est généralement juste une application normale avec un GUI. Il existe de nombreuses utilisations plus complexes d'un service, mais c'est celle que vous utiliserez probablement le plus.

Par exemple: je travaille actuellement sur un serveur vidéo SIP / H323. Il reçoit les demandes d'une application utilisant un SDK que j'ai écrit, les traite et répond en retour. L'application de serveur vidéo est installée en tant que démon sur une machine Linux intégrée (ce serait un service sur une machine Windows intégrée, mais qui utilise quand même Windows pour l'intégration) et toute application utilisant le SDK serait considérée comme un client.

Bien sûr, vous pouvez écrire de telles applications et ne pas en faire un service. Vous pouvez toujours les faire démarrer au démarrage de Windows et les exécuter en arrière-plan. Cependant, cela implique plusieurs entrées de registre et quelques finagling dans votre code - il est beaucoup plus facile de faire en utilisant l'api c que dans quelque chose comme .NET. Microsoft a, d'autre part, rendu cela beaucoup plus facile en créant des services et en nous permettant de les enregistrer avec le système d'exploitation. Il est beaucoup plus simple et plus facile à mettre en œuvre que de le faire manuellement.

Exemples de programmes candidats:

• Systèmes qui doivent surveiller les ressources / autres applications et envoyer des rapports (activité des utilisateurs, types particuliers de trafic de fichiers, notifications de mauvaise conduite des applications)

• Systèmes offrant des services à d'autres applications locales (traductions, conversion de fichiers, messagerie inter-système)

• Logiciel antivirus.

Je pense que ce sont les grands exemples qui ne peuvent pas être facilement réalisés à l'aide de tâches planifiées.

Mes exemples préférés d'utilisation des services:

1. Serveurs - programmes qui répondent aux demandes des clients distants. Ils s'exécutent généralement en tant que services pour vous assurer qu'ils sont disponibles, peu importe si un utilisateur est connecté ou non au serveur. L'exécution en tant que service signifie également que le serveur commence à traiter les demandes dès que la machine est démarrée, personne ne doit se connecter à la machine pour démarrer le programme après le redémarrage de la machine pour une raison quelconque. Un serveur de base de données en est un excellent exemple.
2. Traitement en arrière-plan - programmes chargés de traiter les données d'une source de données et de stocker les résultats dans une cible de données. La cible de données est souvent une source pour un autre processus, etc. L'exécution en tant que services permet à ces programmes de rester là et d'attendre que les données arrivent. Il permet également aux développeurs d'améliorer la robustesse du traitement en divisant le processus en plusieurs étapes semi-indépendantes.

Voici un exemple d'utilisation du concept de service avec du vrai code (voir ci-dessous).

Il s'agit de configurer un bus de service qui consomme hors d'une file d'attente et écoute les messages des serveurs Web et des interfaces graphiques client.

Lorsqu'il reçoit les messages, il fait la logique que le domaine garantit, il enregistre les événements sur le disque et publie ces événements sur le courtier de messages.

La plupart des applications plus grandes qui sont couplées de manière lâche implémentent une sorte d'architecture "de travail" comme celle ci-dessous.

Le projet Documently est un exemple de projet que nous avons créé pour que des gens comme vous apprennent les architectures distribuées. Vous pouvez me poser des questions directement dans le projet, ou le créer et implémenter une fonctionnalité à apprendre, puis soumettre une demande d'extraction (et obtenir des commentaires de code).

https://github.com/haf/Documently/blob/master/src/Documently.Domain.Service/Program.cs :

using System.Threading;
using Castle.MicroKernel.Registration;
using Castle.Windsor;
using Documently.Infrastructure;
using Documently.Infrastructure.Installers;
using MassTransit;
using Topshelf;
using log4net;
using log4net.Config;

namespace Documently.Domain.Service
{
    class Program
    {
        private static readonly ILog _Logger = LogManager.GetLogger(typeof (Program));

        private IWindsorContainer _Container;
        private IServiceBus _Bus;

        public static void Main(string[] args)
        {
            Thread.CurrentThread.Name = "Domain Service Main Thread";
            HostFactory.Run(x =>
            {
                x.Service<Program>(s =>
                {
                    s.ConstructUsing(name => new Program());
                    s.WhenStarted(p => p.Start());
                    s.WhenStopped(p => p.Stop());
                });
                x.RunAsLocalSystem();

                x.SetDescription("Handles the domain logic for the Documently Application.");
                x.SetDisplayName("Documently Domain Service");
                x.SetServiceName("Documently.Domain.Service");
            });
        }

        private void Start()
        {
            XmlConfigurator.Configure();
            _Logger.Info("setting up domain service, installing components");

            _Container = new WindsorContainer()
                .Install(
                    new RavenDbServerInstaller(),
                    new CommandHandlerInstaller(),
                    new EventStoreInstaller(),
                    new BusInstaller(Keys.DomainServiceEndpoint)
                    );

            _Container.Register(Component.For<IWindsorContainer>().Instance(_Container));
            _Bus = _Container.Resolve<IServiceBus>();

            _Logger.Info("application configured, started running");
        }

        private void Stop()
        {
            _Logger.Info("shutting down Domain Service");
            _Container.Release(_Bus);
            _Container.Dispose();
        }
    }
}

Il y a quelque temps, mon équipe a implémenté 3 services Windows sur une banque ici au Brésil, comme ci-dessous:

• Interface entre les systèmes: Nous avions une application front-office chargée de la réservation des transactions en bourse et une application back-office, chargée de la comptabilité et du calcul des frais de transaction. Initialement, la communication intersystème a été effectuée directement sur SQL Server, mais trop de problèmes de verrouillage et de rétention ont fait souffrir le système de performances médiocres. Un service a été implémenté pour se connecter aux bases de données avant et arrière et effectuer la lecture / écriture appropriée en utilisant une sorte de stratégie de rétention (au lieu d'écrire chaque transaction sur le serveur SQL, nous conservons les données dans une certaine mesure, disons 1000 transactions, et a fait un insert en vrac, qui était 40 fois plus rapide que la solution d'origine, et n'a pas verrouillé la plupart des tables impliquées pendant longtemps).

• Message Queue: avec la solution précédente, nous avons écrit un gestionnaire de file d'attente de messages personnalisé, afin que plusieurs procédures de traitement par lots puissent s'exécuter de manière asynchrone. Cela a été intégré avec MSMQ et IBM-MQSeries.

• Centralisation des services aux entreprises: plusieurs applications utilisateur avaient besoin de données communes comme les cours des actions, par exemple, nous avons donc écrit un service personnalisé chargé de recevoir les "demandes de prix" et de renvoyer les informations sur les prix.

L'un des aspects qui nous a amenés à écrire des services, au lieu de "robots", est que les services peuvent s'exécuter en tant qu'utilisateur spécifique (comme quelqu'un l'a déjà souligné sur ce fil), et peuvent être lancés automatiquement lorsque la machine démarre.

Les services n'ont également pas besoin d'un bureau ou d'un service de gestion de fenêtres pour fonctionner. Ils peuvent fonctionner en arrière-plan (enfin, ils doivent fonctionner en arrière-plan).

Et, si vous êtes comme certains de mes pairs qui n'aiment pas écrire des interfaces utilisateur, les services sont de grands défis technologiques, car ils ne doivent généralement pas échouer. C'est donc très amusant d'écrire un service. :)

Si vous concevez une application de bureau Windows qui doit s'exécuter en tant qu'utilisateur standard mais doit parfois effectuer une tâche qui nécessite des privilèges d'administrateur, vous pouvez utiliser un service.

Votre programme d'installation installe le service avec les autorisations nécessaires, votre application de bureau appelle le service lorsqu'elle doit effectuer une tâche avec des privilèges d'administrateur.

Il y a des implications de sécurité à cette approche qui dépassent le cadre de cette réponse.

Pour les programmeurs, la principale raison d'utiliser le service est:

• Ce programme doit démarrer automatiquement sur une machine Windows après un redémarrage.

Tout ce que vous écrivez et qui doit être conforme à ce qui précède doit s'exécuter en tant que service Windows.

Le service le plus utile que j'ai écrit, du point de vue de l'utilisateur final:
* L'utilisateur a imprimé des factures UGLY sur une imprimante matricielle avec pilote d'impression RAW.
* L'utilisateur voulait une facture JOLIE avec le logo, des graphiques en ligne lisse.
* Pas d'accès au code hérité.

Le service devrait:
* Surveiller (plusieurs) dossiers d'imprimantes pour les travaux d'impression.
* Créez un PDF de la facture.
* Le PDF "sous-tend" une belle image de facture vierge
* Superpose le texte brut
* Recherche les métadonnées, en fonction du dossier utilisé (IE: imprimante utilisée)

Ensuite, les métadonnées:
* Génèrent le PDF
* et / ou impriment le PDF
* et / ou déposez le PDF dans un dossier de destination finale
* et / ou supprimez le PDF
* et / ou envoyer la facture PDF au client par e-mail

Dans ce cas, il gère les moteurs ghost-script, PLC et PDF. Cela fonctionne très bien depuis des années. Inclure les fichiers journaux !!!