Udostępnij za pośrednictwem

Wybieranie kodera komunikatów

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 enkoder komunikatów odbiera z transportu zserializowaną formę elementu Message i przekazuje ją 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.

Enkodery System-Provided

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ć POX, ustaw właściwość MessageVersion 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 WCF, i dlatego nie jest interoperacyjny. 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 as-is, bez konwersji na tekst. Pod względem wydajności, wśród koderów, które zapewnia WCF, MTOM znajduje się między tekstowym (najwolniejszym) a 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.

Czynnik Opis Kodery obsługujące ten czynnik
Obsługiwane zestawy znaków TextMessageEncodingBindingElement i MtomMessageEncodingBindingElement obsługują 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). Tekst
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ń transmisji na poziomie komunikatu lub transportu wpływa na zdolność do inspekcji komunikatów. Poufność chroni wiadomość przed badaniem, a integralność chroni wiadomość przed modyfikacją. Tekst
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. Żaden
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 wielkość obciążenia nakładanego 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 ograniczony, rozważ również skompresowanie jego zawartości w trakcie kodowania. Jednak kompresja dodaje koszty przetwarzania zarówno dla nadawcy komunikatu, jak i odbiorcy. Dwójkowy
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 były dostępne na początku komunikatu, aby aplikacja odbierająca nie musiała oczekiwać na ich nadejście. Ponadto aplikacje korzystające z transferu strumieniowego muszą organizować dane w komunikacie przyrostowo, aby zawartość nie miała zależności od przyszłych danych. W wielu przypadkach należy dokonać kompromisu między treściami strumieniowymi a najmniejszym możliwym rozmiarem transferu dla tych treści. Żaden
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. Tekst

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 na jedną z wartości wyliczenia System.ServiceModel.Channels.CompressionFormat.

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, podczas gdy druga strona jest skonfigurowana. Należy dokładnie rozważyć włączenie kompresji. Kompresja ma zastosowanie głównie wtedy, gdy przepustowość sieci stanowi wąskie gardło. W przypadku, gdy procesor jest wąskim gardłem, kompresja zmniejszy przepustowość. Odpowiednie testowanie należy wykonać w środowisku symulowanym, aby dowiedzieć się, czy zapewnia to korzyści aplikacji

Zobacz także