¿Cuáles son los usos prácticos de los servicios de Windows? [cerrado]

Soy nuevo en trabajar con los servicios de Windows. Aunque aprendí a crear servicios de Windows en VS2010, ¿ me gustaría conocer algunas formas prácticas en las que se podrían usar los servicios de Windows?

Intenté buscar en Google teniendo en cuenta el contexto actual solo para encontrar más tutoriales sobre cómo crear servicios de Windows.

EDITAR sobre la oferta de recompensa:

Todas las respuestas son geniales, pero estaba buscando ejemplos más prácticos sobre los servicios de Windows y sus implicaciones. Esto ayudará a los desarrolladores a saber cuándo es apropiado usarlos con el estudio de caso.

Un servicio se ejecuta en segundo plano, incluso si nadie ha iniciado sesión en la máquina. Cualquier cosa que pueda imaginar querer hacer sin depender de una persona para iniciar una aplicación y hacer clic en un botón es un buen candidato para un servicio. Por ejemplo, monitorear una carpeta y cada vez que se escribe un archivo, procesarla de alguna manera. Cualquier "servidor" que se te ocurra (servidor web, servidor ftp, servidor de correo) es un servicio, y también lo son muchos procesos en segundo plano que a menudo no piensas.

Algunas cosas que alguna vez se escribieron como servicios (archivos de copia de seguridad a las 2 a.m., enviar correos electrónicos de recordatorio a las 3 a.m., etc.) probablemente se hagan mejor hoy como tareas programadas, que tienen una gran flexibilidad en Windows 7 y versiones posteriores, pero si el desarrollador nunca las aprendió, o el el sistema debe ser compatible con XP, también encontrará servicios que realizan ese tipo de tareas.

Los servicios en Windows son básicamente programas que se ejecutan sin una GUI. Los servidores web (como apache), los servidores de bases de datos (como el servidor mysql y sql), los motores antivirus y los servidores de aplicaciones / 'middleware' son ejemplos prácticos de aplicaciones que a menudo se ejecutan como servicios. Puede haber un cliente GUI que le permita interactuar con el servicio, pero el servicio en sí no tiene uno. Simplemente se ejecuta 'en segundo plano', haciendo lo suyo. Además, dado que los servicios se ejecutan con los derechos de usuario asignados a ellos, pueden ejecutarse como su usuario asignadosi un usuario está realmente conectado o no a la máquina. Por lo tanto, un servidor de base de datos tendría los mismos derechos de acceso, independientemente de la persona que haya iniciado sesión en la máquina en ese momento, si corresponde. Entonces puede ver por qué eso sería importante: no desea tener que mantener un usuario conectado para mantener un servidor web en funcionamiento, por ejemplo.

Son el equivalente de Windows (en la mayoría de las formas prácticas) a Daemons en * nix.

Servicio

Un programa, rutina o proceso que realiza una función específica del sistema para admitir otros programas, particularmente en un nivel bajo (cercano al hardware). Cuando los servicios se proporcionan a través de una red, pueden publicarse en Active Directory, lo que facilita la administración y el uso centrados en el servicio.

Me gustaría saber algunas formas prácticas en que los servicios de Windows podrían ser utilizados.

Según la definición del servicio, el Servicio de Windows y otros tipos de servicios ofrecen muchas funcionalidades. En este contexto, los motores de búsqueda son tus amigos .

Los servicios de Windows se usan normalmente cuando una aplicación necesita ejecutarse continuamente. Debe crear un servicio de Windows para ejecutar código en segundo plano, sin interacción del usuario .

Se ejecutará un servicio de Windows incluso si nadie ha iniciado sesión. El servicio de Windows puede comenzar a ejecutarse tan pronto como se enciende la máquina , lo que lo hace ideal para funcionar como un servidor, por ejemplo, un servidor http. No se requiere que nadie inicie sesión.

Por ejemplo, si necesitan:

1. Espere las solicitudes entrantes. (Me gusta a través de control remoto o wcf)
2. Monitoree una cola, un sistema de archivos, etc. Si un programa solo necesita ejecutarse periódicamente, como una vez al día. Normalmente es más fácil crear una tarea programada.
3. Cualquier servidor que acepte conexiones (como un servidor de correo, web o FTP) generalmente debería ser un servicio de Windows.

Usaría un servicio por las siguientes razones:

• No necesita tener una sesión en ejecución. Esto es bueno para la seguridad y también reduce la sobrecarga en el servidor.

• Obtiene algunos de los comandos de administración integrados de forma gratuita
  o Inicio
  o Detener
  o Pausa
  o Continuar

• Puede manejar eventos del servidor como el apagado.

Enlaces con información adicional sobre estos servicios:

En Asp.net - // TODONT: use un servicio de Windows solo para ejecutar un proceso programado
¿Qué es el uso del servicio de Windows?

Un programa interactivo, como un winform o WPF, es algo que desea que un usuario abra, interactúe y cierre. Una tarea programada es algo que desea ejecutar en segundo plano como momentos específicos; tal vez solo inicie, haga algo y pare. Un servicio de Windows es algo que desea ejecutar todo el tiempo en segundo plano.

