Wcf c что это

Простой и надежный C# клиент-сервер используя WCF

Есть один маленький ньюанс. На локальном компьютере подключение работает изумительно, но с переносом на сервер при подключении клиента к серверу выскочит Ошибка вызова SSPI. Это из особенностей пакетов безопасности.
В код клиента и сервера необходимо будет добавить следующие строки.
Для клиента:
clientBinding.Security.Mode = SecurityMode.None;
Для сервера:
serverBinding.Security.Mode = SecurityMode.None;

Фотку для примера прикладываю)

Развернуть ветку

Спасибо тебе добрый человек, теперь у меня всё работает. Только я прописал в конфиге, а не в коде.

Что такое Windows Communication Foundation

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

Защищенная служба для обработки бизнес-транзакций.
Служба, передающая другим объектам текущие данные, такие как отчет о трафике, или другая служба наблюдения.
Служба бесед, которая позволяет двум пользователям общаться и обмениваться данными в реальном времени.
Приложение панели мониторинга, которая опрашивает одну или несколько служб и дает логическое представление полученных данных.
Предоставление доступа к рабочему процессу, реализованному с помощью Windows Workflow Foundation, в виде службы WCF.

При создании таких приложений было возможно до существования WCF, WCF упрощает разработку конечных точек, чем когда-либо. В итоге WCF предназначен для обеспечения управляемого подхода к созданию веб-служб и клиентов веб-служб.

gRPC в качестве альтернативы WCF

gRPC — это современная платформа RPC, которая является популярной альтернативой WCF. gRPC построен на основе HTTP/2, что обеспечивает ряд преимуществ по сравнению с WCF, в том числе:

Производительность: gRPC гораздо эффективнее, чем WCF, особенно для длительных подключений.
Масштабируемость: gRPC предназначен для масштабирования до большого количества клиентов и серверов.
Безопасность: gRPC поддерживает различные механизмы безопасности, включая TLS и проверку подлинности.
Кроссплатформенный: gRPC является платформо-нейтральным и может использоваться с различными языками программирования.

Дополнительные сведения о разработке или переносе приложений WCF в gRPC см. в следующем разделе:

Почему мы рекомендуем gRPC для разработчиков WCF
Сравнение WCF с gRPC
Общие сведения о gRPC для разработчиков WCF

Возможности WCF

WCF включает следующий набор функций. Дополнительные сведения см. в разделе «Сведения о функциях WCF».

