Адреса конечных точек

Статья
04/08/2023

С каждой конечной точкой связан адрес, который используется для поиска и идентификации этой конечной точки. Этот адрес в первую очередь включает универсальный код ресурса (URI), задающий расположение конечной точки. Адрес конечной точки представлен в модели EndpointAddress программирования Windows Communication Foundation (WCF) классом, который содержит необязательное свойство, которое обеспечивает проверку подлинности конечной точки другими конечными точками, которые обмениваются сообщениями с ним, и набор необязательных Identity Headers свойств, которые определяют любые другие заголовки SOAP, необходимые для достижения службы. Необязательные заголовки содержат дополнительную и более подробную информацию для идентификации конечной точки службы и взаимодействия с ней. При передаче данных по каналам связи адрес конечной точки представляется ссылкой на конечную точку WS-Addressing.

Структура универсального кода ресурса (URI) адреса

Универсальный код ресурса (URI) адреса для большинства видов транспорта состоит из четырех частей. Например, четыре части универсального кода ресурса (URI) http://www.fabrikam.com:322/mathservice.svc/secureEndpoint можно указать следующим образом:

Схема: http:
Машина: www.fabrikam.com
(необязательно) Порт: 322
Путь: /mathservice.svc/secureEndpoint

Определение адреса службы

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

Определение адреса в файле конфигурации

Чтобы определить конечную точку в файле конфигурации, используйте элемент конечной <точки> . Дополнительные сведения и пример см. в разделе "Указание адреса конечной точки".

Определение адреса в коде

Адрес конечной точки можно создать в коде с помощью класса EndpointAddress. Дополнительные сведения и пример см. в разделе "Указание адреса конечной точки".

Конечные точки на языке WSDL

Адрес конечной точки также может быть представлен на языке WSDL в виде элемента EPR WS-Addressing в элементе wsdl:port соответствующей конечной точки. Ссылка на конечную точку (EPR) содержит адрес конечной точки и любые свойства адреса. Дополнительные сведения и пример см. в разделе "Указание адреса конечной точки".

Поддержка нескольких привязок IIS в платформа .NET Framework 3.5

Поставщики услуг Интернета часто размещают большое число приложений на одном сайте и сервере, чтобы повысить эффективность использования сайта и сократить совокупную стоимость владения. Эти приложения обычно привязываются к различным базовым адресам. Веб-сайт служб IIS может содержать несколько приложений. Доступ к приложениям на сайте может осуществляться через одну или несколько привязок служб IIS.

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

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

Протокол привязки: HTTP
Данные привязки: IP-адрес, порт, заголовок узла

Службы IIS поддерживают задание нескольких привязок для каждого сайта, что позволяет использовать несколько базовых адресов для каждой схемы. До платформа .NET Framework 3.5 WCF не поддерживал несколько адресов для схемы и, если они были указаны, бросили ArgumentException во время активации.

Платформа .NET Framework 3.5 позволяет поставщикам услуг Интернета размещать несколько приложений с разными базовыми адресами для одной схемы на одном сайте.

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

http://payroll.myorg.com/Service.svc
http://shipping.myorg.com/Service.svc

В платформа .NET Framework 3.5 в файле конфигурации укажите фильтр префикса на уровне appDomain. Для этого <используется элемент baseAddressPrefixFilters> , содержащий список префиксов. Входящие базовые адреса, предоставляемые службами IIS, фильтруются с использованием необязательно списка префиксов. Если префикс не задан, по умолчанию пропускаются все адреса. При задании префикса разрешается прохождение данных только с соответствующего базового адреса для данной схемы.

Ниже приведен пример кода конфигурации, в котором используются фильтры префиксов.

<system.serviceModel>  
  <serviceHostingEnvironment>  
     <baseAddressPrefixFilters>  
        <add prefix="net.tcp://payroll.myorg.com:8000"/>  
        <add prefix="http://shipping.myorg.com:8000"/>  
    </baseAddressPrefixFilters>  
  </serviceHostingEnvironment>  
</system.serviceModel>

В предыдущем примере net.tcp://payroll.myorg.com:8000 и http://shipping.myorg.com:8000 являются единственными базовыми адресами для соответствующих схем, которые передаются.

