Поделиться через

Развертывание службы WCF Internet Information Services Services-Hosted

Разработка и развертывание службы Windows Communication Foundation (WCF), размещенной в службах IIS, состоит из следующих задач:

  • Убедитесь, что службы IIS, ASP.NET, WCF и компонент активации WCF правильно установлены и зарегистрированы.

  • Создайте новое приложение IIS или повторно используйте существующее приложение ASP.NET.

  • Создайте SVC-файл для службы WCF.

  • Разверните реализацию службы в приложении IIS.

  • Настройте службу WCF.

Подробное пошаговое руководство по созданию службы WCF, размещенной в IIS, см. в статье "Практическое руководство. Размещение службы WCF в IIS".

Убедитесь, что службы IIS, ASP.NET и WCF правильно установлены и зарегистрированы

Для правильной работы служб WCF, размещенных в IIS, необходимо установить WCF, IIS и ASP.NET. Процедуры установки WCF (в составе .NET Framework), ASP.NET и IIS зависят от операционной системы. Дополнительные сведения об установке WCF и .NET Framework см. в разделе "Установка .NET Framework для разработчиков". Чтобы установить IIS в Windows 10, откройте программы и компоненты на панели управления и выберите "Включить или отключить функции Windows". В компонентах Windows выберите службы Internet Information Services и нажмите кнопку "ОК".

Функции Windows с выделенным IIS

Инструкции по установке IIS в других операционных системах см. в статье "Установка IIS в Windows Vista и Windows 7" и установка IIS8.5 в Windows Server 2012 R2.

Процесс установки .NET Framework автоматически регистрирует WCF в IIS, если IIS уже установлены на компьютере. Если IIS установлена после .NET Framework, необходимо выполнить дополнительный шаг для регистрации WCF в IIS и ASP.NET. Это можно сделать следующим образом, в зависимости от операционной системы:

Создание нового приложения IIS или повторное использование существующего приложения ASP.NET

Службы WCF, размещенные в IIS, должны находиться в приложении IIS. Вы можете создать новое приложение IIS для размещения служб WCF исключительно. Кроме того, можно развернуть службу WCF в существующем приложении, которое уже размещает содержимое ASP.NET 2.0 (например, страницы .aspx и веб-службы ASP.NET [ASMX]). Дополнительные сведения об этих параметрах см. в разделах "Размещение WCF параллельно с ASP.NET" и "Размещение служб WCF в режиме совместимости ASP.NET" в службах WCF и ASP.NET.

Обратите внимание, что службы IIS 6.0 и более поздние версии периодически перезапускали изолированное объектно-ориентированное приложение программирования. Значение по умолчанию — 1740 минут. Максимальное поддерживаемое значение — 71 582 минуты. Этот перезапуск можно отключить. Дополнительные сведения об этом свойстве см. в параметре PeriodicRestartTime.

Создание SVC-файла для службы WCF

Службы WCF, размещенные в службах IIS, представлены в виде специальных файлов контента (.svc-файлов) в приложении IIS. Эта модель аналогична тому, как страницы ASMX представлены внутри приложения IIS как ASMX-файлы. SVC-файл содержит директиву обработки WCF (@ServiceHost), которая позволяет инфраструктуре размещения WCF активировать размещенные службы в ответ на входящие сообщения. Наиболее распространенный синтаксис SVC-файла представлен в следующей инструкции.

<% @ServiceHost Service="MyNamespace.MyServiceImplementationTypeName" %>

Он состоит из директивы @ServiceHost и одного атрибута Service. Значение атрибута Service — это имя типа среды CLR для реализации службы. Использование этой директивы в основном эквивалентно созданию узла службы с помощью следующего кода.

new ServiceHost( typeof( MyNamespace.MyServiceImplementationTypeName ) );

Можно также сделать дополнительную конфигурацию размещения, например создание списка базовых адресов для службы. Вы также можете использовать настраиваемый ServiceHostFactory для расширения директивы, чтобы использовать её с пользовательскими решениями размещения. Приложения IIS, на которых размещаются службы WCF, не несут ответственности за управление созданием и временем существования ServiceHost экземпляров. Управляемая инфраструктура размещения WCF создает необходимый ServiceHost экземпляр динамически при получении первого запроса для SVC-файла. Экземпляр не освобождается, пока он не закрывается явным образом по коду или при перезапуске приложения.

Дополнительные сведения о синтаксисе файлов SVC см. в @ServiceHost.

