Софт-Архив

Windows Сервисы img-1

Windows Сервисы

Рейтинг: 4.8/5.0 (1876 проголосовавших)

Описание

Windows сервисы

Microsoft .NET — сервисы Windows нового поколения

В середине лета этого года Microsoft раскрыла свое видение эволюции платформы Windows в ближайшие годы. Платформа Microsoft .NET (ранее эта платформа называлась Next Generation Windows Services, NGWS) будет служить основой для создания распределенных Web-сервисов, интегрирующих различные сервисы, службы и приложения, и, таким образом, обеспечивать создание нового поколения Internet-приложений.

Если говорить о Microsoft .NET в целом, то эта платформа включает в себя следующие глобальные компоненты:

  • собственно платформу Microsoft .NET — инфраструктуру и средства разработки, используемые для построения и управления новым поколением сервисов;
  • продукты и сервисы Microsoft .NET, включая Windows .NET, MSN .NET, Office .NET, Visual Studio .NET, Office .NET и bCentral for .NET;
  • дополнительные сервисы, разрабатываемых сторонними фирмами.

Все взаимодействие между сервисами и компонентами базируется на языке XML и протоколе SOAP, который не зависит ни от объектных моделей, ни от используемых платформ. В Microsoft .NET легко интегрируются уже существующие, а также новые продукты. Так, в частности, одним из компонентов Microsoft .NET является BizTalk Server.

В данном обзоре мы рассмотрим один из основных концептуальных блоков платформы Microsoft .NET — Web-сервисы, а также обсудим архитектуру Microsoft .NET.

Web-сервисы

Согласно определению Web-сервис — это приложение, обеспечивающее определенный набор сервисов, которое может быть интегрировано с другими Web-сервисами путем использования стандартов Internet. На более низком уровне Web-сервис можно назвать программируемым ресурсом, доступным по URL, который программным образом возвращает клиентам определенную информацию. Главным здесь является то, что клиенту не надо знать, как реализован тот или иной сервис для того, чтобы его использовать.

В отличие от существующих компонентных технологий, Web-сервисы не используют какие-либо специфичные для той или иной объектной модели протоколы типа DCOM, RMI или IIOP — сервисы взаимодействуют посредством стандартов Internet типа HTTP и XML. Таким образом, любая система, поддерживающая эти стандарты Internet, может взаимодействовать с Web-сервисами. Как мы отмечали выше, взаимодействие между сервисами и компонентами базируется на языке XML и протоколе SOAP. Язык XML используется в качестве основы для описания конкретного взаимодействия сервисов (язык Service Contact Language, SCL), а протокол SOAP — для обмена информацией между сервисами. Для публикации описаний сервисов используется спецификация Disco — рабочая версия этой спецификации доступна на Web-сайте фирмы Microsoft.

Отметим, что создание Web-сервисов возможно уже сегодня. Для этого вам необходимо приобрести Microsoft Visual Studio 6, а также загрузить в Web-сайт фирмы Microsoft и установить SOAP Toolkit for Visual Studio 6.0. Более подробно о протоколе SOAP можно прочитать в статье «Windows DNA 2000 — платформа нового тысячелетия», опубликованной в январском номере нашего журнала.

После этого менее чем краткого рассмотрения Web-сервисов давайте обратимся к платформе Microsoft .NET, которая служит основой для построения Web-приложений и Web-сервисов.

Архитектура Microsoft .NET

Другие статьи, обзоры программ, новости

Порядок загрузки драйверов и сервисов в Windows - registry, реестр Windows - Программные продукты

Порядок загрузки драйверов и сервисов в Windows

windowsnotes

Тем, кому интересно внутреннее устойство операционной системы Windows . предлагаю небольшое исследование. Мы попробуем выяснить, что отвечает за порядок загрузки драйверов и сервисов в Windows и можно ли этот порядок изменить.

Прежде всего посмотрим текущий порядок запуска системы с помощью программы LoadOrder от Sysinternals. Программа покажет нам, что и в каком порядке загружается при запуске операционной системы.

Как видно из рисунка, сначала загружаются драйверы устройств, необходимые для запуска системы, а потом различные Windows -сервисы. Поскольку между загрузкой сервисов и загрузкой драйверов есть некоторые различия, рассматривать их будем по отдельности.

В качестве подопытного возьмем драйвер Microsoft ACPI (Advanced Configuration and Power Interface), который отвечает за обнаружение аппаратного обеспечения и  управление питанием. Задача ACPI - обеспечить взаимодействие между операционной системой и аппаратным обеспечением, поэтому драйвер ACPI загружается в самом начале.

Программа Loadorder предоставляет довольно ограниченную информацию о порядке загрузки, поэтому за более точными данными идем в реестр. У каждого драйвера и Windows-сервиса есть свой раздел в ветви реестра HKLM\SYSTEM\CurrentControlSet\Services. Названы разделы по имени драйвера\сервиса, соответственно нам нужен раздел ACPI.

