Возможности упрощения WCF

Статья
04/11/2023

В этом разделе описываются новые возможности, упрощающие написание приложений WCF.

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

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

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

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

Упрощенные сформированные файлы конфигурации

Клиентский файл конфигурации создается при добавлении ссылки на службу в Visual Studio или при использовании средства SvcUtil.exe. В предыдущих версиях WCF эти файлы конфигурации содержали значения каждого свойства привязки, даже если значение было значением по умолчанию. В WCF 4.5 сформированные файлы конфигурации содержат только те свойства привязки, которым присвоено значение не по умолчанию.

Далее приведен пример файла конфигурации, сформированного WCF 3.0.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <system.serviceModel>
        <bindings>
            <basicHttpBinding>
                <binding name="BasicHttpBinding_IService1" closeTimeout="00:01:00"
                    openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
                    allowCookies="false" bypassProxyOnLocal="false"
                    hostNameComparisonMode="StrongWildcard" maxBufferSize="65536"
                    maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
                    messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
                    useDefaultWebProxy="true">
                    <readerQuotas maxDepth="32" maxStringContentLength="8192"
                        maxArrayLength="16384" maxBytesPerRead="4096"
                        maxNameTableCharCount="16384" />
                    <security mode="None">
                        <transport clientCredentialType="None" proxyCredentialType="None"
                            realm="" />
                        <message clientCredentialType="UserName" algorithmSuite="Default" />
                    </security>
                </binding>
            </basicHttpBinding>
        </bindings>
        <client>
            <endpoint address="http://localhost:36906/Service1.svc" binding="basicHttpBinding"
                bindingConfiguration="BasicHttpBinding_IService1" contract="IService1"
                name="BasicHttpBinding_IService1" />
        </client>
    </system.serviceModel>
</configuration>

Далее приведен пример того же файла конфигурации, сформированного WCF 4.5.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <system.serviceModel>
        <bindings>
            <basicHttpBinding>
                <binding name="BasicHttpBinding_IService1" />
            </basicHttpBinding>
        </bindings>
        <client>
            <endpoint address="http://localhost:36906/Service1.svc" binding="basicHttpBinding"
                bindingConfiguration="BasicHttpBinding_IService1" contract="IService1"
                name="BasicHttpBinding_IService1" />
        </client>
    </system.serviceModel>
</configuration>

Разработка в соответствии с парадигмой «Сначала контракт»

WCF теперь поддерживает разработку в соответствии с парадигмой «Сначала контракт». Средство svcutil.exe имеет переключатель /serviceContract, который позволяет создавать контракты службы и данных из документа WSDL.

Добавление ссылки на службу из проекта переносимого подмножества

Переносимые проекты подмножества позволяют программистам сборки .NET поддерживать одно исходное дерево и систему сборки, поддерживая несколько реализаций .NET (классические, Silverlight, Windows Телефон и Xbox). Переносимые проекты подмножества ссылаются только на переносимые библиотеки .NET, которые являются сборками, которые можно использовать в любой реализации .NET. Процесс добавления такой же, как и при добавлении ссылки на службу в рамках любого другого клиентского приложения WCF. Дополнительные сведения см. в разделе "Добавление ссылки на службу" в проекте переносимого подмножества.

Изменились значения по умолчанию для режима совместимости с ASP.NET

WCF предоставляет режим совместимости с ASP.NET, дающий разработчикам при создании служб WCF полный доступ к функциям HTTP-конвейера ASP.NET. Чтобы использовать этот режим, необходимо задать для атрибута aspNetCompatibilityEnabled значение true в <разделе serviceHostingEnvironment> web.config. Кроме того, любая служба в этом домене приложения должна иметь RequirementsMode свойство в его AspNetCompatibilityRequirementsAttribute наборе Allowed или Required. По умолчанию задано значение, а шаблон приложения службы WCF по умолчанию AspNetCompatibilityRequirementsAttribute задает aspNetCompatibilityEnabled атрибутtrue.Allowed Дополнительные сведения см. в статье "Новые возможности Windows Communication Foundation 4.5 " и служб WCF и ASP.NET.

Улучшения в потоковой передаче данных

