Wcf services что это
Что такое Windows Communication Foundation
Windows Communication Foundation (WCF) — это платформа для создания приложений, ориентированных на службы. С помощью WCF можно передавать данные в виде асинхронных сообщений из одной конечной точки службы в другую. Конечная точка службы может входить в постоянно доступную службу, размещаемую в IIS, или представлять службу, размещаемую в приложении. Конечная точка может быть клиентом службы, которая запрашивает данные от конечной точки службы. Сообщения могут представлять одиночный символ или одно слово, отправляемое в формате XML, или иметь вид сложного потока двоичных данных. Далее представлено несколько образцов сценариев.
Защищенная служба для обработки бизнес-транзакций.
Служба, передающая другим объектам текущие данные, такие как отчет о трафике, или другая служба наблюдения.
Служба бесед, которая позволяет двум пользователям общаться и обмениваться данными в реальном времени.
Приложение панели мониторинга, которая опрашивает одну или несколько служб и дает логическое представление полученных данных.
Предоставление доступа к рабочему процессу, реализованному с помощью Windows Workflow Foundation, в виде службы WCF.
Приложение Silverlight для запроса последних каналов данных в службе.
Хотя создание таких приложений было возможным до появления WCF, WCF упрощает разработку конечных точек, чем когда-либо. В целом, WCF призвана обеспечить управляемый подход к созданию веб-служб и клиентов веб-служб.
Возможности WCF
В состав WCF входит следующий набор функций. Дополнительные сведения см. в разделе сведения о функции WCF.
Сервис-ориентированность
Совместимость
WCF реализует современные отраслевые стандарты для взаимодействия веб-служб. Дополнительные сведения о поддерживаемых стандартах см. в статье взаимодействие и интеграция.
Несколько шаблонов сообщений
Обмен сообщениями выполняется по одному из нескольких шаблонов. Чаще всего используется шаблон «запрос-ответ», когда одна конечная точка запрашивает данные от другой конечной точки. Вторая конечная точка отвечает. Существуют и другие шаблоны, например одностороннее сообщение, когда одна конечная точка отправляет сообщение, не ожидая ответа. Более сложным является шаблон дуплексного обмена, когда две конечные точки устанавливают соединение и отправляют данные в обоих направлениях подобно программе обмена мгновенными сообщениями. Дополнительные сведения о реализации различных шаблонов обмена сообщениями с помощью WCF см. в разделе контракты.
Метаданные службы
WCF поддерживает публикацию метаданных службы с использованием форматов, указанных в отраслевых стандартах, таких как WSDL, XML Schema и WS-Policy. Эти метаданные можно использовать для автоматического создания и настройки клиентов для доступа к службам WCF. Метаданные могут публиковаться через HTTP и HTTPS или с использованием стандарта обмена метаданными веб-служб. Дополнительные сведения см. в разделе Метаданные.
Контракты данных
Безопасность
Сообщения можно шифровать для защиты конфиденциальности и требовать от пользователей проходить проверку подлинности перед приемом сообщений. Можно реализовать широко известные стандарты безопасности, такие как SSL и WS-SecureConversation. Дополнительные сведения см. в статье Безопасность.
Несколько транспортов и кодировок
Сообщения могут отправляться по любому из нескольких встроенных транспортных протоколов в различных кодировках. Наиболее распространенный протокол и кодировка — это отправка сообщений SOAP, закодированных в виде текста, с использованием протокола HTTP для использования в Интернете. Кроме того, WCF позволяет отсылать сообщения по протоколу TCP, именованным каналам или MSMQ. Сообщения можно кодировать в виде текста или использовать оптимизированный двоичный формат. Двоичные данные можно эффективно отправлять с использованием стандарта MTOM. Если ни один из предоставляемых транспортов и кодировок не подходит к текущим требованиям, вы можете создать собственный пользовательский транспорт или кодировку. Дополнительные сведения о транспортах и кодировках, поддерживаемых WCF, см. в статье транспорты.
Надежные сообщения и сообщения в очереди
WCF поддерживает надежный обмен сообщениями, используя надежные сеансы, реализованные с помощью WS-Reliable обмена сообщениями и MSMQ. Дополнительные сведения о поддержке надежных и очередных сообщений в WCF см. в статье очереди и надежные сеансы.
Устойчивые сообщения
Устойчивые сообщения не теряются в случае перебоев связи. Сообщения, передаваемые по устойчивому шаблону, всегда сохраняются в базе данных. Если происходит перебой связи, база данных позволяет возобновить обмен сообщениями после восстановления соединения. вы также можете создать устойчивое сообщение с помощью Windows Workflow Foundation (WF). Дополнительные сведения см. в разделе службы рабочих процессов.
Транзакции
WCF также поддерживает транзакции с использованием одной из трех моделей транзакций: WS-Атомиктрансактионс, API-интерфейсы в System.Transactions пространстве имен и Microsoft координатор распределенных транзакций. Дополнительные сведения о поддержке транзакций в WCF см. в разделе транзакции.
Поддержка AJAX и REST
Расширяемость
Архитектура WCF имеет ряд точек расширения. Если требуются дополнительные возможности, поддерживаются точки входа, посредством которых можно настроить поведение службы. Дополнительные сведения о доступных точках расширения см. в разделе Расширение WCF.
Интеграция WCF с другими технологиями Майкрософт
WCF — это гибкая платформа. Из-за такой крайней гибкости WCF также используется в нескольких других продуктах Майкрософт. Зная основы WCF, вы получаете мгновенное преимущество, если вы также используете любой из этих продуктов.
первая технология, связанная с WCF, была Windows Workflow Foundationом (WF). Рабочие процессы упрощают разработку приложений, инкапсулирующие шаги в рабочем процессе как «действия». в первой версии Windows Workflow Foundation разработчику пришлось создавать узел для рабочего процесса. следующая версия Windows Workflow Foundation была интегрирована с WCF. Это позволяло легко размещать любой рабочий процесс в службе WCF. это можно сделать, автоматически выбрав тип проекта WF/WCF в Visual Studio 2012 или более поздней версии.
Microsoft BizTalk Server R2 также использует WCF в качестве коммуникационной технологии. BizTalk предназначен для получения и преобразования данных из одного стандартного формата в другой. Сообщения должны доставляться в центральный ящик, где сообщение может преобразовываться по строгому сопоставления или с использованием одной из функций BizTalk, таких как подсистема рабочих процессов. Теперь BizTalk может использовать бизнес-адаптер WCF для доставки сообщений в окно сообщения.
Платформа Microsoft Silverlight предназначена для создания многофункциональных веб-приложений широкой совместимости и дает разработчикам возможность создавать веб-узлы, интенсивно использующие мультимедиа-функции (например, потоковое видео). Начиная с версии 2, Silverlight внедряет WCF в качестве технологии связи для подключения приложений Silverlight к конечным точкам WCF.
возможности размещения сервера приложений Windows server AppFabric специально разработаны для развертывания приложений, использующих WCF для обмена данными, и управления ими. Функции размещения включают разнообразные средства и параметры конфигурации, специально разработанные для приложений с поддержкой WCF.
Общие сведения о службах рабочих процессов
Службы рабочих процессов — это службы на основе WCF, которые реализуются с помощью рабочих процессов. службы рабочих процессов — это рабочие процессы, которые используют действия обмена сообщениями для отправки и получения сообщений Windows Communication Foundation (WCF). В.NET Framework 4.5 появилось несколько действий обмена сообщениями, позволяющих отправлять и получать сообщения из рабочего процесса. Дополнительные сведения о действиях обмена сообщениями и о том, как их можно использовать для реализации различных шаблонов обмена сообщениями, см. в разделе действия обменасообщениями.
Преимущества использования служб рабочих процессов
По мере возрастания распределения приложений отдельные службы становятся ответственными за вызов других служб для передачи им некоторой части работы. Реализация таких вызовов в виде асинхронных операций в коде представляет некоторую сложность. Обработка ошибок добавляет некоторую сложность в форме обработки исключений и обеспечения подробных сведений об отслеживании. Довольно часто некоторые службы являются длительными и занимают ценные системные ресурсы при ожидании ввода. Вследствие этих причин распределенные приложения часто являются очень сложными и их трудно разрабатывать и поддерживать. Рабочие процессы являются естественным способом координации асинхронной работы, особенно вызовов внешних служб. Рабочие процессы также достаточно эффективны при представлении длительных бизнес-процессов. Эти качества делают рабочий процесс великолепным активом для построения служб в распределенной среде.
Реализация службы рабочего процесса
При реализации службы WCF вы определяете несколько контрактов, описывающих службу и данные, которые она отправляет и получает. Данные, представленные в виде контрактов данных и сообщений. Службы WCF и службы рабочих процессов используют контракты данных и определения контрактов сообщений как часть описаний служб. Служба сама предоставляет метаданные (в форме WSDL) для описания операций службы. В WCF контракты службы и операций определяют службу и операции, которые она поддерживает. Однако в службе рабочего процесса эти контракты являются частью самого бизнес-процесса. Они поставляются в метаданные процессом, называемым выводом контракта. При размещении службы рабочего процесса с использованием WorkflowServiceHost просматривается определение рабочего процесса и формируется контракт на основе набора действий по отправке и получению сообщений, обнаруженных в рабочем процессе. В частности, для создания контракта используются следующие действия и свойства:
Конечным результатом вывода контракта является описание службы, использующее те же структуры данных, что и службы WCF и контракты операций. Затем эти сведения используются для предоставления WSDL для службы рабочего процесса.
.NET Framework 4.6.1 не позволяет писать службы рабочего процесса с использованием существующего определения контракта без дополнительных средств разработки. Контракты служб рабочих процессов создаются посредством процесса вывода, который был рассмотрен ранее. Контракты сообщений и данных, тем не менее, полностью поддерживаются.
Службы рабочих процессов и привязки на основе MSMQ
Размещение службы рабочего процесса
Как и службы WCF, необходимо размещать службы рабочих процессов. Службы WCF используют ServiceHost класс для размещения служб и служб рабочих процессов, используемых WorkflowServiceHost для размещения служб. Как и службы WCF, службы рабочих процессов могут размещаться различными способами, например:
в управляемой службе Windows.
Windows Communication Foundation (WCF) служба
Давайте рассмотрим процесс создания и вызова службы WCF.
Создание службы WCF
Для начала необходимо создать новый проект WCF. Пусть наша Windows Communication Foundation служба будет возвращать количество оставшихся дней до нового года.
Visual studio создаст интерфейс и класс службы по умолчанию с именем IService1.cs и Service1.svc.
Нам необходимо переименовать их в соответствии с нашей предметной областью.
Давайте рассмотрим интерфейс INewYearService. Для начала нам необходимо в теле интерфейса объявить метод, который будет предоставлять служба для вызова. Для этого его необходимо пометить атрибутом [OperationContract].
Как вы видите данный метод возвращает экземпляр класса TimeToNewYear. Это вспомогательный класс, содержащий значения времени до нового года. Ниже приведена его структура. Для того, чтобы данный класс можно было использовать в качестве возвращаемого аргумента, его необходимо пометить атрибутом [DataContract], а свойства, доступные для чтения клиенту в возвращаемом значении помечаются атрибутом [DataMember].
Теперь нам остается реализовать интерфейс Windows Communication Foundation службы в классе NewYearService.svc.cs следующим образом:
Давайте проверим работу нашей службы wcf. Для этого нажмем кнопку Начать отладку. Обратите внимание, что возможные два варианта поведения системы. Если мы начнем отладку находясь в NewYearService.svc, от откроется отладчик службы. Во всех остальных случаях откроется окно браузера. Давайте рассмотрим каждый из вариантов подробнее.
Браузер
После запуска отладки отобразится браузер с файловой структурой нашей службы wcf.
Нам необходимо нажать на ссылку с именем нашей службы NewYearService.svc. Если все работает корректно, то мы увидим следующее окно, иначе будет показано сообщение с ошибкой.
Тестовый клиент WCF
В левой верхней части отладчика можно увидеть структура нашей службы wcf. Для проверки нашего метода выполним двойной щелчок левой кнопкой мыши по его имени. В правой части отладчика откроется форма запроса. Мы можем указать значение, которое будет передано в метод.
После установки передаваемых значений необходимо нажать кнопку Вызвать. Появится предупредительное сообщение. Можно смело ставить галочку Не выводить это сообщение в дальнейшем и нажимать кнопку ОК.
После этого в нижней правой части отладчика будет отображены значения возвращаемые нашей службой wcf.
Консольный клиент для WCF
Теперь нам необходимо создать клиент, который будет обращаться к нашей службе wcf. Для этого для начала создадим новое консольное приложение.
В созданном консольном приложении нам необходимо добавить ссылку на службу wcf.
В открывшимся окне службы необходимо указать имя службы wcf и ввести ее адрес.
Для простоты можно нажать кнопку Найти, тогда адрес службы wcf будет определен автоматически.
После этого необходимо развернуть дерево Windows Communication Foundation службы, чтобы удостоверится что выбран правильность выбора. В правой части должен быть отображен вызываемый метод.
Если настройка прошла корректно, то в обозревателе решения в консольном приложении отобразится ссылка на нашу службу wcf.
Теперь нам остается только обратиться к нашей службе, чтобы взывать метод и вывести результат на экран.
Перед началом отладки не забудьте установить консольное приложение автозагружаемым проектом. Получаем следующий результат.
Web клиент для WCF
Теперь рассмотрим, как нам обратиться к службе wcf из веб-приложения. Процесс подключения службы не отличается от подключения в консольном приложении. Давайте рассмотрим как можно настроить авторизацию с помощью Windows. Это потребует дополнительной настройки приложения. Для начала создадим проект нового MVC приложения.
Нажимаем кнопку ОК, и попадаем в меню настройки создания веб-приложения. Выберем MVC шаблон и изменим способ авторизации. Для этого нажмем на кнопку Изменить способ проверки подлинности.
Выбираем авторизацию с помощью Windows и нажимаем ОК в обоих окнах.
Теперь необходимо будет подождать кое-то время, чтобы создался проект и все библиотеки были загружены и подключены.
Для того, чтобы IISExpres перестала ругаться на нас за попытку создания windows-аутентификации нужно сделать ряд действий в наше службе.
Нужно дополнить наш web.config
Находим раздел и в нем вставляем следующее.
Далее нужно указать разделы биндинг и сервис
Раздел дополняем такой вот строчкой. В ней мы говорим, что именно такая схема аутентификации будет использоваться у нас.
На этом настройка web.config заканчивается. В итоге у нас должен получиться файл примерно следующего содержания.
Настройка applicationhost.config
Далее идем в папку vs нашего проекта (она скрыта по умолчанию). В ней ищем папку config, а уже в ней находим файл applicationhost.config, его то нам нужно будет поправить.
Находим вот такой раздел. Все Deny меняем на Allow, разрешая изменение установленного по умолчанию режима аутентификации.
Далее находим данную настройку. В ней false меняем на true, разрешая механизму работать.
И под конец находим вот эту настройку. Тут мы true меняем на false. Говоря нашему IISExpres, чтобы он не блокировал службу windows-аутентификации.
После этого сохраняем все конфигурационные файлы и пробуем сделать ссылку на службу wcf аналогично как при добавлении службы в консольное приложение.
Изменим контроллер главной страницы web-приложения, чтобы взывать нашу службу wcf.
Теперь нам осталось только изменить представление, чтобы вывести результат работы Windows Communication Foundation службы на экран пользователя.
Получаем следующий результат работы веб-приложения.
Итоги WCF
Исходный код приложения можно скачать из репозитория https://github.com/shwanoff/wcf.
Мы подробно рассмотрели процесс создания и настройки Windows Communication Foundation службы, а также продемонстрировали как можно подключится к wcf через консольное и веб-приложение. Также рекомендую прочитать статью Принципы SOLID C#. И не забудьте подписывайтесь на группу ВКонтакте, Telegram и YouTube-канал. Там еще больше полезного и интересного для программистов.
Практическое руководство. Размещение службы WCF в управляемой службе Windows
в этом разделе описаны основные шаги, необходимые для создания службы Windows Communication Foundation (WCF), размещенной в службе Windows. этот сценарий включается параметром размещения управляемой службы Windows, который является длительно запущенной службой WCF, размещенной за пределами службы IIS (IIS) в безопасной среде, которая не является активируемой сообщением. Вместо этого время существования службы контролируется операционной системой. Данный вариант размещения доступен во всех версиях Windows.
Службами Windows можно управлять при помощи Microsoft.ManagementConsole.SnapIn в консоли управления (MMC) и можно настроить их автоматический запуск при загрузке системы. этот вариант размещения состоит из регистрации домена приложения (AppDomain), в котором размещена служба WCF, в качестве управляемой службы Windows, чтобы время существования процесса службы управлялось диспетчером управления службами (SCM) для служб Windows services.
Создание службы и предоставление кода размещения
создайте новый проект консольного приложения Visual Studio с именем Service.
Измените имя файла Program.cs на Service.cs.
Добавьте ссылки на следующие сборки:
Добавьте следующие операторы using в файл Service.cs.
Переопределите метод OnStart(String[]), создав и открыв новый экземпляр ServiceHost, как показано в следующем коде.
Переопределите метод OnStop, закрывающий ServiceHost, как показано в следующем коде.
Добавьте в проект файл конфигурации приложения. Замените содержимое этого файла следующим XML-кодом конфигурации.
Щелкните правой кнопкой мыши файл App.config в Обозреватель решений и выберите пункт свойства. В разделе Копировать в выходной каталог выберите Копировать, если новее.
Установка и запуск службы
Пример
Ниже приведен полный список кода, используемого в этом разделе.
Как и в случае резидентного размещения, среда размещения службы Windows требует, чтобы код размещения являлся частью приложения. Служба реализуется как консольное приложение и содержит собственный код размещения. В других средах размещения, таких как служба активации Windows (WAS), размещающих в IIS, писать код размещения необязательно.
Основные понятия Windows Communication Foundation
в этом документе представлено высокоуровневое представление архитектуры Windows Communication Foundation (WCF). В нем приводится объяснение ключевых понятий и их взаимосвязь. Руководство по созданию простейшей версии службы WCF и клиента см. в руководстве по начало работы. Дополнительные сведения о программировании WCF см. в разделе Базовая программирование WCF.
Основы WCF
WCF — это среда выполнения и набор интерфейсов API для создания систем, отправляющих сообщения между службами и клиентами. Те же инфраструктура и интерфейсы API используются для создания приложений, обменивающихся данными с другими приложениями на данном компьютере или на компьютере, который находится в другой компании, и доступ к которому можно получить через Интернет.
Обмен сообщениями и конечные точки
WCF основана на концепции связи на основе сообщений, и все, что может быть смоделировано как сообщение (например, HTTP-запрос или сообщение MSMQ), могут быть представлены единообразно в модели программирования. Это обеспечивает универсальный интерфейс API для разных транспортных механизмов.
Модель различает Клиенты, которые являются приложениями, которые инициируют связь, и службами, которые представляют собой приложения, которые ожидают от клиентов взаимодействовать с ними и реагируют на это взаимодействие. Одно приложение может быть как клиентом, так и службой. Примеры см. в разделе Дуплексные службы и одноранговые сети.
Между конечными точками выполняется обмен сообщениями. Конечные точки — это места, куда отправляются или принимаются сообщения (или и те, и другие), и определяются все сведения, необходимые для обмена сообщениями. Служба предоставляет одну или несколько конечных точек приложения (а также ноль или более конечных точек инфраструктуры), а клиент создает конечную точку, совместимую с одной из конечных точек службы.
Конечная точка описывает стандартный способ отправки сообщений, способ их отправки и то, как должны выглядеть сообщения. Служба может предоставлять эти сведения в виде метаданных, которые клиенты могут обрабатывать для создания соответствующих клиентов WCF и стеков связи.
Протоколы связи
Одним из обязательных элементов стека связи является транспортный протокол. Сообщения можно отправлять через интрасети или через Интернет с помощью общих транспортов, таких как HTTP и TCP. Предусмотрены другие транспорты, поддерживающие связь с приложениями очереди сообщений и узлами в сетке одноранговой сети. Дополнительные механизмы транспорта можно добавить с помощью встроенных точек расширения WCF.
Другим обязательным элементом стека связи является кодирование, определяющее способ форматирования любого заданного сообщения. WCF предоставляет следующие кодировки:
двоичное кодирование для эффективной передачи.
Дополнительные механизмы кодирования (например, кодирование сжатия) можно добавить с помощью встроенных точек расширения WCF.
Шаблоны сообщений
WCF поддерживает несколько шаблонов обмена сообщениями, включая запрос-ответ, односторонний и дуплексную связь. Разные транспорты поддерживают разные шаблоны обмена сообщениями и таким образом влияют на типы поддерживаемых взаимодействий. Интерфейсы API и среда выполнения WCF также позволяют безопасно и надежно отсылать сообщения.
Термины WCF
Другие понятия и термины, используемые в документации по WCF, включают следующее:
Message
Автономная единица данных, которая может состоять из нескольких частей, включая текст и заголовки.
Служба
Конструкция, предоставляющая доступ к одной или нескольким конечным точкам, каждая из которых предоставляет доступ к одой или нескольким операциям службы.
Конечная точка
Конструкция, в которой производится отправка или прием сообщений. Он включает в себя расположение (адрес), которое определяет, где можно отправлять сообщения, спецификацию механизма связи (привязка), который описывает, как следует отправлять сообщения, и определение набора сообщений, которые могут быть отправлены или получены (или оба) в этом расположении (контракт службы), описывающего сообщение, которое может быть отправлено.
Служба WCF видима внешнему миру как коллекция конечных точек.
Конечная точка приложения
Конечная точка, предоставляемая приложением и соответствующая контракту службы, реализуемому приложением.
Конечная точка инфраструктуры
Конечная точка, предоставляемая инфраструктурой для расширения функциональных возможностей, необходимых для службы или предоставляемых службой и не имеющих отношения к контракту службы. Например, со службой может быть связана конечная точка инфраструктуры, предоставляющая информацию о метаданных.
Адрес
Задает расположение, где принимаются сообщения. Он задается в виде универсального кода ресурса (URI). Часть URI, определяющая схему, задает транспортный механизм для доставки по адресу, например HTTP и TCP. Иерархическая часть URI содержит уникальное расположение, формат которого зависит от транспортного механизма.
Адрес конечной точки позволяет создавать уникальные адреса для каждой конечной точки в службе или при определенных условиях использовать один адрес для нескольких конечных точек. В следующем примере показан адрес, использующий протокол HTTPS с портом, не установленным по умолчанию:
Привязка
Задает способ связи конечной точки с внешним миром. Она состоит из набора компонентов, называемых элементами привязки, которые компонуются в «стек», один над другим, образуя инфраструктуру связи. Как минимум, привязка определяет используемые транспорт (например HTTP или TCP) и кодирование (например, текстовое или двоичное). Привязка может содержать элементы привязки, задающие такие сведения, как механизмы безопасности, используемые для защищенных сообщений, или шаблон сообщений, используемый конечной точкой. Дополнительные сведения см. в разделе Настройка служб.
Элемент Binding
Представляет определенную часть привязки, такую как транспорт, кодирование, реализация протокола на уровне инфраструктуры (например, WS-ReliableMessaging) или любой другой компонент стека связи.
Расширения функциональности
Компонент, управляющий различными аспектами работы службы, конечной точки, определенной операции или клиента во время выполнения. Расширения функциональности группируются в соответствии с областью действия: общие расширения функциональности влияют глобально на все конечные точки, расширения функциональности служб влияют только на аспекты, относящиеся к службам, расширения функциональности конечных точек влияют только на свойства, относящиеся к конечным точкам, а расширения функциональности уровня операции влияют только на конкретные операции. Например, одно расширение функциональности службы регулирующее и определяет реакцию службы при избытке сообщений, превосходящем возможности обработки. С другой стороны, поведение конечной точки управляет только аспектами, относящимися к конечным точкам, например способом поиска учетных данных безопасности и расположением для поиска.
Привязки, предоставляемые системой
WCF содержит ряд привязок, предоставляемых системой. Они являются коллекциями элементов привязки, оптимизированными для конкретных сценариев. Например, WSHttpBinding предназначен для взаимодействия со службами, которые реализуют различные спецификации WS- * Спецификация. Эти заранее определенные привязки экономят время, предоставляя только те параметры, которые могут быть правильно применены для конкретного сценария. Если заранее определенная привязка не удовлетворяет необходимым требованиям, можно создать собственную настраиваемую привязку.
Настройка и кодирование
Управление приложением возможно с помощью кода, с помощью конфигурации или с помощью и того, и другого. Преимущество конфигурации заключается в том, что после написания кода параметры клиента или службы могут задаваться пользователями (например, системным администратором), а не только разработчиком, при этом отсутствует необходимость в повторной компиляции. Конфигурация не только позволяет задавать значения, такие как адреса конечных точек, но и обеспечивает дополнительные возможности управления, позволяя добавлять конечные точки, привязки и расширения функциональности. Кодирование позволяет разработчику сохранить полный контроль над всеми компонентами службы или клиента; все параметры, заданные при конфигурации, можно проверить и, при необходимости, изменить с помощью кода.
Операция службы
Процедура, определенная в программном коде службы и реализующая функциональные возможности операции. Эта операция видима клиентам в виде методов клиента WCF. Метод может возвращать значение и может иметь ряд необязательных аргументов либо может не иметь аргументов и не возвращать никаких значений. Например, операция, выполняющая функцию простого приветствия «Привет», может использоваться для уведомления о наличии клиента и запуска серии операций.
Контракт службы
Объединяет несколько связанных операций в один функциональный модуль. Контракт может определять параметры уровня службы, такие как пространство имен службы, соответствующий контракт обратного вызова и другие подобные параметры. В большинстве случаев контракт задается путем создания интерфейса на выбранном языке программирования и применения атрибута ServiceContractAttribute к этому интерфейсу. Фактический код службы создается при реализации этого интерфейса.
Контракт операции
Контракт операции определяет параметры операции и тип возвращаемых ею значений. При создании интерфейса, определяющего контракт службы, контракт операции задается применением атрибута OperationContractAttribute к определению каждого метода, входящего в контракт. Операции могут задаваться как получающие одно сообщение и возвращающие одно сообщение или как получающие набор типов и возвращающие тип. В последнем случае формат сообщений, обмен которыми происходит при выполнении данной операции, определяется системой.
Контракт сообщения
Описывает формат сообщения. Например, в нем описывается, должны элементы сообщения размещаться в заголовках или в теле, уровень безопасности, применяемый к определенным элементам сообщения и т. д.
Контракт сбоя
Может связываться с операцией службы для обозначения ошибок, которые могут возвращаться вызывающему объекту. С операцией могут быть связаны ноль или более сбоев. Эти ошибки представляют собой сбои протокола SOAP, которые моделируются в модели программирования как исключения.
Контракт данных
Хранящееся в метаданных описание типов данных, используемых службой. Это описание позволяет другим объектам работать со службой. Типы данных могут использоваться в любой части сообщения, например в виде типов параметров или возвращаемых значений. Если в службе используются только простые типы, явное использование контрактов данных не требуется.
Размещение
Служба должна быть размещена в некотором процессе. Узел — это приложение, которое управляет временем существования службы. Службы могут быть резидентными (размещенными сами в себе) или управляемыми существующим ведущим процессом.
Автономная служба
Служба, которая выполняется в приложении-процессе, созданном разработчиком. Разработчик контролирует время существования службы, набор свойств службы, открывает службу (при этом служба переходит в режим ожидания данных) и закрывает службу.
Ведущий процесс
Приложение, предназначенное для размещения служб. В число таких приложений входят службы IIS, службы активации Windows (WAS) и службы Windows. В этих сценариях ведущее приложение контролирует время существования службы. Например, с помощью IIS можно создать виртуальный каталог, содержащий сборку службы и файл конфигурации. При получении сообщения IIS запускает службу и контролирует время ее существования.
Instancing
Со службой связана модель создания экземпляров. Существуют три модели создания экземпляров: «один экземпляр», в которой один объект CLR обслуживает всех клиентов, «по вызовам», в которой для обработки каждого вызова, поступившего от клиента, создается новый объект CLR, и «по сеансам», в которой создается набор объектов CLR, по одному на каждый отдельный сеанс. Выбор модели создания экземпляров зависит от требований к приложению и ожидаемого режима использования службы.
Клиентское приложение
Программа, обменивающаяся сообщениями с одной или несколькими конечными точками. Клиентское приложение начинает работу с создания экземпляра клиента WCF и вызывает методы этого клиента WCF. Обратите внимание, что одно и то же приложение может быть как клиентом, так и службой.
Канал
Конкретная реализация элемента привязки. Привязка представляет собой конфигурацию, а канал является реализацией, связанной с этой конфигурацией. Следовательно, с каждым элементом привязки связан канал. Каналы, собранные в стек друг на другом, образуют конкретную реализацию привязки: стек каналов.
Клиент WCF можно создать автоматически с помощью средства служебной программы метаданных ServiceModel (Svcutil.exe) и указать его в работающей службе, которая публикует метаданные.
Метаданные
Описывают характеристики службы, которые необходимо знать внешней сущности для обмена данными со службой. Метаданные можно использовать с помощью средства служебной программы метаданных ServiceModel (Svcutil.exe) для создания клиента WCF и сопутствующей конфигурации, которую клиентское приложение может использовать для взаимодействия со службой.
Метаданные, предоставляемые службой, содержат документы схемы XML, определяющие контракт данных службы, и документы WSDL, описывающие методы службы.
Если метаданные для службы включены, они автоматически создаются WCF путем проверки службы и ее конечных точек. Для публикации метаданных службы необходимо явно задать расширение функциональности метаданных.
Безопасность
В WCF включает в себя конфиденциальность (шифрование сообщений для предотвращения перехвата), целостность (средства для обнаружения несанкционированных сообщений), проверку подлинности (средства для проверки серверов и клиентов) и авторизацию (Управление доступом к ресурсам). Эти функции предоставляются либо с помощью существующих механизмов безопасности, таких как TLS по протоколу HTTP (также известного как HTTPS), либо путем реализации одной или нескольких различных * спецификаций WS-Security.
Режим безопасности транспорта
Указывает, что конфиденциальность, целостность и проверка подлинности обеспечиваются механизмами транспортного уровня (такими как HTTPS). При использовании такого транспорта, как HTTPS, преимущества этого режима заключаются в его эффективной производительности и хорошей известности в связи с преобладающим применением в Интернете. Недостаток заключается в том, что безопасность этого типа применяется отдельно на каждом прыжке пути передачи, в результате чего связь становится чувствительной к атакам типа «злоумышленник в середине».
Режим безопасности сообщений
Указывает, что безопасность предоставляется путем реализации одной или нескольких спецификаций безопасности, например спецификации с именем WS-Security: SOAP Message Security. Каждое сообщение содержит необходимые механизмы, обеспечивающие безопасность во время его передачи и позволяющие получателям обнаруживать подделки и расшифровывать сообщения. В этом отношении безопасность заложена внутри каждого сообщения, обеспечивая сквозную безопасность по всем участкам передачи. Поскольку сведения о безопасности становятся частью сообщения, можно также включить несколько типов учетных данных с сообщением (они называются утверждениями). Дополнительным преимуществом такого подхода является возможность безопасной передачи сообщения с помощью любого транспортного механизма, включая несколько транспортных механизмов между источником и назначением. К недостатком этого подхода относится сложность используемых криптографических механизмов, требовательных к производительности.
Транспорт с режимом безопасности учетных данных сообщений
Задает использование транспортного уровня для обеспечения конфиденциальности, проверки подлинности и целостности сообщений, но каждое сообщение может содержать несколько учетных данных (утверждений), требуемых получателями сообщения.
Протокол*
Сокращение для обозначения растущего набора спецификаций веб-служб (WS), таких как WS-Security, WS-ReliableMessaging и т. д., реализованных в WCF.