Сервис-ориентированность Одним из последствий использования стандартов WS является то, что WCF позволяет создавать приложения, ориентированные на обслуживание. Сервисноориентированная архитектура (SOA) подразумевает применение веб-служб для отправки и получения данных. Общим преимуществом служб является слабая связанность вместо жесткой запрограммированности для различных приложений. Слабая связь означает, что любой клиент, созданный на любой платформе, может подключаться к любой службе при условии, что выполняются необходимые контракты.
Совместимость WCF реализует современные отраслевые стандарты взаимодействия веб-служб. Дополнительные сведения о поддерживаемых стандартах см. в разделе «Взаимодействие и интеграция».
Несколько шаблонов сообщений Обмен сообщениями выполняется по одному из нескольких шаблонов. Чаще всего используется шаблон «запрос-ответ», когда одна конечная точка запрашивает данные от другой конечной точки. Вторая конечная точка отвечает. Существуют и другие шаблоны, например одностороннее сообщение, когда одна конечная точка отправляет сообщение, не ожидая ответа. Более сложным является шаблон дуплексного обмена, когда две конечные точки устанавливают соединение и отправляют данные в обоих направлениях подобно программе обмена мгновенными сообщениями. Дополнительные сведения о реализации различных шаблонов обмена сообщениями с помощью WCF см. в разделе «Контракты».
Метаданные службы WCF поддерживает публикацию метаданных службы с использованием форматов, указанных в отраслевых стандартах, таких как WSDL, СХЕМА XML и политика WS-Policy. Эти метаданные можно использовать для автоматического создания и настройки клиентов для доступа к службам WCF. Метаданные могут публиковаться через HTTP и HTTPS или с использованием стандарта обмена метаданными веб-служб. Дополнительные сведения см. в разделе Метаданные.
Контракты данных Так как WCF создается с помощью .NET Framework, он также включает в себя понятные для кода методы предоставления контрактов, которые требуется применить. Одним из универсальных типов контрактов является контракт данных. Если код службы создается на языке Visual C# или Visual Basic, то самым простым способом обработки данных фактически является создание классов, которые представляют сущность данных со свойствами, принадлежащими сущности данных. WCF включает в себя комплексную систему для работы с данными таким простым способом. После создания классов, представляющих данные, служба автоматически создает метаданные, которые позволяют клиентам обеспечивать соответствие заданным типам данных. Дополнительные сведения см. в разделе «Использование контрактов данных».
Безопасность Сообщения можно шифровать для защиты конфиденциальности и требовать от пользователей проходить проверку подлинности перед приемом сообщений. Можно реализовать широко известные стандарты безопасности, такие как SSL и WS-SecureConversation. Дополнительные сведения см. в статье Безопасность.
Несколько транспортов и кодировок Сообщения могут отправляться по любому из нескольких встроенных транспортных протоколов в различных кодировках. Наиболее распространенным протоколом и кодировкой является отправка текстовых сообщений SOAP с помощью протокола HTTP для использования в Интернете. Кроме того, WCF позволяет отправлять сообщения через TCP, именованные каналы или MSMQ. Сообщения можно кодировать в виде текста или использовать оптимизированный двоичный формат. Двоичные данные можно эффективно отправлять с использованием стандарта MTOM. Если ни один из предоставляемых транспортов и кодировок не подходит к текущим требованиям, вы можете создать собственный пользовательский транспорт или кодировку. Дополнительные сведения о транспортах и кодировках, поддерживаемых WCF, см. в разделе «Транспорты».
Надежные сообщения и сообщения в очереди WCF поддерживает надежный обмен сообщениями с помощью надежных сеансов, реализованных через WS-Reliable Messaging и используя MSMQ. Дополнительные сведения о поддержке надежных и очередей обмена сообщениями в WCF см. в разделах «Очереди» и «Надежные сеансы».
Устойчивые сообщения Устойчивые сообщения не теряются в случае перебоев связи. Сообщения, передаваемые по устойчивому шаблону, всегда сохраняются в базе данных. Если происходит перебой связи, база данных позволяет возобновить обмен сообщениями после восстановления соединения. Вы также можете создать устойчивое сообщение с помощью Windows Workflow Foundation (WF). Дополнительные сведения см. в разделе «Службы рабочих процессов».
Транзакции WCF также поддерживает транзакции с помощью одной из трех моделей транзакций: WS-AtomicTransactions, API в System.Transactions пространстве имен и координатор распределенных транзакций Майкрософт. Дополнительные сведения о поддержке транзакций в WCF см. в разделе «Транзакции».
Поддержка AJAX и REST REST — это пример развития технологии Web 2.0. WCF можно настроить для обработки «простых» XML-данных, которые не упаковываются в конверт SOAP. WCF также можно расширить для поддержки конкретных форматов XML, таких как ATOM (популярный стандарт RSS), а также даже форматы, отличные от XML, такие как нотация объектов JavaScript (JSON).
Расширяемость Архитектура 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 Line of Business (LOB) для доставки сообщений в поле сообщения.

Функции размещения сервера приложений Windows Server AppFabric специально предназначены для развертывания приложений и управления ими, использующих WCF для обмена данными. Функции размещения включают расширенные средства и параметры конфигурации, специально предназначенные для приложений с поддержкой WCF.

См. также

System.ServiceModel
Основные понятия Windows Communication Foundation
Архитектура Windows Communication Foundation
Правила и рекомендации
Руководство по началу работы
Руководство по работе с документацией
Базовое программирование для WCF
Примеры Windows Communication Foundation

Пример создания WCF-сервиса, работающего внутри службы Windows

