Compartir a través de

Formateador de operación y selector de operaciones

En el ejemplo QueryStringFormatter se muestra cómo se pueden usar los puntos de extensibilidad de Windows Communication Foundation (WCF) para permitir los datos de mensajes en un formato diferente de lo que WCF espera. De forma predeterminada, los formateadores WCF esperan que los parámetros de método se incluyan en el soap:body elemento . En el ejemplo se muestra cómo implementar un formateador de operación personalizado que analiza los datos de parámetros de una cadena de consulta HTTP GET en su lugar e invoca métodos mediante esos datos.

La muestra se basa en Primeros pasos, que implementa el contrato de servicio ICalculator. Muestra cómo se pueden cambiar los mensajes Add, Subtract, Multiply y Divide para usar HTTP GET para las solicitudes de cliente a servidor y HTTP POST con mensajes POX para las respuestas de servidor a cliente.

Para ello, el ejemplo proporciona lo siguiente:

  • QueryStringFormatter, que implementa IClientMessageFormatter y IDispatchMessageFormatter para el cliente y el servidor, respectivamente, y procesa los datos en la cadena de consulta.

  • UriOperationSelector, que implementa IDispatchOperationSelector en el servidor para realizar el envío de operaciones en función del nombre de la operación en la solicitud GET.

  • EnableHttpGetRequestsBehavior comportamiento del punto de conexión (y la configuración correspondiente), que agrega el selector de operaciones necesario al entorno de ejecución.

  • Muestra cómo insertar un nuevo formateador de operación en el entorno de ejecución.

  • En este ejemplo, tanto el cliente como el servicio son aplicaciones de consola (.exe).

Nota:

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

Conceptos clave

QueryStringFormatter - El formateador de operación es el componente de WCF responsable de convertir un mensaje en una matriz de objetos de parámetro y una matriz de objetos de parámetro en un mensaje. Esto se hace en el cliente mediante la IClientMessageFormatter interfaz y en el servidor con la IDispatchMessageFormatter interfaz . Estas interfaces permiten a los usuarios obtener los mensajes de solicitud y respuesta de los Serialize métodos y Deserialize .

En este ejemplo, QueryStringFormatter implementa ambas interfaces y se implementa en el cliente y el servidor.

Solicitud:

  • En el ejemplo se usa la TypeConverter clase para convertir datos de parámetros en el mensaje de solicitud hacia y desde cadenas. Si TypeConverter no está disponible para un tipo específico, el formateador de ejemplo lanza una excepción.

  • En el método IClientMessageFormatter.SerializeRequest en el cliente, el formateador crea un URI con la dirección A adecuada y añade el nombre de la operación como un sufijo. Este nombre se utiliza para enviar a la operación adecuada en el servidor. A continuación, toma la matriz de objetos de parámetro y serializa los datos del parámetro en la cadena de consulta URI mediante los nombres de los parámetros y los valores convertidos por la clase TypeConverter. Las propiedades To y Via se establecen en este URI. Se tiene acceso a MessageProperties mediante la propiedad Properties.

  • En el método IDispatchMessageFormatter.DeserializeRequest en el servidor, el formateador recupera el URI Via en las propiedades del mensaje de solicitud entrante. Analiza los pares nombre-valor de la cadena de consulta URI en nombres y valores de parámetros y usa los nombres y valores de los parámetros para rellenar la matriz de parámetros pasados al método . Tenga en cuenta que el despacho de la operación ya se ha producido, por lo que el sufijo del nombre de la operación se omite en este método.

Respuesta:

  • En este ejemplo, HTTP GET solo se usa para la solicitud. El formateador delega el envío de la respuesta al formateador original que se habría usado para generar un mensaje XML. Uno de los objetivos de este ejemplo es mostrar cómo se puede implementar este tipo de formateador que delega.

Clase UriPathSuffixOperationSelector

La IDispatchOperationSelector interfaz permite a los usuarios implementar su propia lógica para determinar a qué operación se debe enviar un mensaje en particular.

En este ejemplo, UriPathSuffixOperationSelector debe implementarse en el servidor para seleccionar la operación adecuada porque el nombre de la operación se incluye en el URI HTTP GET en lugar de un encabezado de acción en el mensaje. El ejemplo está configurado para permitir solo nombres de operaciones que no distingan entre mayúsculas y minúsculas.

El SelectOperation método toma el mensaje entrante y busca el Via URI en sus propiedades de mensaje. Extrae el sufijo de nombre de la operación del URI, busca una tabla interna para obtener el nombre de la operación al que se debe enviar el mensaje y devuelve ese nombre de operación.

Clase EnableHttpGetRequestsBehavior

El UriPathSuffixOperationSelector componente se puede configurar mediante programación o mediante un comportamiento de punto de conexión. El ejemplo implementa el EnableHttpGetRequestsBehavior comportamiento, que se especifica en el archivo de configuración de la aplicación del servicio.

En el servidor:

OperationSelector está establecido en la implementación IDispatchOperationSelector.

De forma predeterminada, WCF usa un filtro de direcciones de coincidencia exacta. El URI del mensaje entrante contiene un sufijo de nombre de operación seguido de una cadena de consulta que contiene datos de parámetros, por lo que el comportamiento del punto de conexión también cambia el filtro de direcciones para que sea un filtro de coincidencia de prefijo. Usa WCFPrefixEndpointAddressMessageFilter para este propósito.

