Condividi tramite

Formattatore dell'operazione e selettore di operazioni

L'esempio QueryStringFormatter illustra come usare i punti di estendibilità di Windows Communication Foundation (WCF) per consentire i dati dei messaggi in un formato diverso da quello previsto da WCF. Per impostazione predefinita, i formattatori WCF prevedono che i parametri del metodo vengano inclusi nell'elemento soap:body . Nell'esempio viene illustrato come implementare un formattatore di operazioni personalizzato che analizza i dati dei parametri da una stringa di query HTTP GET e richiama metodi usando tali dati.

L'esempio è basato su Getting Started, che implementa il ICalculator contratto di servizio. Illustra come è possibile modificare i messaggi Add, Subtract, Multiply e Divide per usare HTTP GET per le richieste da client a server e HTTP POST con messaggi POX per le risposte da server a client.

A tale scopo, l'esempio fornisce quanto segue:

  • QueryStringFormatter, che implementa IClientMessageFormatter e IDispatchMessageFormatter per il client e il server, rispettivamente, ed elabora i dati nella stringa di query.

  • UriOperationSelector, che implementa IDispatchOperationSelector nel server per eseguire l'invio dell'operazione in base al nome dell'operazione nella richiesta GET.

  • EnableHttpGetRequestsBehavior funzionalità dell'endpoint (e configurazione corrispondente), che aggiunge il selettore di operazione necessario al runtime.

  • Illustra come inserire un nuovo formattatore di operazioni nel runtime.

  • In questo esempio, sia il client che il servizio sono applicazioni console (.exe).

Annotazioni

La procedura di installazione e le istruzioni di compilazione per questo esempio si trovano alla fine di questo argomento.

Concetti chiave

QueryStringFormatter - Il formattatore dell'operazione è il componente in WCF responsabile della conversione di un messaggio in una matrice di oggetti parametro e di una matrice di oggetti parametro in un messaggio. Questa operazione viene eseguita sul client usando l'interfaccia IClientMessageFormatter e sul server con l'interfaccia IDispatchMessageFormatter . Queste interfacce consentono agli utenti di ottenere i messaggi di richiesta e risposta dai metodi Serialize e Deserialize.

In questo esempio implementa QueryStringFormatter entrambe queste interfacce e viene implementata nel client e nel server.

Richiesta:

  • Nell'esempio viene usata la TypeConverter classe per convertire i dati dei parametri nel messaggio di richiesta in e da stringhe. Se un oggetto TypeConverter non è disponibile per un tipo specifico, il formattatore di esempio genera un'eccezione.

  • IClientMessageFormatter.SerializeRequest Nel metodo sul client il formattatore crea un URI con l'indirizzo To appropriato e aggiunge il nome dell'operazione come suffisso. Questo nome viene usato per inviare all'operazione appropriata nel server. Accetta quindi la matrice di oggetti parametro e serializza i dati dei parametri nella stringa di query URI usando i nomi dei parametri e i valori convertiti dalla TypeConverter classe . Le To proprietà e Via vengono quindi impostate su questo URI. MessageProperties è accessibile tramite la Properties proprietà .

  • IDispatchMessageFormatter.DeserializeRequest Nel metodo sul server, il formattatore recupera l'URI Via nelle proprietà del messaggio di richiesta in ingresso. Analizza le coppie nome-valore nella stringa di query URI in nomi di parametri e valori e usa i nomi e i valori dei parametri per popolare la matrice di parametri passati nel metodo . Si noti che l'invio dell'operazione è già stato eseguito, quindi il suffisso del nome dell'operazione viene ignorato in questo metodo.

Risposta:

  • In questo esempio, HTTP GET viene usato solo per la richiesta. Il formattatore delega l'invio della risposta al formattatore originale che sarebbe stato utilizzato per generare un messaggio XML. Uno degli obiettivi di questo esempio è illustrare come è possibile implementare tale formattatore di delega.

Classe UriPathSuffixOperationSelector

L'interfaccia IDispatchOperationSelector consente agli utenti di implementare la propria logica per decidere quale operazione dovrebbe effettuare il dispatch di un particolare messaggio.

In questo esempio, è necessario implementare UriPathSuffixOperationSelector sul server per selezionare l'operazione appropriata perché il nome dell'operazione è incluso nell'URI HTTP GET anziché nella testata dell'azione nel messaggio. L'esempio è configurato per consentire esclusivamente nomi di operazioni senza distinzione di maiuscole.

Il SelectOperation metodo accetta il messaggio in arrivo e cerca l'URI Via nelle relative proprietà del messaggio. Estrae il suffisso del nome dell'operazione dall'URI, cerca una tabella interna per ottenere il nome dell'operazione a cui deve essere inviato il messaggio e restituisce il nome dell'operazione.

Classe "EnableHttpGetRequestsBehavior"

