Router intermedio

  • Articolo

Questo esempio illustra come implementare un servizio che fornisce la funzionalità di routing di base utile nella configurazione della rete in cui i servizi potrebbero non essere accessibili direttamente dai client. L'esempio non utilizza un router efficiente, scalabile e con una moltitudine di funzionalità.

Nota

La procedura di installazione e le istruzioni di compilazione per questo esempio si trovano alla fine di questo argomento.

In uno scenario di comunicazione tipico che include intermediari SOAP, un messaggio inviato da un client attraversa uno o più servizi aggiuntivi prima di raggiungere la destinazione finale: il servizio che elabora effettivamente il messaggio e fornisce una risposta, se attesa. Un intermediario SOAP esegue varie azioni sul messaggio che sta passando attraverso esso. Ad esempio, un intermediario di memorizzazione nella cache restituisce una risposta inserita nella cache al messaggio, che fa in modo che il servizio non debba elaborare nuovamente la richiesta. Un intermediario bilanciato utilizza un algoritmo round robin per inoltrare il messaggio a uno dei molti potenziali servizi. Un intermediario di convalida dello schema inoltra solo messaggi che sono pienamente conformi all'XSD del contratto e, possibilmente, agli altri protocolli. L'intermediario sviluppato per questo esempio è responsabile dell'indirizzamento dei messaggi a un servizio appropriato sulla base dell'intestazione del messaggio e del contenuto.

Per ulteriori informazioni sui messaggi SOAP, vedere XML Web Service Wire Formats.

In questo esempio, due servizi dell'applicazione vengono distribuiti per elaborare richieste client, ovvero un servizio calcolatrice e un servizio eco. Gli endpoint dell'applicazione dei servizi sono accessibili solo dalla rete interna. Gli endpoint dello scambio di metadati (MEX) del servizio sono pubblicamente accessibili. Il router SOAP fa parte della rete interna e ogni richiesta dell'applicazione proveniente dall'esterno della rete interna deve passare tramite esso.

Il client viene creato eseguendo Service Model Metadata Utility Tool (Svcutil.exe) su entrambi i servizi, per generare due file di codice (un client per ogni servizio) e un file di configurazione come Svcutil.exe, che incorpora le informazioni di configurazione del secondo servizio nel file di configurazione esistente, creato quando Svcutil.exe viene eseguito sul primo servizio. Il linguaggio di descrizione dei servizi Web (WSDL, Web Services Description Language) fornito da ogni servizio contiene l'indirizzo dell'intermediario SOAP anziché l'indirizzo del servizio effettivo. Ciò esonera il client dalla modifica del file di configurazione o dal sapere quale sia l'indirizzo dell'intermediario SOAP.

Inoltre, il servizio del router in questo esempio è configurato con due endpoint: uno in ascolto di messaggi con codifica del testo tramite HTTP per SOAP 1.2 e l'altro in ascolto di messaggi codificati binari che utilizzano TCP per SOAP 1.2. Ogni WSDL del servizio dell'applicazione utilizza l'indirizzo dell'endpoint corretto sul router. Il router viene anche fornito con le informazioni di routing nella sezione appSettings del file di configurazione che contiene le proprietà seguenti:

  • prefixes e namespaces, utilizzati per aggiornare la classe predefinita XmlNamespaceManager in WCF in modo da risolvere prefissi situati nel XPaths del router.
  • xpath e epr , utilizzati per aggiungere voci di routing alla tabella del routing che esegue il mapping di XPaths a EPRs.

Il router utilizza la classe XpathMessageFilterTable (XPathFilterTable<T>), in cui "T" è una classe EndpointAddress che archivia le voci di routing fornite dall'utente. Quando viene ricevuto un messaggio, il router chiama il metodo MatchMultiple che passa in un'istanza Message e recupera un EndpointAddress a cui il messaggio viene inoltrato.

EchoService e CalculatorService, utilizzano la proprietà ListenUri per impostare l'URI sul quale l'endpoint è in ascolto. L'indirizzo fornito nella dichiarazione dell'endpoint è l'indirizzo dell'endpoint del router che è in grado di inoltrare i messaggi del servizio. Si tratta dell'indirizzo che viene visualizzato nel WSDL del servizio e dell'indirizzo che corrisponde all'intestazione To di WS-Addressing di ogni messaggio in arrivo. Tuttavia, l'indirizzo fornito dalla proprietà ListenUri è l'indirizzo di ascolto fisico effettivo dell'endpoint utilizzato solo dal trasporto.

WCF fornisce un altro comportamento che è utilizzato in genere negli scenari intermedi SOAP e che questo esempio non utilizza: il comportamento del canale ClientViaBehavior. La classe ClientViaBehavior viene utilizzata dai client per specificare l'URI per il quale deve essere creato il canale del trasporto. Se tale comportamento esiste nel comportamento di raccolta su un endpoint client, il trasporto utilizza l'URI che fornisce, mentre tutti gli altri livelli del canale dello stack utilizzano la classe EndpointAddress fornita quando si costruisce la classe ChannelFactory. L'oggetto EndpointAddress diviene inoltre l'intestazione To di WS-Addressing. Nel codice di esempio seguente viene illustrato come utilizzare questo comportamento.

