Новые возможности в Windows Communication Foundation

Статья
02/28/2011

В этом разделе рассматриваются новые возможности Windows Communication Foundation (WCF).

Активация на основе конфигурации

Обычно при размещении службы Windows Communication Foundation (WCF) в каталоге IIS или WAS следует предоставить SVC-файл. SVC-файл содержит имя службы, а также дополнительную пользовательскую фабрику узла службы. С помощью этого дополнительного файла добавляются служебные данные по управлению. Функция активации на основе конфигурации снимает требование по наличию SVC-файла и, следовательно, по наличию связанных служебных данных. Дополнительные сведения см. в разделе Активация на основе конфигурации в IIS и WAS, Активация на основе конфигурации.

Интеграция с System.Web.Routing

При размещении службы Windows Communication Foundation (WCF) в службах IIS SVC-файл размещается в виртуальном каталоге. Этот SVC-файл указывает фабрику узла службы, которую необходимо использовать, а также класс, реализующий эту службу. При составлении запросов к службе SVC-файл указывается в URI, например: https://contoso.com/EmployeeServce.svc. Для разработчиков служб REST такой тип URI не является оптимальным. URI для служб REST указывают определенный ресурс и обычно не имеют модулей. Функция интеграции System.Web.Routing позволяет разместить службу WCF, которая отвечает на URI без расширения. Дополнительные сведения см. в разделе Интеграция с System.Web.Routing, Образец интеграции с SystemWebRouting.

Поддержка нескольких привязок узла IIS

При размещении службы Windows Communication Foundation (WCF) в каталоге служб IIS 7.0 может понадобиться предоставить несколько базовых адресов, использующих один и тот же протокол на одном и том же узле. Это позволяет одной и той же службе отвечать на несколько разных URI. Это может оказаться полезным в том случае, если необходимо разместить службу, следящую за https://www.contoso.com и https://contoso.com, или при создании службы, имеющей базовый адрес и отдельный базовый адрес для внутренних пользователей. Дополнительные сведения см. в разделе Поддержка нескольких привязок узла IIS,

Служба маршрутизации

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

Поддержка WS-Discovery

Функция обнаружения служб позволяет клиентским приложениям во время выполнения динамически производить обнаружение адресов служб с помощью WS-Discovery. Спецификация WS-Discovery описывает шаблоны обмена сообщениями, которые необходимы для выполнения облегченного обнаружения служб в многоадресном (нерегламентированном) и одноадресном (с использованием сетевого ресурса) режимах. Дополнительные сведения см. в разделе Обнаружение WCF, Обнаружение (образцы).

Стандартные конечные точки

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

Службы рабочего процесса

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

Атрибут требуемой версии .NET Framework

Атрибут требуемой версии .NET Framework используется для задания версии платформы .NET приложения, которое предназначено для размещения в IIS или WAS. Это позволяет создавать в среде Visual Studio приложения для платформы .NET Framework 2.0, 3.5 или 4. Это набор атрибутов в теге <compilation> в файле приложения Web.config, который представлен в следующем примере.

<compilation debug="false"
        targetFramework="4.0">

        <assemblies>
          <add assembly="System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
          <add assembly="System.Xml.Linq, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
          <add assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
          <add assembly="System.Data.DataSetExtensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
        </assemblies>

      </compilation>

Когда приложение, размещаемое в IIS или WAS, предназначено для работы на платформе .NET, которая не установлена, вызывается исключение, которое указывает на ошибку. Если в файле приложения Web.config не задан моникер целевой версии .NET Framework, то это значение будет получено из версии пула приложений, которая настроена в IIS.

Поскольку это новая функция, при попытке размещения службы WCF, которая написана для платформы .NET Framework 3.5 на компьютере, где работает платформа .NET Framework 4, может возникнуть исключение ProtocolException со следующим текстом.

Необработанное исключение: System.ServiceModel.ProtocolException: Тип содержимого ответного сообщения, text/html; charset=utf-8, не соответствует типу содержимого привязки (application/soap+xml; charset=utf-8).
				При использовании пользовательского кодировщика убедитесь, что метод IsContentTypeSupported реализован надлежащим образом.
				Первые 1024 байта ответа: <html>
					<заголовок>
					<название>Домен или пул приложения в настоящий момент использует .NET Framework версии 4 или более поздней.
				Это может произойти, если параметры служб IIS были заданы на 4.0 или более позднюю версию для этого веб-приложения либо если используется ASP.NET Web Development Server версии 4.0 или более поздней.
				Элемент &lt;compilation&gt; в файле Web.config для этого веб-приложения не содержит требуемый атрибут «targetFrameworkMoniker» для этой версии .NET Framework (например, '&lt;compilation targetFrameworkMoniker=&quot;.NETFramework,Version=v4.0&quot;&gt;').
				Дополните файл Web.config этим атрибутом или настройте веб-приложение на использование другой версии .NET Framework.</название>...

