Udostępnij przez

Formater operacji i selektor operacji

W przykładzie QueryStringFormatter pokazano, jak punkty rozszerzalności programu Windows Communication Foundation (WCF) mogą służyć do zezwalania na dane komunikatów w innym formacie niż oczekiwano w programie WCF. Domyślnie formatery WCF oczekują, że parametry metody zostaną uwzględnione w elemecie soap:body . W przykładzie pokazano, jak zaimplementować niestandardowy formatator operacji, który analizuje dane parametrów z ciągu zapytania w protokole HTTP GET i wywołuje metody, korzystając z tych danych.

Przykład jest oparty na Wprowadzeniu, który implementuje ICalculator umowę serwisową. Pokazuje on, jak można zmienić komunikaty Dodawania, Odejmowania, Mnożenia i Dzielenia, aby używać protokołu HTTP GET dla żądań klient-serwer i żądania HTTP POST z komunikatami POX dla odpowiedzi serwer-klient.

W tym celu przykład zawiera następujące informacje:

  • QueryStringFormatter, który implementuje IClientMessageFormatter i IDispatchMessageFormatter dla klienta i serwera odpowiednio i przetwarza dane w parametrach zapytania.

  • UriOperationSelector, który implementuje IDispatchOperationSelector na serwerze, aby realizować wysyłanie operacji na podstawie nazwy operacji w żądaniu GET.

  • EnableHttpGetRequestsBehavior zachowanie punktu końcowego (i odpowiednia konfiguracja), które dodaje niezbędny selektor operacji do środowiska uruchomieniowego.

  • Pokazuje, jak wstawić nowy formater operacji do środowiska uruchomieniowego.

  • W tym przykładzie zarówno klient, jak i usługa to aplikacje konsolowe (.exe).

Uwaga / Notatka

Procedura instalacji i instrukcje kompilacji dla tego przykładu znajdują się na końcu tego tematu.

Kluczowe pojęcia

QueryStringFormatter - Formater operacji jest składnikiem w programie WCF, który jest odpowiedzialny za konwertowanie komunikatu na tablicę obiektów parametrów i tablicę obiektów parametrów w komunikat. Odbywa się to na kliencie przy użyciu interfejsu IClientMessageFormatter i na serwerze z interfejsem IDispatchMessageFormatter . Te interfejsy umożliwiają użytkownikom otrzymywanie komunikatów żądania i odpowiedzi z metod Serialize i Deserialize.

W tym przykładzie QueryStringFormatter implementuje oba te interfejsy i jest implementowany na kliencie i serwerze.

Żądanie:

  • W przykładzie użyto TypeConverter klasy do konwersji danych parametrów w komunikacie żądania do i z ciągów. Jeśli element TypeConverter nie jest dostępny dla określonego typu, przykładowy formater zgłasza wyjątek.

  • W metodzie IClientMessageFormatter.SerializeRequest na kliencie formater tworzy identyfikator URI z odpowiednim adresem To i dołącza nazwę operacji jako sufiks. Ta nazwa służy do wysyłania do odpowiedniej operacji na serwerze. Następnie pobiera tablicę obiektów parametrów i serializuje dane parametrów do ciągu zapytania identyfikatora URI przy użyciu nazw parametrów i wartości przekonwertowanych przez klasę TypeConverter . Właściwości To i Via są następnie ustawione na ten identyfikator URI. MessageProperties Dostęp do obiektu Properties jest uzyskiwany za pośrednictwem właściwości .

  • W metodzie IDispatchMessageFormatter.DeserializeRequest na serwerze formater pobiera Via identyfikator URI we właściwościach komunikatu żądania przychodzącego. Analizuje pary nazw-wartości w ciągu zapytania URI na nazwy parametrów i wartości oraz używa tych nazw i wartości do wypełnienia tablicy parametrów przekazywanej do metody. Pamiętaj, że operacja wysyłania już wystąpiła, więc sufiks nazwy operacji jest ignorowany w tej metodzie.

Reakcja:

  • W tym przykładzie HTTP GET jest używane tylko do wykonania żądania. Formater deleguje wysyłanie odpowiedzi do oryginalnego formatera, który byłby użyty do wygenerowania komunikatu XML. Jednym z celów tego przykładu jest pokazanie, jak można zaimplementować taki format delegowania.

Klasa UriPathSuffixOperationSelector

Interfejs IDispatchOperationSelector umożliwia użytkownikom implementowanie własnej logiki decydującej, którą operację należy wykonać dla określonego komunikatu.

W tym przykładzie UriPathSuffixOperationSelector musi być zaimplementowane na serwerze, aby wybrać odpowiednią operację, ponieważ nazwa operacji jest zawarta w identyfikatorze URI HTTP GET, a nie w nagłówku akcji w wiadomości. Przykład jest skonfigurowany tak, aby zezwalał tylko na nazwy operacji bez uwzględniania wielkości liter.

Metoda SelectOperation pobiera komunikat przychodzący i wyszukuje identyfikator URI we właściwościach komunikatu Via . Wyodrębnia sufiks nazwy operacji z identyfikatora URI, wyszukuje wewnętrzną tabelę, aby uzyskać nazwę operacji, do którego ma zostać wysłany komunikat, i zwraca tę nazwę operacji.

