Презентация на тему Введение в WCF. WCF-службы. Windows Communication Foundation

и для структурирования программ
Функции
Объектно-ориентированное программирование
Компонентно-ориентированное программирование (COM-компоненты -

.lib, .dll)
Сервис-ориентированное программирование (SOA, Service Oriented Architecture) — модульный подход к разработке программного обеспечения, основанный на использовании сервисов (служб) со стандартизированными интерфейсами. Сервис-ориентированное приложение представляет собой результат агрегирования служб в одно, логически завершенное, связное приложение.

Сервисы являются естественным результатом эволюции компонентов, как компоненты были естественным результатом эволюции объектов. Клиентом сервиса может быть всё, что угодно – класс Windows Forms, страница ASP.NET, другой сервис. В WCF все сообщения передаются в формате SOAP.
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)

process Activation Service) при IIS 7 поддерживает для WCF

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

содержать несколько независимых операций – методов, к которым может

обращаться клиент. Клиент взаимодействует с операциями службы через своего посредника – экземпляр прокси.
Подключение к каждой службе происходит через своего посредника, более того, подключение по разным каналам, к разным точкам одной и той же службы организуется разными посредниками. Классы посредников (прокси-классы), создаются клиентом при предварительной настройке его взаимодействия со службой на основе метаданных службы, описанных в виде контрактов службы и операций.
Пример организации вызова операции GetData() службы MyService через посредника MyProxi на основе заранее созданного прокси-класса MyServiceClient:

MyServiceClient MyProxi = new MyServiceClient();
MyProxi.GetData();
WCF по-умолчанию поддерживает классический вызов методов (клиент выдаёт вызов, блокируется ожидая ответ с тайм-аутом 1 минуту и продолжает работу после ответа). Кроме того он поддерживает односторонние операции («вызвал и забыл» без возвращаемых сообщений), операции обратного вызова (для оповещения клиентов о событиях на стороне сервера) и потоковые операции (обработка данных во время их приёма).
WCF могут поддерживать сеансы между клиентом и определенным экземпляром службы, могут поддерживать транзакции и очереди, а также параллельную обработку.
Все настройки служб и операций осуществляются в их контрактах (Contract), а также в привязках (Binding) и поведениях (behaviors) точек взаимодействия (Endpoint).

службы, с привязкой, определяющей способ взаимодействия со службой, и

с контрактом, который указывает, что делает служба, её параметры, ошибки и сообщения.

Каждая служба должна предоставлять как минимум одну рабочую конечную точку, и каждая конечная точка должна иметь один контракт. Все конечные точки службы имеют уникальные адреса. Одна служба может предоставлять несколько конечных точек.

Конечная точка MEX предоставляет метаданные, описывающие функциональность WCF и способы взаимодействия с ней. Она используется на этапе проектирования клиента службы для настройки его прокси-класса.

Конечные точки могут использовать одинаковые или разные привязки, а также предоставлять одинаковые или разные контракты.

Разные конечные точки никак не связаны друг с другом, они не представлены в коде службы. Конечные точки настраиваются на административном уровне (через конфигурационный файл) или на программном уровне.

Конечная точка MEX

Конечная точка службы

кодиро-ванию сообщений, коммуникационной схеме, надёжности, безопасности, распространению транзакций и

совместимости.
Можно настраивать свойства стандартных привязок, можно писать собственные привязки. Служба публикует свои привязки в метаданных (в формате WSDL). Клиент должен использовать точно такие же параметры привязки, что и служба. Одна служба может поддерживать несколько привязок по разным адресам.

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

делает данная служба.
Существуют четыре разновидности контрактов:
Контракты служб [ServiceContract] описывают

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

Studio 2008)
Контракт службы
Контракты методов (операций). Другие методы интерфейса без

этого атрибута в контракт не включаются.

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

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

всеми привязками (кроме NetPeerTcpBinding и NetMsmqBinding):
[OperationContract(IsOneWay = false)] string

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

Режим двусторонней операции, включается по умолчанию (можно не указывать)

Принято по умолчанию (можно не указывать)

- раздел настроек всех служб

службы
behaviorConfiguration="SrvBehavior"> – имя её поведения в
конечная рабочая точка 1
конечная рабочая точка 2
…


Описание второй службы
конечная рабочая точка 1
конечная рабочая точка 2
…



- раздел конфигурации привязок (при необходимости)…


- раздел настроек поведения (доступ к метаданным, исключения…)
для различных служб и конечных точек

службы

имя для конфигурации привязки в
behaviorConfiguration="PointBehavior"> – имя для поведения точки в

binding="netTcpBinding"
contract="MyNamespace.IMyContract"
name="MyPoint2">

через который он будет взаимодействовать со службой. Метаданные можно

опубликовать двумя способами:
по протоколу HTTP-GET,
через конечную точку MEX
Оба варианта автоматически генерируются VS в файле конфигурации .config:

address="mex"
binding="mexHttpBinding"
contract="IMetadataExchange" />

Доступ к метаданным через конечную mex-точку (относительно базового адреса)

To avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above before deployment -->










…

HTTP-GET-доступ к метаданным. true - можно просмотреть метаинформацию в браузере

Настройка поведения для службы с behaviorConfiguration="SrvBehavior">

Настройка поведения для конечной точки с behaviorConfiguration="PointBehavior"

Не отправлять клиенту сообщения об исключениях, возникающих внутри методов

Поддерживать до 20 параллельных сеансов. По умолчанию – 10

Настройка поведения всех служб

Настройка поведения конечных рабочих точек служб

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

к метаданным.

к метаданным
При этом служба и её клиенты продолжают работать.
После

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

управлением некоторого процесса Windows, называемого хостовым процессом. Существуют 4

типа хостинга:
Резидентное размещение в управляемом приложении .NET (со своим экземпляром класса ServiceHost);
Размещение в виде управляемой службы Windows;
Размещение в IIS;
Размещение в службе активации Windows – WAS (Windows Server 2008, Vista)

Понятие базового адреса

Базовый адрес — это корневой адрес для резидентного хостинга службы, реализующего работу класса ServiceHost, указывается в файле конфигурации в ветке ...
Базовый адрес эквивалентен виртуальному каталогу в ASP.NET. При хостинге в службах IIS базовый адрес — это всегда адрес службы, указанный в её файле SVC. При размещении службы в IIS создается один базовый адрес в виртуальном каталоге, содержащем приложение. Следовательно, для конечных точек служб, размещенных в IIS, следует использовать относительные адреса. Указание полного адреса конечной точки может привести к ошибкам при развертывании службы.

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

и импортировать определение контракта службы (по протоколу WSDL), т.е., клиентское приложение должно содержать информацию о конечных точках службы. Visual Studio, при добавлении ссылки на службы, автоматически добавляет необходимую информацию о конечных точках службы в раздел своего файла конфигурации web.config. Данный раздел может находиться и в корневом файле конфигурации сайта и в файле конфигурации каталога где находится клиент.

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

Visual Studio позволяет просто генерировать посредника и импортировать метаданные службы в папку ссылок проекта App_WebReferences и в файл конфигурации web.config. В файле конфигурации автоматически появляется узел - рабочая точка и её привязка - .

После построения посредника клиент может прямо обращаться к операциям (методам) службы.

closeTimeout="00:01:00“
openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"

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