Сервисные приложения вроде Web-серверов состоят минимум из одной программы, выполняемой как Windows-сервис. Для запуска, остановки и настройки сервиса предназначена SCR Хотя в Windows имеются встроенные SCP, обеспечивающие базовую функциональность для запуска, остановки, приостановки и возобновления сервисных приложений, некоторые сервисные приложения предоставляют собственные SCP, позволяющие администраторам указывать параметры конфигурации того сервиса, которым они управляют.

Сервисные приложения представляют собой просто Windows-программы (GUI или консольные) с дополнительным кодом для обработки команд от SCM и возврата ему статусной информации. Поскольку у большинства сервисов нет пользовательского интерфейса, они создаются в виде консольных программ.

Когда вы устанавливаете приложение, в состав которого входит некий сервис, программа установки приложения должна зарегистрировать этот сервис в системе. Для его регистрации вызывается Windows-функция Create-Service, реализованная в Advapi32.dll (\Windows\System32\Advapi32.dll). Эта DLL, название которой расшифровывается как «Advanced API», реализует всю клиентскую часть SCM API.

Регистрируя сервис через CreateService, программа установки посылает SCM сообщение о том, где будет находиться данный сервис. Затем SCM создает в реестре раздел для сервиса по адресу HKLM\SYSTEM\CurrentControl-Set\Services. Раздел Services является постоянным представлением базы данных SCM. Индивидуальные разделы для каждого сервиса определяют пути к соответствующим исполняемым файлам, а также параметры и конфигурационные настройки сервисов.

Зарегистрировав сервис, программа установки или управляющее приложение может запустить его через функцию StartService. Поскольку некоторые приложения, основанные на сервисах, нужно инициализировать при загрузке системы, программа установки обычно регистрирует сервис как автоматически запускаемый, просит пользователя перезагрузить систему для завершения установки и при загрузке системы позволяет SCM запустить сервис.

При вызове CreateService программа должна указывать некоторые параметры, описывающие характеристики сервиса. Эти характеристики включают тип сервиса (выполняется ли этот сервис в собственном процессе или совместно с другими сервисами), местонахождение его исполняемого файла, необязательное экранное имя, необязательные имя и пароль для запуска сервиса в контексте защиты определенной учетной записи, тип запуска (запускается ли он автоматически при загрузке системы или вручную под управлением SCP), код, указывающий, как система должна реагировать на ошибку при запуске сервиса, и необязательную информацию о моменте запуска относительно других сервисов (если данный сервис запускается автоматически).

SCM хранит каждую характеристику как параметр в разделе, созданном для данного сервиса. Пример такого раздела реестра показан на рис. 4–8.

Рис. 4–8. Пример раздела реестра для сервиса

B таблице 4–7 перечислены характеристики сервиса, многие из которых применимы и к драйверам устройств. (Заметьте, что не все из них свойственны каждому типу сервисов или драйверов устройств.) Для хранения собственной конфигурационной информации сервиса в его разделе создается подраздел Parameters, в котором и будут находиться параметры конфигурации этого сервиса. Сервис получает значения параметров через стандартные функции реестра.

ПРИМЕЧАНИЕ SCM не обращается к подразделу Parameters сервиса до тех пор, пока данный сервис не удаляется; лишь в момент его удаления SCM уничтожает весь раздел сервиса вместе с подразделами вроде Parameters.

Заметьте, что к драйверам устройств применимы три значения параметра Туре. Они используются драйверами устройств, которые также хранят свои параметры в разделе реестра Services. SCM отвечает за запуск драйверов со значением Start, равным SERVICE_AUTO_START или SERVICE_DEMAND_START, поэтому база данных SCM естественным образом включает и драйверы. Сервисы используютдругие типы (SERVICE_WIN32_OWN_PROCESS и SERVICE_ WIN32_SHARE_PROCESS), которые являются взаимоисключающими. Программы, содержащие более одного сервиса, указывают тип SERVICE_WIN32_ SHARE_PROCESS. Преимущество совместного использования процесса несколькими сервисами — экономия ресурсов, которые в ином случае понадобились бы на диспетчеризацию индивидуальных процессов. Ho потенциальный недостаток этой схемы в том, что работа всех сервисов данного процесса прекращается, если один из них вызывает ошибку, из-за которой завершается их процесс. Кроме того, все сервисы в одном процессе должны выполняться под одной и той же учетной записью.

Когда SCM запускает сервисный процесс, тот немедленно вызывает StartServiceCtrlDispatcher. Эта функция принимает список точек входа в сервисы — по одной на каждый сервис процесса. Каждая точка входа идентифицируется именем соответствующего сервиса. Установив соединение с SCM по именованному каналу, StartServiceCtrlDispatcher входит в цикл, ожидая, когда от SCM поступит команда. SCM посылает команду запуска сервиса, и функция StartServiceCtrlDispatcher — всякий раз, когда получает такую команду, — создает поток, называемый потоком сервиса (service thread); он вызывает точку входа запускаемого сервиса и реализует цикл ожидания команд для сервиса. StartServiceCtrlDispatcher находится в бесконечном ожидании команд SCM и возвращает управление основной функции процесса только после остановки всех сервисов в этом процессе, давая ему время на очистку ресурсов.

Первое, что происходит при передаче управления входной точке сервиса, — вызов RegisterServiceCtrlHandler. Эта функция принимает и хранит указатель на функцию — обработчик управления (control handler), которую реализует сервис для обработки различных команд SCM. Она не взаимодействует с SCM, а лишь хранит только что упомянутую функцию в локальной памяти процесса для функции StartServiceCtrlDispatcher. Входная точка продолжает инициализацию сервиса, выделяя нужную память, создавая конечные точки коммуникационного канала и считывая из реестра данные о собственной конфигурации сервиса. По соглашению, которому следует большинство сервисов, эти параметры хранятся в подразделе Parameters раздела соответствующего сервиса. Входная точка, инициализируя сервис, может периодически посылать SCM сообщения о ходе процесса запуска сервиса (при этом используется функция SetServiceStatus). Когда входная точка заканчивает инициализацию, поток сервиса обычно входит в цикл ожидания запросов от клиентских приложений. Например, Web-сервер должен инициализировать ТСР-сокет и ждать запросы на входящие НТТР-соединения.

Основной поток сервисного процесса, выполняемый в функции Start-SetviceCtrlDispatcher, принимает команды SCM, направляемые сервисам в этом процессе, и вызывает функцию — обработчик управления (хранимой RegisterServiceCtrlHandler) для соответствующего сервиса. SCM посылает следующие команды: stop (стоп), pause (пауза), resume (возобновление), interrogate (опрос), shutdown (выключение) и команды, определенные приложением. Схема внутренней организации сервисного процесса показана на рис. 4–9. Ha этой иллюстрации изображены два потока процесса, предоставляющего один сервис (основной поток и поток сервиса).