Windows Communication Foundation – программная платформа от Microsoft для создания, настройки и развертывания распределенных сетевых сервисов. WCF-runtime и его пространство имен System.ServiceModel, представляющее его главный программный интерфейс, это преемник технологий создания распределенных систем, успешно применяемых разработчиками для создания распределенных приложений на платформе Windows в последнее десятилетие. Разберём тестовый пример создания WCF-сервиса.

Открываем Visual Studio 2015 и создаём новый проект типа Class Library. Проект назовём WCFMyServiceLibrary.

Файл Class1.cs переименуем в MyService.cs и добавим ещё один класс, файл для которого назовём IMyService.cs.

Добавим ссылку на сборку System.ServiceModel.

В файле IMyService.cs опишем интерфейс:

using System.ServiceModel; namespace WCFMyServiceLibrary < [ServiceContract] public interface IMyService < [OperationContract] string Method1(string x); [OperationContract] string Method2(string x); >>

В файле MyService.cs опишем реализацию интерфейса:

namespace WCFMyServiceLibrary < public class MyService : IMyService < public string Method1(string x) < string s = $"1 You entered: = = = 1"; return s; > public string Method2(string x) < string s = $"2 you entered: = = = 2"; return s; > > >

На этом разработка сервиса завершена. Переходим к созданию службы Windows, которая будет контейнером для данного сервиса.

В том же решении (Solution) создадим новый проект типа «Служба Windows». Называем проект WindowsServiceHostForMyService.

Затем файл Service1.cs (только что созданного проекта) переименуем в MyService.cs. В этот проект добавим ссылку на сборку System.ServiceModel, а также не забываем указывать в файле MyService.cs директивы:

using System.ServiceModel; using System.ServiceModel.Description;

В классе MyService добавляем новый член:

private ServiceHost service_host = null;

Также необходимо добавить ссылку на проект WCFMyServiceLibrary, который находится в этом же решении:

Затем в классе MyService изменим метод OnStart таким образом, чтобы в этом методе добавлялись конечные точки нашего сервиса (endpoint):

метод OnStart

 protected override void OnStart(string[] args) < if (service_host != null) service_host.Close(); string address_HTTP = "http://localhost:9001/MyService"; string address_TCP = "net.tcp://localhost:9002/MyService"; Uri[] address_base = < new Uri(address_HTTP), new Uri(address_TCP) >; service_host = new ServiceHost(typeof(WCFMyServiceLibrary.MyService), address_base); ServiceMetadataBehavior behavior = new ServiceMetadataBehavior(); service_host.Description.Behaviors.Add(behavior); BasicHttpBinding binding_http = new BasicHttpBinding(); service_host.AddServiceEndpoint(typeof(WCFMyServiceLibrary.IMyService), binding_http, address_HTTP); service_host.AddServiceEndpoint(typeof(IMetadataExchange), MetadataExchangeBindings.CreateMexHttpBinding(), "mex"); NetTcpBinding binding_tcp = new NetTcpBinding(); binding_tcp.Security.Mode = SecurityMode.Transport; binding_tcp.Security.Transport.ClientCredentialType = TcpClientCredentialType.Windows; binding_tcp.Security.Message.ClientCredentialType = MessageCredentialType.Windows; binding_tcp.Security.Transport.ProtectionLevel = System.Net.Security.ProtectionLevel.EncryptAndSign; service_host.AddServiceEndpoint(typeof(WCFMyServiceLibrary.IMyService), binding_tcp, address_TCP); service_host.AddServiceEndpoint(typeof(IMetadataExchange), MetadataExchangeBindings.CreateMexTcpBinding(), "mex"); service_host.Open(); >

Затем реализуем остановку сервиса в методе OnStop:

 protected override void OnStop() < if (service_host != null) < service_host.Close(); service_host = null; >>

Затем в Обозревателе решения — двойной клик на файле MyService.cs (проекта WindowsServiceHostForMyService) откроет этот файл в режиме конструктора (Design Mode).

На пустом пространстве вызываем контекстное меню (щелчок правой кнопкой мыши) и выбираем «Добавить установщик».

При этом будет создан новый класс ProjectInstaller.cs
Переименуем файл ProjectInstaller.cs в MyServiceInstaller.cs.
При этом выйдет окно с вопросом, следует ли переименовать зависимые объекты – отвечаем «Да».

