Enrutador intermediario

Download sample

Este ejemplo muestra cómo implementar un servicio que proporciona la funcionalidad de enrutamiento básico útil en configuraciones de red donde los clientes no pueden tener acceso directamente a los servicios. El ejemplo no es un ejemplo de un enrutador eficaz, escalable con una multitud de características.

Nota

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

En un escenario de comunicación típico que involucra a los intermediarios de SOAP, un mensaje enviado por un cliente atraviesa uno o más servicios adicionales antes de alcanzar su destino final, el servicio que realmente procesa el mensaje y proporciona una respuesta, si es que se espera una. Un intermediario de SOAP puede realizar varias acciones en el mensaje que está atravesándolo. Por ejemplo, un intermediario de almacenamiento en caché devolvería una respuesta almacenada en memoria caché al mensaje, que alivia la tensión en el servicio que tendría que procesar de nuevo la solicitud. Un intermediario del equilibrio de carga utilizaría un algoritmo de la operación por turnos para reenviar el mensaje a uno de los muchos servicios potenciales. Un intermediario de validación de esquema sólo reenviaría mensajes que son totalmente compatibles con el XSD del contrato y, posiblemente, otros protocolos. El intermediario desarrollado para este ejemplo es responsable de enrutar los mensajes a un servicio adecuado basado en los encabezados y el contenido del mensaje.

En este ejemplo, se han implementado dos servicios de aplicación para procesar solicitudes de clientes: un servicio de calculadora y uno de eco. Sólo se puede acceder a los extremos de la aplicación del servicio desde la red interna. Los extremos de intercambio (MEX) de metadatos del servicio son de acceso público. El enrutador de SOAP forma parte de la red interna y todas las solicitudes de la aplicación que provienen de fuera de la red interna deben atravesarlo.

El cliente se creó ejecutando la Service Model Metadata Utility Tool (Svcutil.exe) en ambos servicios para generar dos archivos de código (un cliente para cada servicio) y un archivo de configuración cuando Svcutil.exe combina la información de configuración del segundo servicio en el archivo de configuración existente creado cuando Svcutil.exe se ejecutó en el primer servicio. El Lenguaje de descripción de servicios web (WSDL) proporcionado por cada servicio contiene la dirección del intermediario de SOAP en lugar de la dirección del servicio real. Esto libera al cliente de modificar el archivo de configuración o de conocer cuál es la dirección del intermediario de SOAP.

Además, el servicio del enrutador en este ejemplo se configura con dos extremos: uno que escucha los mensajes codificados de texto usando HTTP para SOAP 1.2 y el otro que realiza escuchas para los mensajes codificados binarios utilizando TCP para SOAP 1.2. El WSDL de cada servicio de aplicación utiliza la dirección del extremo correcta en el enrutador. El enrutador se proporciona con información de enrutamiento en la sección appSettings del archivo de configuración que contiene las propiedades siguientes:

• prefixes y namespaces: utilizado para actualizar el XmlNamespaceManager predeterminado en WCF de manera que sabe cómo resolver los prefijos situados en XPaths del enrutador.

• xpath y epr: usado para agregar las entradas de enrutamiento a la tabla de enrutamiento que asigna XPaths a EPRs.

El enrutador utiliza la clase XpathMessageFilterTable (XPathFilterTable<T>), donde "T" es un EndpointAddress que almacena las entradas del enrutamiento que el usuario proporciona. Cuando se recibe un mensaje, el enrutador llama al método MatchMultiple que pasa en una instancia Message y recupera un EndpointAddress al que reenvía el mensaje.

EchoService y CalculatorService utilizan la propiedad ListenUri para establecer el URI en el que el extremo está realizando escuchas. La dirección proporcionada dentro de la declaración del extremo es la dirección del extremo del enrutador que es capaz de reenviar los mensajes del servicio. Ésta es la dirección que aparece en el WSDL del servicio y la dirección que coincide con Toheader de WS-Addressing de cada mensaje entrante. Sin embargo, la dirección proporcionada por la propiedad ListenUri es la dirección de escucha física real del extremo que sólo utiliza el transporte.

WCF proporciona otro comportamiento que se utiliza normalmente en escenarios intermediarios de SOAP que este ejemplo no ejercita: el comportamiento de canal de ClientViaBehavior. Los clientes utilizan ClientViaBehavior para especificar el URI para el que se debería crear el canal de transporte. Si este tipo de comportamiento existe en la colección de comportamiento en un extremo del cliente, el transporte utiliza el URI que proporciona, mientras el resto de niveles del canal en la pila usan la EndpointAddress proporcionada en el momento de construcción ChannelFactory. Este EndpointAddress también se convierte en Toheader de WS-Addressing. El código de ejemplo siguiente muestra cómo se utiliza este comportamiento.

