Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Per implementare il routing basato sul contenuto, il servizio di routing usa MessageFilter implementazioni che controllano sezioni specifiche di un messaggio, ad esempio l'indirizzo, il nome dell'endpoint o un'istruzione XPath specifica. Se nessuno dei filtri dei messaggi forniti con .NET Framework 4.6.1 soddisfa le proprie esigenze, è possibile creare un filtro personalizzato creando una nuova implementazione della classe di base MessageFilter .
Quando si configura il servizio di routing, è necessario definire gli elementi di filtro (FilterElement oggetti) che descrivono il tipo di MessageFilter ed eventuali dati di supporto necessari per creare il filtro, ad esempio valori stringa specifici da cercare all'interno del messaggio. Si noti che la creazione degli elementi filtro definisce solo i singoli filtri dei messaggi; per usare i filtri per valutare e instradare i messaggi, è necessario definire anche una tabella di filtro (FilterTableEntryCollection).
Ogni voce della tabella dei filtri fa riferimento a un elemento filtro e specifica l'endpoint client a cui verrà indirizzato un messaggio se il messaggio corrisponde al filtro. Le voci della tabella di filtro consentono inoltre di specificare una raccolta di endpoint di backup (BackupEndpointCollection), che definisce un elenco di endpoint a cui il messaggio verrà trasmesso in caso di errore di trasmissione durante l'invio all'endpoint primario. Questi endpoint verranno provati nell'ordine specificato fino a quando uno non avrà successo.
Filtri messaggi
I filtri dei messaggi utilizzati dal servizio di routing forniscono funzionalità comuni di selezione dei messaggi, ad esempio la valutazione del nome dell'endpoint a cui è stato inviato un messaggio, l'azione SOAP o il prefisso dell'indirizzo o dell'indirizzo a cui è stato inviato il messaggio. I filtri possono anche essere uniti a una AND condizione, in modo che i messaggi vengano indirizzati a un endpoint solo se il messaggio corrisponde a entrambi i filtri. È anche possibile creare filtri personalizzati creando la propria implementazione di MessageFilter.
La tabella seguente elenca l'oggetto FilterType usato dal servizio di routing, la classe che implementa il filtro del messaggio specifico e i parametri necessari FilterData .
| Tipo di filtro | Descrizione | Filtrare il significato dei dati | Filtro di esempio |
|---|---|---|---|
| Azione | Usa la ActionMessageFilter classe per trovare una corrispondenza con i messaggi contenenti un'azione specifica. | Azione da filtrare. | <filter name="action1" filterType="Action" filterData="http://namespace/contract/operation" /> |
| Indirizzo di Endpoint | Usa la EndpointAddressMessageFilter classe con IncludeHostNameInComparison == true per trovare le corrispondenze con i messaggi contenenti un indirizzo specifico. |
L'indirizzo su cui filtrare (nell'intestazione 'To'). | <filter name="address1" filterType="EndpointAddress" filterData="http://host/vdir/s.svc/b" /> |
| EndpointAddressPrefix | Usa la PrefixEndpointAddressMessageFilter classe , con IncludeHostNameInComparison == true per trovare la corrispondenza con i messaggi contenenti un prefisso di indirizzo specifico. |
Indirizzo da filtrare utilizzando la corrispondenza del prefisso più lungo. | <filter name="prefix1" filterType="EndpointAddressPrefix" filterData="http://host/" /> |
| E | Usa la StrictAndMessageFilter classe che valuta sempre entrambe le condizioni prima della restituzione. | filterData non viene usato; piuttosto, filter1 e filter2 hanno i nomi dei filtri dei messaggi corrispondenti (anche nella tabella), che devono essere ANDati insieme. | <filter name="and1" filterType="And" filter1="address1" filter2="action1" /> |
| Personalizzato | Tipo definito dall'utente che estende la MessageFilter classe e ha un costruttore che accetta una stringa. | L'attributo customType è il nome completo del tipo della classe da creare; filterData è la stringa da passare al costruttore durante la creazione del filtro. | <filter name="custom1" filterType="Custom" customType="CustomAssembly.CustomMsgFilter, CustomAssembly" filterData="Custom Data" /> |
| Nome dell'Endpoint | Usa la EndpointNameMessageFilter classe per trovare una corrispondenza con i messaggi in base al nome dell'endpoint del servizio in cui sono arrivati. | Nome dell'endpoint del servizio, ad esempio: "serviceEndpoint1". Deve trattarsi di uno degli endpoint esposti nel servizio di routing. | <filter name="stock1" filterType="Endpoint" filterData="SvcEndpoint" /> |
| MatchAll | Usa la MatchAllMessageFilter classe . Questo filtro corrisponde a tutti i messaggi in arrivo. | filterData non viene utilizzato. Questo filtro corrisponderà sempre a tutti i messaggi. | <filter name="matchAll1" filterType="MatchAll" /> |
| XPath | Usa la XPathMessageFilter classe per trovare una corrispondenza con query XPath specifiche all'interno del messaggio. | La query XPath da utilizzare quando si confrontano i messaggi. | <filter name="XPath1" filterType="XPath" filterData="//ns:element" /> |
Nell'esempio seguente vengono definite voci di filtro che usano i filtri dei messaggi XPath, EndpointName e PrefixEndpointAddress. In questo esempio viene inoltre illustrato l'uso di un filtro personalizzato per le voci RoundRobinFilter1 e RoundRobinFilter2.
<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>
Annotazioni
La semplice definizione di un filtro non comporta la valutazione dei messaggi rispetto al filtro. Il filtro deve essere aggiunto a una tabella di filtro, che viene quindi associata all'endpoint di servizio esposto dal servizio di routing.
Tabella dei namespace
Quando si utilizza un filtro XPath, i dati del filtro che contengono la query XPath possono diventare estremamente grandi a causa dell'uso dei namespace. Per risolvere questo problema, il servizio di routing consente di definire prefissi dello spazio dei nomi personalizzati usando la tabella dello spazio dei nomi.
La tabella dei namespace è una raccolta di oggetti NamespaceElement che definisce i prefissi per i namespace comuni che possono essere utilizzati in un'espressione XPath. Di seguito sono riportati i namespace predefiniti e i prefissi di namespace contenuti nella tabella dei namespace.
| Prefisso | Namespace |
|---|---|
| s11 | http://schemas.xmlsoap.org/soap/envelope |
| s12 | http://www.w3.org/2003/05/soap-envelope |
| wsaAgosto2004 | http://schemas.xmlsoap.org/ws/2004/08/addressing |
| wsa10 | http://www.w3.org/2005/08/addressing |
| Sm | http://schemas.microsoft.com/serviceModel/2004/05/xpathfunctions |
| tempuri | http://tempuri.org |
| Ser | http://schemas.microsoft.com/2003/10/Serialization |
Quando si sa che si userà uno spazio dei nomi specifico nelle query XPath, è possibile aggiungerlo alla tabella dello spazio dei nomi insieme a un prefisso dello spazio dei nomi univoco e usare il prefisso in qualsiasi query XPath anziché nello spazio dei nomi completo. Nell'esempio seguente viene definito un prefisso "custom" per lo spazio dei nomi "http://my.custom.namespace", che viene quindi usato nella query XPath contenuta in filterData.
<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>
Filtra tabelle
Mentre ogni elemento filtro definisce un confronto logico che può essere applicato a un messaggio, la tabella dei filtri fornisce l'associazione tra l'elemento filtro e l'endpoint client di destinazione. Una tabella di filtri è una raccolta denominata di FilterTableEntryElement oggetti che definiscono l'associazione tra un filtro, un endpoint di destinazione primario e un elenco di endpoint di backup alternativi. Le voci della tabella di filtro consentono anche di specificare una priorità facoltativa per ogni condizione di filtro. Nell'esempio seguente vengono definiti due filtri e quindi viene definita una tabella di filtro che associa ogni filtro a un endpoint di destinazione.
<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à di valutazione filtro
Per impostazione predefinita, tutte le voci nella tabella dei filtri vengono valutate contemporaneamente e il messaggio valutato viene indirizzato agli endpoint associati a ogni voce di filtro corrispondente. Se più filtri restituiscono true e il messaggio è unidirezionale o duplex, il messaggio viene multicast agli endpoint che corrispondono ai filtri corrispondenti. I messaggi request-reply non possono essere multicast perché è possibile restituire al client una sola risposta.
È possibile implementare una logica di routing più complessa specificando i livelli di priorità per ogni filtro; Il servizio di routing valuta prima tutti i filtri al livello di priorità più alto. Se un messaggio corrisponde a un filtro di questo livello, non vengono elaborati filtri con priorità inferiore. Ad esempio, un messaggio unidirezionale in ingresso viene prima valutato rispetto a tutti i filtri con priorità 2. Il messaggio non corrisponde ad alcun filtro a questo livello di priorità, quindi il messaggio successivo viene confrontato con i filtri con priorità 1. Due filtri di priorità 1 corrispondono al messaggio e, poiché si tratta di un messaggio unidirezionale, viene instradato a entrambi gli endpoint di destinazione. Poiché è stata trovata una corrispondenza tra i filtri con priorità 1, non vengono valutati filtri di priorità 0.
Annotazioni
Se non viene specificata alcuna priorità, viene utilizzata la priorità predefinita 0.
Nell'esempio seguente viene definita una tabella di filtro che specifica le priorità di 2, 1 e 0 per i filtri a cui si fa riferimento nella tabella.
<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>
Nell'esempio precedente, se un messaggio corrisponde a XPathFilter, verrà instradato al roundingCalcEndpoint e non verranno valutati altri filtri nella tabella perché tutti gli altri filtri hanno una priorità inferiore. Tuttavia, se il messaggio non corrisponde a XPathFilter, verrà valutato rispetto a tutti i filtri della priorità inferiore successiva, EndpointNameFilter e PrefixAddressFilter.
Annotazioni
Quando possibile, usare filtri esclusivi anziché specificare una priorità perché la valutazione della priorità può comportare una riduzione delle prestazioni.
Elenchi di backup
Ogni filtro nella tabella dei filtri può facoltativamente specificare un elenco di backup, ovvero una raccolta denominata di endpoint (BackupEndpointCollection). Questa raccolta contiene un elenco ordinato di endpoint a cui il messaggio verrà trasmesso in caso di CommunicationException invio all'endpoint primario specificato in EndpointName. Nell'esempio seguente viene definito un elenco di backup denominato "backupServiceEndpoints" che contiene due endpoint.
<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>
Nell'esempio precedente, se un invio all'endpoint primario "Destination" ha esito negativo, il servizio di routing tenterà di inviare a ogni endpoint nella sequenza in cui sono elencati, prima di tutto inviando a backupServiceQueue e successivamente inviando a alternateServiceQueue se l'invio a backupServiceQueue non riesce. Se tutti gli endpoint di backup hanno esito negativo, viene restituito un errore.