Добавим в файл ссылку

using System.ServiceProcess;

Затем изменим код конструктора класса MyServiceInstaller:

 public MyServiceInstaller() < // InitializeComponent(); serviceProcessInstaller1 = new ServiceProcessInstaller(); serviceProcessInstaller1.Account = ServiceAccount.LocalSystem; serviceInstaller1 = new ServiceInstaller(); serviceInstaller1.ServiceName = "WindowsServiceHostForMyService"; serviceInstaller1.DisplayName = "WindowsServiceHostForMyService"; serviceInstaller1.Description = "WCF Service Hosted by Windows NT Service"; serviceInstaller1.StartType = ServiceStartMode.Automatic; Installers.Add(serviceProcessInstaller1); Installers.Add(serviceInstaller1); >

Заметим, что вызов метода InitializeComponent() мы заблокировали с помощью комментария.
На этом разработка службы Windows завершена. Собираем всё решение (Build Solution) и переходим к следующему этапу – установка службы Windows.

Для установки нашей службы создадим bat-файл (с произвольным названием, например Install_Windows_Service.bat) следующего содержания:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\InstallUtil.exe WindowsServiceHostForMyService.exe

Нужно скопировать этот bat-файл в ту же папку, где находится скомпилированный файл WindowsServiceHostForMyService.exe (вам нужно заранее продумать, в какой папке будет лежать этот файл, который будет всегда запущен в качестве службы Windows).

Запускаем bat-файл, после чего наша программа WindowsServiceHostForMyService.exe будет установлена в качестве службы Windows.

Запустим эту службу с помощью стандартной программы управления службами.

Следующий этап – разработка клиентского приложения для использования предоставляемых сервисом услуг.

Для этого прежде всего нужно организовать так называемый «переходник» — Service Proxy – набор настроек, описывающих сервис для клиентского приложения.

Воспользуемся для этого стандартной утилитой SvcUtil.exe. Создадим файл Generate_Proxy.bat следующего содержания

SvcUtil http://localhost:9001/MyService /out:MyServiceProxy.cs /config:App.config

Запустим этот файл (стандартная утилита SvcUtil.exe находится в папке C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin).

Этот файл нужно запустить во время работы нашего сервиса, т.е. в данном случае, после успешного запуска службы Windows WindowsServiceHostForMyService.

В случае успешного запуска, программа SvcUtil.exe сгенерирует 2 файла — MyServiceProxy.cs и App.config.

Эти файлы необходимо добавить для клиентского приложения, чтобы это приложение могло вызывать методы нашей службы (чуть ниже вы узнаете, что файл App.config я решил не добавлять — обойдёмся и без него).

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

SvcUtil net.tcp://localhost:9002/MyService /out:MyServiceProxy.cs /config:App.config

Т.е. можно запускать эту утилиту, указав только одну конечную точку, либо http либо net.tcp.

В том же решении (Solution) создадим обычное приложение Windows Forms. Назовем его WindowsFormsApplication1

Добавим в этот проект ссылку на System.ServiceModel и, конечно же,

using System.ServiceModel в файле формы.

Добавим в этот проект файл MyServiceProxy.cs (именно его мы сгенерировали утилитой SvcUtil.exe). При этом следует добавить в файл MyServiceProxy.cs следующие строки:

namespace ServiceReference1

После этого, мы сможем ссылаться на класс MyServiceClient (этот класс создан программой SvcUtil.exe), указав в файле формы директиву.

 using ServiceReference1;

Пример готового файла MyServiceProxy.cs (комментарии удалены):