Algunas ventajas de un servicio de Windows es que se ejecuta sin importar qué usuario haya iniciado sesión (o incluso si ningún usuario ha iniciado sesión) y se puede configurar para que comience a ejecutarse tan pronto como se inicie la computadora, lo que puede ser realmente útil si el El sistema se reinicia.

Usualmente he usado servicios cuando tengo que monitorear algo como una carpeta o bandeja de entrada de correo electrónico.

Como agregó la nota sobre ejemplos prácticos a su pregunta, le daré algunos ejemplos de servicios que he escrito para aplicaciones empresariales (no dice si es un programador de aplicaciones empresariales, pero supongo que la mayoría de los programadores de C # VS2010 lo son) . Creo que está buscando una idea de lo que los desarrolladores que no trabajan para Microsoft podrían escribir.

Un servicio de monitoreo de latidos que verificó si otros programas todavía se estaban ejecutando (esto podría haber funcionado también como una tarea programada, pero se implementó como un servicio).

Un servicio de redacción de informes que trabajó a través de colas de solicitudes de informes, ejecutó los informes y los envió a diferentes impresoras dependiendo de qué impresora estaba ocupada. Esto ayudó a descargar una buena cantidad de trabajo de una aplicación heredada y permitió que el informe en ejecución fuera compartido por varias cajas baratas que ejecutaban el servicio.

Se implementó como un servicio para que se ejecute continuamente, se inicie automáticamente al reiniciar y pueda usar la interfaz estándar de servicios de Windows para iniciar, detener, pausar, etc. Además, si fuera una tarea programada, necesitaría inicie la obtención de datos de otros programas o de una fuente persistente (una cola, un archivo, una base de datos) en lugar de estar disponible para que otros programas llamen (socket, pipe).

La parte del servidor de esa aplicación cliente / servidor también se implementó como un servicio para que se reiniciara al reiniciar, etc. Hubo otro proyecto con un .exe que ejecutó el mismo programa no como un servicio, para que sea más fácil depurar en máquinas de desarrollo.

Espero que eso ayude. Sin embargo, las otras respuestas son mejores respuestas generales, especialmente la idea de que las tareas programadas son probablemente más fáciles de escribir y administrar para la mayoría de los propósitos ahora.

Hay muchos usos prácticos para un servicio. Un uso práctico principal es la interacción entre la IU y los programas de servicio (o daemon en unix), que es, en este caso, la diferencia entre un cliente y un servidor. Un servidor recibe solicitudes, procesa la solicitud y generalmente envía una respuesta. En otras palabras, atiende una solicitud. Piense en SQLSERVER, IIS o telnet. Un cliente, generalmente utiliza un servidor enviando solicitudes al servidor y luego mostrando o procesando la respuesta. es decir, una aplicación de entrada de datos, una aplicación web ... El servidor casi siempre se instala como un servicio en Windows (o un demonio en Unix) y el cliente suele ser simplemente una aplicación normal con una interfaz gráfica de usuario. Hay muchos usos más complejos de un servicio, pero este es el que probablemente usará más.

Por ejemplo: actualmente estoy trabajando en un servidor de video SIP / H323. Recibe solicitudes de una aplicación usando un SDK que escribí, las procesa y responde. La aplicación del servidor de video se instala como un demonio en una máquina Linux embebida (sería un servicio en una máquina Windows embebida, pero de todos modos, quién usa Windows para embebido) y cualquier aplicación que utilice el SDK se consideraría un cliente.

Por supuesto, podría escribir tales aplicaciones y no convertirlas en un servicio. Todavía puede hacer que se inicien al iniciar Windows y hacer que se ejecuten en segundo plano. Sin embargo, implica varias entradas de registro y algunas modificaciones en su código: es mucho más fácil hacerlo usando la API c que en algo como .NET. Microsoft, por otro lado, lo hizo mucho más fácil al crear servicios y al permitirnos registrarlos en el sistema operativo. Es mucho más simple y fácil de implementar que hacerlo manualmente.

Ejemplos de programas candidatos:

• Sistemas que deben monitorear recursos / otras aplicaciones y enviar informes (actividad del usuario, tipos particulares de tráfico de archivos, notificaciones de mal comportamiento de la aplicación)

• Sistemas que ofrecen servicios a otras aplicaciones locales (traducciones, conversión de archivos, mensajería entre sistemas)

• Software antivirus.

Creo que estos son los grandes ejemplos que no se pueden hacer fácilmente usando tareas programadas.

Mis ejemplos favoritos de uso de servicios:

1. Servidores : programas que atienden solicitudes de clientes remotos. Por lo general, se ejecutarán como servicios para asegurarse de que estén disponibles sin importar si algún usuario ha iniciado sesión en el servidor o no. La ejecución como servicio también significa que el servidor comienza a procesar las solicitudes tan pronto como se inicia la máquina, nadie tiene que iniciar sesión en la máquina para iniciar el programa después de que la máquina se reinicie por cualquier motivo. Un servidor de base de datos es un gran ejemplo.
2. Procesamiento en segundo plano : programas que son responsables de procesar los datos de una fuente de datos y almacenar los resultados en un objetivo de datos. El objetivo de datos es a menudo una fuente para otro proceso, y así sucesivamente. Ejecutar como servicios permite que esos programas simplemente permanezcan allí y esperen a que lleguen los datos. También permite a los desarrolladores mejorar la robustez del procesamiento al dividir el proceso en múltiples pasos semi-independientes.

Aquí hay un ejemplo de uso del concepto de servicio con código real (ver abajo).

Lo que hace es configurar un bus de servicio que consume fuera de una cola y escucha los mensajes de los servidores web y las GUI del cliente.

Cuando recibe los mensajes, hace qué lógica garantiza el dominio, guarda los eventos en el disco y los publica en el intermediario de mensajes.

La mayoría de las aplicaciones más grandes que están acopladas libremente implementan algún tipo de arquitecturas de "trabajador" como la que se muestra a continuación.

El proyecto Documently es un proyecto de muestra que hemos creado para que personas como usted aprendan arquitecturas distribuidas. Puede hacerme preguntas directamente en el proyecto, o bifurcarlo e implementar alguna característica para aprender y luego enviar una solicitud de extracción (y obtener comentarios de código).

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();
        }
    }
}