За порядок загрузки драйвера отвечают три параметра реестра. Основной параметр  Start - определяет тип запуска драйвера. Вот правила, по которым драйверы устанавливают значение своего параметра Start:

• Драйверы, которые должны загружаться системным загрузчиком при запуске операционной системы, указывают значение Start равное 0 (запуск при загрузке системы). Пример - драйверы системных шин и драйвер файловой системы, используемый при загрузке системы;

• Драйвер, который не требуется непосредственно для загрузки системы, указывает в Start значение, равное 1 (запуск системой). Пример - стандартный драйвер видеокарты (VgaSave);

• Драйвер, не обязательный для загрузки системы, устанавливает значение Start равным 2 (автозапуск). Пример - драйвер многосетевого UNC-npoвайдера (Multiple UNC Provider, MUP), поддерживающий UNC-имена удаленных ресурсов (типа \\Computer\Share);

• Драйверы, не обязательные для работы операционной системы (например, драйверы сетевых адаптеров), указывают значение Start равным 3 (запуск по требованию).

Также драйверы устройств могут использовать параметры Group и Tag для контроля порядка своей загрузки при запуске системы. Параметр Group драйверы\сервисы используют, чтобы указать группу, к которой они принадлежат, а порядок загрузки групп определяется параметром List, находящимся в разделе HKLM\SYSTEM\ CurrentControlSet\Control\ServiceGroupOrder\.

Кстати, параметр Group указывать не обязательно. Если драйвер\сервис не входит в какую либо группу, то он загружается в самом конце очереди.

Драйвер может еще больше детализировать порядок своей загрузки с помощью параметра Tag. который указывает конкретную позицию драйвера в группе. Диспетчер ввода-вывода сортирует драйверы в группе по значениям этого параметра, а драйверы, не имеющие параметра Tag, перемещаются в конец списка драйверов группы.

Посмотрев на порядок загрузки, можно подумать что сначала загружаются драйверы с меньшими значениями Tag, потом - с большими, но это не совсем так. Приоритет значений параметров Tag в рамках группы определяется в разделе HKLM\SYSTEM\CurrentControlSet\Control\GroupOrderList.

Для примера откроем двоичный параметр Boot Bus Extender, который соответствует одноименной группе, к которой относится и драйвер ACPI. Параметр представляет из себя набор двойных слов (по 4 байта каждое). Первое слово (выделено красным) задает общую длину переменной (количество двойных слов), в нашем примере 06. Остальные двойные слова как раз и являются тэгами. Драйверу ACPI соответствует тэг, равный 01 (выделен зеленым).

Приоритетность тега определяется не значением тега, а его положением. чем выше расположен тэг, тем выше его приоритет в группе, и тем выше приоритет драйвера, которому этот тэг соответствует. А поскольку 01 выше остальных тегов, то и драйвер ACPI загружается первым в группе.

Порядок загрузки Windows-сервисов несколько отличается от порядка загрузки драйверов. В качестве примера возьмем сервис aвтоматического обновления (wuauserv). Он не особо критичен для работы системы и поэтому грузится в последнюю очередь.

Опять идем в реестр. Параметры запуска сервиса находятся в разделе HKLM\SYSTEM\CurrentControlSet\Services\wuauserv. Я выделил два основных параметра, отвечающих за порядок загрузки данного сервиса.

Windows-сервисы запускаются диспетчером управления сервисами (Service Control Manager, SCM)  в соответствии со значением параметра Start. Параметр этот для сервисов может принимать следующие значения:

• Авто запуск (2) - сервис запускается автоматически, сразу после запуска основного SCM-процесса Services.exe;

• Запуск по требованию (3) - сервис запускается при необходимости, по требованию какого либо сервиса или программы;

• Отключено (4) - сервис отключен и не запускается ни при каких условиях.

Значения 0 (запуск при загрузке системы) и 1 (запуск системой) для сервисов не могут быть указаны, только для драйверов устройств.

Кроме того, начиная с Windows Vista\Server 2008 для сервисов появился еще один режим запуска - отложенный автозапуск. Отвечает за него параметр DelayedAutoStart = 1, который   который указывает SCM произвести автоматический старт данного сервиса с задержкой.  SCM запускает службы, для которых выбран отложенный запуск, после загрузки сервисов, отмеченных для автозапуска.

Режимом запуска сервисов можно управлять не только из реестра, но и в графическом режиме, из консоли Службы (Services).

Так же как и драйверы, Windows-сервисы могут использовать параметр Group в своем разделе реестра, чтобы указать группу, к которой они принадлежат. Сейчас, для наглядности, возьмем наш сервис wuauserv, находящийся в самом конце списка загрузки. С помощью ключа Group поместим его в группу Event Log, перезагрузимся и посмотрим порядок загрузки в Loadorder. Как видите, порядок изменился и wuauserv поднялся с последнего места, загрузившись сразу после своего одногруппника - службы eventlog. Правда порядок размещения внутри группы изменить уже не получится, т.к.  Tag для сервисов не используется.

