2009-11-27 2 views
6

Ho un servizio accessibile tramite http e net.pipe. È ospitato in IIS 7 (Server 2008). Potrei ospitare diverse istanze di questo servizio per diversi clienti sulla stessa macchina e quindi l'HTTP è configurato con nomi host virtuali ecc. Tutto questo funziona perfettamente.che controlla il nome di una named pipe durante l'hosting di WCF net.pipe binding in IIS

ho pensato che avrei fatto simile per il tubo di rete denominata vincolante - utilizzando una qualche forma di dei clienti virtualhostname 'l'indirizzo di base named pipe, quindi, che mi permette per accedere alle diverse istanze dei clienti con diverse urne net.pipe (Mi rendo conto di i nomi net.pipe non sono URL dell'URN, quindi possono essere essenzialmente arbitrari ma Ho pensato di seguire un modello simile agli indirizzi HTTP).

Ecco il mio web.config

<service name="Administration" behaviorConfiguration="AdministrationBehavior"> 
    <endpoint address="" binding="wsHttpBinding" bindingConfiguration="normalWsBinding" contract="IAdministration" /> 
    <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> 
    <endpoint address="" binding="netNamedPipeBinding" bindingConfiguration="normalNetNamedPipeBinding" contract="IAdministration" /> 
    <endpoint address="mex" binding="mexNamedPipeBinding" contract="IMetadataExchange" /> 
    <host> 
     <baseAddresses> 
     <add baseAddress="http://virtualhostname.com/service" /> 
     <add baseAddress="net.pipe://virtualhostname.com/administration/service" /> 
     </baseAddresses> 
    </host> 
</service> 

Tuttavia, quando si accede al WSDL per il servizio - l'indirizzo di base per la net.pipe sembra di essere ignorato da IIS. Ricevo invece il vero nome host della macchina e un indirizzo URN della rete che sembra essere stato interamente formattato da IIS.

<wsdl:port name="NetNamedPipeBinding_IAdministration" binding="tns:NetNamedPipeBinding_IAdministration"> 
    <soap12:address location="net.pipe://realhostname/service/Administration.svc"/> 
    <wsa10:EndpointReference> 
     <wsa10:Address>net.pipe://realhostname.com/service/Administration.svc</wsa10:Address> 
     <Identity> 
      <Spn>host/realhostname.com</Spn> 
     </Identity> 
    </wsa10:EndpointReference> 
</wsdl:port> 

Con alcun controllo sul modo in cui si formano i nomi net.pipe, non sarò in grado di discriminare tra le diverse istanze di servizio al cliente sulla macchina. Qualcuno ha qualche idea su come il binding di pipe denominato net URN può essere controllato all'interno dell'ambiente IIS?

(Faccio un sacco di net.pipe standalone che ospita durante i test (cioè nuova ServiceHost()) quindi so che i miei attacchi net.pipe funzionano al di fuori di IIS, e DO consentono il controllo sopra il tubo di nome esatto URN utilizzato)

Se i nomi non possono essere controllati all'interno di IIS, qualcuno ha esperienza con hosting e accesso a più istanze del servizio net.pipe separate sulla stessa macchina ?

+0

si sa che i collegamenti net.pipe funzionano solo "sulla macchina", ad es. non è possibile accedere a quelli da qualche altro computer, anche se sono ospitati in IIS .... –

+0

quando si esegue l'hosting in IIS, non si può veramente scegliere il proprio indirizzo di servizio - è sempre 'http: // machinename [: port ]/virtualdir/yourservice.svc' - Sospetto che lo stesso valga per gli indirizzi net.pipe - non si può controllare la loro denominazione se ospitati in IIS .... –

+0

Sì, gli endpoint HTTP sono per l'accesso fuori macchina, e speravo di usare gli endpoint net.pipe per un accesso limitato alla macchina (ma, spero, più veloce). Quando si ospitano i miei endpoint HTTP in IIS, tuttavia, è possibile scegliere l'indirizzo del servizio (a un certo livello) perché si specifica il dominio che si desidera utilizzare. Questo mi permette di avere più siti IIS ogni accessibili tramite URL diversi cioè http://customer1.com/admin/Admin.svc e http://customer2.com/admin/Admin.svc Se posso' t scegliere i miei indirizzi di base per net.pipe, come posso avere più binding net.pipe ospitati per diversi clienti in IIS? –

risposta

2

Questa è una vecchia questione, ma ho pensato che vorrei aggiungere la mia risposta quando ho anche bisogno di una risposta per questo (e forse ci sono altri là fuori che ne ho bisogno anche tu).

L'indirizzo di base di un servizio WCF ospitato da IIS è controllato da IIS e non può essere sovrascritto in web.config. Invece, è possibile controllare gli indirizzi di base aggiornando le informazioni sul bind del sito IIS per il sito in cui si sta ospitando il servizio.

La maggior parte della documentazione che ho trovato online suggerisce di usare * come configurazione di binding per net.pipe. Se invece si utilizza "virtualsite.com" come valore di configurazione del binding, l'indirizzo di base del proprio endpoint net.pipe sarà "virtualsite.com" anziché il nome del computer.

Ecco un esempio utilizzando appcmd per configurare un sito in IIS con il legame del net.pipe corretta:

%windir%\system32\inetsrv\appcmd.exe set site "Default Web Site" -+bindings.[protocol='net.pipe',bindingInformation='virtualhostname.com'] 

Una nota circa HostNameComparisonMode, non ha alcun effetto in IIS in base al MSDN:

Questi valori non hanno alcun effetto se utilizzati all'interno dell'Internet Information Services (IIS) o dell'ambiente di hosting di Windows Process Activation Service (WAS). In questi casi, WCF utilizza qualsiasi modalità di confronto nome host fornita dal sito Web IIS che ospita i servizi WCF.

Invece, è necessario utilizzare il meccanismo che ho descritto sopra. Ho capito questo indagando su come funziona il binding del nome host in HTTP per IIS. Sfortunatamente, non sono stato in grado di trovare alcuna documentazione ufficiale per questo scenario basato su IIS per altri trasporti WCF.

+0

Grazie Chris. Il mio bisogno di risolvere questo problema è passato da tempo, ma sembra una buona informazione! –

0

Sembra che la parte del nome host dell'URI sia ignorata e sostituita dall'implementazione basata su HostNameComparisonMode del binding del canale. Si può provare a cambiare a "esatta" tramite la configurazione del servizio di ...

http://msdn.microsoft.com/en-us/library/system.servicemodel.netnamedpipebinding.hostnamecomparisonmode.aspx

NetNamedPipeBinding.HostnameComparisonMode Il valore HostNameComparisonMode che indica se il nome host viene utilizzato per raggiungere il servizio quando la corrispondenza URI. Il valore predefinito è StrongWildcard(), che ignora il nome host nella corrispondenza.

visualizzare la sintassi di configurazione qui: http://msdn.microsoft.com/en-us/library/ms731291.aspx

+0

Non sono sicuro se questo è nuovo rispetto alla risposta originale, ma in base al collegamento, HostnameComparisonMode non ha alcun effetto in IIS. –