Развертывание реализации службы в приложении IIS

Службы WCF, размещенные в IIS, используют ту же динамическую модель компиляции, что и ASP.NET 2.0. Как и в случае с ASP.NET, можно развернуть код реализации для служб WCF, размещенных в IIS, несколькими способами в различных расположениях, как показано ниже.

  • Как файлы .dll, предварительно скомпилированные и расположенные в глобальном кэше сборок (GAC) или в каталоге \bin приложения. Предварительно скомпилированные двоичные файлы не обновляются до развертывания новой версии библиотеки классов.

  • Как некомпилированные исходные файлы, расположенные в каталоге \App_Code приложения. Исходные файлы, расположенные в этом каталоге, динамически требуются при обработке первого запроса приложения. Любые изменения в файлах в каталоге \App_Code вызывают перезагрузку всего приложения и повторной компиляции при получении следующего запроса.

  • Как некомпилированный код, помещаемый непосредственно в .svc файл. Код реализации также можно найти в встроенном файле SVC службы после директивы @ServiceHost. Любые изменения встроенного кода приводят к перезапуску приложения и повторной компиляции при получении следующего запроса.

Дополнительные сведения о модели компиляции ASP.NET 2.0 см. в разделе Обзор компиляции ASP.NET.

Настройка службы WCF

Службы WCF, размещенные в IIS, хранят конфигурацию в Web.config файле приложений. Службы, размещенные в IIS, используют те же элементы конфигурации и синтаксис, что и службы WCF, размещенные за пределами IIS. Однако следующие ограничения уникальны для среды размещения IIS:

  • Базовые адреса для служб, размещенных в IIS.

  • Приложения, размещающие службы WCF за пределами IIS, могут управлять базовым адресом служб, которые они размещают, передав набор URI ServiceHost базовых адресов конструктору или предоставляя <элемент узла> в конфигурации службы. Службы, размещенные в IIS, не имеют возможности управлять их базовым адресом; базовый адрес размещенной службы IIS — это адрес его SVC-файла.

Адреса конечных точек для служб IIS-Hosted

При размещении в IIS, адреса конечных точек всегда считаются относительными по отношению к адресу файла .svc, представляющего службу. Например, если базовый адрес службы WCF равен http://localhost/Application1/MyService.svc со следующей конфигурацией конечной точки:

<endpoint address="anotherEndpoint" />

Это обеспечивает конечную точку, которую можно получить по адресу http://localhost/Application1/MyService.svc/anotherEndpoint.

Аналогичным образом, элемент конфигурации конечной точки, использующий пустую строку в качестве относительного адреса, предоставляет доступную конечную точку, http://localhost/Application1/MyService.svcкоторая является базовым адресом.

<endpoint address="" />

Всегда следует использовать относительные адреса для конечных точек, размещенных в IIS. Предоставление полного адреса конечной точки (например, http://localhost/MyService.svc) может привести к ошибкам в развертывании службы, если адрес конечной точки не указывает на приложение IIS, в котором размещена служба и предоставляющего конечную точку. Использование относительных адресов конечных точек для размещенных служб позволяет избежать этих потенциальных конфликтов.

Доступные транспорты

Службы WCF, размещенные в IIS 5.1 и IIS 6.0, ограничены использованием связи на основе HTTP. На этих платформах IIS настройка размещенной службы для использования привязки, отличной от HTTP, приводит к ошибке во время активации службы. Для IIS 7.0 поддерживаемые транспорты включают HTTP, Net.TCP, Net.Pipe, Net.MSMQ и msmq.formatname для обратной совместимости с существующими приложениями MSMQ.

Безопасность транспорта HTTP

Службы WCF, размещенные в IIS, могут использовать безопасность транспорта HTTP (например, схемы проверки подлинности HTTPS и HTTP, такие как базовая, дайджест и встроенная проверка подлинности Windows), если виртуальный каталог IIS, содержащий службу, поддерживает эти параметры. Параметры безопасности транспорта HTTP в привязке размещенной конечной точки должны соответствовать параметрам безопасности транспорта в виртуальном каталоге IIS, содержащему его.

Например, конечная точка WCF, настроенная для использования проверки подлинности дайджеста HTTP, должна находиться в виртуальном каталоге IIS, который также настроен для разрешения проверки подлинности дайджеста HTTP. Несовпаденные сочетания параметров IIS и параметров конечной точки WCF приводят к ошибке во время активации службы.

См. также