Udostępnij za pośrednictwem

Wybieranie kodera komunikatów

  • Artykuł

W tym artykule omówiono kryteria wyboru między koderami komunikatów, które są zawarte w programie Windows Communication Foundation (WCF): binarnym, tekstowym i mechanizmem optymalizacji transmisji komunikatów (MTOM).

W programie WCF określasz sposób przesyłania danych między siecią między punktami końcowymi za pomocą powiązania, które składa się z sekwencji elementów powiązania. Koder komunikatów jest reprezentowany przez element powiązania kodowania komunikatów w stosie powiązań. Powiązanie zawiera opcjonalne elementy powiązania protokołu, takie jak element powiązania zabezpieczeń lub element powiązania niezawodnej obsługi komunikatów, wymagany element powiązania kodowania komunikatów i wymagany element powiązania transportu.

Element powiązania kodowania komunikatów znajduje się poniżej opcjonalnych elementów powiązania protokołu i powyżej wymaganego elementu powiązania transportu. Po stronie wychodzącej koder komunikatów serializuje wychodzące Message i przekazuje go do transportu. Po stronie przychodzącej koder komunikatów odbiera serializowaną formę Message elementu z transportu i przekazuje go do wyższej warstwy protokołu, jeśli istnieje, lub do aplikacji, jeśli nie.

Podczas nawiązywania połączenia ze wstępnie istniejącym klientem lub serwerem może nie być konieczne użycie określonego kodowania komunikatów, ponieważ konieczne jest kodowanie komunikatów w sposób oczekiwany po drugiej stronie. Jeśli jednak piszesz usługę WCF, możesz uwidocznić usługę za pośrednictwem wielu punktów końcowych, z których każda korzysta z innego kodowania komunikatów. Dzięki temu klienci mogą wybrać najlepsze kodowanie do rozmowy z usługą za pośrednictwem punktu końcowego, który jest dla nich najlepszy, a także zapewnić klientom elastyczność wyboru kodowania, które jest dla nich najlepsze. Korzystanie z wielu punktów końcowych umożliwia również łączenie zalet różnych kodowań komunikatów z innymi elementami powiązania.

Kodery dostarczone przez system

Program WCF zawiera trzy kodery komunikatów, które są reprezentowane przez następujące trzy klasy:

  • TextMessageEncodingBindingElement, koder komunikatów tekstowych, obsługuje zarówno zwykłe kodowanie XML, jak i kodowanie SOAP. Zwykły tryb kodowania XML kodera komunikatów tekstowych nosi nazwę "zwykły stary kod XML" (POX), aby odróżnić go od kodowania SOAP opartego na tekście. Aby włączyć funkcję MessageVersion POX, ustaw właściwość na None. Użyj kodera komunikatów tekstowych, aby współdziałać z punktami końcowymi innych niż WCF.

  • BinaryMessageEncodingBindingElement, koder komunikatów binarnych, używa kompaktowego formatu binarnego i jest zoptymalizowany pod kątem komunikacji WCF z usługą WCF i dlatego nie jest możliwy do współdziałania. Jest to również najbardziej wydajny koder wszystkich koderów WCF.

  • MtomMessageEncodingBindingElement, element powiązania, określa kodowanie znaków i przechowywanie wersji komunikatów dla komunikatów przy użyciu kodowania MTOM. MTOM to wydajna technologia przesyłania danych binarnych w komunikatach WCF. Koder MTOM próbuje utworzyć równowagę między wydajnością a współdziałaniem. Kodowanie MTOM przesyła większość kodu XML w postaci tekstowej, ale optymalizuje duże bloki danych binarnych, przesyłając je tak jak w przypadku, bez konwersji na tekst. Pod względem wydajności, wśród koderów zapewnia WCF, MTOM jest między tekstem (najwolniejszym) i binarnym (najszybszym).

Jak wybrać koder komunikatów

W poniższej tabeli opisano typowe czynniki używane do wybierania kodera komunikatów. Określ priorytety czynników, które są ważne dla aplikacji, a następnie wybierz kodery komunikatów, które najlepiej współdziałają z tymi czynnikami. Pamiętaj, aby wziąć pod uwagę wszelkie dodatkowe czynniki, które nie zostały wymienione w tej tabeli, i wszelkie niestandardowe kodery komunikatów, które mogą być wymagane w aplikacji.