Эта ошибка возникает из-за того, что домен приложения, в котором работает IIS, использует платформу .NET Framework 4, а служба WCF предполагает выполнение на платформе .NET Framework 3.5. Дополнительные сведения о том, как решить эту проблему, см. в разделе Как разместить службу WCF, написанную для.NET Framework 3.5 в IIS, которая работает в среде в .NET Framework 4.

WCF REST

Кэширование

Платформа .NET Framework 4 позволяет использовать декларативный механизм кэширования, который уже доступен в ASP.NET в службах WCF REST. Это позволяет кэшу выполнять ответы из операций службы WCF REST. Когда пользователь отправляет инструкцию HTTP GET службе, настроенной для кэширования, ASP.NET отправляет обратно кэшированный ответ, метод службы при этом не вызывается. По истечении срока действия кэш в следующий раз, когда пользователь отправит инструкцию HTTP GET, будет вызван метод службы и ответ будет снова кэширован.

Платформа .NET Framework 4 позволяет также реализовать условное кэширование HTTP GET. В сценариях REST условный HTTP-запрос GET часто используется службами для реализации интеллектуального HTTP-кэширования, которое описано в Спецификации протокола HTTP. Дополнительные сведения см. в разделе Поддержка кэширования для веб-служб HTTP WCF, Caching and Automatic Help Page.

Поддержка форматов

Модель веб-программирования HTTP WCF позволяет динамически найти лучший формат для операции службы, в котором она возвращает свой ответ. Ответы можно настроить автоматически для XML и JSON через заголовок Accept. Добавлены вспомогательные API-интерфейсы для установки формата операции программным способом. Дополнительные сведения см. в разделе Форматирование веб-объектов HTTP WCF, Автоматический выбор формата, Выбор дополнительного формата.

Обработка ошибок HTTP REST

Обработка ошибок веб-протокола WCF HTTP позволяет возвращать ошибки из служб WCF REST, указывающие код состояния HTTP, а также возвращать их в том же формате, который используется для операции (например, XML или JSON). Дополнительные сведения см. в разделе Обработка ошибок веб-протокола HTTP WCF, .

Функциональные возможности развертывания

Конфигурация, необходимая для запуска службы, была упрощена. Для этого были введены новые стандартные конечные точки. Дополнительные сведения о новой упрощенной конфигурации см. в разделе Упрощенная конфигурация. Дополнительные сведения о стандартных конечных точках см. в разделе Стандартные конечные точки.

При размещении службы Windows Communication Foundation (WCF) в службах IIS SVC-файл размещается в виртуальном каталоге. Этот SVC-файл указывает фабрику узла службы, которую необходимо использовать, а также класс, реализующий эту службу. При составлении запросов к службе SVC-файл указывается в URI, например: https://contoso.com/EmployeeServce.svc. Для разработчиков служб REST такой тип URI не является оптимальным. URI для служб REST указывают определенный ресурс и обычно не имеют модулей. Функция интеграции System.Web.Routing позволяет разместить службу WCF REST, которая отвечает на URI без расширения. Дополнительные сведения см. в разделе Интеграция с System.Web.Routing.

Междоменный JavaScript

Дополнение нотации объектов JavaScript (JSONP) — это механизм, используемый для обеспечения поддержки межсайтовых сценариев в веб-обозревателях. JSONP основан на возможности веб-обозревателей загружать скрипты не с тех сайтов, с которых загружается исходный документ. Механизм работает посредством дополнения полезных данных JSON именем определяемой пользователем функции обратного вызова, как показано в следующем примере:

callback({ “a” = \“b\” });

В вышеприведенном примере полезные данные JSON, {“a” = \”b\”}, помещены в вызов функции callback. Функция обратного вызова должна быть уже определена на текущей веб-странице. Типом содержимого ответа JSONP является «приложение/javascript». Дополнительные сведения см. в разделе JSONP.

Справочная страница службы WCF REST

.NET Framework, версия 4 предоставляет автоматическую справочную страницу для службы WCF REST. На этой странице справки приводится описание каждой операции, форматов запроса и ответа, а также схем. Дополнительные сведения см. в разделе Страница справки веб-службы HTTP WCF, Caching and Automatic Help Page.

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