Hace algún tiempo, mi equipo implementó 3 servicios de Windows en un banco aquí en Brasil, como a continuación:

• Interfaz entre sistemas: teníamos una aplicación de front-office responsable de reservar operaciones en el mercado de valores, y una aplicación de back-office, responsable de contabilizar y calcular las tarifas de las operaciones. Inicialmente, la comunicación entre sistemas se realizó directamente en SQL Server, pero demasiados problemas de bloqueo y retención hicieron que el sistema sufriera un bajo rendimiento. Se implementó un servicio para conectarse a las bases de datos frontales y posteriores y realizar la lectura / escritura correcta utilizando algún tipo de estrategia de retención (en lugar de escribir cada operación en el servidor SQL, mantenemos los datos en cierta medida, digamos 1000 operaciones, y hizo una inserción masiva, que fue 40 veces más rápida que la solución original, y no bloqueó muchas de las tablas involucradas durante mucho tiempo).

• Cola de mensajes: junto con la solución anterior, escribimos un controlador de cola de mensajes personalizado, por lo que varios procedimientos de procesamiento por lotes podrían ejecutarse de forma asincrónica. Eso se integró con MSMQ e IBM-MQSeries.

• Centralización de servicios comerciales: varias aplicaciones de usuario necesitaban datos comunes como precios de acciones, por ejemplo, por lo que escribimos un servicio personalizado responsable de recibir "solicitudes de precios" y enviar la información de precios.

Uno de los aspectos que nos llevó a escribir servicios, en lugar de "robots", es que los servicios pueden ejecutarse como un usuario específico (como alguien ya señaló en este hilo) y pueden iniciarse automáticamente cuando la máquina arranca.

Los servicios tampoco necesitan un escritorio o un servicio de administración de ventanas para ejecutarse. Pueden ejecutarse en segundo plano (bueno, deben ejecutarse en segundo plano).

Y, si usted es como algunos de mis colegas a quienes no les gusta escribir interfaces de usuario, los servicios son grandes desafíos tecnológicos, porque generalmente no deben fallar. Entonces es muy divertido escribir un servicio. :)

Si está diseñando una aplicación de escritorio de Windows que necesita ejecutarse como usuario estándar pero a veces necesita realizar una tarea que requiere privilegios de administrador, puede usar un servicio.

Su instalador instala el servicio con los permisos necesarios, su aplicación de escritorio llama al servicio cuando necesita realizar una tarea con privilegios de administrador.

Hay implicaciones de seguridad para este enfoque que están más allá del alcance de esta respuesta.

Para los programadores, la razón principal para usar el servicio es:

• Este programa debe iniciarse automáticamente en una máquina con Windows después de reiniciar.

Todo lo que escriba que debe cumplir con lo anterior debe ejecutarse como un Servicio de Windows.

El servicio más útil que he escrito, desde la perspectiva del usuario final:
* El usuario imprimió facturas UGLY en una impresora matricial con controlador de impresión RAW.
* El usuario quería una factura BONITA con logotipo, gráficos de líneas suaves.
* Sin acceso al código heredado.

El servicio:
* Supervisaría (múltiples) carpetas de impresoras para trabajos de impresión.
* Crear un PDF de la factura.
* PDF "subyace" una bonita imagen de factura en blanco
* Superpone el texto sin procesar
* Busca metadatos, en función de la carpeta que se está usando (IE: impresora que se está usando)

Luego los metadatos:
* Generar PDF
* y / o imprimir PDF
* y / o archivar el PDF en una carpeta de destino final * y / o enviar por correo electrónico la factura en PDF al cliente
* y / o eliminar el PDF

En este caso, maneja motores de script fantasma, PLC y PDF. Ha estado funcionando muy limpiamente durante años. Incluye archivos de registro !!!