Элемент baseAddressPrefixFilter не поддерживает подстановочные знаки.

Среди базовых адресов, предоставляемых службами IIS, могут присутствовать адреса, привязанные к другим схемам, не представленным в списке baseAddressPrefixFilters. Эти адреса не фильтруются.

Поддержка нескольких привязок служб IIS в платформе .NET Framework 4 и более поздних версиях

Начиная с .NET 4, в службах IIS можно включить поддержку нескольких привязок, при этом не требуется выбирать один базовый адрес. Для этого атрибуту ServiceHostingEnvironment элемента MultipleSiteBindingsEnabled необходимо задать значение true. Эта поддержка обеспечивается только для схем протокола HTTP.

Ниже приведен пример кода конфигурации, использующего несколькоSiteBindingsEnabled в serviceHostingEnvironment>.<

<system.serviceModel>  
  <serviceHostingEnvironment multipleSiteBindingsEnabled="true" >  
  </serviceHostingEnvironment>  
</system.serviceModel>

Если с помощью этого параметра включены несколько привязок к узлам, все параметры baseAddressPrefixFilters не учитываются как для протокола HTTP, так и для других протоколов.

Дополнительные сведения и примеры см. в разделе "Поддержка нескольких привязок сайта IIS" и MultipleSiteBindingsEnabled.

Расширение модели адресов в службах WCF

Модель адресации по умолчанию служб WCF использует URI адреса конечной точки для следующих целей:

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

Значения в каждом из этих случаев могут задаваться отдельно, что позволяет реализовать несколько расширений модели адресов, которые можно использовать в следующих сценариях:

посредники протокола SOAP: сообщение, отправляемое клиентом, проходит через одну или несколько дополнительных служб, обрабатывающих это сообщение, прежде чем оно достигнет конечной точки назначения. Посредники протокола SOAP могут выполнять с сообщениями различные задачи, например кэширование, маршрутизацию или проверку схемы. Этот сценарий также можно реализовать путем отправки сообщения по отдельному физическому адресу (via), нацеленному на посредник, а не просто по логическому адресу (wsa:To), который нацелен на конечную точку назначения;
адрес ожидания передачи данных конечной точки является закрытым универсальным кодом ресурса (URI) и имеет значение, отличное от значения свойства listenURI.

Адрес транспорта, задаваемый параметром via, определяет расположение, через которое сообщение должно предварительно пройти по пути на какой-либо другой удаленный адрес, задаваемый параметром to и определяющий расположение службы. В большинстве случаев работы через Интернет значение универсального кода ресурса (URI) via совпадает со значением свойства Uri конечного адреса to службы. При осуществлении маршрутизации вручную приходится выбирать только между этими двумя адресами.

Заголовки адресов

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

Пользовательские заголовки адресов можно определять двумя способами - с помощью кода или файла конфигурации:

в коде создайте пользовательские заголовки адреса с помощью класса AddressHeader, а затем используйте их в конструкторе класса EndpointAddress;
В конфигурации пользовательские <заголовки> указываются в качестве дочерних элементов конечной <точки>.

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

Пользовательские адреса ожидания передачи данных

Можно задать адрес ожидания передачи данных, который отличается от универсального кода ресурса (URI) конечной точки. Это бывает удобно в сценариях с посредниками, когда предоставляемый адрес SOAP является адресом открытого посредника протокола SOAP, а адрес, по которому конечная точка ожидает передачи данных, является закрытым сетевым адресом.

Пользовательский адрес ожидания передачи данных можно задать с помощью кода или файла конфигурации:

для задания пользовательского адреса ожидания передачи данных в коде необходимо добавить класс ClientViaBehavior в коллекцию расширений функциональности конечной точки;
В конфигурации укажите пользовательский адрес прослушивания с ListenUri атрибутом элемента конечной точки> службы<.

Пользовательский фильтр адресов SOAP

Свойство Uri в сочетании со свойством Headers позволяет определить фильтр адресов SOAP конечной точки (AddressFilter). По умолчанию этот фильтр проверяет, что заголовок To входящего сообщения совпадает с универсальным кодом ресурса (URI) конечной точки и что в сообщении имеются все обязательные заголовки конечной точки.

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