Introduction to Windows Service Applications

Microsoft Windows services, formerly known as NT services, enable you to create long-running executable applications that run in their own Windows sessions. These services can be automatically started when the computer boots, can be paused and restarted, and do not show any user interface. These features make services ideal for use on a server or whenever you need long-running functionality that does not interfere with other users who are working on the same computer. You can also run services in the security context of a specific user account that is different from the logged-on user or the default computer account. For more information about services and Windows sessions, see the Windows SDK documentation.

You can easily create services by creating an application that is installed as a service. For example, suppose you want to monitor performance counter data and react to threshold values. You could write a Windows Service application that listens to the performance counter data, deploy the application, and begin collecting and analyzing data.

You create your service as a Microsoft Visual Studio project, defining code within it that controls what commands can be sent to the service and what actions should be taken when those commands are received. Commands that can be sent to a service include starting, pausing, resuming, and stopping the service; you can also execute custom commands.

After you create and build the application, you can install it by running the command-line utility InstallUtil.exe and passing the path to the service’s executable file. You can then use the Services Control Manager to start, stop, pause, resume, and configure your service. You can also accomplish many of these same tasks in the Services node in Server Explorer or by using the ServiceController class.

Service Applications vs. Other Visual Studio Applications

Service applications function differently from many other project types in several ways:

The compiled executable file that a service application project creates must be installed on the server before the project can function in a meaningful way. You cannot debug or run a service application by pressing F5 or F11; you cannot immediately run a service or step into its code. Instead, you must install and start your service, and then attach a debugger to the service’s process. For more information, see How to: Debug Windows Service Applications.

Unlike some types of projects, you must create installation components for service applications. The installation components install and register the service on the server and create an entry for your service with the Windows Services Control Manager. For more information, see How to: Add Installers to Your Service Application.

The Main method for your service application must issue the Run command for the services your project contains. The Run method loads the services into the Services Control Manager on the appropriate server. If you use the Windows Services project template, this method is written for you automatically. Note that loading a service is not the same thing as starting the service. See «Service Lifetime» below for more information.

Windows Service applications run in a different window station than the interactive station of the logged-on user. A window station is a secure object that contains a Clipboard, a set of global atoms, and a group of desktop objects. Because the station of the Windows service is not an interactive station, dialog boxes raised from within a Windows service application will not be seen and may cause your program to stop responding. Similarly, error messages should be logged in the Windows event log rather than raised in the user interface.

The Windows service classes supported by the .NET Framework do not support interaction with interactive stations, that is, the logged-on user. The .NET Framework also does not include classes that represent stations and desktops. If your Windows service must interact with other stations, you will need to access the unmanaged Windows API. For more information, see the Windows SDK documentation.

The interaction of the Windows service with the user or other stations must be carefully designed to include scenarios such as there being no logged on user, or the user having an unexpected set of desktop objects. In some cases, it may be more appropriate to write a Windows application that runs under the control of the user.

Windows service applications run in their own security context and are started before the user logs into the Windows computer on which they are installed. You should plan carefully what user account to run the service within; a service running under the system account has more permissions and privileges than a user account.

Service Lifetime

A service goes through several internal states in its lifetime. First, the service is installed onto the system on which it will run. This process executes the installers for the service project and loads the service into the Services Control Manager for that computer. The Services Control Manager is the central utility provided by Windows to administer services.

After the service has been loaded, it must be started. Starting the service allows it to begin functioning. You can start a service from the Services Control Manager, from Server Explorer, or from code by calling the Start method. The Start method passes processing to the application’s OnStart method and processes any code you have defined there.

A running service can exist in this state indefinitely until it is either stopped or paused or until the computer shuts down. A service can exist in one of three basic states: Running, Paused, or Stopped. The service can also report the state of a pending command: ContinuePending, PausePending, StartPending, or StopPending. These statuses indicate that a command has been issued, such as a command to pause a running service, but has not been carried out yet. You can query the Status to determine what state a service is in, or use the WaitForStatus to carry out an action when any of these states occurs.

You can pause, stop, or resume a service from the Services Control Manager, from Server Explorer, or by calling methods in code. Each of these actions can call an associated procedure in the service (OnStop, OnPause, or OnContinue), in which you can define additional processing to be performed when the service changes state.