И еще один параметр, который косвенно влияет на порядок загрузки сервисов - DependOnService. Он указывает, от каких сервисов зависит данный сервис. Соответственно сервис не загружается, пока не будут загружены сервисы, перечисленные в DependOnService.

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

Более наглядно это показано в оснастке Службы, где на вкладке Зависимости (Dependency) указаны как сервисы, от которых зависит данный сервис, так и сервисы, зависящие от него.

Вот мы и выяснили, в каком порядке загружаются драйверы и сервисы в Windows и как этот порядок можно изменить. Но прежде чем бросаться править реестр помните, что порядок загрузки драйверов и сервисов определяется автоматически, и не стоит вносить в него изменения без веской причины. Всего один неправильно выставленный параметр может привести к полной неработоспособности системы, и не факт что ее удасться восстановить. Поэтому, прежде чем приступить к редактированию реестра, обязательно сделайте его резервную копию, а также желательно иметь под рукой загрузочный носитель.

Создание Windows C# служб (сервисов)

Раздел 9. Создание Windows C# служб (сервисов) в Visual Studio NET

Аннотация: Данный материал был написан после того, как попытка создать сервис по материалу, изложенному в MSDN, многократно заставляла задумываться над тем, что же хотели сделать авторы и, почему именно так, а не так, как надо. В результате этого, появилось это рабочее обобщение, которым автор и сам теперь пользуется, когда возникает необходимость создания или модернизации сервисов.

Глава 1. Создать сервис это просто

Службы Windows (Windows NT services) - процессы, обладающие унифицированным интерфейсом для взаимодействия с операционными системами Windows серии NT. Службы делятся на два типа - службы Win32, взаимодействующие с операционной системой посредством диспетчера управления службами (Service Control Manager - SCM), и драйвера, работающие по протоколу драйвера устройства (далее речь идет о службах Win32). Службы работают в фоновом режиме, и их работа скрыта от пользователя. В силу этого они идеально подходят для реализации серверных процессов в архитектуре клиент-сервер, сетевых служб, программ мониторинга и спорадически выполняемых программ.