ChannelFactory<IContract> factory = new ChannelFactory<IContract>(new EndpointAddress("http://hostname/service"));
factory.Endpoint.Behaviors.Add(new ViaUriBehavior(new Uri("http://hostname/intermediary")));
IContract channel = factory.CreateChannel(); 

Otra característica de WCF que se utiliza con intermediarios de SOAP es la propiedad AddressFilter. WCF utiliza AddressFilter para aceptar sólo los mensajes que coinciden con un filtro determinado. Si los métodos del contrato de servicio utilizan "*" como Action, sólo se comprobará la dirección. Este ejemplo no utiliza esta característica porque la dirección siempre es correcta. El enrutador acepta los mensajes del cliente porque Toheaders coincide con su dirección del extremo y los servicios aceptan mensajes que se reenviaron a ellos porque Toheader coincide con la dirección lógica del extremo.

El archivo Contracts.cs del ejemplo define las cuatro interfaces siguientes, una para cada modelo de transporte:

• ISimplexDatagramRouter. Es necesario que esta interfaz acepte los mensajes en canales de datagrama símplex. Agregue un extremo mediante esta interfaz si espera los mensajes en canales HTTP unidireccionales, o TCP y NamedPipe unidireccionales.

• IRequestReplyDatagramRouter. Exigen a esta interfaz que acepte los mensajes en canales de datagrama de solicitud-respuesta. Utilice esta interfaz para los mensajes en un canal HTTP bidireccional.

• ISimplexSessionRouter. Esta interfaz debe aceptar los mensajes en canales con sesión símplex. Utilice esta interfaz para los canales TCP y NamedPipe símplex.

• IDuplexSessionRouter. Esta interfaz es para los canales de sesión dúplex. Utilice esta interfaz para los canales TCP y NamedPipe dúplex.

RouterBinding proporciona un ejemplo de un enlace de WCF que puede crear para admitir al intermediario de SOAP. Le permite especificar los valores más comunes que puede necesitar en este escenario y garantiza que sólo se agregarán los elementos de enlace que sean verdaderamente necesarios. También se muestra la compatibilidad de configuración básica.

Este ejemplo no utiliza el alojamiento web porque confía en transportes distintos de HTTP. La activación de TCP sólo está actualmente disponible en Windows Vista e IIS 7.0.

Al ejecutar el ejemplo, las solicitudes y respuestas de la operación se muestran en la ventana de la consola del cliente. Presione ENTRAR en la ventana de cliente para cerrar el cliente.

Echo("Is anyone there?") returned: Is anyone there?
Add(5) returned: 5
Add(-3) returned: 2

Para configurar, generar y ejecutar el ejemplo

1. Para generar el código C#, C++ o Visual Basic .NET Edition de la solución, siga las instrucciones de Generación de ejemplos de Windows Communication Foundation.

2. Para ejecutar el ejemplo en una configuración de equipos única o cruzada, siga las instrucciones de Ejecución de ejemplos de Windows Communication Foundation con las excepciones siguientes.

   1. Tanto en las configuraciones de equipos única como cruzada, son necesarios cuatro proyectos y cuatro aplicaciones ejecutables, una para el cliente, una para el enrutador de SOAP y una para cada servicio de aplicación.

   2. En una configuración de equipos cruzada, se deben realizar los cambios siguientes en los cuatro archivos de configuración.

      El archivo App.config para CalculatorService y EchoService debe cambiarse en la línea 21. El nombre de host real del intermediario debe reemplazar el nombre del host local.

      Se debe cambiar el archivo App.config en la línea 15. Las dos direcciones (separadas con una '|') se deben cambiar con el nombre del host de EchoService y CalculatorService, respectivamente.

      El archivo App.config del cliente debe cambiarse en las líneas 5 y 7. El nombre de host real del intermediario debe reemplazar el nombre del host local.

      Puede utilizar también la Service Model Metadata Utility Tool (Svcutil.exe) en los dos servicios de aplicación (una vez actualizados para utilizar la dirección correcta) y volver a generar los archivos App.config.

3. Asegúrese de que Router, EchoService y CalculatorService se ejecutan antes de iniciar el cliente. Cada uno de los tres servicios imprime las direcciones del extremo en las que están escuchando al iniciar.

   Nota

   El extremo de la aplicación de EchoService y CalculatorService utiliza la dirección del enrutador.

4. Ejecute el cliente. El cliente se pone en contacto primero con EchoServicey después con CalculatorService. Router imprime las acciones de WS-Addressing de mensajes que está reenviando en ambas direcciones.

   Nota

   Si Client.exe y Router.exe están en equipos independientes, quite los comentarios de la sección <identity/> en Client.exe.config y establezca el nombre principal del usuario en el que esté ejecutando Router.exe.

Copyright © 2007 Microsoft Corporation. Reservados todos los derechos.