Udostępnij przez

Kodery niestandardowe

W tym temacie omówiono sposób tworzenia koderów niestandardowych.

W programie Windows Communication Foundation (WCF) należy użyć powiązania , aby określić sposób przesyłania danych między punktami końcowymi. Powiązanie składa się z sekwencji elementów powiązania. Powiązanie zawiera opcjonalne elementy powiązania protokołu, takie jak zabezpieczenia, wymagany element powiązania kodera komunikatów i wymagany element powiązania transportu. Koder komunikatów jest reprezentowany przez element powiązania kodowania komunikatów. WCF zawiera trzy kodery komunikatów: binarny, mechanizm optymalizacji transmisji komunikatów (MTOM) oraz tekstowy.

Element powiązania kodowania komunikatów serializuje wychodzące Message i przekazuje je do transportu lub odbiera zserializowaną formę komunikatu z transportu i przekazuje ją do warstwy protokołu, jeśli jest obecna, lub do aplikacji, jeśli warstwa protokołu nie jest obecna.

Enkodery komunikatów przekształcają Message wystąpienia do i z postaci przewodowej. Choć kodery są opisywane jako znajdujące się powyżej warstwy transportowej w stosie warstw kanału, faktycznie znajdują się wewnątrz tej warstwy. Transporty (na przykład HTTP) formatują komunikat zgodnie z wymaganiami standardu transportowego. Kodery (na przykład Tekst xml) po prostu kodują komunikat.

Podczas nawiązywania połączenia z wcześniej istniejącego klienta lub serwera może nie być konieczne użycie określonego kodowania komunikatów. Jednak usługi WCF mogą być dostępne za pośrednictwem wielu punktów końcowych, z których każdy ma inny koder komunikatów. Jeśli pojedynczy enkoder nie obejmuje całej grupy odbiorców usługi, rozważ udostępnienie usługi za pośrednictwem wielu punktów końcowych. Aplikacje klienckie mogą następnie wybrać punkt końcowy, który jest dla nich najlepszy. Korzystanie z wielu punktów końcowych umożliwia łączenie zalet różnych koderów komunikatów z innymi elementami powiązania.

Enkodery System-Provided

Program WCF udostępnia kilka powiązań dostarczanych przez system, które są przeznaczone do obsługi najbardziej typowych scenariuszy aplikacji. Każde z tych powiązań łączy transport, koder komunikatów i inne opcje (na przykład zabezpieczenia). W tym temacie opisano sposób rozszerzania koderów komunikatów Text, Binary i MTOM zawartych w programie WCF lub tworzenia własnego kodera niestandardowego. 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 jest nazywany koderem POX ("Zwykły stary kod XML"), aby odróżnić go od kodowania SOAP opartego na tekście.

Aby uzyskać więcej informacji na temat kombinacji elementów powiązania dostarczanych przez systemowe powiązania, zobacz odpowiednią sekcję w temacie Wybieranie transportu.

Jak pracować z koderami System-Provided

Kodowanie jest dodawane do powiązania za pomocą klasy pochodzącej z MessageEncodingBindingElement.

Program WCF udostępnia następujące typy elementów powiązań pochodzące z klasy MessageEncodingBindingElement, które mogą obsługiwać kodowanie tekstowe, binarne oraz mechanizm optymalizacji transmisji komunikatów (MTOM):

  • TextMessageEncodingBindingElement: Najbardziej współdziałalny, ale najmniej wydajny koder dla komunikatów XML. Usługa sieci Web lub klient usługi sieci Web zazwyczaj rozumie tekstowy kod XML. Jednak przesyłanie dużych bloków danych binarnych jako tekst nie jest wydajne.

  • BinaryMessageEncodingBindingElement: reprezentuje element powiązania, który określa kodowanie znaków i przechowywanie wersji komunikatów używanych dla komunikatów XML opartych na binarnej bazie danych. Jest to najbardziej wydajna opcja kodowania, ale najmniej interoperacyjna, ponieważ jest obsługiwana tylko przez punkty końcowe WCF.

  • MtomMessageEncodingBindingElement: reprezentuje element powiązania, który określa kodowanie znaków i wersjonowanie wiadomości używanych w komunikacie z kodowaniem MTOM (Mechanizmem Optymalizacji Transmisji Wiadomości). MTOM to wydajna technologia przesyłania danych binarnych w komunikatach WCF. Koder MTOM próbuje zrównoważyć wydajność i współdziałanie. 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.

Element powiązania tworzy plik binarny, MTOM lub tekst MessageEncoderFactory. Fabryka tworzy obiekt binarny, MTOM lub tekstowy MessageEncoderFactory. Zazwyczaj istnieje tylko jedno wystąpienie. Jeśli jednak sesje są używane, do każdej sesji może być udostępniany inny koder. Koder binarny wykorzystuje to do koordynowania słowników dynamicznych (zobacz Infrastruktura XML).

Metody ReadMessage i WriteMessage są rdzeniem koderów. Metody umożliwiają odczytywanie komunikatu ze strumienia lub tablicy Byte . Tablice bajtów są używane, gdy transport działa w trybie buforowym. Komunikaty są zawsze zapisywane w strumieniach. Jeśli transport musi buforować komunikat, udostępnia strumień, który wykonuje buforowanie.

Pozostali członkowie zespołu pracują z zawartością, typami multimediów i MessageVersion. Transport wywołuje te metody kodera, aby sprawdzić, czy komunikat przychodzący może zostać zdekodowany przez niego, czy też określić, czy komunikat wychodzący jest prawidłowy dla tego kodera.

