Compartilhar via

Endereços do ponto de extremidade

  • Artigo

Cada ponto de extremidade tem um endereço associado a ele, usado para localizar e identificar o ponto de extremidade. Esse endereço é composto principalmente por um URI (Uniform Resource Identifier), que especifica o local do ponto de extremidade. O endereço do ponto de extremidade é representado no modelo de programação do WCF (Windows Communication Foundation) pela classe EndpointAddress, que contém uma propriedade opcional Identity que permite a autenticação do ponto de extremidade por outros pontos de extremidade que trocam mensagens com ele, e um conjunto de propriedades opcionais Headers, que definem quaisquer outros cabeçalhos SOAP necessários para chegar ao serviço. Os cabeçalhos opcionais fornecem informações de endereçamento adicionais e mais detalhadas para identificar ou interagir com o ponto de extremidade do serviço. O endereço de um ponto de extremidade é representado na transferência como uma EPR (referência de ponto de extremidade WS-Addressing).

Estrutura de URI de um endereço

O URI de endereço para a maioria dos transportes tem quatro partes. Por exemplo, as quatro partes do URI http://www.fabrikam.com:322/mathservice.svc/secureEndpoint podem ser itemizadas da seguinte maneira:

  • Esquema: http:

  • Computador: www.fabrikam.com

  • (opcional) Porta: 322

  • Caminho: /mathservice.svc/secureEndpoint

Definição de um endereço para um serviço

O endereço do ponto de extremidade de um serviço pode ser especificado de forma imperativa usando código ou declarativamente por meio da configuração. A definição de pontos de extremidade no código não costuma ser prática, porque as associações e os endereços de um serviço implantado normalmente são diferentes daqueles usados conforme o serviço está sendo desenvolvido. Geralmente, é mais prático definir pontos de extremidade de serviço usando configuração em vez de código. Manter as informações de endereçamento e associação fora do código permite que elas sejam alteradas sem a necessidade de compilar ou implantar novamente o aplicativo.

Definição de um endereço na configuração

Para definir um ponto de extremidade em um arquivo de configuração, use o elemento <ponto de extremidade>. Para obter detalhes e um exemplo, confira Especificar um endereço de ponto de extremidade.

Definição de um endereço no código

Um endereço de ponto de extremidade pode ser criado no código com a classe EndpointAddress. Para obter detalhes e um exemplo, confira Especificar um endereço de ponto de extremidade.

Pontos de extremidade no WSDL

Um endereço de ponto de extremidade também pode ser representado no WSDL como um elemento EPR WS-Addressing dentro do elemento wsdl:port do ponto de extremidade correspondente. O EPR contém o endereço do ponto de extremidade, bem como quaisquer propriedades de endereço. Para obter detalhes e um exemplo, confira Especificar um endereço de ponto de extremidade.

Suporte à associação múltipla do IIS no .NET Framework 3.5

Os provedores de serviços de Internet geralmente hospedam muitos aplicativos no mesmo servidor e site para aumentar a densidade do site e reduzir o custo total de propriedade. Normalmente, esses aplicativos são associados a endereços básicos diferentes. Um site de IIS (Serviços de Informações da Internet) pode conter vários aplicativos. O aplicativo em um site pode ser acessado por meio de uma ou mais associações do IIS.

Uma associação do IIS fornece duas informações: um protocolo de associação e informações de associação. O protocolo de associação define o esquema sobre o qual a comunicação ocorre e as informações de associação são as informações usadas para acessar o site.

O exemplo a seguir mostra os componentes que podem estar presentes em uma associação do IIS:

  • Protocolo de associação: HTTP

  • Informações de associação: endereço IP, porta, cabeçalho host

O IIS pode especificar várias associações para cada site, o que resulta em vários endereços básicos para cada esquema. Antes do .NET Framework 3.5, o WCF não dava suporte a vários endereços para um esquema e, se foram especificados, lançou um ArgumentException durante a ativação.

O .NET Framework 3.5 permite que os provedores de serviços de Internet hospedem vários aplicativos com endereços básicos diferentes para o mesmo esquema no mesmo site.

Por exemplo, um site pode conter os seguintes endereços básicos:

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

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

Com o .NET Framework 3.5, você especifica um filtro de prefixo no nível AppDomain no arquivo de configuração. Faça isso com o elemento <baseAddressPrefixFilters>, que contém uma lista de prefixos. Os endereços básicos de entrada, fornecidos pelo IIS, são filtrados com base na lista de prefixos opcionais. Por padrão, quando um prefixo não é especificado, todos os endereços são passados. Especificar o prefixo resulta apenas no endereço básico correspondente para que esse esquema seja passado.

Veja a seguir um exemplo de código de configuração que usa os filtros de prefixo.

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