Współczynnik opis Kodery obsługujące ten czynnik
Obsługiwane zestawy znaków TextMessageEncodingBindingElement obsługują MtomMessageEncodingBindingElement tylko kodowania UTF8 i UTF16 Unicode (big-endian i little-endian). Jeśli wymagane są inne kodowanie, takie jak UTF7 lub ASCII, należy użyć kodera niestandardowego. Przykładowy koder niestandardowy można znaleźć w temacie Custom Message Encoder (Koder niestandardowy komunikatów). Text
Inspekcja Inspekcja to możliwość sprawdzania komunikatów podczas transmisji. Kodowanie tekstu z użyciem protokołu SOAP lub bez niego umożliwia inspekcję i analizowanie komunikatów przez wiele aplikacji bez użycia wyspecjalizowanych narzędzi. Korzystanie z zabezpieczeń transferu na poziomie komunikatu lub transportu wpływa na możliwość inspekcji komunikatów. Poufność chroni wiadomość przed badaniem, a integralność chroni wiadomość przed modyfikacją. Text
Niezawodność Niezawodność to odporność kodera na błędy transmisji. Niezawodność można również udostępnić w warstwie komunikatu, transportu lub aplikacji. Wszystkie standardowe kodery WCF zakładają, że inna warstwa zapewnia niezawodność. Koder nie ma możliwości odzyskania sprawności po błędzie transmisji. Brak
Prostota Prostota reprezentuje łatwość tworzenia koderów i dekodatorów dla specyfikacji kodowania. Kodowanie tekstu jest szczególnie korzystne dla uproszczenia, a kodowanie tekstu POX ma dodatkową zaletę braku obsługi przetwarzania protokołu SOAP. Tekst (POX)
Rozmiar Kodowanie określa ilość narzutów nakładanych na zawartość. Rozmiar zakodowanych komunikatów jest bezpośrednio związany z maksymalną przepływnością operacji usługi. Kodowanie binarne jest na ogół bardziej kompaktowe niż kodowanie tekstu. Jeśli rozmiar komunikatu jest w warstwie Premium, rozważ również skompresowanie zawartości komunikatu podczas kodowania. Jednak kompresja dodaje koszty przetwarzania zarówno dla nadawcy komunikatu, jak i odbiorcy. Plik binarny
Przesyłanie strumieniowe Przesyłanie strumieniowe umożliwia aplikacjom rozpoczęcie przetwarzania komunikatu przed przybyciem całego komunikatu. Efektywne korzystanie z przesyłania strumieniowego wymaga, aby ważne dane dla komunikatu mogły być dostępne na początku komunikatu, aby aplikacja odbierającego nie była wymagana do oczekiwania na nadejście komunikatu. Ponadto aplikacje korzystające z transferu strumieniowego muszą organizować dane w komunikacie przyrostowo, aby zawartość nie miała zależności przesyłania dalej. W wielu przypadkach należy naruszyć bezpieczeństwo między zawartością strumieniową a najmniejszym możliwym rozmiarem transferu dla tej zawartości. Brak
Obsługa narzędzi innych firm Obszary wsparcia dla kodowania obejmują programowanie i diagnostykę. Deweloperzy innych firm zainwestowali w biblioteki i zestawy narzędzi do obsługi komunikatów zakodowanych w formacie POX. Tekst (POX)
Współdziałanie Ten czynnik odnosi się do możliwości współdziałania kodera WCF z usługami innych niż WCF. Text

MTOM (częściowe)

Uwaga: w przypadku korzystania z kodera binarnego użycie ustawienia IgnoreWhitespace podczas tworzenia elementu XMLReader nie będzie miało żadnego wpływu. Jeśli na przykład wykonasz następujące czynności wewnątrz operacji usługi:

public void OperationContract(XElement input)
{
    Console.WriteLine("{0}", input.Value);
    int counter = 0;
    var xreader = input.CreateReader();
    var reader = XmlReader.Create(xreader, new XmlReaderSettings() { IgnoreWhitespace = true });
    while (reader.Read())
    {
        counter++;
    }

    Console.WriteLine("Read {0} lines with reader", counter);
}

Ustawienie IgnoreWhitespace jest ignorowane.

Kompresja i koder binarny

Począwszy od WCF 4.5 koder binarny WCF dodaje obsługę kompresji. Dzięki temu można użyć algorytmu gzip/deflate do wysyłania skompresowanych komunikatów z klienta WCF, a także odpowiadać za pomocą skompresowanych komunikatów z własnej usługi WCF. Ta funkcja umożliwia kompresję zarówno w transportach HTTP, jak i TCP. Usługę WCF hostowaną przez usługi IIS zawsze można włączyć do wysyłania skompresowanych odpowiedzi przez skonfigurowanie serwera hosta usług IIS. Typ kompresji jest skonfigurowany z właściwością BinaryMessageEncodingBindingElement.CompressionFormat . Ta właściwość jest ustawiona System.ServiceModel.Channels.CompressionFormat na jedną z wartości wyliczenia:

Ponieważ ta właściwość jest uwidoczniona tylko w binaryMessageEncodingBindingElement, należy utworzyć powiązanie niestandardowe, takie jak następujące, aby użyć tej funkcji:

<customBinding>
  <binding name="BinaryCompressionBinding">
    <binaryMessageEncoding compressionFormat ="GZip" />
    <httpTransport />
 </binding>
</customBinding>

Zarówno klient, jak i usługa muszą wyrazić zgodę na wysyłanie i odbieranie skompresowanych komunikatów, dlatego właściwość compressionFormat musi być skonfigurowana w elemencie binaryMessageEncoding zarówno w kliencie, jak i usłudze. Wyjątek ProtocolException jest zgłaszany, jeśli usługa lub klient nie jest skonfigurowany do kompresji, ale po drugiej stronie. Należy dokładnie rozważyć włączenie kompresji. Kompresja jest głównie przydatna, jeśli przepustowość sieci jest wąskim gardłem. W przypadku, gdy procesor cpu jest wąskim gardłem, kompresja zmniejszy przepływność. Odpowiednie testowanie należy wykonać w środowisku symulowanym, aby dowiedzieć się, czy zapewnia to korzyści aplikacji

Zobacz też