Każda z trzech implementacji kodera dodaje właściwości, które są istotne dla określonych kodowań i jest w pełni konfigurowalne. Enkodery również ujawniają limity odczytu, które mają bezpieczne ustawienia domyślne. Zobacz infrastrukturę XML, aby zapoznać się z omówieniem limitów.

Funkcje koderów System-Provided

Istnieje wiele funkcji udostępnianych przez kodery dostarczane przez system.

Grupowanie

Każda implementacja kodera próbuje zbierać zasoby jak najwięcej. Zmniejszenie alokacji to kluczowy sposób na poprawę wydajności kodu zarządzanego. Aby przeprowadzić tę agregację, implementacje używają SynchronizedPool klasy. Plik C# zawiera opis dodatkowych optymalizacji używanych przez tę klasę.

XmlDictionaryReader i XmlDictionaryWriter są łączone w pulę wystąpień i ponownie inicjowane, aby zapobiec przydzielaniu nowych dla każdego komunikatu. Dla czytelników, wywołanie zwrotne OnClose odzyskuje czytelnika, gdy zostanie wywołane Close(). Koder także recykluje niektóre obiekty stanu komunikatów używane, kiedy konstruuje komunikaty. Rozmiary tych pul można konfigurować za pomocą właściwości MaxReadPoolSize i MaxWritePoolSize w każdej z trzech klasach pochodzących z MessageEncodingBindingElement.

Kodowanie binarne

Gdy kodowanie binarne używa sesji, ciąg słownika dynamicznego musi być przekazywany do odbiorcy komunikatu. Odbywa się to przez dodanie na początku komunikatu ciągów z dynamicznego słownika. Odbiornik usuwa ciągi, dodaje je do sesji i przetwarza komunikat. Prawidłowe przekazywanie ciągów słownika wymaga buforowanego transportu.

Ciągi znaków są dołączane do komunikatu za pomocą wewnętrznej metody AddSessionInformationToMessage. Dodaje ciągi w formacie UTF-8 na początku komunikatu, poprzedzając je ich długością. Cały nagłówek słownika jest następnie poprzedzony długością danych. Operacja odwrotna jest wykonywana przez metodę wewnętrzną ExtractSessionInformationFromMessage .

Oprócz przetwarzania dynamicznych kluczy słownika, buforowane komunikaty związane z sesją są odbierane w unikalny sposób. Zamiast tworzyć czytelnika w dokumencie i przetwarzać go, koder binarny używa klasy wewnętrznej MessagePatterns do dekonstrukcji strumienia binarnego. Chodzi o to, że większość komunikatów ma określony zestaw nagłówków, które są wyświetlane w określonej kolejności po wygenerowaniu przez usługę WCF. System wzorców dzieli komunikat na podstawie tego, czego oczekuje. Jeśli operacja zakończy się pomyślnie, inicjuje MessageHeaders obiekt bez analizowania kodu XML. Jeśli nie, wraca do standardowej metody.

Kodowanie MTOM

Klasa MtomMessageEncodingBindingElement ma dodatkową właściwość konfiguracji o nazwie MaxBufferSize. Nakłada to górną granicę na ilość danych, które można buforować podczas odczytywania wiadomości. Może być konieczne buforowania zestawu informacji XML (Infoset) lub innych części MIME, aby ponownie połączyć wszystkie części MIME w jeden komunikat.

Aby prawidłowo pracować z protokołem HTTP, wewnętrzna klasa kodera wiadomości MTOM udostępnia pewne wewnętrzne API dla GetContentType (również wewnętrznego) oraz WriteMessage, które jest publiczne i może zostać zastąpione. Aby zapewnić, że wartości w nagłówkach HTTP zgadzają się z wartościami w nagłówkach MIME, musi wystąpić więcej komunikacji.

Wewnętrznie koder komunikatów MTOM używa czytników tekstu WCF i jest podobny do kodera tekstowego. Główną różnicą jest to, że optymalizuje duże fragmenty danych binarnych, czyli "Binarne duże obiekty" (BLOBs), nie konwertując ich na kodowanie Base-64 przed osadzeniem ich w bajtach wiadomości. Zamiast tego te obiekty BLOB są wyodrębniane i przywoływane jako załączniki MIME.

Pisanie własnego kodera

Aby zaimplementować własny niestandardowy koder komunikatów, należy podać niestandardowe implementacje następujących abstrakcyjnych klas bazowych:

Konwertowanie z reprezentacji w pamięci komunikatu na reprezentację, którą można zapisać w strumieniu, jest hermetyzowane w klasie MessageEncoder, która służy jako fabryka czytników XML i zapisujących XML, obsługujących określone typy kodowań XML.

Jest to kod, który piszesz w tych metodach, który obsługuje konwersję między standardowym protokołem transportowym i dostosowanym kodowaniem.

Następnie należy stworzyć klasę fabryki, która tworzy własny enkoder. Zastąp Encoder, aby zwrócić instancję niestandardowego obiektu MessageEncoder.

Następnie połącz swój niestandardowy MessageEncoderFactory ze stosu elementów powiązania używanego do konfiguracji usługi lub klienta, przesłaniając metodę CreateMessageEncoderFactory w celu zwrócenia wystąpienia tej fabryki.

Istnieją dwa przykłady dostarczane z usługą WCF, które ilustrują ten proces za pomocą przykładowego kodu: Custom Message Encoder: Custom Text Encoder i Custom Message Encoder: Compression Encoder.

Zobacz także

  • Last updated on