Types of Services

There are two types of services you can create in Visual Studio using the .NET Framework. Services that are the only service in a process are assigned the type Win32OwnProcess. Services that share a process with another service are assigned the type Win32ShareProcess. You can retrieve the service type by querying the ServiceType property.

You might occasionally see other service types if you query existing services that were not created in Visual Studio. For more information on these, see the ServiceType.

Services and the ServiceController Component

The ServiceController component is used to connect to an installed service and manipulate its state; using a ServiceController component, you can start and stop a service, pause and continue its functioning, and send custom commands to a service. However, you do not need to use a ServiceController component when you create a service application. In fact, in most cases your ServiceController component should exist in a separate application from the Windows service application that defines your service.

For more information, see ServiceController.

Requirements

Services must be created in a Windows Service application project or another .NET Framework–enabled project that creates an .exe file when built and inherits from the ServiceBase class.

Projects containing Windows services must have installation components for the project and its services. This can be easily accomplished from the Properties window. For more information, see How to: Add Installers to Your Service Application.

Введение в WCF Web Service

Аннотация: Данная статья написана когда автор столкнулся с необходимостью использования Web сервисов в поставляемом в фирму ПО. До этого как то обходились без Web сервисов. Литературы в инете по данному вопросу много и много прочитано, но очень многое еще и остается темными пятнами. Поэтому, по мере накопления знаний, статья будет модифицироваться и уточняться. Автор будет благодарен за любые замечания и уточнения. Адрес почты — найдете на главной странице сайта по ссылке «Об авторе».

Весь материал разработан в Visual Studio Net 2010 в Windows 7

Параграф 1. Вместо предисловия

Веб-служба, веб-сервис (web service) — программная система, идентифицируемая строкой URI, чьи общедоступные интерфейсы определены на языке XML (eXtensible Markup Language). Благодаря веб-сервисам функции любой программы могут стать доступными через Интернет — программы могут обращаться к какой-нибудь программе, работающей на другом сервере (т.е. к веб-сервису), и использовать ответ, полученный от нее на своем веб-сайте, или в приложении. Веб-службы обеспечивают взаимодействие программных систем независимо от платформы. Они основаны на базе открытых стандартов и протоколов. Благодаря использованию XML достигается простота разработки и отладки веб-служб.

XML: Расширяемый язык разметки, предназначенный для хранения и передачи структурированных данных;

SOAP (Simple Object Access Protocol): Протокол обмена сообщениями на базе XML;

WSDL (Web Services Description Language): Язык описания внешних интерфейсов веб-службы на базе XML;

UDDI: Универсальный интерфейс распознавания, описания и интеграции (Universal Discovery, Description and Integration). Каталог веб-служб и сведений о компаниях, предоставляющих веб-службы во всеобщее пользование или конкретным компаниям.

Для создания Web сервиса в Visual Studio Net воспользуемся темплатой «WCF Server Application» (меню «File/New Project») и дадим ему имя «MyFirstWebService» (Рис.1). Сразу отметим, что мы создаем непривычный для предыдущих Net Framework web сервис — WCF (Windows Communication Foundation). WCF — программный фреймворк, используемый для обмена данными между приложениями входящими в состав .NET Framework. До Net Framework 4 использовался немного другой сервис (его мы можем найти, если сменим в окне «.Net Framework 4», на «.Net Framework 3.5» и найдем темплату ASP.NET Web Service Application). Создав проект на базе этой темплаты, мы найдем привычные .asmx файлы, которых, как видно из Рис.2. нет в проекте WCF сервиса. Это не просто смена имен файлов, а смена технологии — WCF делает возможным построение безопасных и надёжных транзакционных систем через упрощённую унифицированную программную модель межплатформенного взаимодействия. Комбинируя функциональность существующих технологий .NET по разработке распределённых приложений (ASP.NET XML Web Services — ASMX, WSE 3.0, .NET Remoting, .NET Enterprise Services и System.Messaging). WCF предоставляет единую инфраструктуру разработки, повышающую производительность и снижающую затраты на создание безопасных, надёжных и транзакционных Web-служб нового поколения.

Параграф 2. Создаем WCF web сервис