Il UriPathSuffixOperationSelector componente può essere configurato a livello di codice o tramite un comportamento dell'endpoint. L'esempio implementa il EnableHttpGetRequestsBehavior comportamento, specificato nel file di configurazione dell'applicazione del servizio.

Sul server:

L'oggetto OperationSelector è stato impostato sull'implementazione IDispatchOperationSelector.

Per impostazione predefinita, WCF utilizza un filtro per indirizzi a corrispondenza esatta. L'URI nel messaggio in arrivo contiene un suffisso del nome dell'operazione seguito da una stringa di query che contiene i dati dei parametri; pertanto, il comportamento dell'endpoint modifica anche il filtro dell'indirizzo per farlo diventare un filtro basato sulla corrispondenza del prefisso. A questo scopo, usa WCFPrefixEndpointAddressMessageFilter .

Installazione dei formattatori operativi

I comportamenti dell'operazione che specificano i formattatori sono univoci. Un comportamento di questo tipo viene sempre implementato per impostazione predefinita per ogni operazione per creare il formattatore dell'operazione necessario. Tuttavia, questi comportamenti sono simili a un altro comportamento dell'operazione; non sono identificabili da altri attributi. Per installare un comportamento di sostituzione, l'implementazione deve cercare comportamenti specifici del formattatore installati dal caricatore di tipi WCF per impostazione predefinita e sostituirlo o aggiungere un comportamento compatibile per l'esecuzione dopo il comportamento predefinito.

Questi comportamenti dei formattatori dell'operazione possono essere configurati a livello di codice prima di chiamare CommunicationObject.Open o specificando un comportamento dell'operazione eseguito dopo quello predefinito. Tuttavia, non può essere facilmente configurato da un comportamento dell'endpoint (e pertanto dalla configurazione) perché il modello di comportamento non consente a un comportamento di sostituire altri comportamenti o di modificare in altro modo l'albero della descrizione.

Nel client:

L'implementazione IClientMessageFormatter deve essere implementata in modo che possa convertire le richieste in richieste HTTP GET e delegare al formattatore originale per le risposte. Questo viene fatto chiamando il metodo helper EnableHttpGetRequestsBehavior.ReplaceFormatterBehavior.

Questa operazione deve essere eseguita prima di chiamare 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);
}

Sul server:

  • L'interfaccia IDispatchMessageFormatter deve essere implementata in modo che possa leggere le richieste HTTP GET e delegare al formattatore originale per scrivere risposte. Per fare ciò, chiamare lo stesso metodo helper EnableHttpGetRequestsBehavior.ReplaceFormatterBehavior del client (vedere l'esempio di codice precedente).

  • Questa operazione deve essere eseguita prima che Open venga chiamato. In questo esempio viene illustrato come il formattatore viene modificato manualmente prima di chiamare Open. Un altro modo per ottenere la stessa cosa consiste nel derivare una classe da ServiceHost che effettua le chiamate a EnableHttpGetRequestsBehavior.ReplaceFormatterBehavior prima dell'apertura (vedere la documentazione sull'hosting e gli esempi per esempi).

Esperienza utente

Sul server:

  • L'implementazione del server ICalculator non deve essere modificata.

  • Il App.config per il servizio deve usare un'associazione POX personalizzata che imposta l'attributo messageVersion dell'elemento textMessageEncoding su None.

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

  • Il App.config per il servizio deve anche specificare il personalizzato EnableHttpGetRequestsBehavior aggiungendolo alla sezione delle estensioni del comportamento e poi utilizzarlo.

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

  • Aggiungere formattatori delle operazioni prima di chiamare Open.

Nel client:

  • L'implementazione client non deve essere modificata.

  • Il App.config per il client deve usare un'associazione POX personalizzata che imposta l'attributo messageVersion dell'elemento textMessageEncoding su None. Una differenza rispetto al servizio è che il client deve abilitare l'indirizzamento manuale affinché l'indirizzo di destinazione possa essere modificato.

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

  • Il App.config per il client deve specificare la stessa personalizzazione EnableHttpGetRequestsBehavior del server.

  • Aggiungere formattatori delle operazioni prima di chiamare CreateChannel().

Quando si esegue l'esempio, le richieste e le risposte dell'operazione vengono visualizzate nella finestra della console client. Tutte e quattro le operazioni (Aggiungi, Sottrazione, Moltiplicazione e Divisione) devono avere esito positivo.

Per configurare, compilare ed eseguire l'esempio

  1. Assicurati di aver eseguito la procedura di installazione di One-Time per gli esempi di Windows Communication Foundation.

  2. Per compilare la soluzione, seguire le istruzioni riportate in Compilazione degli esempi di Windows Communication Foundation.

  3. Per eseguire l'esempio in una configurazione con computer singolo o incrociato, seguire le istruzioni riportate in Esecuzione degli esempi di Windows Communication Foundation.

  • Last updated on