Windows Server 2003 en todas sus ediciones, inician algunas aplicaciones durante el arranque del sistema no vinculados a ningún usuario. Estas aplicaciones se denominan Servicios, o servicios Win32 por su relación con las API Win32 para interactuar con el sistema operativo. Similar a los demonios de Unix, los servicios implementan frecuentemente la parte del servidor del modelo de aplicación cliente/servidor. Adquirir conocimiento sobre la funcionalidad, seguimiento, administración y resolución de problemas de los servicios, mejora nuestra habilitad de llevar a cabo procedimientos de diagnóstico para resolver problemas relacionados con los servicios.
Un servicio no es más ni menos que una aplicación basada en sofware que lleva a cabo una función específica del sistema y que frecuentemente proporciona una API para ser llamada por otros procesos. Los servicios son aplicación que se ejecutan en segundo plano en el equipo local. Muchos también proporcionan funcionalidad para otros equipos en la red.
En Windows Server 2003 y anteriores los servicios son llamadas a procedimiento remoto (RPC) hasta el punto de que pueden ser llamados desde equipos remotos de la red. La mayoría de servicios pueden añadirse/quitarse desde la opción Añadir/quitar Componentes de Windows en Añadir o quitar programas del panel de control, y pueden administrarse y configurarse mediante el complemento Services, que se encuentra en Herramientas administrativas o usando el comando Sc.exe.
Modelo aplicación cliente/servidor
Frente al paradigma informático cliente/servidor, uno o más clientes y uno o más servidores, junto al sistema operativo subyacente y la comunicacón interproceso (IPC), forma un modelo que permite la informática distribuida, análisis y presentación.
En este modelo, el cliente es el proceso que interactúa con el usuario y que tiene ciertas características:
- Presenta el interfaz de usuario, que normalmente es un interfaz de usuario gráfico (GUI).
- Solicitudes al servidor y formularios de consulta o comandos en una estructura predefinida hacia el servidor, basados en entradas del usuario.
- Se comunica con el servidor mediante un método IPC como es RPC, y lo usa para la transmisión de solicitudes o comandos hacia el servidor.
- Lleva a cabo análisis de datos sobre los resultados envíados por el servidor y muestra los resultados al usuario en un formato de aplicación definido.
El servidor por su parte es un proceso, o un conjunto de procesos, todos los que pueden existir en un equipo único que proporciona un servicio a uno o más clientes. El servidor tiene las siguientes características:
- Generalmente trabaja para el cliente. La naturaleza y extensión de sus servicios están determinados por los objetivos empresariales del sistema cliente/servidor.
- Responder a consultas o comandos desde los clientes. No inicia ninguna conversación con ningún cliente, aunque puede existir diálogo entre ambos después de un contacto iniciado por el cliente. Un servidor actúa principalmente como repositorio de datos o conocimientos, o como un proveedor de servicios.
- Oculta la composición del sistema cliente/servidor para el cliente y el usuario (es transparente). La comunicación entre un cliente y un servidor puede ser totalmene ajeno a la plataforma de hardware/software del servidor y de la tecnología de comunicación empleada. Esencialmente los clientes necesitan conocer sólo el interfaz, no los detalles de implementación del servidor. Esto permite al servidor cambiar o escalar según crece la demanda, sin afectar al cliente.
En el modelo cliente/servidor , un servidor -o demonio- se activa y espera las solicitudes del cliente. Un demonio es un programa que se ejecuta indefinidamente y que tiene el propósito de manejar periódicamente solicitudes al servicio que un equipo espera recibir. El demonio reenvía la solicitud a otros programas (o procesos) correspondientes. Los servicios de W2k3 realizan una labor similar.
Arquitectura
Los principales componentes del núcleo de la arquitectura de servicios son Service Control Manager (SMC), service control programs y service applications.
Service control programs no comunica con los servicios directamente; todas las comunicaciones van a través de SCM. Esta arquitectura es precisamente lo que hace la administración remota transparente al servicio de control de programa y al servicio de aplicaciones.
SCM Es un proceso del sistema especial que ejecuta ruta_del_sistemaSystem32Services.exe, que es el responsable del inicio, parada e interactuación con los servicios. Los servicios son aplicaciones Win32 que llaman a funciones Win32 especiales para interactuar con SCM para llevar a cabo acciones como registrar el inicio del sistema correcto, responder a solicitudes del estado, pausar o detener el servicio.
Service control programs Son aplicaciones Win32 estándar que usan las APIs SCM CreateSercice, OpenService, StartService, ControlService, QueryServiceStatus, y DeleteService para comunicarse con, o controlar servicios. Para el uso de estas funciones, un service control program debe primeramente abrir un canal de comunicación hacia SCM. Al mismo tiempo que llama, el servicio de control de programa debe especificar los tipos de acciones que quiere llevar a cabo.Durante su inicio, SCM crea un objeto interno que representa la base de datos SCM y usa funciones de seguridad de Windows para proteger el objeto con un descriptor de seguridad. El descriptor de seguridad especifica las cuentas que pueden abrir el objeto y los permisos de acceso a aquéllas cuentas que pueden usarlo.
SCM almacena el descriptor de seguridad en la subclave del registro del servicio como el valor de seguridad, y lo lee durante el inicio tanto de la configuración de seguridad como en el reinicio del equipo. (En caso de no existencia de una subclave especifica para un servicio SCM usara un descriptor de seguridad predeterminado seguro.)
De la misma forma que un service control program debe especificar los tipos de acceso que quiere a la base de SCM, debe también decir que acceso quiere para un servicio.
El Service control program que nos debe ser más familiar es el comando Sc.exe.
Service applications Un service application contiene la infraestructura necesaria para la comunicación con SCM, que envia comandos al servicio diciéndole que pare, se pause, continue o se apague. Un servicio llama también a funciones especiales que comunican su estado al SCM.
Los Service applications, como Servidores Web, consisten en al menos una aplicación que se ejecuta como un servicio. Un usuario que quiere iniciar, detener o configurar un servicio usa un Service control program. Aunque Windows Server 2003 proporciona programas de control de servicios integrados que proporcionan funcionalidades de inicio, parada, pausa y continuación , algunas service applications incluyen su propio programa de control de servicio que permite a los administradores especificar una configuración particular del servicio que administran.
Ya que la mayoría de servicios no tienen (y no deberían) un interfaz de usuario, se integran como programas de consola. En la figura anterior, los servicios 1, 2 y 3 representan service applications.
Cuando instalamos una aplicación que incluye un servicio, el instalador de la aplicación debe registrar el servicio con el SCM. Normalmente para hacerlo, el instalador llama a la función Win32 CreateService, una función relacionada con los servicios cuya parte de cliente está implementada en Advapi32.dll (que se encuentra dentro de la carpeta System32 de la ruta_del_sistema). Esta librería dinámina implementa la parte cliente de todas las APIs de SCM.
Clientes y servidores RPC Para service applications que usan las APIs como QueryServiceStatus y OpenService, el cliente RPC comunica directamente con SCM ya que éste es el servidor para éstas APIs.
Para las que usan APIs donde el servicio mismo es el servidor RPC, el cliente RPC se comunica con el servidor RPC directamente. De este modo, SCM no interfiere en las llamadas RPC a menos que las implemente.