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

Статья
02/28/2011

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

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

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

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

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

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

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

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

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

Адрес конечной точки можно создать в коде с помощью класса 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 позволяет поставщикам услуг Интернета размещать на одном сайте несколько приложений с различными базовыми адресами в рамках одной схемы.

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

Платформа .NET Framework 3.5 позволяет задать в файле конфигурации фильтр префикса на уровне домена приложения. Для этого следует воспользоваться элементом <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:9000 являются единственными базовыми адресами для соответствующих схем, которые будут пропущены.

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

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

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

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

Ниже приведен пример кода конфигурации, в котором используется атрибут multipleSiteBindingsEnabled элемента <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;
в файле конфигурации пользовательские значения <headers><endpoint> задаются в качестве дочерних элементов элемента.

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

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

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

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

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

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

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

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

См. также

Основные понятия

Задание адреса конечной точки
Идентификация и проверка подлинности службы

Поделиться через