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

2025-06-17

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

Структура URI адреса

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

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

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

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

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

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

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

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

Конечные точки в WSDL

Адрес конечной точки можно также представить в WSDL как элемент WS-Addressing EPR внутри элемента соответствующей конечной точки 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.

Ниже приведен пример кода конфигурации, который использует параметр multipleSiteBindingsEnabled в <serviceHostingEnvironment>.

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

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

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

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

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

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

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

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

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

Адресация заголовков

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

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

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

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

Настраиваемые адреса прослушивания

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

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

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

Настраиваемый фильтр адресов SOAP

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

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