Filtrowanie

System filtrowania Windows Communication Foundation (WCF) może używać filtrów deklaratywnych do dopasowywania komunikatów i podejmowania decyzji operacyjnych. Za pomocą filtrów można określić, co zrobić z komunikatem, sprawdzając część komunikatu. Na przykład proces kolejkowania może użyć zapytania XPath 1.0, aby sprawdzić element priorytetu znanego nagłówka, aby określić, czy przenieść komunikat do przodu kolejki.

System filtrowania składa się z zestawu klas, które mogą skutecznie określić, który z zestawów filtrów jest true przeznaczony dla określonego komunikatu WCF.

System filtrowania jest podstawowym składnikiem komunikatów WCF; został zaprojektowany tak, aby był bardzo szybki. Każda implementacja filtru została zoptymalizowana pod kątem konkretnego rodzaju dopasowania do komunikatów WCF.

System filtrowania nie jest bezpieczny dla wątków. Aplikacja musi obsługiwać wszelkie semantyki blokowania. Obsługuje jednak wielu czytelników i jednego piszącego.

Gdzie filtrowanie pasuje

Filtrowanie jest wykonywane po odebraniu komunikatu i jest częścią procesu wysyłania komunikatu do odpowiedniego składnika aplikacji. Projekt systemu filtrowania odpowiada wymaganiom kilku podsystemów WCF, w tym obsługi komunikatów, routingu, zabezpieczeń, obsługi zdarzeń i zarządzania systemem.

Filtry

Aparat filtrów ma dwa podstawowe składniki, filtry i tabele filtrów. Filtr podejmuje decyzje logiczne dotyczące komunikatu na podstawie warunków logicznych określonych przez użytkownika. Filtry implementują klasę MessageFilter .

Metody Match są używane do określenia, czy komunikat spełnia filtr. Jedna z metod sprawdza nagłówek komunikatu, ale nie może sprawdzić treści komunikatu. Druga metoda przyjmuje bufor komunikatu jako parametr wejściowy i może sprawdzić treść komunikatu.

Filtry nie są zwykle testowane indywidualnie, ale w ramach tabeli filtrów, która jest klasą ogólną tworzoną przez CreateFilterTable metodę.

Kilka rodzajów filtrów, które specjalizują się w dopasowywaniu do określonego rodzaju warunku logicznego. Po utworzeniu filtru nie można zmienić kryteriów używanych przez filtr; aby zmodyfikować kryteria filtru, skonstruuj nowy i usuń istniejący filtr.

Filtry akcji

ActionMessageFilter zawiera listę ciągów akcji. Jeśli jakaś akcja z listy filtra pasuje do nagłówkiem Akcja w buforze komunikatu lub w komunikacie, metoda Match zwraca wartość true. Jeśli lista jest pusta, filtr jest traktowany jako filtr pasujący do wszystkiego i każda wiadomość lub bufor wiadomości pasuje oraz Match zwraca true. Jeśli żadna z akcji na liście filtru nie odpowiada nagłówkowi Akcja w wiadomości lub buforze wiadomości, Match zwraca wartość false. Jeśli w komunikacie nie ma żadnej akcji, a lista filtru nie jest pusta, zwraca Match wartość false.

Filtry adresów punktu końcowego

Filtruje EndpointAddressMessageFilter komunikaty i buforów komunikatów na podstawie adresu punktu końcowego, zgodnie z reprezentacją w ich kolekcji nagłówków. Aby komunikat przeszedł przez taki filtr, należy spełnić następujące warunki:

• Adres filtru Uniform Resource Identifier (URI) musi być taki sam jak adres w nagłówku Do.

• Każdy parametr punktu końcowego w adresie filtru (address.Headers kolekcji) musi znaleźć nagłówek w komunikacie do mapowania. Dodatkowe nagłówki w buforze komunikatu lub wiadomości są dopuszczalne, aby dopasowanie pozostało true.

Filtry prefiksów adresów punktów końcowych

1. Funkcja PrefixEndpointAddressMessageFilter działa podobnie jak filtr EndpointAddressMessageFilter, z tą różnicą, że dopasowanie może występować na prefiksie identyfikatora URI komunikatu. Na przykład filtr określający adres http://www.adatum.com pasuje do komunikatów adresowanych do http://www.adatum.com/userA.

Filtry komunikatów XPath

Obiekt XPathMessageFilter używa wyrażenia XPath do określenia, czy dokument XML zawiera określone elementy, atrybuty, tekst lub inne konstrukcje składniowe XML. Filtr jest zoptymalizowany, aby być niezwykle wydajny dla ścisłego podzbioru XPath. Język ścieżki XML jest opisany w specyfikacji W3C XML Path Language 1.0.

Zazwyczaj aplikacja używa XPathMessageFilter elementu w punkcie końcowym do wykonywania zapytań dotyczących zawartości komunikatu PROTOKOŁU SOAP, a następnie wykonuje odpowiednią akcję na podstawie wyników tego zapytania. Na przykład proces kolejkowania może użyć zapytania XPath, aby sprawdzić element priorytetu znanego nagłówka, aby zdecydować, czy przenieść komunikat do przodu kolejki.