Собственно говоря мы уже приступили к его созданию (см.выше). На Рис.1. показан выбор темплаты и задание имени службы — «MyFirstWebService» и таким же оставим и имя проекта. Если мы планируем тестировать службу перед применением и будем создавать Host и клиентское приложение для работы, то имена службы и проекта следует разделить. После нажатия кнопки «OK» служба практически создана.

Рис.1. Создание Web сервиса WCF

Рис.2. Создание Web сервиса WCF

Сервис WCF представлен основным файлом Service1.svc.cs (Рис.2.), где размещены методы сервиса, IService1.cs — методы интерфейса и два файла Web.config для двух режимов. Кроме того обратим внимание на закладке References и в используемых пространствах имен на ссылки System.ServiceModel:

Стартовый пример показывает и то, как вводить данные собственных типов ([DataContract]):

Так как сервис создан, нажав F5, мы можем посмотреть его презентационное представление и указание на то, что делать дальше. А нажав ссылку svcutil.exe http://localhost:3818/Service1.svc?wsdl — можем посмотреть с помощью «svcutil.exe» его XML содержание (.wsdl файл, в котором описывается, что сервис может делать и с какими данными он может работать) — (Рис.3).

Рис.3. Web сервис WCF

В XML коде мы можем найти:

контракт сервиса (2 метода: GetData, GetDataUsingDataContract);

контракт данных (2 встроенных типа: int, string, + 1 собственный тип: CompositeType состоящий из bool и string);

сигнатуры методов (из wsdl:input message= и wsdl:output message=).

Для отладки сервиса можно использовать «WCF Test Client». Выберем узел «Service1.svc» и в его контекстном меню выберем пункт «Set As Start Page» и нажмем F5. Теперь появится окно «WCF Test Client» (Рис.4.). В нем мы можем просмотреть и протестировать наши методы и посмотреть их XML реализацию.

Рис.4. Использование WCF Test Client

Наполним сервис своим содержанием, например, поставим ему задачу проверять валидность почтовых адресов, для чего в файле IService1.cs оставим один контакт(OperationContract).

В принципе, если мы уверены в работоспособности службы, то мы можем ее опубликовать.

Параграф 3. Публикация Web сервиса

Опубликуем наш сервис. Режим компиляции выберем «Release», на всякий случай перекомпилируем службу (меню «Build/RebuildMyFirstService») и далее выбираем меню «Build/Publish MyFirstService» (Рис.5.):

Рис.5. Публикация службы

На Рис.6. показано, что мы публикуем службу туда, куда IIS нам определил сайт по умолчанию (Default Web Site). Это сделано для удобства. В принципе, когда мы работаем «на дядю», то есть, сайт у нас на другой машине, то можно опубликовать в любое место, а затем скопировать файлы сборки в нужное место, а далее с помощью тамошнего IIS сделать директорию сборки приложением. Еще один момент — не рекомендуется менять имя сервиса.

Рис.6. Публикация службы

Теперь превратим нашу папку сборки в приложение IIS.

Рис.7. Создание приложения

Рис.8. Создание приложения

Осталось проверить работоспособность службы, как показано на Рис.9., и доступность кода XML, как это делали выше, нажав ссылку http://localhost/MyFirstWebService/Service1.svc?wsdl:

Отметим, что для выборки службы мы использовали вызов

Рис.9. Проверка службы

Параграф 4. Создание клиентских Windows и Web приложений, использующих Web службу

Далее создадим новый проект — либо консольное, либо WindowsApplication или Asp.Net приложение, которое будет обращаться к службе. У нас будет возможность проверить, являются ли действительными указанные адреса электронной почты, или, по крайней мере удовлетворяющими нашему регулярному выражению. Я создал обычное ASP.Net Web приложение (Рис.10.):

Рис.10. Создание ASP.NET приложения

Поместим на форму два контрола: Button и Label и добавим ссылку на наш сервис как показано на Рис.11-17.

Рис.11. Создание ASP.NET приложения

Рис.12. Добавление ссылки на сервис

Рис.13. Добавление ссылки на сервис

Рис.14. Добавление ссылки на сервис

Если сервис не отображается — введите его адрес и нажмите зеленую кнопочку справа:

Рис.15. Добавление ссылки на сервис

