Nachrichtenfilter

Um inhaltsbasiertes Routing zu implementieren, verwendet MessageFilter der Routingdienst Implementierungen, die bestimmte Abschnitte einer Nachricht prüfen, z. B. die Adresse, den Endpunktnamen oder eine bestimmte XPath-Anweisung. Wenn keiner der Nachrichtenfilter, die mit .NET Framework 4.6.1 bereitgestellt werden, Ihren Anforderungen entspricht, können Sie einen benutzerdefinierten Filter erstellen, indem Sie eine neue Implementierung der Basisklasse MessageFilter erstellen.

Beim Konfigurieren des Routingdiensts müssen Sie Filterelemente (FilterElement Objekte) definieren, die den Typ von MessageFilter und alle unterstützenden Daten beschreiben, die zum Erstellen des Filters erforderlich sind, z. B. bestimmte Zeichenfolgenwerte, nach denen innerhalb der Nachricht gesucht werden soll. Beachten Sie, dass das Erstellen der Filterelemente nur die einzelnen Nachrichtenfilter definiert; um die Filter zum Auswerten und Weiterleiten von Nachrichten zu verwenden, müssen Sie auch eine Filtertabelle (FilterTableEntryCollection) definieren.

Jeder Eintrag in der Filtertabelle verweist auf ein Filterelement und gibt den Clientendpunkt an, an den eine Nachricht weitergeleitet wird, wenn die Nachricht dem Filter entspricht. Mit den Filtertabelleneinträgen können Sie auch eine Sammlung von Sicherungsendpunkten (BackupEndpointCollection) angeben, die eine Liste der Endpunkte definiert, an die die Nachricht im Falle eines Übertragungsfehlers beim Senden an den primären Endpunkt übertragen wird. Diese Endpunkte werden in der angegebenen Reihenfolge ausprobiert, bis eine erfolgreich ist.

Nachrichtenfilter

Die vom Routingdienst verwendeten Nachrichtenfilter stellen allgemeine Nachrichtenauswahlfunktionen bereit, z. B. die Auswertung des Namens des Endpunkts, an den eine Nachricht gesendet wurde, die SOAP-Aktion oder das Adress- oder Adresspräfix, an das die Nachricht gesendet wurde. Filter können auch mit einer AND Bedingung verknüpft werden, sodass Nachrichten nur an einen Endpunkt weitergeleitet werden, wenn die Nachricht mit beiden Filtern übereinstimmt. Sie können benutzerdefinierte Filter auch erstellen, indem Sie eine eigene Implementierung von MessageFilter erstellen.

In der folgenden Tabelle sind die vom Routingdienst verwendeten FilterType, die Klassen, die den spezifischen Nachrichtenfilter implementieren, und der erforderliche FilterData Parameter aufgeführt.

Im folgenden Beispiel werden Filtereinträge definiert, die die Nachrichtenfilter "XPath", "EndpointName" und "PrefixEndpointAddress" verwenden. In diesem Beispiel wird auch die Verwendung eines benutzerdefinierten Filters für die Einträge "RoundRobinFilter1" und "RoundRobinFilter2" veranschaulicht.

<filters>  
     <filter name="XPathFilter" filterType="XPath"
             filterData="/s12:Envelope/s12:Header/custom:RoundingCalculator = 1"/>  
     <filter name="EndpointNameFilter" filterType="EndpointName"
             filterData="calculatorEndpoint"/>  
     <filter name="PrefixAddressFilter" filterType="PrefixEndpointAddress"
             filterData="http://localhost/routingservice/router/rounding/"/>  
     <filter name="RoundRobinFilter1" filterType="Custom"
             customType="RoutingServiceFilters.RoundRobinMessageFilter,
             RoutingService" filterData="group1"/>  
     <filter name="RoundRobinFilter2" filterType="Custom"
             customType="RoutingServiceFilters.RoundRobinMessageFilter,
             RoutingService" filterData="group1"/>  
</filters>  

Namespace-Tabelle

Bei Verwendung eines XPath-Filters können die Filterdaten, die die XPath-Abfrage enthalten, aufgrund der Verwendung von Namespaces extrem groß werden. Um dieses Problem zu beheben, bietet der Routingdienst die Möglichkeit, eigene Namespacepräfixe mithilfe der Namespacetabelle zu definieren.

Die Namespacetabelle ist eine Auflistung von NamespaceElement Objekten, die die Namespacepräfixe für allgemeine Namespaces definieren, die in einem XPath verwendet werden können. Im Folgenden sind die Standardnamespaces und Namespacepräfixe aufgeführt, die in der Namespacetabelle enthalten sind.

Wenn Sie wissen, dass Sie in Ihren XPath-Abfragen einen bestimmten Namespace verwenden, können Sie ihn der Namespacetabelle zusammen mit einem eindeutigen Namespacepräfix hinzufügen und das Präfix in jeder XPath-Abfrage anstelle des vollständigen Namespaces verwenden. Im folgenden Beispiel wird ein Präfix "custom" für den Namespace "http://my.custom.namespace"definiert, der dann in der XPath-Abfrage verwendet wird, die in filterData enthalten ist.

<namespaceTable>  
     <add prefix="custom" namespace="http://my.custom.namespace/"/>  
</namespaceTable>  
<filters>  
     <filter name="XPathFilter" filterType="XPath" filterData="/s12:Envelope/s12:Header/custom:RoundingCalculator = 1"/>  
</filters>  

Tabellen filtern