Filtrowanie tabel

Tabele filtrów są używane do przechowywania par klucz-wartość, gdzie filtr jest kluczem, a niektóre skojarzone dane są wartością. Dane filtru mogą służyć do wskazywania akcji, które należy wykonać, jeśli komunikat pasuje do filtru, a typ danych filtru jest ogólnym parametrem klasy tabeli filtru. Dane filtru mogą składać się z reguł routingu, stanu zabezpieczeń sesji, odbiorników w kanale itd. Dane mogą być używane, gdy konieczne jest sterowanie przepływem danych.

Tabele filtrów implementują interfejs IMessageFilterTable<TFilterData>ogólny .

Tabele filtrów mają kilka metod, które porównują komunikat ze wszystkimi filtrami w tabeli i zwracają nieuporządkowaną kolekcję dopasowanych filtrów lub danych. Niektóre metody dopasowania są wielokrotne i zwracają wszystkie pasujące elementy. Inne są jednokrotne, zwracają tylko jeden element i zgłaszają MultipleFilterMatchesException, jeśli więcej niż jeden filtr pasuje.

Tabela filtru komunikatów

MessageFilterTable<TFilterData> jest najbardziej ogólną implementacją IMessageFilterTable<TFilterData>. Filtry wszystkich typów można przechowywać w tabeli.

Priorytety liczbowe można przypisać do filtrów, gdzie najwyższy priorytet jest oznaczany przez największą liczbę. Wiele typów filtrów może mieć ten sam priorytet. Określony typ filtru może być wyświetlany na więcej niż jednym poziomie priorytetu.

Dopasowywanie jest wykonywane od najwyższego priorytetu, a po znalezieniu pasujących filtrów z określonym priorytetem nie są badane filtry o niższych priorytetach. W związku z tym, jeśli używasz metody dopasowania pojedynczego filtru, a więcej niż jeden filtr pasuje do komunikatu, ale każdy pasujący filtr ma inny priorytet, żaden wyjątek nie jest zgłaszany, a filtr o najwyższym prioryfikcie jest zwracany. Podobnie metoda dopasowania wielokrotnego filtrowania zwraca tylko te pasujące filtry z najwyższym priorytetem.

Tabela filtru komunikatów XPath

Element XPathMessageFilterTable<TFilterData> jest zoptymalizowany pod kątem deklaratywnych filtrów XPath, więc klucz tabeli to XPathMessageFilter.

Klasa XPathMessageFilterTable<TFilterData> optymalizuje dopasowywanie podzestawu XPath, który obejmuje większość scenariuszy obsługi komunikatów, a także obsługuje pełną gramatykę XPath 1.0. Ma zoptymalizowane algorytmy pod kątem wydajnego dopasowywania równoległego.

Ta tabela zawiera kilka wyspecjalizowanych Match metod, które działają na elementach XPathNavigator i SeekableXPathNavigator. Obiekt SeekableXPathNavigator rozszerza klasę XPathNavigator przez dodanie właściwości CurrentPosition. Ta właściwość umożliwia szybkie zapisanie i załadowanie pozycji w dokumencie XML bez konieczności klonowania nawigatora — kosztownej alokacji XPathNavigator pamięci wymaganej przez taką operację. Silnik WCF XPath musi często rejestrować położenie kursora w trakcie wykonywania zapytań na dokumentach XML, dzięki czemu SeekableXPathNavigator zapewnia ważną optymalizację przetwarzania komunikatów.

Scenariusze klienta

Filtrowanie można używać w dowolnym momencie, gdy chcesz wysłać komunikat do różnych modułów przetwarzania w zależności od danych zawartych w komunikacie. Dwa typowe scenariusze to trasowanie komunikatu na podstawie jego kodu akcji i de-multipleksowanie strumienia komunikatów na podstawie adresu ich punktu końcowego.

Trasowanie

Nasłuchujący punktu końcowego odbiera komunikaty, które mają jeden lub więcej kodów akcji w nagłówku wiadomości SOAP. Można to zaimplementować, tworząc obiekt ActionMessageFilter, przekazując tablicę zawierającą kody akcji do jego konstruktora. Używa tego filtru, aby zarejestrować się z ListenerFactory, dzięki czemu tylko komunikaty, których akcja pasuje do jednego z tych w filtrze, trafiają do tego konkretnego punktu końcowego.

De-multipleksowanie

Gdy wiele punktów końcowych rozchodzi się z tego samego ServiceListener połączenia, jedynym sposobem na demultipleksowanie komunikatów i ustalenie, czy należą do określonego adresu punktu końcowego, jest użycie EndpointAddressMessageFilter, które kierują komunikaty do zarejestrowanych punktów końcowych, wykonując wyszukiwanie informacji przechowywanych w nagłówkach. W tych filtrach tylko te komunikaty, które są przekazywane, mają wszystkie niezbędne nagłówki odpowiadające obu:

• Identyfikator URI w pliku EndpointAddress.

• Pozostałe parametry punktu końcowego w EndpointAddress zgodnie z EndpointAddressMessageFilter.

Zobacz także

• Transfer danych i serializacja