Varios puntos de conexión en un ListenUri único

El ejemplo MultipleEndpointsSingleUri muestra un servicio que hospeda varios puntos de conexión en un único ListenUri. Este ejemplo se basa en la Guía de inicio que implementa un servicio de calculadora.

Nota:

El procedimiento de instalación y las instrucciones de compilación de este ejemplo se encuentran al final de este tema.

Como se muestra en el ejemplo Varios puntos de conexión , un servicio puede hospedar varios puntos de conexión, cada uno con direcciones diferentes y, posiblemente, enlaces diferentes. En este ejemplo se muestra que es posible hospedar varios puntos de conexión en la misma dirección. En este ejemplo también se muestran las diferencias entre los dos tipos de direcciones que tiene un punto de conexión de servicio: EndpointAddress y ListenUri.

EndpointAddress es la dirección lógica de un servicio. Es la dirección a la que se dirigen los mensajes SOAP. ListenUri es la dirección física del servicio. Tiene el puerto y direcciona la información hacia donde el punto de conexión del servicio realmente realiza escuchas para los mensajes en el equipo actual. En la mayoría de los casos, no es necesario que estas direcciones sean diferentes; cuando ListenUri no se especifica explícitamente, este toma como valor predeterminado el URI del EndpointAddress del punto de conexión. En algunos casos, resulta útil distinguirlos, como al configurar un enrutador, que podría aceptar mensajes dirigidos a una serie de servicios diferentes.

Servicio

El servicio de este ejemplo tiene dos contratos, ICalculator y IEcho. Además del punto de conexión habitual IMetadataExchange , hay tres puntos de conexión de aplicación, como se muestra en el código siguiente.

<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" />

Los tres puntos de conexión se hospedan en el mismo ListenUri y usan la misma binding : los puntos de conexión en el mismo ListenUri deben tener la misma vinculación, ya que comparten una única pila de canales que escucha los mensajes en esa dirección física del equipo. El address de cada punto de conexión es un URN; aunque normalmente las direcciones representan ubicaciones físicas, de hecho la dirección puede ser cualquier tipo de URI, ya que la dirección se usa para fines coincidentes y de filtrado, como se muestra en este ejemplo.

Dado que los tres puntos de conexión comparten el mismo ListenUri, cuando llega un mensaje allí, Windows Communication Foundation (WCF) debe decidir para qué punto de conexión está destinado el mensaje. Cada punto de conexión tiene un filtro de mensajes que consta de dos partes: el filtro de direcciones y el filtro de contrato. El filtro de direcciones hace coincidir el To del mensaje SOAP con la dirección del punto de conexión del servicio. Por ejemplo, solo los mensajes dirigidos To "Urn:OtherEcho" son candidatos para el tercer punto de conexión de este servicio. El filtro del contrato coincide con las Acciones asociadas a las operaciones de un contrato determinado. Por ejemplo, los mensajes con la acción de IEcho. Echo coincide con los filtros de contrato del segundo y tercer extremos de este servicio, porque ambos de esos extremos hospedan el contrato IEcho.

Por lo tanto, la combinación de filtro de dirección y filtro de contratos permite enrutar cada mensaje que llega a este servicio ListenUri al punto de conexión correcto. El tercer punto de conexión se diferencia de los otros dos porque acepta mensajes enviados a una dirección diferente de los demás puntos de conexión. Los primeros y segundos puntos de conexión se diferencian entre sí basándose en sus contratos (la acción del mensaje entrante).

Cliente

Al igual que los puntos de conexión del servidor tienen dos direcciones diferentes, los puntos de conexión de cliente también tienen dos direcciones. En el servidor y el cliente, la dirección lógica se denomina EndpointAddress. Pero mientras que la dirección física se llama al ListenUri en el servidor, en el cliente, la dirección física se denomina Via.

Como en el servidor, de forma predeterminada, estas dos direcciones son las mismas. Para especificar un Via en el cliente que es diferente de la dirección del punto de conexión, ClientViaBehavior se usa:

Uri via = new Uri("http://localhost/ServiceModelSamples/service.svc");
CalculatorClient calcClient = new CalculatorClient();
calcClient.ChannelFactory.Endpoint.Behaviors.Add(
        new ClientViaBehavior(via));

Como de costumbre, la dirección procede del archivo de configuración del cliente, que se generó mediante Svcutil.exe. ( Via que corresponde al ListenUri del servicio) no aparece en los metadatos del servicio y, por tanto, esta información debe comunicarse al cliente fuera de banda (al igual que la dirección de metadatos del servicio).

El cliente de este ejemplo envía mensajes a cada uno de los tres puntos de conexión de aplicación del servidor, para demostrar que puede comunicarse con (y diferenciar) los tres puntos de conexión, aunque todos tengan el mismo Via.

Para configurar, compilar y ejecutar el ejemplo

1. Asegúrese de que ha realizado el procedimiento de instalación única para los ejemplos de Windows Communication Foundation.

2. Para compilar el código C# o Visual Basic .NET Edition de la solución, siga las instrucciones de Building the Windows Communication Foundation Samples.

3. Para ejecutar el ejemplo en una configuración de una máquina única o entre máquinas, siga las instrucciones de Ejecución de los ejemplos de Windows Communication Foundation.

   Nota:

   En el caso de uso entre máquinas, debe reemplazar "localhost" en el archivo "Client.cs" por el nombre de la máquina de servicio.