Для создания службы в VS .NET необходимо выполнить:
Создать проект решения службы с помощью специального шаблона Visual C# Projects - Windows Service.
  • Написать функциональный код и код событий OnStart и OnStop.
  • Создать установщики для службы (ProjectInstaller - для установки процесса и ServiceInstaller - для службы или служб проекта).
  • Создать исполняемый файл.
  • Создать проект установки.
  • Установить и активизировать службу.

  • Параграф 1. Создание проекта службы

    В меню File VS .NET выбераем New и Project. В диалоговом окне New Project Project Types выбираем Visual C# Projects, Template - Windows Service, задаем Name, например, MyFirstServicee, Location - определяем директорию, где будем формировать проект.

    После нажатия кнопки OK проект решения Service будет создан. Cозданные файлы проекта несколько отличны от тех, что были в Visual Studio 2003. Их имена (см. Рис.1. и директорию проекта):

    - Имя_Проекта.sln,

    - Имя_Проекта.csproj,

    - Servece1.Designer.cs,

    - Service1.cs,

    - Service1.resx.

    Файл AssemblyInfo.cs "переехал" в папку Properties.

    Рис.1. Создание проекта решения службы

    На данном этапе нас интересует файл с именем Service1.cs. Service - имя класса проекта, наследника класса System.ServiceProcess.ServiceBase.

    Класс содержит конструктор класса, функцию main и функции методов OnStart и OnStop. Методы OnPause (), и OnContinue () также могут быть включены в проект (их код может быть дописан вручную, но методы не являются обязательными).

    Код инициализации компонент в Visual Studio 2005 перемещен в файл Servece1.Designer.cs, как и метод Dispose:

    В контекстном меню дизайнера формы (вкладка проекта Service1.cs [Design], правый клик мышки) выбираем пункт Properties (если вкладка не видна - дважды кликнем мышкой по имени файла Servece1.cs в Solutation Explorer). Устанавливаем свойства(Рис.2.):

    - ServiceName (имя проекта) - MyFirstService,

    - AutoLog - True.

    Рис.2. Установка свойств сервиса

    Здесь можно изменить и отображаемое имя сервиса (свойство ServiceName).

    На этом проект решения сервиса создан.

    Параграф 2. Написание функционального кода сервиса Для того, чтобы убедиться в работоспособности нашего сервиса, возложим на него задачу писать в некоторый лог файл какую либо информацию при старте и останове. Для этого:
    Добавим пространство имен:
  • Объявим в классе Service1 StreamWriter:
  • Коды обработчиков событий запишем следующим образом:

    Позже мы добавим нашему сервису другую функциональность.

    Параграф 3. Создание установщиков для службы

    На вкладке Service1.cs [Design] вызываем вновь контекстное меню и пункт Add Instaler. В проект добавляется класс компонента, содержащий два установщика:

    - ServiceName - MyFirstService ,

    - ServerType - Automati c.

    Для ServiceProcessInstaller1 устанавливаем значение Account в LocalSystem (Рис.3.).

    Рис.3. Создание установщика для службы

    Параграф 4. Создание исполняемого файла для службы

    В Solution Explorer выбираем пункт Properties для узла MyFirstServices. В диалоговом окне выбираем вкладку Application. Для пункта Startup object выбираем в выпадающем списке MyFirstService.Programm (Рис.4.).

    Рис.4. Установка свойств для программы установки

    В контекстном меню для узла MyFirstServices выбираем пункт Build. После этого, проект построен и в директории проекта obj\debug или obj\release будет сформирован файл MyFirstService.exe. Однако, попытка его запуска приведет к выдаче сообщения (Рис.5.):

    Рис.5. Необходимость установки сервиса

    Параграф 5. Создание проекта установки для службы

    В меню File выбираем пункт Add Project и New Project. В диалоговом окне Add New Project в окне Project Types выбираем вкладку Other Project Types ветвь Setup and Deployment, в окне Templates - Setup Project, задаем Name и Location - оба параметра непринципиальны(Рис.6.).

    Рис.6. Добавление проекта решения установки службы

    Проект установки добавлен в решение и мы его видим в Solutation Explorer.

    Кроме того на вкладке File System (FirstServices) мы можем видеть сборку файлов для установки "File System on Target Machine" (Рис.7.).

    Рис.7. Создание проекта решения установки службы

    Следующее, что нужно сделать - это определить для установки директорию для проекта службы Windows.

    Выбираем узел File System on Target Machine (если по какой либо причине мы не видим дерево папок, то можно его отобразить через контекстное меню узла FirstServices, пункт View/File System), в его контекстном меню выбираем Add Special Folder и System Folder. Имя System Folder появилось в ветви узла File System on Target Machine.

    В контекстном меню System Folder выбираем Add, Project Output\Primary Output (Рис.8.).

    Рис.8. Определение директории для службы

    Выбираем пункт View для узла FirstServices пункт Custom Action, слева в окне откроются по умолчанию четыре возможных действия для инсталлятора: Install, Commit, Rollback и Uninstall. Для Install и Uninstall через их контекстное меню выполняем пункт Add Custom Action и указываем System Folder (Рис.9.).

    Рис.9. Определение действий инсталлятора

    Практически, мы определили не только действие, но и объект этого действия - Primary output from MyFirstService (Active). В данные узлы пользовательских действий (Install и Uninstall) будет добавлен основной выходной файл проекта. В свойствах можно изменить для файла CustomInstaller, значение true сообщает инсталлятору, что используется класс инсталлятора (Рис.10.).

    Рис.10. Определение действий инсталлятора

    Теперь можно построить проект инсталлятора, вызвав для узла FirstServices в Solutation Explorer пункт Build.

    Параграф 6. Установка, активизация и удаление службы

    Для установки службы в Solutation Explorer выбираем проект установки (FirstServices) и в контекстном меню пункт Install. В результате, будет запущен Setup Wizard. На втором шаге его работы зададим системную папку Windows - C:\WINDOWS\system32\. После окончания работы Setup Wizard служба будет установлена.

    Чтобы запустить и остановить службу откроем диспетчер управления службами (в Windows XP - Start/Programm/Administrative Tools/Services). Имя нашей службы MyFirstService будет отображено в окне Services, и можно обычным образом запустить наш сервис через контекстное меню пункт Start (кроме того, служба автоматически будет запускаться при перегрузке компьютера).

    Наш сервис (служба) создал файл Service1.log в "C:\windows\System32\ и выполнил в него запись о своем старте. При останове сервиса запись будет выполнена вновь.

    Службу можно устанавливать и удалять, используя файлы setup.exe и FirstServices.msi, которые после построения установщика находятся в каталоге, где был создан проект инсталлятора В данном примере в C:\. \FirstService\Debug\ и, кроме того, этих двух файлов достаточно для установки службы из любой директории любого компьютера.

    На данном этапе мы выполнили все требуемые шаги и проверили нашу службу в работе. Далее, можно выполнить построение проекта в режиме Release (меню Build, Configuration Manager, Release). setup.exe и FirstServices.msi, после построения установщика будут находятся в каталоге C:\. \FirstServices\bin\Release). Далее возможно наполнять функциональность службы по своему усмотрению.

    Удаления сервиса с компьютера выполняется как и обычного приложения Windows - (Settings/Control Panel/Add on Remove Programs).

    Параграф 7. Пример использования службы, для периодического выполнения некоторых действий

    Для задания простого механизма опроса можно воспользоваться компонентом System.Timers.Timer. В методе OnStart можно задать параметры компонента. Таймер будет выполнять в коде периодически некоторые действия (например, запись в файл текущего времени, как это показано ниже). В код лишь добавлен компонент Timer и обработчик события, выполняющий некоторые действия по истечении заданного свойством timer1.Interval времени.

    Содержимое файла Service1.log:

    Молчанов Владислав 21.06.2005г.

    Адаптировано к VS 2005 16.04.2008г.

    Еcли Вы пришли с поискового сервера - посетите мою главную страничку

    На главной странице Вы найдете программы комплекса Veles - программы для автолюбителей, программы из раздела графика - программы для работы с фото, сделанными цифровым фотоаппаратом, программу Bricks - игрушку для детей и взрослых, программу записную книжку, программу TellMe - говорящий Русско-Английский разговорник - программу для тех, кто собирается погостить за бугром или повысить свои знания в английском, теоретический материал по программированию в среде Borland C++ Builder, C# (Windows приложения и ASP.Net Web сайты).

  • Службы Windows (сервисы)

    Службы Windows (сервисы)

    Слу?жбы Windows (англ. Windows Service, сервисы) — приложения, автоматически запускаемые системой при запуске Windows и выполняющиеся вне зависимости от статуса пользователя. Имеет общие черты с концепцией демонов в Unix.

       Режимы работы

    В большинстве случаев службам запрещено взаимодействие с консолью или рабочим столом пользователей (как локальных, так и удалённых), однако для некоторых сервисов возможно исключение — взаимодействие с консолью (сессией с номером 0, в которой зарегистрирован пользователь локально или при запуске службы mstsc с ключом /console).

    Существует четыре режима для сервисов:

    * запрещён к запуску;

    * ручной запуск (по запросу);

    * автоматический запуск при загрузке компьютера;

    * обязательный сервис (автоматический запуск и невозможность (для пользователя) остановить сервис).

       Фоновый режим

    Windows предлагает программу Service Control Manager, с её помощью можно управлять созданием, удалением, запуском и остановкой служб. Приложение, имеющее статус сервиса, должно быть написано таким образом, чтобы оно могло принимать сообщения от Service Control Manager. Затем, одним или несколькими вызовами API, имя службы и другие атрибуты, такие, как его описание, регистрируются в Service Control Manager.

       Запуск, остановка и изменение служб Windows

    После установки службы, её атрибуты могут быть изменены путём запуска «Services» из Панели управления Windows в Administrative Tools.

       Управление запуском служб при старте Windows

    Список служб находится в ветке реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services. Значения параметра «Start» имеют тип «REG_DWORD» и могут принимать значения: «0», «1», «2», «3» и «4» (когда служба не запускается, то есть запуск даной службы запрещен).

       Управление работой служб из командной строки

    Управление службами возможно с помощью командной строки: остановка службы — «net stop service_name», запуск службы — «net start service_name».

       Права пользователя и особенности реализации

    Сервисы Windows по умолчанию запускаются от имени пользователя «LocalSystem», который обладает полными правами в системе (превосходящими права даже учётной записи Administrator). Рабочим каталогом будет системный каталог Windows (обычно C:\WINNT или C:\WINDOWS), а каталог для хранения временных файлов будет C:\WINNT\TEMP.

    Поскольку это не настоящий пользователь, а «виртуальный», появляются некоторые трудности, когда приложению необходимо сохранить данные, относящиеся к пользователю (user-specific data), поскольку не существует папки этого пользователя.

    Важно также то, что в случае если служба работает от имени локального пользователя (реальный пользователь созданный для служебных целей) если пароль такого пользователя изменён, сервис не будет запускаться до тех пор, пока пароль для сервиса тоже не будет изменен.

    Эта статья находится под лицензией GNU Free Documentation License. Она использует материалы из Википедеи.

    Создание Windows сервисов средствами FPC и Lazarus

    Создание Windows сервисов средствами FPC и Lazarus

    03.04.2009

    Лагунов А.А.

    1. Введение

    Существует целый класс специальных программ, которые по логике своей работы не требуют постоянных ответных действий от оператора. И это самые хорошие для конечного пользователя программы, так как они работают сами.

    В Linux и прочих клонах UNIX они называются демонами, в Windows это службы. Хотя название этого класса программ в windows и Unix-подобных системах различно — принцип работы их одинаков. Программа запускается в фоновом режиме и не требует, чтобы оператор совершал при этом какие-либо действия.

    Компилятор FPC имеет в своём составе прекрасные библиотеки для облегчения создания таких программ. IDE Lazarus с помощью своих визуальных средств — большое подспорье в этом интересном деле.

    Процесс создания в общем не зависит от операционной системы, полностью проявляя главный девиз Lazarus: «Пишем код один раз — компилируем везде».

    2. Общая настройка Lazarus

    Сначала подготовим Lazarus к работе — этот этап общий для любой операционной системы, где он запускается.

    Для этого необходимо установить в Lazarus дополнительные компоненты для создания сервисов. То есть необходимо открыть пакет lazdaemon.lpk и установить его. Он находится в каталоге стандартных компонентов — $lazarus/components/daemon ($lazarus — это та папка, куда установлен IDE lazarus). После успешной компиляции и перезапуска IDE в меню создания нового проекта (меню «Проект/Создать новый проект») будет доступен новый тип проекта (Daemon (service) Application:

    А в меню «Файл/Создать. » будет доступно создание новых объектов (Daemon Application, Daemon Module, Daemon Mapper):

    Пункт меню «Файл/Создать. » необходим в том случае, если планируется в одном исполняемом модуле разместить несколько служб.

    3. Создание сервиса 3.1. Что происходит при создании проекта?

    При создании нового проекта будет открыто автоматически 2 невизуальных формы - класс TDaemon и TDaemonMapper.

    TDaemon — непосредственно экземпляр сервиса. Именно этот объект реализует сам сервис (его мы видим в Windows в «Управление компьютерами/Сервисы»).

    TDaemonMapper — это компонент, отвечающий за управление работой сервисов. Особенно актуален он в случае включения в один исполняемый модуль нескольких сервисов.

    3.2. Описание свойств компоненты TDaemonMapper

    Рассмотрим свойства и события, доступные у TDaemonMapper.

    Уникальным свойством компоненты TDaemonMapper является DaemonDefs. Именно оно определяет, какие сервисы содержит исполняемый модуль, производит регистрацию сервисов в системе. Это свойство — коллекция элементов. Ниже, в п.3.3 подробно рассматривается элемент, который может содержаться в данной коллекции.

    Стоит обратить внимание на несколько событий используемой компоненты. Событие, которое возникает в момент запуска исполняемого модуля программы и создания экземпляра объекта TDaemonMapper. Полезно,например, когда необходимо при запуске считать значения некоторых переменных из конфигурационного файла, подготовить какие либо структуры данных и т.п. Событие, которое возникает в момент завершения работы исполняемого модуля программы и уничтожения экземпляра объекта TDaemonMapper. Используется для «уборки» после работы программы: освобождение ресурсов, закрытие файлов и т.п. Событие возникает при запуске на выполнение исполняемого файла с нестандартными параметрами запуска или вообще без параметров. Стандартными считаются 3 параметра командной строки: -i, -r, -u (подробнее параметры расписаны в Приложение А. Стандартные параметры командной строки) Событие возникает в момент регистрации сервисов в системе — запуск программы с ключом -i. Событие возникает в момент удаления регистрационной информации о сервисе из системы — запуск программы с ключом -u.

    3.3. Более подробно класс TDaemonDef

    Экземпляры данного класса хранятся в свойстве-коллекции DaemonDefs класса TDaemonMapper.

    Свойство содержит имя типа регистрируемого сервиса — например TDaemon1. На данном этапе Lazarus не позволяет визуально выбрать значение — пока можно только вписать вручную. Но, я надеюсь, в ближайшее время будет реализован редактор.

    Наименование сервиса Наименование сервиса — отображается в окне ОС просмотра списка зарегистрированных сервисов. Список дополнительных аргументов командной строки, которые будут передаваться указанному сервису в момент старта сервиса. Параметры работы сервиса — может ли сервис быть остановлен или приостановлен вручную, может ли он взаимодействовать с рабочим столом оператора (см. Приложение В. Параметры сервиса — TDaemonOption) Признак доступности сервиса. Если это свойство включено, то в момент запуска исполняемого файла с ключом регистрации сервисов (-i), сервис будет зарегистрирован. В противном случае — сервис не регистрируется. Аналогичное поведение и при деинсталяции сервисаов. Этот параметр удобно менять в момент создания экземпляра TDaemonMapper из его соответствующего события OnCreate. Сложное свойство, отвечает за параметры регистрации сервиса в Windows системах:
    • Список служб, от которых зависит данная служба.
    • Наименование группы, к которой относится служба.
    • Пароль учётной записи, от имени которой производится запуск данной службы (пустой при запуске от System).
    • Наименование учётной записи, от имени которой производится запуск данной службы.
    • Тип запуска службы — автоматический или ручной. Допустимые значения приведены ниже (см. Приложение Б. Типы запуска служб).
    • Временной интервал, который необходим службе для выполнения действий. Например, время необходимое для старта службы. По истечении этого времени будет сгенерированно сообщение о том, что служба не отвечает на внешние запросы. Если в качестве значения указать 0, то ожидание не прерывается.
    • Определяется тип службы — либо просто программа, либо драйвер устройства или файловой системы. В данной статье рассматриваются только службы с типом stWin32.
    Писать в файл протокола факт изменения состояния сервиса (запуск / приостановка / остановка) Это событие возникает в момент создания самого экземпляра сервиса. 3.4. Описание компоненты TDaemon

    Эта невизуальная компонента является реализацией сервиса. Физически при запуске сервиса создаётся дополнительный поток в составе приложения, который и является основной рабочей нитью сервиса. Этот поток вызывает методы компонента, потомка TDaemon, по мере поступления от операционной системы соответствующих сигналов.

    Ниже приведен перечень свойств этого компонента: Свойство содержит текущее состояние сервиса. Событие возникает в момент начала выполнения сервиса. Событие возникает в момент остановки сервиса. Событие возникает в момент приостановки работы сервиса. Событие возникает в момент возобновления работы сервиса. Событие возникает в момент выгрузки сервиса. Событие возникает в момент начала выполнения сервиса. События, возникают до и после момента установки и деинсталяции сервиса соответственно. Это событие возникает для обработки не стандартного сообщения от системы (не имеющего типового обработчика).

    3.5. Пример кода

    Для примера рассмотрим создание сервиса, который будет определять наличие файла в указанной папке по специальной маске, и если такой файл или файлы будут найдены — сохранит информацию об этом в базу данных FireBird.

    Внешний вид окна разработки сервиса приведён на рисунке ниже:

    Разместим в окне сервиса компоненты доступа к базе данных (UIBDataBase1, UIBQuery1, UIBTransaction1). Для периодического сканирования каталога, в котором могут находится и появляться в течение работы сервиса файлы, будем использовать таймер (Timer1).

    Создадим обработчики на события сервиса:
    • OnStart — Старт сервиса. В момент старта сервиса укажем для объекта подключения к базе данных (UIBDataBase1) имя пользователя, пароль и строку подключения. Устанавливаем соединение с базой данных. Затем для таймера (Timer1) установим временной интервал сканирования каталога. Последней операцией — включим таймер в работу.
    • OnStop — Остановка сервиса. Выключаем таймер. Отсоединяемся от базы данных.
    • OnPause — Оператор запрашивает с помощью инструментов операционной системы приостановку работы сервиса. Мы это реализуем просто выключением таймера.
    • OnContinue — Работа сервиса продолжается. Таймер можно включить.

    Теперь приступим к реализации основного рабочего кода сервиса — сканирование каталога и сохранение результата сканирования в базе данных. Запуск процесса сканирования будет происходит по сигналу таймера — поэтому пишем его обработчик. Полный текст всего примера есть в прикреплённом архиве — а тут приведу только часть кода:

    Таким образом, функционал всего сервиса обеспечивается 3-мя методами.

    В процедуре обработчике таймера вызываем процедуру сканирования тестового каталога, после завершения этой процедуры, если была начата транзакция записи данных, то подтверждаем транзакцию и записываем данные в базу.

    Если же при выполнении кода была ошибка — то она будет подавлена. Работа сервиса прервана не будет, но факт ошибки будет записан в файле протокола.

    Метод DoScanFolder выполнит сканирование указанного каталога. Если при этом будут обнаружены файлы удовлетворяющие условию, их названия будут записаны в БД программы с помощью процедуры DoSaveFileNameToBD. а затем, после успешной записи — удалены.

    Метод DoSaveFileNameToBD просто проверяет была ли начата транзакция в данной итерации, если нет — то открывает её и записывает данные в базу.

    3.6. Замечания из личного опыта
    • Использование таймера таит странную на первый взгляд ошибку. Если просто пытаться использовать таймер — то ничего не выйдет. Это обусловлено реализацией кода компонента таймера в Lazarus. Код таймера находится в библиотеках, которые относятся к визуальным виджетам — просто в разных операционных системах механизм таймеров реализован по разному. Из-за этого без подключения модуля Interfaces тут не обойтись. Первый раз я долго голову ломал — что не так?
    • Объект Application служб реализует систему протоколирования работы. Эта удобная вещь таит не очень явную трудность для случая, если в одном исполняемом файле находится несколько сервисов. В случае когда Application.Logger пишет протокол в системный протокол — то всё будет нормально. Но если запись протокола идёт в файл (а именно так по умолчанию всё работает) — то возникнет ошибка при попытке запуска второго и последующих сервисов. Всё дело в том, что Application.Logger открывает файл протокола на запись в монопольном доступе и имя, если не задано явно, будет равно имени исполняемого модуля с расширением .log. В этом случае я просто в момент создания экземпляра TDaemonMapper определяю какой именно сервис запускается и Application.Logger.FileName присваиваю необходимое имя файла протокола для этого сервиса. Получается, что на каждый сервис у меня ведётся отдельный протокол.
    4. Специфика для Windows

    Рассмотрим создание сервиса с помощью FPC и Lazarus для использования его в OS Windows. Само создание сервисов не отличается от описанного выше.

    Специфика начинается в момент установки. Фактически установку созданного сервиса можно проводить из любого каталога, но если сервис будет запускаться от специальной учётной записи, необходимо отследить возможность этой учётной записи работать с папкой, где расположены файлы сервиса (исполняемые и вспомогательные). Также для этой учётной записи должна быть доступна на чтение и удаление папка, в которой сервис будет производить поиск файлов по маске.

    Весь процесс установки сервиса сводится к запуску исполняемого файла с ключом командной строки -i. После выполнения этой команды сервис зарегистрирует себя в реестре Windows. Можно открыть окно управления компьютером и запустить сервис.

    Для деинсталляции сервиса необходимо просто запустить сервис с ключом -u.

    По умолчанию протоколирование ведётся в системный каталог — %SYSTEM_ROOT%system32 .log.

    5. Заключение

    Данная статья написана с использованием Lazarus версии 0.9.27 (18965) и FPC версии 2.3.1. Но эти же примеры должны заработать и на предыдущих версиях (не очень старых). Лично для меня эта статья была инициирована необходимостью написания сервиса рассылки СМС сообщений. Так что всё проверено опытным путём.

    Сервисы Windows Live

    Безопасность пользователя как новая концепция от Microsoft

    Существенно проработаны и дополнены функции безопасности при работе в Сети (рис. 3). Условно их можно разделить на две группы: блокирование нежелательной информации (спама) и защита от атак. Для защиты от нежелательной почты можно установить один из предлагаемых уровней защиты: отключена, низкий, высокий, доставка только с установленных безопасных адресов. При желании можно отправлять Microsoft список адресов, с которых рассылается спам. При настройке фильтров можно использовать различные опции: устанавливать перечни безопасных и запрещенных адресов, запрет на домены, в том числе первого уровня, и специфические кодировки сообщений. Например, можно установить фильтр на все сообщения, приходящие из домена .cn, если вам никто не должен писать из Китая, или .bf, если из Буркина-Фасо ничего, кроме спама, ранее на ваш ящик не поступало.

    Отдельно стоит упомянуть о настройках безопасности на закладке Security, которые устанавливаются аналогично такой же закладке в Internet Explorer. Интересным дополнением стала встроенная система защиты персональных данных от фишинга. Для реализации этой функции используется интеграция со встроенным программным межсетевым экраном (firewall) Windows XP SP2 или Vista. Дополнительной защитой от несанкционированного доступа к приватной информации служит шифрование данных контактов. Оно обеспечивает возможность доступа к контактам только средствами Windows Live.

    Отдельно Microsoft оговаривает правила сбора, использования и защиты личной информации пользователей при использовании ими сервисов семейства Live. Мы не будем подробно останавливаться на них в этой статье. Оговорим лишь, что правила эти весьма строги и охватывают очень широкий спектр ограничений от сбора и хранения информации до правил ее использования исключительно для предоставления заказанных пользователем сервисов. Особое внимание уделяется защите приватных сведений о банковских счетах и кредитных картах, которые запрашиваются в сервисах типа Microsoft Billing, и данных о детях-пользователях. Для юных пользователей даже разработан отдельный бесплатный сервис (Kids), который рассазывает о правилах безопасности при работе в Сети.

    Подробно поговорив о вопросах и сервисах безопасности работы в Интернете и при пользовании сервисами Windows Live, посмотрим теперь, каким образом работать с новостными лентами. Работа в Сети — это непрерывный процесс получения и предоставления информации. Возможность оперативного получения требуемой информации предоставляет сервис RSS * Feeds. Он доступен в Windows Mail как самостоятельный сервис. Однако, его применение сейчас существенно ограничено из-за обязательного требования установки Internet Explorer 7.0.

    Windows Live Messenger

    Еще один очень удобный и полезный пользовательский сервис — Windows Live Messenger. Как и свои предшественники, он рассчитан на организацию общения пользователей один на один. Начнем знакомстово с этой службой, как обычно, с пользовательских настроек. Их состав довольно обширен. Это настройки личного профиля: имя, электронный адрес, фотография, подпись, телефон, включая управление доступностью к персональной информации. Разнообразные настройки безопасности: проверка на вирусы, режим карантина, управление списками контактов и их уровнем конфиденциальности. Одной из востребованных функций стал режим работы "Общая папка". Эта папка создается на локальных компьютерах у подключенных к службе пользователей. Все они могут управлять ее содержимым (рис. 4). Синхронизация папки производится при подключении к Windows Live Messenger. Это чрезвычайно удобный и одновременно надежный механизм совместной работы над документами. Фактически вы со своими коллегами организуете распределенный автоматически синхронизируемый файл-сервер проекта. Если коллега обновил файлы, то сам файл и все папки по иерархии помечаются специальным значком. Для каждой папки указывается количество новых и измененных файлов. Отметка об обновлении снимается только после просмотра или копирования файла, так что состав документов не может остаться несинхронизированным. Все обновления, изменения и синхронизация логируются в журнале в удобном для просмотра виде. Это очень важно и удобно при совместной работе над проектами.

    В представленной статье мы остановились только на двух наиболее распространенных сервисах из семейства Windows Live. Всего же в нем около 20 различных служб. Это и онлайн-магазины. и блоги. и службы вопросов и ответов. Есть свои сервисы для разработчиков и активных пользователей по Vista, Office, Internet Explorer, академических исследователей, служба программ — антивирусов и антитроянов и многое другое. Отдельно можно упомянуть набирающую популярность трехмерную карту мира с фотографиями местности, дорожными картами и видами с высоты птичьего полета. Так что каждый найдет в Windows Live возможности по своим интересам.