В WCF была добавлена новая поддержка асинхронной потоковой передачи данных. Чтобы включить асинхронную потоковую передачу, добавьте DispatcherSynchronizationBehavior поведение конечной точки в узел службы и задайте для его свойства trueзначениеAsynchronousSendEnabled. Это может улучшить масштабируемость, когда служба отправляет потоковые сообщения нескольким клиентам, которые медленно считывают сообщения. WCF больше не блокирует один поток для каждого клиента и освобождает поток для обслуживания другого клиента.
Убраны ограничения для буферизации сообщений, возникающие, когда служба размещается в IIS. В предыдущих версиях WCF при получении сообщения для размещенной в IIS службы, использующей потоковую передачу, ASP.NET перед отправкой сообщения в WCF поместило бы его в буфер целиком. Это привело бы к использованию большого объема памяти. Эта буферизация была удалена в платформа .NET Framework 4.5, и теперь службы WCF, размещенные в IIS, могут начать обработку входящего потока до получения всего сообщения, тем самым обеспечивая истинную потоковую передачу. Это позволяет WCF-службам моментально реагировать на сообщения, улучшая производительность. Кроме того, теперь вам больше не требуется указывать значение для maxRequestLength, ограничивающего размер входящих запросов в ASP.NET. Если данное свойство установлено, то оно не учитывается. Дополнительные сведения об maxRequestLength элементе конфигурации httpRuntime> см. в разделе <. Вам по-прежнему потребуется настроить maxAllowedContentLength, дополнительные сведения см. в разделе "Ограничения запросов IIS".

Новые значения по умолчанию для свойств транспорта

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

Свойство	Вкл	Новое значение по умолчанию	Дополнительные сведения
channelInitializationTimeout	NetTcpBinding	30 секунд	Это свойство определяет, сколько времени может занять tcp-подключение для проверки подлинности с помощью протокола Framing .NET. Клиенту необходимо отправить некоторые исходные данные, прежде чем сервер получит достаточно сведений для аутентификации. Это время ожидания специально сделано меньше значения параметра ReceiveTimeout (10 мин) для того, чтобы непроверенные вредоносные клиенты не сохраняли соединение с сервером в течение долгого времени. Значение по умолчанию — 30 секунд. Дополнительные сведения о ChannelInitializationTimeout
listenBacklog	NetTcpBinding	16 * число процессоров	Это свойство уровня сокетов, которое описывает количество допустимых, ожидающих подтверждения запросов в очереди. Если очередь по невыполненной работе по ожиданию передачи данных заполнится полностью, новые запросы будут отклоняться. Дополнительные сведения о ListenBacklog
maxPendingAccepts	ConnectionOrientedTransportBindingElement SMSvcHost.exe	2 * количество процессоров для транспорта 4 * число процессоров для SMSvcHost.exe	Это свойство ограничивает число каналов, которое может прослушиваться в режиме ожидания на сервере. Когда параметру MaxPendingAccepts задано слишком маленькое значение, возникает небольшой промежуток времени, в течение которого ожидающие каналы начнут обслуживать подключения, но новые каналы прослушиваться не будут. Соединение может произойти именно в этот интервал, и оно не будет установлено, потому что на сервере нет ожидающих каналов. Это свойство может быть сконфигурировано путем задания свойству MaxPendingConnections большего значения. Дополнительные сведения см. в статье MaxPendingAccepts и настройке службы общего доступа к портам Net.TCP
maxPendingConnections	ConnectionOrientedTransportBindingElement	12 * количество процессоров	Это свойство определяет количество соединений, которое может быть принято транспортом, но которое не было принято диспетчером ServiceModel. Для настройки этого значения используйте свойство `MaxConnections` привязки или свойство `maxOutboundConnectionsPerEndpoint` элемента привязки. Дополнительные сведения о MaxPendingConnections
receiveTimeout	SMSvcHost.exe	30 секунд	Это свойство определяет время ожидания для чтения данных кадрирования TCP и проведения распределения подключений из базовых подключений. Это выполняется, чтобы ограничить время, которое служба SMSvcHost.exe тратит на считывание начальных данных из входящего соединения. Дополнительные сведения см. в разделе "Настройка службы общего доступа к tcp-порту Net.TCP".

Примечание.

