Введение в WCF

История технологий программирования для борьбы с повторением кода и для структурирования программ
Функции, функциональное программирование
Объектно-ориентированное программирование
Компонентно-ориентированное программирование (Component Object Model) – каждый компонент в COM-объекте (ActiveX, DCOM, COM+, DirectX…), может использоваться во многих программах одновременно
Сервис-ориентированное программирование (SOA, SСервис-ориентированное программирование (SOA, ServiceСервис-ориентированное программирование (SOA, Service OСервис-ориентированное программирование (SOA, Service Oriented Сервис-ориентированное программирование (SOA, Service Oriented AСервис-ориентированное программирование (SOA, Service Oriented Architecture) — модульный подход к разработке программного обеспечения, основанный на использовании сервисов (служб).
Сервисы являются естественным результатом эволюции компонентов, как компоненты были естественным результатом эволюции объектов. Клиентом сервиса может быть всё, что угодно – класс Windows Forms, страница ASP.NET, другой сервис. В WCF все сообщения передаются в формате SOAP как в классических Web-сервисах.
WCF предоставляет следующие транспортные схемы (Адреса):
HTTP: http://localhost:8001/MyService (в глобальной сети)
TCP: net.tcp://localhost:8002/MyService (в лок. сети)
IPC (именованные каналы): net.pipe://localhost/MyService (на одном компьютере)
MSMQ (механизм очередей): net.msmq://localhost/MyService
Одноранговые сети: net.p2p: (например, узлы GRID)

WAS: реализация не HTTP протоколов
Именно WAS (Windows process Activation Service) при IIS 7 и выше поддерживает для WCF отличные от HTTP протоколы (net.tcp, net.pipe…). Он позволяет для не HTTP-запросов реализовать их обработку аналогично IIS: активировать WCF-сервисы по требованию, создавать для них пулы и запускать рабочие процессы, наблюдать за работоспособностью процесса, управлять приложениями, обеспечивать быструю защиту от сбоев.
Web-служба IIS (Svchost.exe) сохраняет роль прослушивателя HTTP, но компоненты, ответственные за настройку и активацию процесса, были перенесены в WAS, которая имеет три части: диспетчер настройки, диспетчер обработки и интерфейс адаптера прослушивателя.
Диспетчер настройки считывает настройки приложения и пула приложений из файла applicationhost.config. Диспетчер обработки сопоставляет пулы приложений существующим рабочим процессам w3wpw3wp.exe и запускает процессы. Интерфейс адаптера прослушивателя используется WCF для передачи принятых запросов на активацию по протоколам, отличным от HTTP.

Сервисы, посредники (прокси), операции (методы)
Каждая служба WCF может содержать несколько независимых операций – методов. Клиент службы подключается к конечным точкам службы и взаимодействует с операциями службы через своего посредника (прокси), создаваемого в приложении клиента.
Подключение к одной и той же службе по разным каналам, к разным точкам службы организуется разными посредниками. Классы посредников (прокси-классы), создаются клиентом при предварительной настройке его взаимодействия со службой на основе метаданных службы, описанных в виде контрактов службы и операций.
Пример вызова операции GetData() службы MyService через посредника MyProxi на основе автоматически ранее созданного прокси-класса MyServiceClient:
MyServiceClient MyProxi = new MyServiceClient();
MyProxi.GetData();
WCF по умолчанию поддерживает классический вызов операций (клиент делает вызов, блокируется ожидая ответ с тайм-аутом 1 минуту и продолжает работу после ответа). Кроме того он поддерживает односторонние операции («вызвал и забыл» без возвращаемых сообщений), операции обратного вызова (для оповещения клиентов о событиях на стороне сервера) и потоковые операции (обработка данных во время их приёма). Напомним, что приложения клиентов с вызовом сервисов надо выполнять асинхронно. Например, на странице ASP.NET надо указать <%@ Page Async="true" %>.
Все настройки служб и их операций осуществляются в контрактах (Contract), а также в привязках (Binding) и поведениях (behaviors) точек взаимодействия (Endpoint).

Обмен сообщениями
в SOAP-конвертах
Клиент
Сервис
Вадим Мелещук
Software Design Engineer
Microsoft/ WCF

Конечные точки
Клиент
Сервис

Address, Binding, Contract
Клиент
Сервис
Address
Binding
Contract
(Где)
(Как)
(Что)
(+Behaviors)

Конечные точки
Каждая служба связывается с адресом, определяющим местоположение службы, с привязкой, определяющей способ взаимодействия со службой (безопасность, сеансы, транзакции…), и с контрактом, который указывает, что делает служба, её параметры, ошибки и сообщения.
Каждая служба должна предоставлять как минимум одну рабочую конечную точку. Одна служба может предоставлять несколько конечных точек.
Конечная точка MEX предоставляет метаданные (по протоколу WSDL), описывающие функциональность WCF и способы взаимодействия с ней. Она используется на этапе проектирования клиента службы для настройки его прокси-класса.
Конечные точки могут использовать одинаковые или разные привязки, а также предоставлять одинаковые или разные контракты.
Разные конечные точки никак не связаны друг с другом, они не представлены в коде службы. Конечные точки могут настраиваються на административном уровне (через конфигурационный файл Web.config) или на программном уровне.
Конечная точка MEX
Рабочая конечная точка службы

Привязки
фиксированный набор настроек, относящихся к транспортному протоколу, кодиро-ванию сообщений, коммуникационной схеме, надёжности, безопасности, распространению транзакций и совместимости.
Можно настраивать свойства стандартных привязок, можно писать собственные привязки. Служба публикует свои привязки в метаданных (в формате WSDL). Клиент должен использовать точно такие же параметры привязки, что и служба. Одна служба может поддерживать несколько привязок но по разным адресам.
Стандартные привязки
BasicHttpBinding (HTTP, HTTPS) – для взаимодействия со старыми веб-службами и клиентам .asmx
NetTcpBinding (TCP) – для интрасетей, поддерживает надёжность, транзакции, безопасность, оптимизирована для взаимодействия WCF-WCF
NetPeerTcpBinding (P2P) – для одноранговых сетей типа GRID
NetNamedPipeBinding (IPC) – именованные каналы в пределах одного компьютера. Наиболее защищённые (не принимают вызовы от TCP), поддерживают все функции NetTcpBinding
wsHttpBinding (HTTP, HTTPS) – для интернет-сетей с поддержкой надёжности, транзакций, безопасности
wsDualHttpBinding (HTTP, HTTPS) – в дополнение к предыдущей поддерживает двухстороннее взаимодействие между службой и клиентом (поддерживается второй HTTP-канал для обратного вызова от службы к клиенту)
NetMsmqBinding (MSMQ) – для поддержки очередей автономных вызовов в интрасетях

Контракты
- описание того, что делает служба. На его основе формируется WSDL-ответ.
Существуют четыре разновидности контрактов:
Контракты служб [ServiceContract] описывают операции (методы), которые могут выполняться клиентом с помощью службы и контракты необходимых операций [OperationContract];
Контракты данных [DataContract] определяют, какие типы данных принимаются и передаются службой. При передаче объекта или структурного типа в параметре операции, в действительности, надо передать лишь его состояние, а принимающая сторона должна преобразовать его обратно к своему родному представлению. Это называется маршалтинг по значению. Он реализуется посредством сериализации, когда пользовательские типы переводятся из CLR представлений в XML содержимое SOAP-конвертов. При приёме параметров происходит десериализация, т.е. набор XML преобразуется в объект CLR и дальше передаётся для обработки;
Контракты ошибок [FaultContract] определяют, какие исключения инициируются службой, как служба обрабатывает их и передаёт своим клиентам;
Контракты сообщений [MessageContract], [MessageHeader] [MessageBodyHeader] позволяют службам напрямую взаимодействовать с сообщениями и моделировать структуру всего конверта SOAP.

Пример контрактов
(интерфейс службы .svc из примера (интерфейс службы .svc из примера Visual Studio 2008)
Контракт службы
Контракты методов (операций).
Другие методы интерфейса без этого атрибута в контракт не включаются.
Контракт данных
Этот атрибут означает необходимость осуществления маршалтинга по значению для этого типа данных
Этот атрибут означает необходимость сериализации указанных полей данных, чтобы они участвовали в маршалтинге по значению текущего типа данных
Служба Service/svc

Примеры настройки контрактов
Классический вызов метода с ожиданием ответа поддерживается всеми привязками (кроме NetPeerTcpBinding и NetMsmqBinding):
[OperationContract(IsOneWay = false)]
string MyMethod(out int n1, int n2);
Возвращаемые параметры должны стоять в начале списка параметров.
Односторонний вызов метода поддерживается всеми привязками:
[OperationContract(IsOneWay = true)]
void MyMethod();
Двухсторонний (обратный) вызов поддерживается привязками NetTcpBinding, NetNamedPipeBinding, wsDualHttpBinding:
[ServiceContract(CallBackContract = typeof(ISomeBackConract)]
Обратный вызов должен специально организовываться и у клиента.
Поддержка сеанса в контракте службы или операции (нет в Web-сервисах):
[ServiceContract(SessionMode = SessionMode.Allowed]
и в поведении службы: [ServiceBehavior(InstanceContextMode =
InstanceContextMode.PerSession)]
Режим двусторонней операции, включается по умолчанию (можно не указывать)
Принято по умолчанию (можно не указывать)

Структура файла конфигурации служб - Web.config
- раздел WCF
- раздел адресов, настроек всех служб
behaviorConfiguration="SrvBehavior"> – имя её поведения в
конечная рабочая точка 1
конечная рабочая точка 2
…
Описание второй службы
конечная рабочая точка 1
конечная рабочая точка 2
…
- раздел конфигурации привязок (при необходимости)…
- раздел настроек поведения (доступ к метаданным, исключения…)
для различных служб и конечных точек

Конфигурация конечных точек (адрес, привязка, контракт) для первой службы рабочая точка 1
binding="wsHttpBinding"
contract="MyNamespace.IMyContract"
name="MyPoint1"
bindingConfiguration="MyConfigNetTCP" – имя для конфигурации привязки в
behaviorConfiguration="MyPointBehavior"> – имя для поведения точки в
binding="netTcpBinding"
contract="MyNamespace.IMyContract"
name="MyPoint2">

Обмен метаданными
Метаданные необходимы для создания прокси-класса у клиента через который он будет взаимодействовать со службой. Метаданные можно опубликовать двумя способами:
по протоколу HTTP-GET,
через конечную точку MEX
Оба варианта автоматически генерируются VS в файле конфигурации .config:
address="mex"
binding="mexHttpBinding"
contract="IMetadataExchange" />
Доступ к метаданным через конечную mex-точку
(относительно базового адреса)

Настройка поведения behaviors
set the value below to false and remove the metadata endpoint above before deployment -->
…
HTTP-GET-доступ к метаданным.
true - можно просмотреть метаинформацию в браузере
Настройка поведения для службы с behaviorConfiguration="SrvBehavior">
Настройка поведения для конечной точки с behaviorConfiguration=“MyPointBehavior"
Не отправлять клиенту сообщения об исключениях, возникающих внутри методов
Поддерживать до 20 параллельных сеансов.
По умолчанию – 10
Настройка поведения всех служб
Настройка поведения конечных рабочих точек служб set the value below to false and remove the metadata endpoint above before deployment -->
…
HTTP-GET-доступ к метаданным.
true - можно просмотреть метаинформацию в браузере
Настройка поведения для службы с behaviorConfiguration="SrvBehavior">
Настройка поведения для конечной точки с behaviorConfiguration=“MyPointBehavior"
Не отправлять клиенту сообщения об исключениях, возникающих внутри методов
Поддерживать до 20 параллельных сеансов.
По умолчанию – 10
Настройка поведения всех служб
Настройка поведения конечных рабочих точек служб

Тестирование службы в браузере
(Проверка доступа к метаданным службы)
Это окно означает, что хостинг службы организован успешно, имеется Get-доступ к метаданным.

Метаданные службы (GET-доступ – ?wsdl)

Проверка доступа к метаданным службы
при отключённом доступе к метаданным
При этом служба и её клиенты продолжают работать.
После настройки прокси-класса клиента надо удалить mex-точку службы и задать httpGetEnabled="false" для предотвращения несанкционированного подключения к службе. В этом случае попытка доступа к метаданным:

Тестирование службы: кнопка F5 в VS

Хостинг служб WCF
Каждая служба WCF должна находится под управлением некоторого процесса Windows, называемого хостовым процессом. Существуют 4 типа хостинга:
Резидентное размещение в управляемом приложении .NET (со своим
экземпляром класса ServiceHost);
Размещение в виде управляемой службы Windows;
Размещение в IIS;
Размещение в службе активации Windows – WAS (Windows Server 2008,
Vista)
Понятие базового адреса
Базовый адрес — это корневой адрес для резидентного хостинга службы, реализующего работу класса ServiceHost, указывается в файле конфигурации в ветке
...
Базовый адрес эквивалентен виртуальному каталогу в ASP.NET. При хостинге в службах IIS базовый адрес — это всегда адрес службы, указанный в её файле SVC. При размещении службы в IIS создается один базовый адрес в виртуальном каталоге, содержащем приложение. Следовательно, для конечных точек служб, размещенных в IIS, следует использовать относительные адреса. Указание полного адреса конечной точки может привести к ошибкам при развертывании службы.

Построение клиентов для служб WCF
Клиент должен знать, где находится служба, использовать ту же привязку, что и служба и импортировать определение контракта службы (по протоколу WSDL), т.е., клиентское приложение должно содержать информацию о конечных точках службы. Visual Studio, при добавлении ссылки на службы, автоматически добавляет необходимую информацию о конечных точках службы в раздел
своего файла конфигурации web.config. Данный раздел может находиться и в корневом файле конфигурации сайта и в файле конфигурации каталога где находится клиент.
Для вызова операций службы клиент должен сначала импортировать контракт службы в родное представление своей среды и создать посредника – прокси-класс для общения с WCF-службой. Посредник предоставляет те же операции, что и контракт службы, но при этом содержит дополнительные методы для управления жизненным циклом и подключением к службе.
Visual Studio позволяет просто генерировать посредника и импортировать метаданные службы в папку ссылок проекта App_WebReferences и в файл конфигурации web.config. В файле конфигурации автоматически появляется узел
- рабочая точка и её привязка -
.
После построения посредника клиент может прямо обращаться к операциям (методам) службы.

Конфигурация конечных точек на стороне клиента
… bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard"
maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true"
allowCookies="false">
…
address="http://localhost:8000/MyService1/" binding="wsHttpBinding"
contract="MyNamespace.IMyPoint"
bindingConfiguration="MyPoint" >
Настройка привязки конечной точки с bindingConfiguration="MyPoint"
Уточнение настроек для привязок типа wsHttpBinding