учебник. начало работы с Windows Communication Foundation приложениями
в приведенной ниже серии руководств представлены инструкции по программированию Windows Communication Foundation (WCF). При работе с этими учебниками вы получите вводные сведения о шагах, необходимых для создания приложений WCF. После завершения работы у вас будет работающая служба WCF и клиент WCF, который вызывает службу.
в учебнике предполагается, что вы используете Visual Studio в качестве среды разработки. если вы используете другую среду разработки, игнорируйте инструкции, относящиеся к Visual Studio.
примеры приложений WCF, которые можно скачать и запустить, см. в разделе Windows Communication Foundation samples. Общие сведения о примерах см. в статье Приступая к работе.
Более подробные сведения о создании служб и клиентов см. в разделе Базовая программирование WCF.
Учебники по WCF
В первых трех руководствах описывается, как определить контракт службы WCF, как его реализовать и как разместить его. Создаваемая служба является саморазмещенной в консольном приложении. службы также можно размещать в Microsoft IIS (IIS). Дополнительные сведения см. в разделе инструкции. размещение службы WCF в IIS. Хотя для настройки службы в этом учебнике используется код, можно также настроить службы в файле конфигурации.
Вы создаете контракт WCF с определяемым пользователем интерфейсом. Этот контракт определяет функциональные возможности, предоставляемые службой.
После определения контракта его необходимо реализовать с помощью класса службы.
Настройте конечную точку для службы и разместите ее в консольном приложении. Чтобы служба стала активной, ее необходимо настроить и разместить в среде выполнения. Эта среда времени выполнения создает службу и управляет ее контекстом и временем существования.
Получите метаданные для создания прокси клиента WCF из службы WCF. метаданные извлекаются с помощью Visual Studio для добавления ссылки на службу или можно использовать средство служебной программы метаданных ServiceModel. Укажите конечную точку, которую клиент использует для доступа к службе.
Используйте прокси клиента WCF для вызова операций службы.
Новые возможности в Windows Communication Foundation 4.5
в этом разделе обсуждаются новые функции Windows Communication Foundation (WCF) версии 4,5.
Возможности упрощения WCF
Много работы было посвящено тому, чтобы сделать разработку и поддержку приложений WCF 4.5 более легкой. Дополнительные сведения см. в разделе функции упрощения WCF.
Поддержка асинхронного выполнения задач
По умолчанию команда добавления ссылки на службу формирует методы асинхронных операций службы, возвращающие объекты задач. Это выполняется как для синхронных, так и для асинхронных методов. Это позволяет вызывать операции службы асинхронно, используя новую модель асинхронного программирования на основе задач. При вызове сформированного прокси-метода WCF создает объект задачи, представляющий асинхронную операцию, и возвращает ее. Задача завершается после завершения операции. При реализации асинхронной операции ее можно реализовать как асинхронную операцию на основе задач. Дополнительные сведения см. в разделе синхронные и асинхронные операции.
Упрощенные сформированные файлы конфигурации
Клиентский файл конфигурации создается при добавлении ссылки на службу в Visual Studio или при использовании средства SvcUtil.exe. В предыдущих версиях WCF эти файлы конфигурации содержали значения каждого свойства привязки, даже если значение было значением по умолчанию. В WCF 4.5 сформированные файлы конфигурации содержат только те свойства привязки, которым присвоено значение не по умолчанию.
Дополнительные сведения см. в разделе функции упрощения WCF.
Разработка в соответствии с парадигмой «Сначала контракт»
WCF теперь поддерживает разработку в соответствии с парадигмой «Сначала контракт». svcutil.exe имеет параметр/Сервицеконтракт, который позволяет создавать контракты служб и данных из документа WSDL.
Добавление ссылки на службу из проекта переносимого подмножества
Изменились значения по умолчанию для режима совместимости с ASP.NET
Новые значения по умолчанию для свойств транспорта
Для упрощения настройки были изменены несколько значений по умолчанию для свойств транспорта. Дополнительные сведения см. в разделе функции упрощения WCF.
XmlDictionaryReaderQuotas
XmlDictionaryReaderQuotas содержит настраиваемые значения квот для средств чтения словаря XML, которые ограничивают объем памяти, используемый кодировщиком при создании сообщения. Хотя эти квоты и можно изменить, значения по умолчанию были изменены для уменьшения вероятности явной настройки разработчиками этих данных. Дополнительные сведения см. в разделе функции упрощения WCF.
Проверка конфигурации WCF
В ходе выполнения процесса сборки в Visual Studio теперь выполняется проверка файлов конфигурации WCF на наличие атрибутов, заданных в проекте. Если проверка завершается с ошибкой, то в Visual Studio отображается список ошибок и предупреждений.
Подсказки в редакторе XML
В XML-редакторе Visual Studio отображаются подсказки для каждого элемента конфигурации (и его свойств), входящего в файл конфигурации службы. Это облегчает работу разработчиков по конфигурации WCF-служб.
Улучшения в потоковой передаче данных
Добавлена поддержка истинной асинхронной потоковой передачи, когда отправляющая сторона не блокирует потоки в случае, если принимающая сторона не считывает или считывает медленно, таким образом увеличивая масштабируемость решений. Снято ограничение буферизации сообщений, когда клиент отправляет потоковое сообщение службе WCF, размещенной на веб-сервере служб IIS. Дополнительные сведения см. в разделе функции упрощения WCF.
Упрощено предоставление доступа к конечной точке по протоколу HTTPS в службах IIS
Было добавлено сопоставление протокола HTTPS для упрощения предоставления доступа к конечной точке по протоколу HTTPS. Чтобы включить конечную точку HTTPS, убедитесь, что веб-сайт имеет привязку HTTPS и настроенный SSL-сертификат, а затем просто включите HTTPS для виртуального каталога, в котором размещается служба. Если для службы включены метаданные, то доступ к ней будет также предоставлен по протоколу HTTPS.
Создание одного документа WSDL
Некоторые стеки обработки WSDL от сторонних производителей не могут обрабатывать документы WSDL, которые имеют зависимости от других документов посредством xsd:import. WCF теперь позволяет указывать, что все данные WSDL должны быть возвращены в одном документе. Чтобы запросить один документ WSDL, добавьте «? Синглевсдл» в универсальный код ресурса (URI) при запросе метаданных из службы.
Поддержка WebSocket
Новые значения по умолчанию для свойств транспорта
В следующей таблице описываются измененные настройки и разделы, в которых можно найти дополнительные сведения.
| Свойство | Включено | Новое значение по умолчанию | Дополнительные сведения см. в разделе |
|---|---|---|---|
| channelInitializationTimeout | NetTcpBinding | 30 секунд | ChannelInitializationTimeout |
| listenBacklog | NetTcpBinding | 12 * количество процессоров | ListenBacklog |
| maxPendingAccepts | ConnectionOrientedTransportBindingElement SMSvcHost.exe | 2 * количество процессоров для транспорта 4 * число процессоров для SMSvcHost.exe | MaxPendingAccepts Настройка службы совместного использования портов Net.TCP |
| maxPendingConnections | ConnectionOrientedTransportBindingElement | 12 * количество процессоров | MaxPendingConnections |
| receiveTimeout | SMSvcHost.exe | 30 секунд | Настройка службы совместного использования портов Net.TCP |
Подсказки в редакторе XML
В XML-редакторе Visual Studio отображаются подсказки для каждого элемента конфигурации (и его свойств), входящего в файл конфигурации службы. Это облегчает работу разработчиков по конфигурации WCF-служб.
Настройка служб WCF в коде
Кэширование ChannelFactory
Клиентские приложения WCF используют класс ChannelFactory для создания коммуникационного канала со службой WCF. Создание экземпляров класса ChannelFactory оказывает определенное влияние на производительность, поскольку выполняются следующие операции:
Отображение всех необходимых типов CLR
Построение стека каналов
Чтобы уменьшить дополнительные расходы ресурсов, WCF может кэшировать фабрики каналов при использовании прокси клиента WCF. Дополнительные сведения см. в статье фабрика каналов и кэширование.
Сжатие и двоичный кодировщик
Начиная с версии WCF 4.5, в двоичном кодировщике появилась поддержка сжатия. Тип сжатия задается с помощью свойства CompressionFormat. Свойство CompressionFormat должно быть задано и в клиенте и в службе. Сжатие будет работать для протоколов HTTP, HTTPS и TCP. Если клиент указывает использование сжатия, но служба его не поддерживает, возникает исключение протокола, указывающее на несоответствие. Дополнительные сведения см. в разделе Выбор кодировщика сообщений.
Добавлена поддержка для транспорта UDP, который позволяет разработчикам писать службы, использующие «пожар и забыть» сообщения. Клиент отправляет сообщение службе, но не ожидает от нее ответа.
Поддержка нескольких видов проверок подлинности
Была добавлена поддержка нескольких режимов проверок подлинности, поддерживаемых службами IIS, в одной конечной точке WCF при использовании транспорта HTTP и безопасности транспорта. Служба IIS позволяет включить несколько режимов проверки подлинности в виртуальном каталоге. Эта возможность позволяет одной конечной точке WCF поддерживать несколько режимов проверки подлинности, разрешенных для виртуального каталога, в котором размещена служба WCF.
Поддержка IDN
Добавлена поддержка служб WCF с интернационализированными именами домена (IDN). Дополнительные сведения см. в разделе WCF и международные доменные имена.
HttpClient
Был добавлен новый класс HttpClient, существенного облегчающий работу с HTTP-запросами. Дополнительные сведения см. в статье Создание приложений в социальных сетях и подключение к службам HTTP.
Настройка IntelliSense
Значения атрибутов в файлах конфигурации для настраиваемых атрибутов, определенных в проекте, теперь поддерживают IntelliSense для быстрого и точного упрощения работы с конфигурациями.
Всплывающие подсказки в файлах конфигурации
Элементы и атрибуты WCF теперь имеют подсказки в редакторе XML, что упрощает и точно определяет назначение элемента или атрибута.
Вставка данных в виде классов
WebServiceHost и конечные точки по умолчанию.
В Visual Studio 2010 WebServiceHost автоматически создавал конечную точку по умолчанию независимо от того, была она явно указана или нет. в Visual Studio 2012 и более поздних версиях класс servicehost создает конечную точку по умолчанию только в том случае, если конечные точки явно не добавлены. Если клиент ожидает конечную точку по умолчанию, можно явно добавить конечную точку и указать клиенту на нее. Кроме того, можно вернуть прежнее поведение WCF, добавив следующий параметр в файл конфигурации приложения.
IHttpCookieContainerManager
Затем можно получать или устанавливать куки-файлы из CookieContainer. Когда свойство AllowCookies имеет значение false, куки-файл можно получить вручную с помощью OperationContext и отправить его запросом с помощью другого OperationContext или средства проверки сообщений. Интерфейс IHttpCookieContainerManager позволяет выполнить проверку подлинности пользователя для службы и использовать куки-файл, возвращенный службой, для проверки подлинности в других службах.
Действительно прозрачное использование WCF
Мотивация
По крайней мере, так должно быть. На практике добавление нового сервиса — это рутина. Нужно не забыть прописать конфигурацию на сервере, сделать то же самое на клиенте, нужно написать или сгенерировать proxy-класс. Поддерживать конфиги неудобно. Если сервис изменился, то нужно вносить изменения в proxy-класс. А ещё не забыть про регистрации в IoC-контейнере. И добавление новых хостов для новых сервисов. И еще хочется простой асинхронности. По отдельности всё просто, но даже для статьи я дописывал этот список уже трижды, и не уверен, что не упустил чего-нибудь.
Quick start
Создадим клиент-серверное приложение. Клиенты передают серверу индекс числа из последовательности Фибоначчи, сервер возвращает число из последовательности с заданным индексом. Из кода в статье убрано логирование и обработка ошибок, но в коде на github я привожу более полный пример для иллюстрации целостного подхода.
Структура проектов, приближенная к реальности:
Server.Contracts содержит интерфейсы wcf-сервисов, Server — их реализацию, а так же реализацию хостера — класса, который будет поднимать wcf-сервисы. BL — логика сервера. ConsoleServiceHost хостит сервисы в домене консольного приложения. Client.Presentaion содержит соответствующий слой клиента. В нашем примере там только команда вызова сервиса и обработка результата. Client — консольное приложение, использующее предыдущую сборку для обработки ввода пользователя.
Реализация в CalculatorService.cs будет передавать запрос и возвращать результат из слоя бизнес-логики:
Пока можно заметить одну особенность — wcf-сервис использует async/await для описания асинхронности. В остальном никаких специфических конструкций нет.
Теперь перейдем к регистрации. Простейший синтаксис для сервера указывает тип привязки (NetTcp) список поведений, которые должны быть добавлены к сервисам:
Для клиента указывается тип обёртки-исполнителя для сервисов (ServiceExecutor), тип обёртки над привязкой (Standart предполагает NetTcp) и, собственно, адрес сервера:
Всё. Не нужно регистрировать каждый сервис по интерфейсу, не нужно создавать Proxy, не нужно прописывать wcf в конфигурации — эти регистрации позволят сразу начать работать с сервисами так, будто это локальные вызовы.
Но сначала нужно захостить их на сервере. Библиотека Rikrop.Core.Wcf уже включает класс ServiceHostManager, который сделает всю работу самостоятельно. Прописывать каждый сервис не нужно:
Сравнение с классическим подходом и расширяемость
Может показаться, что предложенное решение требует довольно много инфраструктурного кода и не несёт преимуществ перед обычным использованием wcf. Проще всего будет показать разницу на примере типовых ситуаций, возникающих при работе над проектами.
Добавление нового метода в существующий wcf-сервис или изменение сигнатуры существующего метода
Добавление нового wcf-сервиса в существующий хост
Изменение настроек всех wcf-сервисов (на примере типа привязки)
Изменение настроек нескольких wcf-сервисов (на примере типа привязки)
Расширяемость. Behavior для авторизации и работы с сессиями
Расширение функциональности и изменение поведения происходит за счёт добавления при регистрации Behavior. Наиболее частым в применении является поведение, отвечающее за передачу в заголовке wcf-сообщения информации о сессии.
Для демонстрации функционала был создан отдельный branch с расширенным кодом предыдущего примера. В стандартной настройке поведения разработчику предлагается выбрать метод авторизации — это OperationContract, который будет доступен пользователям без сессии в заголовке сообщения. Вызов остальных методов будет возможен только при заполненном заголовке.
Регистрация на сервере будет выглядеть следующим образом:
Можно изменить способ авторизации, добавив свою имплементацию System.ServiceModel.ServiceAuthorizationManager, изменить способ инициализации идентификатора сессии, метод проверки авторизации, способ извлечения сессии из контекста выполнения запроса, способ хранения и копирования сессий на сервере. В обобщенном случае регистрация AuthorizationBehavior может выглядеть следующим образом:
Клиентская регистрация так же меняется:
Алгоритм работы
Что внутри
Большую часть инфраструктуры предоставляет библиотека System.ServiceModel.dll. Однако, есть несколько решений, которые нужно рассмотреть подробнее.
Основой взаимодействия между клиентом и сервером служат реализации интерфейса IServiceExecutor, находящиеся в библиотеке Rikrop.Core.Wcf.
В простейшем случае открывается канал и метод вызывается в контексте этого канала:
Более сложные реализации могут конвертировать ошибки или дополнительно извещать об окончании обработки изменением свойства. Наибольшее распространение эти идеи получили в WPF-реализациях IServiceExecutor, где с помощью ServiceExecutorFactory можно создать обёртки над wcf-сервисом, позволяющие использовать DataBinding для оповещения UI о продолжительной операции, или отображающие popup с произвольной информацией во время ожидания ответа от сервера.
Для легкой реализации главную роль играют Fluent interface при регистрации и стандартные реализации инфраструктуры библиотеки, из-за чего даже даже в самых сложных конструкциях легко разобраться с первого раза с помощью подскзок студии:
Итоги
Единожды настроив инфраструктуру на проекте, можно надолго забыть о сетевой природе взаимодействия через IServiceExexutor. Лучше всего применять системный подход и использовать так же бибилиотки для построения настольных приложений с применением mvvm-паттерна, взаимодействия с БД, логирования и других типовых задач. Но даже при нежелании использовать незнакомый и не всегда привычный фреймворк, можно найти применение идеям, лежащим в его основе. Расширяемость компонент, строгая типизация при конфигурировании, прозрачность взаимодействия на всех слоях, минимизация инфраструктурного кода и затрат времени на поддержание инфрастурктуры — это то, о чём важно не забывать при написании калькулятора и многопользовательской Enterprise-системы. Можно скачать код библиотек и подключить их к решению проектом вместо использования библиотеки. Это позволит изучить работу под отладчиком и при необходимости внести свои изменения.
Бонус
Еще есть решение для wpf с информированием пользователя через блокировку ui или всплывающие окна, реализованные через ServiceExecutorFactory. Это частный пример и он относится куда больше к wpf, чем к wcf. Но это может дать больше информации о преимуществах библиотеки и мотивации к использованию.
Использование сеансов
в приложениях Windows Communication Foundation (WCF) сеанс сопоставляет группу сообщений с диалогом. сеансы WCF отличаются от объектов сеансов, доступных в ASP.NET приложениях, поддерживают различные поведения и управляются различными способами. В этом разделе описываются функции, которые сеансы включают в приложениях WCF, и способы их использования.
Сеансы в приложениях Windows Communication Foundation
Если в контракте службы указано, что для него требуется сеанс, это означает, что все вызовы (т. е. обмен сообщениями, на котором он основан) должны быть частью одного диалога. Если в контракте указано, что сеансы для него разрешены, но не требуются, клиенты могут подключаться, создавая сеанс или не создавая его. Если сеанс завершен и по его каналу отправляется сообщение, выдается исключение.
Сеансы WCF имеют следующие основные концептуальные функции:
Они явным образом инициируются и завершаются вызвавшим приложением (клиентом WCF).
Сообщения, доставленные в ходе сеанса, обрабатываются в порядке их получения.
Нет общего хранилища данных, связанного с сеансом WCF.
если вы знакомы с System.Web.SessionState.HttpSessionState классом в ASP.NET приложениях и предоставляемых им функциях, вы можете заметить следующие различия между этим видом сеанса и сеансами WCF:
ASP.NET сеансы всегда инициируются сервером.
сеансы ASP.NET неявно неупорядочены.
ASP.NET сеансы предоставляют общий механизм хранения данных для запросов.
Содержание этого раздела:
Поведение выполнения по умолчанию при использовании привязок, основанных на сеансе, в уровне модели службы.
Типы функций, предоставляемых системными привязками, основанными на сеансах WCF.
Создание контракта, объявляющего требование сеанса.
Управление созданием и прекращением сеанса и его связью с экземпляром службы.
Поведение выполнения по умолчанию с использованием сеансов
Когда служба WCF принимает сеанс клиента, по умолчанию включаются следующие функции.
Все вызовы между объектом клиента WCF обрабатываются одним и тем же экземпляром службы.
Различные привязки на основе сеанса предоставляют дополнительные возможности.
Типы сеансов, предоставляемые системой
Привязка, основанная на сеансе, поддерживает ассоциацию по умолчанию экземпляра службы с определенным сеансом. Впрочем, различные привязки, основанные на сеансе, поддерживают и другие различные функции, помимо описанного выше управления созданием экземпляров на основе сеанса.
WCF предоставляет следующие типы поведения приложений на основе сеансов:
Привязка System.ServiceModel.NetTcpBinding поддерживает сеансы, основанные на TCP/IP, что обеспечивает корреляцию всех сообщений по подключению на уровне сокетов.
Привязка System.ServiceModel.NetMsmqBinding обеспечивает сеансы датаграммы MSMQ. Дополнительные сведения см. в разделе очереди в WCF.
Установка свойства SessionMode указывает о том, что для контракта требуется сеанс, но не задает тип этого сеанса.
Создание контракта, требующего сеанс
Клиенту допускается создавать сеанс.
Если сеанс разрешен службой, он создается и используется, если он инициирован клиентом. В противном случае сеанс не создается.
Сеансы и экземпляры служб
При использовании поведения создания экземпляров по умолчанию в WCF все вызовы между объектом клиента WCF обрабатываются одним и тем же экземпляром службы. Таким образом, на уровне приложения можно считать, что сеанс обеспечивает поведение приложений, аналогичное поведению местных вызовов. Например, при создании локального объекта происходит следующее:
Все последующие вызовы к клиентской ссылке на объект WCF обрабатываются одним и тем же экземпляром объекта.
Деструктор вызывается при уничтожении ссылки на объект.
Завершающие операции— это, соответственно, операции, вызываемые как последние сообщения существующих сеансов. В случае по умолчанию WCF повторно использует объект службы и его контекст после закрытия сеанса, с которым была связана эта служба. Поэтому можно создать некоторое подобие деструктора, объявив завершающие операции, которые выполняют функции по завершению действия экземпляра службы.
Поведение по умолчанию имеет сходство с локальными конструкторами и деструкторами, но это не более чем сходство. Любая операция службы WCF может быть инициированной или завершающей операцией одновременно. Кроме того, в случае по умолчанию инициирующие операции можно вызывать сколько угодно раз и в любом порядке. После того как сеанс установлен и связан с экземпляром, дополнительные сеансы могут быть созданы только в случае осуществления явным образом управления временем существования экземпляра службы (путем обработки объекта System.ServiceModel.InstanceContext ). И наконец, состояние связывается с сеансом, а не с объектом службы.
Службы не начинают сеансы с клиентами. В клиентских приложениях WCF существует прямая связь между временем существования канала на основе сеанса и временем существования самого сеанса. Таким образом, клиенты создают новые сеансы путем создания новых каналов, основанных на сеансах, и прерывают существующие сеансы путем правильного закрытия этих каналов. Клиент начинает сеанс с конечной точкой службы путем вызова одной из следующих операций:
Операция инициирования для любого типа клиентского объекта WCF (по умолчанию инициируются все операции). При вызове первой операции клиентский объект WCF автоматически открывает канал и инициирует сеанс.
Обычно клиент завершает сеанс с конечной точкой службы путем вызова одной из следующих операций:
Завершающая операция для любого типа клиентского объекта WCF (по умолчанию никакие операции не завершаются; контракт должен явно указать завершающую операцию). При вызове первой операции клиентский объект WCF автоматически открывает канал и инициирует сеанс.
Дополнительные сведения о клиентах и сеансах см. в разделе доступ к службам с помощью клиента WCF.
Сеансы взаимодействуют с параметрами InstanceContext
Совместное использование объектов InstanceContext
Также можно задать для каждого вызова или канала, основанного на сеансе, с каким именно объектом InstanceContext он будет ассоциирован, самостоятельно назначив ассоциацию.
Сеансы и потоковая передача
Свойство MaxConcurrentSessions в данном случае ни на что не влияет, поскольку имеется всего один сеанс.