ChannelFactory<IContract> factory = new ChannelFactory<IContract>(new EndpointAddress("http://hostname/service"));
factory.Endpoint.Behaviors.Add(new ClientViaBehavior(new Uri("http://hostname/intermediary")));
IContract channel = factory.CreateChannel();

Un'altra funzionalità WCF utilizzata con gli intermediari SOAP è la proprietà AddressFilter. La proprietàAddressFilter viene utilizzata da WCF per accettare solo messaggi che corrispondono a un particolare filtro. Se i metodi del contratto di servizio utilizzano "*" come Action, viene controllato solo l'indirizzo. Questo esempio non si avvale di questa funzionalità perché l'indirizzo è sempre corretto. Il router accetta i messaggi del client in quanto le intestazioni To corrispondono all'indirizzo del relativo endpoint e i servizi accettano i messaggi inoltrati ad essi in quanto l'intestazione To corrisponde all'indirizzo logico del relativo endpoint.

Il file Contracts.cs dell'esempio definisce le quattro interfacce seguenti, una per ogni modello di trasporto:

  • ISimplexDatagramRouter. Questa interfaccia è necessaria per accettare messaggi su canali del datagramma simplex. Aggiungere un endpoint utilizzando questa interfaccia se si aspettano messaggi sui canali unidirezionali HTTP, o canali unidirezionali TCP e NamedPipe.
  • IRequestReplyDatagramRouter. Questa interfaccia è necessaria per accettare messaggi su canali del datagramma richiesta-risposta. Utilizzare questa interfaccia per i messaggi su un canale HTTP bidirezionale.
  • ISimplexSessionRouter. Questa interfaccia deve accettare messaggi su canali con sessione simplex. Utilizzare questa interfaccia per canali TCP simplex e NamedPipe simplex.
  • IDuplexSessionRouter. Questa interfaccia è per i canali della sessione duplex. Utilizzare questa interfaccia per canali TCP duplex e NamedPipe duplex.

RouterBinding fornisce un esempio di un'associazione WCF che è possibile creare per supportare l'intermediario SOAP. Consente di specificare le impostazioni più comuni richieste in questo scenario e assicura che vengano aggiunti solo gli elementi di associazione realmente necessari. Viene illustrato anche il supporto di configurazione di base.

Questo esempio non utilizza hosting Web perché si basa su trasporti diversi da HTTP. L'attivazione TCP è attualmente disponibile solo su Windows Vista e IIS 7.0.

Quando si esegue l'esempio, le richieste e le risposte dell'operazione vengono visualizzate nella finestra della console client. Premere INVIO nella finestra del client per arrestare il client.

Echo("Is anyone there?") returned: Is anyone there?
Add(5) returned: 5
Add(-3) returned: 2

Per impostare, compilare ed eseguire l'esempio

  1. Per compilare l'edizione C#, C++ o Visual Basic .NET della soluzione, seguire le istruzioni in Generazione degli esempi Windows Communication Foundation.

  2. Per eseguire l'esempio su un solo computer o tra computer diversi, seguire le istruzioni in Esecuzione degli esempi di Windows Communication Foundation, con le seguenti eccezioni.

    1. Per la configurazione su un solo computer o tra computer diversi sono necessari quattro progetti e quattro file eseguibili: uno per il client, uno per il router SOAP e uno per ogni servizio dell'applicazione.
    2. In una configurazione a più computer, devono essere apportate le modifiche seguenti ai quattro file di configurazione.
      La riga 21 del file App.config per CalculatorService e EchoService deve essere modificata. Il nome host del localhost deve essere sostituito con il vero nome host dell'intermediario.
      La riga 15 del file App.config del router deve essere modificata. I due indirizzi (separati con '|') devono essere impostati sul nome host di EchoService e CalculatorService, rispettivamente.
      Le righe 5 e 7 del file App.config devono essere modificate. Il nome host del localhost deve essere sostituito con il vero nome host dell'intermediario.
      È anche possibile utilizzare Service Model Metadata Utility Tool (Svcutil.exe) sui due servizi dell'applicazione (una volta aggiornati per utilizzare l'indirizzo giusto) e rigenerare i file App.config.

  3. Assicurarsi che Router, EchoServicee CalculatorService siano tutti in esecuzione prima di avviare il client. Ognuno dei tre servizi stampa gli indirizzi degli endpoint su cui è in ascolto all'avvio.

    Nota

    L'endpoint dell'applicazione EchoService e CalculatorService utilizza l'indirizzo del router.

  4. Eseguire il client. Il client contatta prima EchoServicee poi CalculatorService. Router stampa le azioni WS-Addressing dei messaggi che sta inoltrando, in entrambe le direzioni.

    Nota

    Se Client.exe e Router.exe sono sui computer diversi, rimuovere l'impostazione come commento della sezione <identity/> in Client.exe.config e impostare il nome utente principale su quello dell'utente che esegue Router.exe.

Send comments about this topic to Microsoft.
© 2007 Microsoft Corporation. All rights reserved.