Vários pontos de extremidade em um único ListenUri
O exemplo MultipleEndpointsSingleUri demonstra um serviço que hospeda vários pontos de extremidade em um único ListenUri. Este exemplo é baseado na Introdução que implementa um serviço de calculadora.
Nota
O procedimento de configuração e as instruções de compilação para este exemplo estão localizados no final deste tópico.
Conforme demonstrado no exemplo de vários pontos de extremidade , um serviço pode hospedar vários pontos de extremidade, cada um com endereços diferentes e, possivelmente, também associações diferentes. Este exemplo mostra que é possível hospedar vários pontos de extremidade no mesmo endereço. Este exemplo também demonstra as diferenças entre os dois tipos de endereços que um ponto de extremidade de serviço tem: EndpointAddress e ListenUri.
O EndpointAddress é o endereço lógico de um serviço. É o endereço para o qual as mensagens SOAP são endereçadas. O ListenUri é o endereço físico do serviço. Ele tem as informações de porta e endereço onde o ponto de extremidade de serviço realmente escuta mensagens na máquina atual. Na maioria dos casos, não há necessidade de esses endereços diferirem; quando a ListenUri não é explicitamente especificado, ele assume como padrão o URI do ponto de EndpointAddress extremidade. Em alguns casos, é útil distingui-los, como ao configurar um roteador, que pode aceitar mensagens endereçadas a vários serviços diferentes.
Serviço
O serviço nesta amostra tem dois contratos ICalculator e IEcho. Além do ponto de extremidade habitual IMetadataExchange , há três pontos de extremidade de aplicativo, conforme mostrado no código a seguir.
<endpoint address="urn:Stuff"
binding="wsHttpBinding"
contract="Microsoft.ServiceModel.Samples.ICalculator"
listenUri="http://localhost/servicemodelsamples/service.svc" />
<endpoint address="urn:Stuff"
binding="wsHttpBinding"
contract="Microsoft.ServiceModel.Samples.IEcho"
listenUri="http://localhost/servicemodelsamples/service.svc" />
<endpoint address="urn:OtherEcho"
binding="wsHttpBinding"
contract="Microsoft.ServiceModel.Samples.IEcho"
listenUri="http://localhost/servicemodelsamples/service.svc" />
Todos os três pontos de extremidade são hospedados no mesmo ListenUri e usam o mesmo binding - os pontos de extremidade ao mesmo ListenUri tempo devem ter a mesma ligação, porque eles estão compartilhando uma pilha de canal único que escuta mensagens nesse endereço físico na máquina. O address de cada ponto de extremidade é um URN, embora normalmente os endereços representem locais físicos, na verdade o endereço pode ser qualquer tipo de URI, porque o endereço é usado para fins de correspondência e filtragem, como é demonstrado neste exemplo.
Como todos os três pontos de extremidade compartilham o mesmo ListenUri, quando uma mensagem chega lá, o Windows Communication Foundation (WCF) deve decidir a qual ponto de extremidade a mensagem se destina. Cada ponto de extremidade tem um filtro de mensagens que é composto por duas partes: o filtro de endereço e o filtro de contrato. O filtro de endereço corresponde ao To endereço da mensagem SOAP ao endereço do ponto de extremidade do serviço. Por exemplo, apenas as mensagens endereçadas To "Urn:OtherEcho" são candidatas para o terceiro ponto de extremidade deste serviço. O filtro de contrato corresponde às Ações associadas às operações de um contrato específico. Por exemplo, mensagens com a ação de IEcho. Echo Corresponde aos filtros de contrato do segundo e terceiro pontos de extremidade deste serviço, porque ambos os pontos de extremidade hospedam o IEcho contrato.
Assim, a combinação de filtro de endereço e filtro de contrato torna possível rotear cada mensagem que chega a este serviço para o ponto de ListenUri extremidade correto. O terceiro ponto de extremidade é diferenciado dos outros dois porque aceita mensagens enviadas para um endereço diferente dos outros pontos de extremidade. O primeiro e o segundo pontos de extremidade são diferenciados entre si com base em seus contratos (a ação da mensagem recebida).
Cliente
Assim como os pontos de extremidade no servidor têm dois endereços diferentes, os pontos de extremidade do cliente também têm dois endereços. No servidor e no cliente, o endereço lógico é chamado de EndpointAddress. Mas enquanto o endereço físico é chamado ListenUri de no servidor, no cliente, o endereço físico é chamado de Via.
Como no servidor, por padrão, esses dois endereços são os mesmos. Para especificar um Via no cliente que é diferente do endereço do ponto de extremidade, ClientViaBehavior é usado:
Uri via = new Uri("http://localhost/ServiceModelSamples/service.svc");
CalculatorClient calcClient = new CalculatorClient();
calcClient.ChannelFactory.Endpoint.Behaviors.Add(
new ClientViaBehavior(via));
Como de costume, o endereço vem do arquivo de configuração do cliente, que foi gerado por Svcutil.exe. O Via (que corresponde ao ListenUri do serviço) não aparece nos metadados do serviço e, portanto, essas informações devem ser comunicadas ao cliente fora de banda (assim como o endereço de metadados do serviço).
O cliente neste exemplo envia mensagens para cada um dos três pontos de extremidade de aplicativo do servidor, para demonstrar que ele pode se comunicar com (e diferenciar) todos os três pontos de extremidade, mesmo que todos tenham o mesmo Via.
Para configurar, compilar e executar o exemplo
Certifique-se de ter executado o procedimento de instalação única para os exemplos do Windows Communication Foundation.
Para criar a edição C# ou Visual Basic .NET da solução, siga as instruções em Criando os exemplos do Windows Communication Foundation.
Para executar o exemplo em uma configuração de máquina única ou cruzada, siga as instruções em Executando os exemplos do Windows Communication Foundation.
Nota
Para máquinas cruzadas, você deve substituir localhost no arquivo Client.cs pelo nome da máquina de serviço.