namespace ServiceReference1 < using System.Runtime.Serialization; using System; [System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "3.0.0.0")] [System.ServiceModel.ServiceContractAttribute(ConfigurationName="IMyService")] public interface IMyService < [System.ServiceModel.OperationContractAttribute(Action="http://tempuri.org/IMyService/Method1", ReplyAction="http://tempuri.org/IMyService/Method1Response")] string Method1(string x); [System.ServiceModel.OperationContractAttribute(Action="http://tempuri.org/IMyService/Method2", ReplyAction="http://tempuri.org/IMyService/Method2Response")] string Method2(string x); >[System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "3.0.0.0")] public interface IMyServiceChannel : IMyService, System.ServiceModel.IClientChannel < >[System.Diagnostics.DebuggerStepThroughAttribute()] [System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "3.0.0.0")] public partial class MyServiceClient : System.ServiceModel.ClientBase, IMyService < public MyServiceClient() < >public MyServiceClient(string endpointConfigurationName) : base(endpointConfigurationName) < >public MyServiceClient(string endpointConfigurationName, string remoteAddress) : base(endpointConfigurationName, remoteAddress) < >public MyServiceClient(string endpointConfigurationName, System.ServiceModel.EndpointAddress remoteAddress) : base(endpointConfigurationName, remoteAddress) < >public MyServiceClient(System.ServiceModel.Channels.Binding binding, System.ServiceModel.EndpointAddress remoteAddress) : base(binding, remoteAddress) < >public string Method1(string x) < return base.Channel.Method1(x); >public string Method2(string x) < return base.Channel.Method2(x); >> >

Поступим неординарно – и не будем добавлять файл App.Config в проект клиента!

Затем набросаем на форму 3 кнопки, текстовое поле textBox1 (пользователь вводит сюда строку для отправки на сервер) и поле richTextbox1 (имитация подсистемы сообщений нашего приложения – именно в это поле будут поступать сообщения от программы, в том числе и те, что вернул нам сервис)

Кнопка btn_Start – создаёт клиента
Кнопка btn_Send – отправляет сервису текстовую строку из текстового поля
Кнопка btn_Close – удаляет клиента из памяти и закрывает приложение

Код формы:

using System; using System.ServiceModel; using System.Windows.Forms; using ServiceReference1; namespace WindowsFormsApplication1 < public partial class Form1 : Form < MyServiceClient client = null; public Form1() < InitializeComponent(); >private void Print(string text) < richTextBox1.Text += text + "\n\n"; richTextBox1.SelectionStart = richTextBox1.Text.Length; richTextBox1.ScrollToCaret(); >private void Print(Exception ex) < if (ex == null) return; Print(ex.Message); Print(ex.Source); Print(ex.StackTrace); >private void Create_New_Client() < if (client == null) try < Try_To_Create_New_Client(); >catch (Exception ex) < Print(ex); Print(ex.InnerException); client = null; >else < Print("Cannot create a new client. The current Client is active."); >> private void Try_To_Create_New_Client() < try < NetTcpBinding binding = new NetTcpBinding(SecurityMode.Transport); binding.Security.Message.ClientCredentialType = MessageCredentialType.Windows; binding.Security.Transport.ClientCredentialType = TcpClientCredentialType.Windows; binding.Security.Transport.ProtectionLevel = System.Net.Security.ProtectionLevel.EncryptAndSign; string uri = "net.tcp://192.168.1.2:9002/MyService"; EndpointAddress endpoint = new EndpointAddress(new Uri(uri)); client = new MyServiceClient(binding, endpoint); client.ClientCredentials.Windows.ClientCredential.Domain = ""; client.ClientCredentials.Windows.ClientCredential.UserName = "Vasya"; client.ClientCredentials.Windows.ClientCredential.Password = "12345"; Print("Creating new client . "); Print(endpoint.Uri.ToString()); Print(uri); string test = client.Method1("test"); if (test.Length < 1) < throw new Exception("Проверка соединения не удалась"); >else < Print("test is OK ! " + test); >> catch (Exception ex) < Print(ex); Print(ex.InnerException); client = null; >> private void btn_Start_Click(object sender, EventArgs e) < Create_New_Client(); >private void btn_Send_Click(object sender, EventArgs e) < Print("sending message . . ."); string s = textBox1.Text; string x = ""; if (client != null) < x = client.Method1(s); Print(x); x = client.Method2(s); Print(x); >else < Print("Error! Client does not exist!"); >> private void btn_Close_Click(object sender, EventArgs e) < if (client != null) < Print("Closing a client . "); client.Close(); client = null; >else < Print("Error! Client does not exist!"); >this.Close(); > > >

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