Instalación de formateadores de operaciones

Los comportamientos operativos que especifican los formateadores son únicos. Uno de estos comportamientos siempre se implementa de forma predeterminada para cada operación para crear el formateador de operación necesario. Sin embargo, estos comportamientos tienen un aspecto similar a otro comportamiento de operación; no son identificables por ningún otro atributo. Para instalar un comportamiento de reemplazo, la implementación debe buscar comportamientos de formateador específicos instalados por el cargador de tipos WCF de forma predeterminada y reemplazarlo o agregar un comportamiento compatible para ejecutarse después del comportamiento predeterminado.

Estos comportamientos de los formateadores de operación se pueden configurar mediante programación, bien programándolos antes de llamar a CommunicationObject.Open, o especificando un comportamiento de operación que se ejecute después del predeterminado. Sin embargo, no se puede configurar fácilmente a través de un comportamiento de punto de conexión (y por lo tanto mediante configuración) porque el modelo de comportamiento no permite que un comportamiento reemplace a otros o modifique el árbol de descripciones.

En el cliente:

La IClientMessageFormatter implementación debe implementarse para que pueda convertir las solicitudes en solicitudes HTTP GET y delegarlas en el formateador original para las respuestas. Para ello, se llama al EnableHttpGetRequestsBehavior.ReplaceFormatterBehavior método auxiliar.

Esto debe hacerse antes de llamar a CreateChannel.

void ReplaceFormatterBehavior(OperationDescription operationDescription, EndpointAddress address)
{
    // Remove the DataContract behavior if it is present.
    IOperationBehavior formatterBehavior = operationDescription.Behaviors.Remove<DataContractSerializerOperationBehavior>();
    if (formatterBehavior == null)
    {
        // Remove the XmlSerializer behavior if it is present.
        formatterBehavior = operationDescription.Behaviors.Remove<XmlSerializerOperationBehavior>();
        ...
    }

    // Remember what the innerFormatterBehavior was.
    DelegatingFormatterBehavior delegatingFormatterBehavior = new DelegatingFormatterBehavior(address);
    delegatingFormatterBehavior.InnerFormatterBehavior = formatterBehavior;
   operationDescription.Behaviors.Add(delegatingFormatterBehavior);
}

En el servidor:

  • La IDispatchMessageFormatter interfaz debe implementarse para que pueda leer solicitudes HTTP GET y delegarlas en el formateador original para escribir respuestas. Para ello, se llama al mismo EnableHttpGetRequestsBehavior.ReplaceFormatterBehavior método auxiliar que el cliente (consulte el ejemplo de código anterior).

  • Este paso se debe realizar antes de llamar a Open. En este ejemplo, mostramos cómo el formateador se modifica manualmente antes de llamar a Open. Otra manera de lograr lo mismo es derivar una clase de ServiceHost que realice las llamadas a EnableHttpGetRequestsBehavior.ReplaceFormatterBehavior antes de abrir (consulte la documentación de hospedaje y ejemplos para obtener ejemplos).

Experiencia del usuario

En el servidor:

  • La implementación del servidor ICalculator no necesita cambiar.

  • El App.config del servicio debe usar un enlace POX personalizado que establezca el atributo messageVersion del elemento textMessageEncoding a None.

    <bindings>
  <customBinding>
    <binding name="poxBinding">
      <textMessageEncoding messageVersion="None" />
      <httpTransport />
    </binding>
  </customBinding>
</bindings>

  • App.config para el servicio también debe especificar el EnableHttpGetRequestsBehavior personalizado agregándolo a la sección de extensiones de comportamiento y utilizándolo.

    <behaviors>
  <endpointBehaviors>
    <behavior name="enableHttpGetRequestsBehavior">
      <enableHttpGetRequests />
    </behavior>
  </endpointBehaviors>
</behaviors>

<extensions>
  <behaviorExtensions>
    <!-- Enabling HTTP GET requests: Behavior Extension -->
    <add
      name="enableHttpGetRequests"           type="Microsoft.ServiceModel.Samples.EnableHttpGetRequestsBehaviorElement, QueryStringFormatter, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  </behaviorExtensions>
</extensions>

  • Agregue los formateadores de operación antes de llamar a Open.

En el cliente:

  • La implementación del cliente no necesita cambiar.

  • El App.config para el cliente debe usar un enlace POX personalizado que establezca el atributo messageVersion del elemento textMessageEncoding en None. Una diferencia con respecto al servicio es que el cliente debe habilitar el direccionamiento manual para que se pueda modificar la dirección de destino.

    <bindings>
  <customBinding>
    <binding name="poxBinding">
      <textMessageEncoding messageVersion="None" />
      <httpTransport manualAddressing="True" />
    </binding>
  </customBinding>
</bindings>

  • App.config para el cliente debe especificar el mismo EnableHttpGetRequestsBehavior personalizado que el servidor.

  • Agregue los formateadores de operación antes de llamar a CreateChannel().

Al ejecutar el ejemplo, las solicitudes de operación y las respuestas se muestran en la ventana de la consola del cliente. Las cuatro operaciones (Agregar, Restar, Multiplicar y Dividir) deben realizarse correctamente.

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 la solución, siga las instrucciones que se indican en Compilación de los ejemplos de Windows Communication Foundation.

  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.