Più endpoint su un solo ListenUri

L'esempio MultipleEndpointsSingleUri illustra un servizio che ospita più endpoint su un singolo ListenUri. Questo esempio si basa sull'Introduzione che implementa un servizio calcolatrice.

Nota

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

Come illustrato nell'esempio Più endpoint, un servizio può ospitare più endpoint, ognuno con indirizzi diversi e possibilmente anche associazioni diverse. Questo esempio mostra che è possibile ospitare più endpoint sullo stesso indirizzo. Questo esempio illustra anche le differenze tra i due tipi di indirizzi che un endpoint del servizio possiede: EndpointAddress e ListenUri.

EndpointAddress è l'indirizzo logico del servizio. È l'indirizzo cui vengono inviati i messaggi SOAP. ListenUri è l'indirizzo fisico del servizio. Ha una porta e indirizza le informazioni laddove l'endpoint del servizio effettivamente è in ascolto per i messaggi sul computer corrente. Nella maggior parte dei casi, non è necessario che questi indirizzi siano differenti; quando un ListenUri non è specificato in modo esplicito, imposta come valore predefinito l'URI dell'EndpointAddress dell'endpoint. In alcuni casi, è utile per distinguerli, ad esempio durante la configurazione di un router che potrebbe accettare messaggi indirizzati a vari servizi diversi.

Servizio

Il servizio in questo esempio ha due contratti, ICalculator e IEcho. Oltre all'endpoint IMetadataExchange consueto, sono tre gli endpoint dell'applicazione, come mostra il codice seguente.

<endpoint address="urn:Stuff"
        binding="wsHttpBinding"
        contract="Microsoft.ServiceModel.Samples.ICalculator"
        listenUri="http://localhost/servicemodelsamples/service.svc" />
<endpoint address="urn:Stuff"
        binding="wsHttpBinding"
        contract="Microsoft.ServiceModel.Samples.IEcho"
        listenUri="http://localhost/servicemodelsamples/service.svc" />
<endpoint address="urn:OtherEcho"
        binding="wsHttpBinding"
        contract="Microsoft.ServiceModel.Samples.IEcho"
        listenUri="http://localhost/servicemodelsamples/service.svc" />

Tutti e tre gli endpoint sono ospitati sullo stesso ListenUri e utilizzano la stessa binding- endpoint sullo stesso ListenUri devono avere la stessa associazione, perché condividono un solo stack di canali che ascolta i messaggi su quell'indirizzo fisico del computer. L' address di ogni endpoint è un URN; sebbene in genere gli indirizzi rappresentano posizioni fisiche, infatti l'indirizzo può essere qualsiasi tipo di URI, perché l'indirizzo viene utilizzato per far corrispondere e filtrare scopi come è dimostrato in questo esempio.

Perché tutti e tre gli endpoint condividono stesso ListenUri, quando un messaggio vi arriva, Windows Communication Foundation (WCF) deve decidere a quale endpoint è destinato il messaggio. Ogni endpoint ha un filtro messaggi composto di due parti: il filtro dell'indirizzo e il filtro del contratto. Il filtro dell'indirizzo adegua To del messaggio SOAP all'indirizzo dell'endpoint del servizio. Ad esempio, solo i messaggi con indirizzo To "Urn:OtherEcho" sono candidati per il terzo endpoint di questo servizio. Il filtro del contratto associa le azioni associate alle operazioni di un particolare contratto. Ad esempio, messaggi con l'azione IEcho. Echo fa corrispondere i filtri del contratto del secondo e del terzo endpoint di questo servizio, perché entrambi quegli endpoint ospitano il contratto IEcho.

Così la combinazione di filtro dell'indirizzo e filtro del contratto rende possibile il routing di ogni messaggio che arriva al ListenUri di questo servizio all'endpoint corretto. Il terzo endpoint è differente dagli altri due perché accetta messaggi inviati a un indirizzo diverso dagli altri endpoint. I primo e secondo endpoint sono diversi uno dall'altro sulla base dei contratti (azione del messaggio in arrivo).

Client

Nel momento in cui gli endpoint del server hanno due indirizzi diversi, anche gli endpoint client hanno due indirizzi. Su server e client, viene chiamato l'indirizzo logico EndpointAddress. Ma mentre l'indirizzo fisico è chiamato ListenUri nel server, sul client l'indirizzo fisico è chiamato Via.

Come nel server, per impostazione predefinita, questi due indirizzi sono gli stessi. Per specificare una Via sul client diversa dall'indirizzo dell'endpoint viene utilizzato ClientViaBehavior:

Uri via = new Uri("http://localhost/ServiceModelSamples/service.svc");
CalculatorClient calcClient = new CalculatorClient();
calcClient.ChannelFactory.Endpoint.Behaviors.Add(
        new ClientViaBehavior(via));

Come al solito, l'indirizzo proviene dal file di configurazione client, generato da Svcutil.exe. Via (che corrisponde a ListenUri del servizio) non viene visualizzato nei metadati del servizio e così queste informazioni devono essere comunicate al client fuori banda (proprio come l'indirizzo dei metadati del servizio).

Il client in questo esempio invia messaggi a ognuno dei tre endpoint dell'applicazione del server, per dimostrare che può comunicare con (e distinguere tra) i tre endpoint, anche se tutti hanno la stessa Via.

Per impostare, compilare ed eseguire l'esempio

1. Assicurarsi di aver eseguito la Procedura di installazione singola per gli esempi di Windows Communication Foundation.

2. Per compilare l'edizione in C# o Visual Basic .NET della soluzione, seguire le istruzioni in Building the Windows Communication Foundation Samples.

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

   Nota

   Per un'esecuzione a più computer, è necessario sostituire localhost nel file Client.cs con il nome del computer del servizio.