Заметим, что в данном примере на клиенте мы совсем не использовали конечную точку

http://localhost:9001/MyService
а работали только с

net.tcp://localhost:9002/MyService
(вы легко сможете это сделать самостоятельно – раз уж вам net.tcp по плечу, то уж http-то с закрытыми глазами сделаете).

Кроме того, мы не использовали файл App.config, создав на клиенте конечную точку не с помощью настроек, а с помощью кода C#. Причины тому – субъективные – автор не любит возиться с XML-настройками, а по возможности всё делает явно в коде. Спасибо за внимание!

Лирическое отступление. Автор статейки познакомился с языком C# в марте сего года, первое приложение на C# написал в мае (до этого много лет формошлёпил на Delphi и даже на MS Access).

Основные понятия Windows Communication Foundation

В этом документе представлено общее представление архитектуры Windows Communication Foundation (WCF). В нем приводится объяснение ключевых понятий и их взаимосвязь. Руководство по созданию простейшей версии службы и клиента WCF см. в руководстве по начало работы. Сведения о программировании WCF см. в статье Базовое программирование WCF.

Основы WCF

WCF — это среда выполнения и набор API для создания систем, которые отправляют сообщения между службами и клиентами. Те же инфраструктура и интерфейсы API используются для создания приложений, обменивающихся данными с другими приложениями на данном компьютере или на компьютере, который находится в другой компании, и доступ к которому можно получить через Интернет.

Обмен сообщениями и конечные точки