Эти новые значения по умолчанию используются только при развертывании службы WCF на компьютере с платформой .NET Framework 4.5. При развертывании той же службы на компьютере с платформой .NET Framework 4.0 используются значения по умолчанию платформы .NET 4.0. В таких случаях рекомендуется настроить эти параметры явно.

XmlDictionaryReaderQuotas

XmlDictionaryReaderQuotas содержит настраиваемые значения квот для средств чтения словаря XML, которые ограничивают объем памяти, используемый кодировщиком при создании сообщения. Хотя эти квоты и можно изменить, значения по умолчанию были изменены так, чтобы разработчикам редко приходилось их менять. Квота MaxReceivedMessageSize не была изменена, и с ее помощью можно по-прежнему ограничить потребление памяти, избегнув таким образом работы со сложными XmlDictionaryReaderQuotas. В следующей таблице приведены квоты, их новые значения по умолчанию и краткое описание, для чего используется каждая квота.

Имя квоты	Значение по умолчанию	Description
MaxArrayLength	Int32.MaxValue	Возвращает и задает максимально допустимую длину массива. Эта квота ограничивает максимальный размер массива примитивов, возвращаемых средством чтения XML, включая байтовые массивы. Эта квота ограничивает потребление памяти не в самом средстве чтения XML, а в компоненте, использующем средство чтения. Например, когда DataContractSerializer использует средство чтения, защищенное MaxArrayLength, оно не десериализует байтовые массивы, чей размер превышает указанное в этой квоте значение.
MaxBytesPerRead	Int32.MaxValue	Возвращает и задает максимально допустимое число байтов, возвращаемых для каждой операции чтения. Эта квота ограничивает число байтов, которые считываются за одну операцию считывания при чтении открывающего тега элемента и его атрибутов. (В случае непотоковой передачи данных само имя элемента не входит в квоту.) Наличие слишком большого числа атрибутов XML может привести к неоправданно большому времени обработки, поскольку требуется проверка уникальности имен атрибутов. MaxBytesPerRead устраняет эту возможную проблему.
MaxDepth	Глубина в 128 узлов	Эта квота ограничивает максимальную глубину вложенности XML-элементов. MaxDepth взаимодействует с MaxBytesPerRead: средство чтения всегда сохраняет в памяти данные по текущему элементу и всем его предкам, поэтому максимальный потребляемый средством чтения объем памяти пропорционален произведению этих двух параметров. При десериализации графа объекта с глубоким вложением десериализатор принудительно получает доступ ко всему стеку, и выдается неисправимое исключение StackOverflowException. Между вложением XML и вложением объекта существует прямая связь как для DataContractSerializer , так и для XmlSerializer. MaxDepth используется для устранения этой проблемы.
MaxNameTableCharCount	Int32.MaxValue	Эта квота ограничивает максимальное количество символов, разрешенных в таблице имен. В таблице имен содержатся определенные строки (например пространства имен и префиксы), возникающие при обработке документа XML. Поскольку эти строки буферизуются в память, эта квота используется для предотвращения чрезмерной буферизации, если ожидается потоковая передача.
MaxStringContentLength	Int32.MaxValue	Эта квота ограничивает максимальный размер строки, возвращаемой средством чтения XML. Эта квота ограничивает потребление памяти не в самом средстве чтения XML, а в компоненте, использующем средство чтения. Например, когда DataContractSerializer использует средство чтения, защищенное MaxStringContentLength, он не десериализует строки, чей размер превышает указанное в этой квоте значение.

Внимание

Дополнительные сведения о защите данных см. в разделе "Использование XML-Сейф ly".

Примечание.

Проверка конфигурации WCF

Будучи частью процесса сборки в Visual Studio, файлы конфигурации WCF теперь проверяются. Если проверка завершается с ошибкой, то в Visual Studio отображается список ошибок и предупреждений.

Подсказки в редакторе XML

В XML-редакторе Visual Studio отображаются подсказки для каждого элемента конфигурации (и его свойств), входящего в файл конфигурации службы. Это облегчает работу разработчиков по конфигурации WCF-служб.

Улучшения для BasicHttpBinding

Позволяет одной конечной точке WCF отвечать на разные режимы проверки подлинности.
Позволяет IIS контролировать настройки безопасности WCF-службы.