Servizio hosting IIS WCF vs servizio Windows

Question

Abbiamo sviluppato un servizio WCF e stiamo cercando di distribuirlo. I nostri clienti lo utilizzeranno con basicHttpBinding ma il nostro team interno lo utilizzerà con namedPipesBinding.

Ci chiediamo se è meglio ospitarli in IIS 7 o con un servizio di Windows. Abbiamo eseguito alcuni test e abbiamo scoperto che quando aggiungiamo binding in IIS, non aggiorna il file di configurazione del nostro servizio. Ciò significa che avremmo bisogno di mantenere la configurazione in due posti diversi. Non è logico, giusto?

Leggiamo anche su StackOverflow che l'indirizzo di base viene ignorato quando un servizio WCF è ospite in IIS (vedi WCF service configuration file question regarding <baseAddresses>)

Answer 1

Per rispondere a coloro domanda:

abbiamo eseguito alcuni test e abbiamo scoperto che quando stiamo aggiungendo attacchi in IIS, esso non aggiorna il file di configurazione del nostro servizio. Ciò significa che vorremmo che mantenga la configurazione in in due posti diversi. Non è logico, giusto?

Quando si utilizza IIS per ospitare il servizio, è necessario configurare il file app.config o il file web.config per permettere IIS per esporre qualche legame, quindi nel file di configurazione, si metterà tutto il vostro legame permettete al tuo servizio wcf. Http, net.tcp ecc ...

Nel bind non verrà specificato l'indirizzo, poiché verranno specificati tali indirizzi in IIS direttamente.

In IIS è necessario consentire l'associazione disponibile nelle impostazioni avanzate del proprio sito Web. Dopodiché imposterai nuovi binding per il tuo sito web "web service" e aggiungerai tutti i binding che vuoi ascoltare e specifichi l'indirizzo.

Specificare l'indirizzo direttamente in IIS.

C'è un esempio.

Il file di configurazione:

<services> 
    <service name="ServiceName">      
     <endpoint address="" 
      binding="basicHttpBinding" 
      bindingConfiguration="httpMode" 
      contract="IContract" />     
     <endpoint address="" 
      binding="netTcpBinding" 
      contract="IContract" /> 
     <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> 
    </service> 
</services> 

Nel vostro IIS Advenced impostando il metterà

http, net.tcp in Protocolli abilitati

Dopo di che si andrà nella vostra vincolante in IIS. Metti la tua vincolante per http normalmente e aggiungere un nuovo net.tcp vincolante, nella configurazione vincolante mettere il porto e la directory virtuale come

8001: *

Questa impostazione consentire a tutti la connessione alla porta 8001 per qualsiasi directory virtuale.

È inoltre necessario disporre della funzionalità "Attivazione WCF (attivazione Http e attivazione non Http)" sul server.

Answer 2

IIS fornisce un sacco di funzioni out-of-the-box, come dominio app ricarica, monitoraggio e così via.

Ecco perché è necessario rispondere a queste domande prima: avete bisogno di tutte queste funzionalità o no? In caso contrario, è possibile prendere in considerazione il servizio Windows.

Answer 3

L'hosting in IIS ha molti vantaggi e molti svantaggi.

Sì, IIS offre un caricamento su richiesta, che può essere più o meno. Quando arriva una richiesta, viene creato ServiceHost, quindi la classe di servizio ospitata viene istanziata e la richiesta viene gestita. Niente deve essere in esecuzione tutto il giorno. Ma allo stesso tempo, questa configurazione richiede più tempo e impegno ogni volta che arriva un messaggio, e tu come programmatore non hai molto controllo sul tuo host di servizio, davvero.

E sì, con IIS, la directory virtuale in cui risiede il file * .svc definisce il proprio indirizzo: tutti gli indirizzi di base o gli indirizzi definiti in modo esplicito nella configurazione vengono ignorati. E senza molti sforzi, non puoi cambiare il layout degli indirizzi di servizio: saranno sempre http://servername/virtualdirectory/YourService.svc (inclusa l'estensione .svc).

L'auto-hosting è spesso più veloce, dal momento che ServiceHost è già attivo e funzionante, ma spetta a te assicurarti che sia davvero attivo e funzionante, non c'è caricamento "su richiesta" ogni volta che arriva un messaggio - o è su e può servire la richiesta, o no. Ma hai molto più controllo sull'host del servizio - quando e come è costruito ecc., E puoi scegliere e definire i tuoi indirizzi di servizio come meglio credi.

Personalmente preferirei quasi sempre utilizzare l'auto-hosting - in un'app console per i test, in un servizio NT per la produzione. Per me, sembra il modo più appropriato per farlo, e anche il modo più controllato. Devi fare più lavoro - ma sai esattamente cosa stai facendo.

Marc

Answer 4

marc_s solito dà grandi risposte che sono d'accordo con tutto, ma in questo caso io non lo fanno.
L'auto-hosting di WCF non è una buona idea, specialmente con le tecnologie di Dublino rilasciate presto da Microsoft. La gestione e le operazioni delle applicazioni WCF (e WF) sono molto più semplici quando sono ospitate all'interno di IIS.

Inoltre si ottiene il caricamento su richiesta.

Esiste un'opzione sempre attiva per IIS7.5 (WS2008 R2).

E si può facilmente fare la riscrittura dell'URL per omettere il .svc se questo ti infastidisce.

Answer 5

Interessante tidbit-> dopo aver letto questa discussione mi sono imbattuto in queste parole in MSDN sull'hosting un servizio WCF utilizzando un servizio di Windows:

I seguenti sono alcuni degli svantaggi di servizi di Windows:

• Distribuzione: i servizi devono essere installati con l'utilità Installutil.exe di .NET Framework o tramite un'azione personalizzata in un pacchetto di installazione.
• Funzioni limitate: i servizi Windows dispongono ancora di un set limitato di funzioni pronte all'uso per supportare la disponibilità elevata, la facile gestione, il controllo delle versioni e gli scenari di distribuzione. In sostanza, devi soddisfare questi requisiti da te stesso tramite codice personalizzato mentre, ad esempio, IIS viene fornito con alcune di queste funzionalità per impostazione predefinita. I servizi di Windows aumentano la recuperabilità e alcune funzionalità di sicurezza, ma devi comunque lavorare autonomamente.
http://msdn.microsoft.com/en-us/library/bb332338.aspx

... e il seguente link:

Hosting Services: (tabella di confronto bello)
http://msdn.microsoft.com/en-us/library/ms730158.aspx

Answer 6

Non esiste una risposta standard a questa domanda. Non sono d'accordo completamente con la risposta di Cheeso (l'auto-hosting di WCF non è una buona idea).

Si prega di verificare seguenti link: (http://msdn.microsoft.com/en-us/library/ms730158.aspx, http://msdn.microsoft.com/en-us/library/bb332338.aspx) e pensare alle vincoli:

• sistema operativo
• prestazioni attese
• disponibili HW
• disponibilità prevista

e vedrai che in molte situazioni "self hosting" è il bes t alternativa.

Answer 7

Sebbene sia presente una risposta selezionata, mi consentirò di pubblicare un collegamento di thread Q/A.

How to configure WCF service from code when hosted in IIS?

quello che troverete nella mia risposta lì (e il link in esso) è il vostro controllo preciso l'host di servizi se lo si carica in WService o in IIS.

All'avvio del servizio è possibile interconnettere a IIS i collegamenti necessari e creare gli endpoint appropriati. Cerca la configurazione di IIs attraverso lo spazio dei nomi Microsoft.Web.Administration.

Spero che questo aiuti un po '.