WCF основан на понятии обмена данными на основе сообщений, и все, что можно смоделировать как сообщение (например, HTTP-запрос или сообщение очереди сообщений (также известное как СООБЩЕНИЕ MSMQ), может быть представлено в модели программирования единым образом. Это обеспечивает универсальный интерфейс API для разных транспортных механизмов.

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

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

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

Протоколы связи

Одним из обязательных элементов стека связи является транспортный протокол. Сообщения можно отправлять через интрасети или через Интернет с помощью общих транспортов, таких как HTTP и TCP. Предусмотрены другие транспорты, поддерживающие связь с приложениями очереди сообщений и узлами в сетке одноранговой сети. Дополнительные механизмы транспорта можно добавить с помощью встроенных точек расширения WCF.

Другим обязательным элементом стека связи является кодирование, определяющее способ форматирования любого заданного сообщения. WCF предоставляет следующие кодировки:

кодировка текста — кодирование с возможностью взаимодействия;
кодировка подсистемы оптимизации передачи сообщений MTOM — поддерживающий взаимодействие способ эффективной отправки неструктурированных двоичных данных в службу и из нее;
двоичное кодирование для эффективной передачи.

Дополнительные механизмы кодирования (например, кодирование сжатия) можно добавить с помощью встроенных точек расширения WCF.

Шаблоны сообщений

WCF поддерживает несколько шаблонов обмена сообщениями, включая запрос и ответ, одностороннюю и дуплексную связь. Разные транспорты поддерживают разные шаблоны обмена сообщениями и таким образом влияют на типы поддерживаемых взаимодействий. API WCF и среда выполнения также помогают безопасно и надежно отправлять сообщения.

Термины WCF

К другим понятиям и терминам, используемым в документации WCF, относятся следующие:

Message
Автономная единица данных, которая может состоять из нескольких частей, включая текст и заголовки.

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

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

Служба WCF видима внешнему миру как коллекция конечных точек.

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

Конечная точка инфраструктуры
Конечная точка, предоставляемая инфраструктурой для расширения функциональных возможностей, необходимых для службы или предоставляемых службой и не имеющих отношения к контракту службы. Например, со службой может быть связана конечная точка инфраструктуры, предоставляющая информацию о метаданных.

Адрес
Задает расположение, где принимаются сообщения. Он задается в виде универсального кода ресурса (URI). Часть URI, определяющая схему, задает транспортный механизм для доставки по адресу, например HTTP и TCP. Иерархическая часть URI содержит уникальное расположение, формат которого зависит от транспортного механизма.

Адрес конечной точки позволяет создавать уникальные адреса для каждой конечной точки в службе или при определенных условиях использовать один адрес для нескольких конечных точек. В следующем примере показан адрес, использующий протокол HTTPS с портом, не установленным по умолчанию:

HTTPS://cohowinery:8005/ServiceModelSamples/CalculatorService

Привязка
Задает способ связи конечной точки с внешним миром. Она состоит из набора компонентов, называемых элементами привязки, которые компонуются в «стек», один над другим, образуя инфраструктуру связи. Как минимум, привязка определяет используемые транспорт (например 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
Конструкция клиентского приложения, которая предоставляет операции службы в виде методов (на выбранном платформа .NET Framework языке программирования, например Visual Basic или Visual C#). Каждое приложение может содержать клиента WCF, включая приложение, содержащее службу. Следовательно, можно создать службу, содержащую клиентов WCF других служб.

Клиент WCF можно создать автоматически с помощью служебной программы метаданных ServiceModel (Svcutil.exe) и направив ее на выполняющуюся службу, которая публикует метаданные.

Метаданные
Описывают характеристики службы, которые необходимо знать внешней сущности для обмена данными со службой. Метаданные могут использоваться служебной программой метаданных ServiceModel (Svcutil.exe) для создания клиента WCF и сопутствующей конфигурации, которую клиентское приложение может использовать для взаимодействия со службой.

Метаданные, предоставляемые службой, содержат документы схемы XML, определяющие контракт данных службы, и документы WSDL, описывающие методы службы.

Если метаданные для службы включены, они автоматически создаются WCF путем проверки службы и ее конечных точек. Для публикации метаданных службы необходимо явно задать расширение функциональности метаданных.

Безопасность
В WCF включает конфиденциальность (шифрование сообщений для предотвращения перехвата), целостность (средства обнаружения незаконного изменения сообщения), проверку подлинности (средства проверки серверов и клиентов) и авторизацию (управление доступом к ресурсам). Эти функции предоставляются либо путем использования существующих механизмов обеспечения безопасности, таких как TLS по HTTP (также называемого HTTPS), либо путем реализации одной или нескольких различных спецификаций безопасности WS-*.

Режим безопасности транспорта
Указывает, что конфиденциальность, целостность и проверка подлинности обеспечиваются механизмами транспортного уровня (такими как HTTPS). При использовании такого транспорта, как HTTPS, преимущества этого режима заключаются в его эффективной производительности и хорошей известности в связи с преобладающим применением в Интернете. Недостаток заключается в том, что безопасность этого типа применяется отдельно на каждом прыжке пути передачи, в результате чего связь становится чувствительной к атакам типа «злоумышленник в середине».

Режим безопасности сообщений
Указывает, что безопасность обеспечивается путем реализации одной или нескольких спецификаций безопасности, таких как спецификация Безопасность веб-служб: безопасность сообщений SOAP. Каждое сообщение содержит необходимые механизмы, обеспечивающие безопасность во время его передачи и позволяющие получателям обнаруживать подделки и расшифровывать сообщения. В этом отношении безопасность заложена внутри каждого сообщения, обеспечивая сквозную безопасность по всем участкам передачи. Так как сведения о безопасности становятся частью сообщения, можно также включить в сообщение несколько типов учетных данных (они называются утверждениями). Дополнительным преимуществом такого подхода является возможность безопасной передачи сообщения с помощью любого транспортного механизма, включая несколько транспортных механизмов между источником и назначением. К недостатком этого подхода относится сложность используемых криптографических механизмов, требовательных к производительности.

Транспорт с режимом безопасности учетных данных сообщения
Задает использование транспортного уровня для обеспечения конфиденциальности, проверки подлинности и целостности сообщений, но каждое сообщение может содержать несколько учетных данных (утверждений), требуемых получателями сообщения.

WS-*
Сокращение для обозначения растущего набора спецификаций веб-служб (WS), таких как WS-Security, WS-ReliableMessaging и т. д., реализованных в WCF.

См. также раздел

Что такое Windows Communication Foundation
Архитектура Windows Communication Foundation