EnableHttpGetRequestsBehavior class

Składnik UriPathSuffixOperationSelector można skonfigurować programowo lub poprzez zachowanie zdefiniowane na poziomie punktu końcowego. Przykład implementuje EnableHttpGetRequestsBehavior zachowanie, które jest określone w pliku konfiguracji aplikacji usługi.

Na serwerze:

Parametr OperationSelector jest ustawiony na implementację IDispatchOperationSelector .

Domyślnie WCF używa filtru adresu z dokładnym dopasowaniem. Identyfikator URI w wiadomości przychodzącej zawiera sufiks nazwy operacji, po którym następuje ciąg zapytania zawierający dane parametrów, dlatego zachowanie punktu końcowego zmienia również filtr adresu na filtr dopasowania do prefiksu. W tym celu jest używany program WCFPrefixEndpointAddressMessageFilter .

Instalowanie modułów formatujących operacje

Sposoby działania operacji definiujące formatery są wyjątkowe. Jedno z takich zachowań jest zawsze implementowane domyślnie dla każdej operacji, aby utworzyć niezbędny formater operacji. Jednak te zachowania wyglądają jak każde inne zachowanie operacyjne; nie można ich zidentyfikować za pomocą żadnego innego atrybutu. Aby zainstalować zachowanie zastępcze, implementacja musi wyszukać określone zachowania formatera zainstalowane przez moduł ładujący typu WCF domyślnie i zastąpić je lub dodać zgodne zachowanie do uruchomienia po zachowaniu domyślnym.

Te zachowania formatujące operacje można skonfigurować programowo przed wywołaniem CommunicationObject.Open lub przez określenie zachowania operacji wykonywanego po domyślnym. Nie można go jednak łatwo skonfigurować przez zachowanie punktu końcowego (a zatem przez konfigurację), ponieważ model zachowania nie zezwala na zachowanie w celu zastąpienia innych zachowań lub w inny sposób zmodyfikowania drzewa opisu.

Na urządzeniu klienckim:

Implementacja IClientMessageFormatter musi zostać zaimplementowana, aby można było przekonwertować żądania na żądania HTTP GET i delegować je do oryginalnego formatującego odpowiedzi. Odbywa się to przez wywołanie metody pomocniczej EnableHttpGetRequestsBehavior.ReplaceFormatterBehavior .

Należy to zrobić przed wywołaniem metody 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);
}

Na serwerze:

  • Interfejs IDispatchMessageFormatter musi być zaimplementowany, aby można było odczytywać żądania HTTP GET i delegować do oryginalnego formatującego na potrzeby pisania odpowiedzi. Odbywa się to przez wywołanie tej samej EnableHttpGetRequestsBehavior.ReplaceFormatterBehavior metody pomocniczej co klient (zobacz poprzedni przykładowy kod).

  • Należy to zrobić przed wywołaniem Open. W tym przykładzie pokazano, jak formatator jest modyfikowany ręcznie przed wywołaniem metody Open. Innym sposobem osiągnięcia tego samego celu jest dziedziczenie klasy z ServiceHost, która wykonuje wywołania do EnableHttpGetRequestsBehavior.ReplaceFormatterBehavior przed otwarciem (zobacz dokumentację hostingu i przykłady).

Doświadczenie użytkownika

Na serwerze:

  • Implementacja serwera ICalculator nie musi się zmieniać.

  • App.config dla usługi musi używać niestandardowego powiązania POX, które ustawia atrybut messageVersion elementu textMessageEncoding na None.

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

  • App.config dla usługi musi również określać niestandardowy EnableHttpGetRequestsBehavior, dodając go do sekcji rozszerzeń zachowania i używając go w tej samej sekcji.

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

  • Dodaj formatery operacji przed wywołaniem metody Open.

Na urządzeniu klienckim:

  • Implementacja klienta nie musi się zmieniać.

  • App.config dla klienta musi używać niestandardowego wiązania POX, które ustawia atrybut messageVersion elementu textMessageEncoding na None. Jedną z różnic między usługą jest to, że klient musi włączyć ręczne adresowanie, aby można było zmodyfikować adres wychodzący Do.

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

  • App.config dla klienta musi określać ten sam niestandardowy EnableHttpGetRequestsBehavior , co serwer.

  • Dodaj formatery operacji przed wywołaniem metody CreateChannel().

Po uruchomieniu przykładu żądania operacji i odpowiedzi są wyświetlane w oknie konsoli klienta. Wszystkie cztery operacje (dodawanie, odejmowanie, mnożenie i dzielenie) musi zakończyć się powodzeniem.

Aby skonfigurować, skompilować i uruchomić przykładowy program

  1. Upewnij się, że wykonano procedurę instalacji One-Time dla przykładów programu Windows Communication Foundation.

  2. Aby skompilować rozwiązanie, postępuj zgodnie z instrukcjami w temacie Building the Windows Communication Foundation Samples (Tworzenie przykładów programu Windows Communication Foundation).

  3. Aby uruchomić przykład w konfiguracji pojedynczej lub między maszynami, postępuj zgodnie z instrukcjami w Uruchamianie przykładów programu Windows Communication Foundation.

  • Last updated on