Während jedes Filterelement einen logischen Vergleich definiert, der auf eine Nachricht angewendet werden kann, stellt die Filtertabelle die Zuordnung zwischen dem Filterelement und dem Zielclientendpunkt bereit. Eine Filtertabelle ist eine benannte Auflistung von FilterTableEntryElement Objekten, die die Zuordnung zwischen einem Filter, einem primären Zielendpunkt und einer Liste alternativer Sicherungsendpunkte definieren. Mit den Filtertabelleneinträgen können Sie auch eine optionale Priorität für jede Filterbedingung angeben. Im folgenden Beispiel werden zwei Filter definiert und dann eine Filtertabelle definiert, die jedem Filter einen Zielendpunkt zuordnet.

<routing>  
     <filters>  
       <filter name="AddAction" filterType="Action" filterData="Add" />  
       <filter name="SubtractAction" filterType="Action" filterData="Subtract" />  
     </filters>  
     <filterTables>  
       <table name="routingTable1">  
         <filters>  
           <add filterName="AddAction" endpointName="Addition" />  
           <add filterName="SubtractAction" endpointName="Subtraction" />  
         </filters>  
       </table>  
     </filterTables>
</routing>  

Priorität bei der Filterauswertung

Standardmäßig werden alle Einträge in der Filtertabelle gleichzeitig ausgewertet, und die zu bewertende Nachricht wird an die Endpunkte weitergeleitet, die jedem übereinstimmenden Filtereintrag zugeordnet sind. Wenn mehrere Filter auf true auswerten und die Nachricht einweg oder duplex ist, wird die Nachricht als Multicast an die Endpunkte bei allen übereinstimmenden Filtern gesendet. Anforderungsantwortnachrichten können nicht Multicast sein, da nur eine Antwort an den Client zurückgegeben werden kann.

Komplexere Routinglogik kann implementiert werden, indem Prioritätsebenen für jeden Filter angegeben werden; Der Routingdienst wertet zuerst alle Filter auf der Höchsten Prioritätsebene aus. Wenn eine Nachricht mit einem Filter dieser Ebene übereinstimmt, werden keine Filter einer niedrigeren Priorität verarbeitet. Beispielsweise wird eine eingehende unidirektionale Nachricht zuerst anhand aller Filter mit einer Priorität von 2 ausgewertet. Die Nachricht stimmt nicht mit einem Filter auf dieser Prioritätsebene überein, sodass die Nachricht als Nächstes mit Filtern mit einer Priorität von 1 verglichen wird. Zwei Prioritätsfilter 1 stimmen mit der Nachricht überein, und da es sich um eine unidirektionale Nachricht handelt, wird sie an beide Zielendpunkte weitergeleitet. Da eine Übereinstimmung zwischen den Prioritätsfiltern 1 gefunden wurde, werden keine Filter der Priorität 0 ausgewertet.

Im folgenden Beispiel wird eine Filtertabelle definiert, die Prioritäten von 2, 1 und 0 für die Filter angibt, auf die in der Tabelle verwiesen wird.

<filterTables>  
     <filterTable name="filterTable1">  
          <add filterName="XPathFilter" endpointName="roundingCalcEndpoint"
               priority="2"/>  
          <add filterName="EndpointNameFilter" endpointName="regularCalcEndpoint"
               priority="1"/>  
          <add filterName="PrefixAddressFilter" endpointName="roundingCalcEndpoint"
               priority="1"/>  
          <add filterName="MatchAllMessageFilter" endpointName="defaultCalcEndpoint"
               priority="0"/>  
     </filterTable>  
</filterTables>  

Wenn eine Nachricht im vorherigen Beispiel mit dem XPathFilter übereinstimmt, wird sie an den roundingCalcEndpoint weitergeleitet, und es werden keine weiteren Filter in der Tabelle ausgewertet, da alle anderen Filter eine niedrigere Priorität haben. Wenn die Nachricht jedoch nicht mit dem XPathFilter übereinstimmt, wird sie für alle Filter der nächsten niedrigeren Priorität ausgewertet, EndpointNameFilter und PrefixAddressFilter.

Sicherungslisten

Jeder Filter in der Filtertabelle kann optional eine Sicherungsliste angeben, bei der es sich um eine benannte Sammlung von Endpunkten (BackupEndpointCollection) handelt. Diese Auflistung enthält eine sortierte Liste von Endpunkten, an die die Nachricht übertragen wird, falls es beim Senden an den in CommunicationException angegebenen primären Endpunkt zu einem EndpointName kommt. Im folgenden Beispiel wird eine Sicherungsliste namens "backupServiceEndpoints" definiert, die zwei Endpunkte enthält.

<filterTables>  
     <filterTable name="filterTable1">  
          <add filterName="MatchAllFilter1" endpointName="Destination" backupList="backupEndpointList"/>  
     </filterTable>  
</filterTables>  
<backupLists>  
     <backupList name="backupEndpointList">  
          <add endpointName="backupServiceQueue" />  
          <add endpointName="alternateServiceQueue" />  
     </backupList>  
</backupLists>  

Wenn beim Senden an den primären Endpunkt "Destination" ein Fehler auftritt, versucht der Routingdienst im vorherigen Beispiel, an jeden Endpunkt in der aufgeführten Reihenfolge zu senden, zuerst an backupServiceQueue zu senden und anschließend an alternateServiceQueue zu senden, wenn das Senden an backupServiceQueue fehlschlägt. Wenn alle Sicherungsendpunkte fehlschlagen, wird ein Fehler zurückgegeben.