No exemplo anterior, net.tcp://payroll.myorg.com:8000 e http://shipping.myorg.com:8000 são os únicos endereços básicos, para seus respectivos esquemas, que são passados.

baseAddressPrefixFilter não dá suporte a curingas.

Os endereços básicos fornecidos pelo IIS podem ter endereços associados a outros esquemas não presentes na lista baseAddressPrefixFilters. Esses endereços não são filtrados.

Suporte à associação múltipla do IIS no .NET Framework 4 e posterior

A partir do .NET 4, você pode habilitar o suporte a várias associações no IIS sem precisar escolher um único endereço básico definindo a configuração MultipleSiteBindingsEnabled de ServiceHostingEnvironment como true. Esse suporte é limitado a esquemas de protocolo HTTP.

Veja a seguir um exemplo de código de configuração que usa multipleSiteBindingsEnabled no <serviceHostingEnvironment>.

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

Todas as configurações baseAddressPrefixFilters são ignoradas, para protocolos HTTP e não HTTP, quando várias associações de site são habilitadas usando essa configuração.

Para obter detalhes e exemplos, confira Suporte a várias associações de site do IIS e MultipleSiteBindingsEnabled.

Extensão do endereçamento nos Serviços WCF

O modelo de endereçamento padrão dos Serviços WCF usa o URI de endereço de ponto de extremidade para as seguintes finalidades:

  • Especificar o endereço de escuta do serviço, o local no qual o ponto de extremidade escuta mensagens,

  • Especificar o filtro de endereço SOAP, o endereço que um ponto de extremidade espera como um cabeçalho SOAP.

Os valores para cada uma dessas finalidades podem ser especificados separadamente, permitindo várias extensões de endereçamento que abrangem cenários úteis:

  • Intermediários SOAP: uma mensagem enviada por um cliente atravessa um ou mais serviços adicionais que processam a mensagem antes de chegar ao seu destino final. Os intermediários SOAP podem executar várias tarefas, como cache, roteamento, balanceamento de carga ou validação de esquema nas mensagens. Esse cenário é realizado enviando mensagens para um endereço físico separado (via) que direciona o intermediário, em vez de apenas para um endereço lógico (wsa:To) que tem como destino o destino final.

  • O endereço de escuta do ponto de extremidade é um URI privado e é definido como um valor diferente de sua propriedade listenURI.

O endereço de transporte especificado por via é o local para o qual uma mensagem deve ser enviada inicialmente em seu caminho para algum outro endereço remoto especificado pelo parâmetro to no qual o serviço está localizado. Na maioria dos cenários da Internet, o URI via é o mesmo que a propriedade Uri do endereço final to do serviço. Você só diferencia esses dois endereços quando precisar fazer o roteamento manual.

Cabeçalhos de endereçamento

Um ponto de extremidade pode ser abordado por um ou mais cabeçalhos SOAP, além de seu URI básico. Um conjunto de cenários em que isso é útil é um conjunto de cenários intermediários SOAP em que um ponto de extremidade exige que os clientes desse ponto de extremidade incluam cabeçalhos SOAP direcionados a intermediários.

Você pode definir cabeçalhos de endereço personalizados de duas maneiras: usando código ou configuração:

Geralmente, prefere-se a configuração em vez do código, pois ela permite que você altere os cabeçalhos após a implantação.

Endereços de escuta personalizados

Você pode definir o endereço de escuta para um valor diferente do URI do ponto de extremidade. Isso é útil em cenários intermediários em que o endereço SOAP a ser exposto é o de um intermediário SOAP público, enquanto o endereço em que o ponto de extremidade realmente escuta é um endereço de rede privado.

Você pode especificar um endereço de escuta personalizado usando código ou configuração:

  • No código, especifique um endereço de escuta personalizado adicionando uma classe ClientViaBehavior à coleção de comportamento do ponto de extremidade.

  • Na configuração, especifique um endereço de escuta personalizado com o atributo ListenUri do elemento ponto de extremidade<> do serviço.

Filtro de endereço SOAP personalizado

O Uri é usado em conjunto com qualquer propriedade Headers para definir o filtro de endereço SOAP de um ponto de extremidade (AddressFilter). Por padrão, esse filtro verifica se uma mensagem de entrada tem um cabeçalho de mensagem To correspondente ao URI do ponto de extremidade e se todos os cabeçalhos de ponto de extremidade necessários estão presentes na mensagem.

Em alguns cenários, um ponto de extremidade recebe todas as mensagens que chegam no transporte subjacente e não apenas aquelas com o cabeçalho To apropriado. Para habilitar isso, o usuário pode usar a classe MatchAllMessageFilter.

Confira também