Задайте имя сервису для приложения и нажмите кнопочку «Add Reference»:

Рис.16. Добавление ссылки на сервис

Рис.17. Ссылка на сервис добавлена

Добавим код в приложение, как показано на Рис.18.

Рис.18. Код приложения

Испытаем приложение — результат показан на Рис.19.

Рис.19. Выполнение ASP.NET приложения

Проделав все то же cамое для Windows приложения, получим тот же результат (Рис.20):

Рис.20. Выполнение Windows приложения

Параграф 6. Совмещение проектов для удобства отладки Web сервисов

Возьмем наш проект в том виде, в котором он изображен на Рис.5. — иначе на момент когда мы создали наш сервис. Переименуем решение из MyFirstService в FirstService, воспользовавшись контекстным меню, пункт «Rename». К решению добавим, например Console Application (контекстное меню решения, пункты «Add/New Project» — темплата «Console Application» (закладка «Windows»)). Не меняя имени приложения нажмем кнопку «OK». Получим результат, показанный на Рис.21.

Рис.21. Сервис и консольное приложение

Кликаем в Solution Exploreре на узле CondoleApplication1 и в контекстном иеню выбираем «Add Service Reference» (Рис.22.).

Рис.21. Сервис и консольное приложение

Далее повторяем шаги, показанные на Рис.12-14. На шаге Рис.14. выбираем «Web Services in This Solution» (Рис.23.).

Рис.23. Добавление сервиса из текущего проекта

Выбираем Service1 и даем ему имя, например «myservice», нажимаем кнопку «Add Reference» (Рис.24.).

Рис.24. Добавление сервиса из текущего проекта

В проет ConsoleApplication добавляем пространство имен:

Кликаем в Solution Exploreре на узле CondoleApplication1 и в контекстном иеню выбираем пункт «Set as Startup Project». Запускаем приложение и получаем резельтат, как показано на Рис.25.

Рис.25. Исрользование Web сервиса в целях отладки приложения

После отладки приложения мы точно также можем публиковать наш сервис, как это описано выше.

Параграф 7. О параметрах вызова методов Web Service

Пока мы работали с методом, в котором все параметры строки, проблем не было с вызовом метода, ровно, как и с тем как, и сколько параметров определено в файле интерфейса, и с тем, как и столько параметров используется. Однако. Если мы зададим в IService1.cs контакт с параметрами типа int или другими, отличными от строковых, например:

При этом в файле Service1.svc.cs определим его, как метод возведения числа в квадрат:

Вновь добавим web ссылку на service в консольном приложении, как это сделано в параграфе 6. И теперь попытаемся использовать наш метод:

То получим ошибку:

Кликнув правой кнопкой мышки на методе «square» и выбрав в контекстном меню «Go To Defination», попадем в файл «Reference.cs», где увидим, что наш метод получил серьезное преобразование:

По крайней мере, параметров в методе стало 4. Прием первого параметра методом выглядит как обычно, а возврат результата осуществляется через параметр типа «out». Два параметра «xxxSpecified» определяют действительность параметров в сериализованном XML документе. Эти преобразования как раз и связаны с передачей XML документа в сериализованном виде.

В MSDN написано: «Сериализация XML– это процесс преобразования открытых свойств и полей объекта в серийный формат (в данном случае в формат XML) для хранения и транспортировки. Десериализация пересоздает объект в его исходном состоянии из вывода XML. Сериализацию можно представить в качестве способа сохранения состояния объекта в поток или буфер. Например, ASP.NET использует класс XmlSerializer для кодирования сообщений веб-службы XML. схема включает использование двух параметров — один параметр для использования (System.ComponentModel.DefaultValueAttribute) значения по умолчанию, другой параметр для использования специального шаблона с целью создания логического поля, определяемого XmlSerializer, и с целью применения XmlIgnoreAttribute к полю. Шаблон создается в форме propertyNameSpecified. Например, при наличии поля с именем «MyFirstName» (Мое имя) также будет создано поле с именем «MyFirstNameSpecified» (Мое имя указано), инструктирующее XmlSerializer о необходимости генерирования элемента XML с именем «MyFirstName»

Таким образом, мы вынуждены мириться с изменением определенных в интерфейсе методов, например, в нашем примере выход из положения прост: