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 wątkiem. Aplikacja musi obsługiwać wszelkie semantyki blokowania. Obsługuje to jednak wieloczytny, pojedynczy moduł zapisujący.

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

Zawiera ActionMessageFilter listę ciągów akcji. Jeśli którakolwiek z akcji na liście filtru pasuje do nagłówka Akcja w buforze komunikatu lub komunikatu, Match metoda zwraca truewartość . Jeśli lista jest pusta, filtr jest traktowany jako filtr zgodny ze wszystkimi, a wszystkie komunikaty lub bufor komunikatów są zgodne i Match zwraca wartość true. Jeśli żadna z akcji na liście filtru nie pasuje do nagłówka Akcja w buforze komunikatu lub komunikatu, 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 bufory komunikatów na podstawie adresu punktu końcowego, jak pokazano w kolekcji nagłówków. Aby komunikat mógł przekazać 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 adresów punktu końcowego prefiksu

1. Funkcje PrefixEndpointAddressMessageFilter podobne do filtru EndpointAddressMessageFilter , z tą różnicą, że dopasowanie może znajdować się 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 pod kątem bardzo wydajnego podzestawu 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 pasują do komunikatu względem wszystkich filtrów w tabeli i zwracają nieurządkowaną kolekcję pasujących filtrów lub danych. Niektóre metody dopasowania są wielokrotne i zwracają wszystkie pasujące elementy. Inne są jednopasmowe, zwracają tylko jeden element i zgłaszają MultipleFilterMatchesException , jeśli więcej niż jeden filtr pasuje.

Tabela filtru komunikatów

Jest MessageFilterTable<TFilterData> to najbardziej ogólna implementacja programu 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 obiekcie XPathNavigator i SeekableXPathNavigator. Obiekt SeekableXPathNavigator rozszerza klasę XPathNavigatorCurrentPosition przez dodanie właściwości. 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ę. Aparat WCF XPath musi często rejestrować położenie kursora w trakcie wykonywania zapytań dotyczących dokumentów 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 routing komunikatu na podstawie kodu akcji i dekodowanie strumienia komunikatów na podstawie adresu punktu końcowego komunikatów.

Routing

Odbiornik punktu końcowego nasłuchuje komunikatów, które mają co najmniej jeden kod akcji w nagłówku protokołu SOAP komunikatu. Można to zaimplementować, tworząc ActionMessageFilter obiekt, przekazując tablicę zawierającą kody akcji do konstruktora. Używa tego filtru ListenerFactorydo zarejestrowania w obiekcie , więc tylko komunikaty, których akcja pasuje do jednego z tych w filtrze, uzyskają dostęp do tego konkretnego punktu końcowego.

De-multipleksowanie

Gdy wiele punktów końcowych odchodzą od tego samego ServiceListener połączenia, jedynym sposobem na usunięcie komunikatów multipleksu i sprawdzenie, czy należą do określonego adresu punktu końcowego, jest użycie EndpointAddressMessageFilters, które wybiera komunikaty w kierunku 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 parametrach EndpointAddress określonych w pliku EndpointAddressMessageFilter.

Zobacz też

• Transfer i serializacja danych