Se paragoniamo la facilità con cui si possono servizi con WCF alle modalità di deploy, queste sono proprio un incubo.
Registrazione del Url in Http.sys
- Se il processo host è IIS, la registrazione non è necessaria
- Gli altri host (un Windows Service ad esempio) devono registrare il canale durante il setup.
Naturalmente i servizi non vanno mai fatti girare con alti privilegi come Administrator o Localsystem, per cui è necessario eseguire la registrazione in Http.sys durante il setup.
In cosa consiste la registrazione? Http.sys consente di far ascoltare più applicazioni sullo stesso indirizzo e sulla stessa porta. No, non è una violazione del TCP/IP, semplicemente Http.sys funge da multiplexer e ascolta lui per tutti, smistando le varie richieste ai processi in ascolto basandosi sugli URL.
Perciò una applicazione deve avere il permesso di poter ascoltare su un certo Url. In pratica è necessario assegnare una ACL con il permesso di Execute su un certo Url. Il formato di questi url è spiegato qui: http://msdn2.microsoft.com/en-us/library/aa364687.aspx
Ok, il setup gira come admin e quindi non è un problema.... invece si. In Windows 2003 (attualmente l'unico OS papabile per installazioni server nel mondo reale) non esiste una utility da poter lanciare durante il setup per fare questa registrazione.
L'utility HttpCfg.exe viene fornita nei support tools di Windows 2003 e non è installata by default, quindi il setup non può sapere se c'è e dove si trova. Inoltre non so neppure se sia possibile metterla dentro un setup, quindi anche la redistribuzione è un'ipotesi che ho dovuto scartare.
La soluzione è stata di riscrivermi l'utility in C++ nativo. Installazione, Visualizzazione e Rimozione della registrazione Url e relativa ACL. Finalmente ora posso usare una "custom action" di Windows Installer per eseguire la registrazione...
Configurazioni ed Endpoint
Che le configurazioni non siano la cosa più semplice in WCF appare chiaro fin dal primo approccio. Bello il tool di editing integrato con l'IDE di VS.NET ma alcune cose mi lasciano perplesso:
- maxReceivedMessageSize ed altri attributi nel <binding> non vengono passati nei metadati. Questo implica doverli cambiare specularmente a mano anche nella configurazione client. A scrivermi una versione custom dell'erogatore di metadati non ci penso proprio
- Ogni volta che aggiorno il contratto dal lato client, la configurazione non viene modificata ma aggiunta. Durante lo sviluppo questo è realmente penoso e si perde un sacco di tempo.
- Il nome del server come lo modifico nel web.config da setup? Se lascio localhost i metadati non sono più esposti in rete. Non vogliamo mica cablare il nome del server dentro il setup??? Orrore. Devo ancora trovare una soluzione indolore.
- Gli errori sul file di configurazione non hanno diagnostica. Peccato, capire dove sia il problema quando i servizi si chiamano in cascata è realmente complesso.
Unione delle configurazioni dei servizi
Bene, abbiamo scritto una decina di servizi e per risparmiare un po' di memoria li abbiamo messi in deploy in IIS dentro un unica web application (un solo AppDomain).
Sarebbe bello se ... i web.config dei servizi venissero uniti dal runtime semplicemente mettendoli in sottocartelle differenti, nè più nè meno di come avviene per i web.config di normali applicazioni asp.net.
Peccato che non funziona e sia necessario unire a mano tutti i file di configuraione in un web.config unico, con l'obbligo di ri-testare tutti i servizi visto che si è cambiato il file di configurazione che è comune.
Non ci penso nemmeno e quindi ho chiesto al fido collaboratore di scrivere una piccola utility che unisce tutti i .config nelle sottocartelle in un unico web.config. Qui mi sorge un dubbio... o mi sono perso qualcosa o sono l'unico che vede queste cose come gravosi problemi.
In conclusione
Dal punto di vista del modello e delle funzionalità, WCF è splendido. Tuttalpiù si tribola nel mettere a punto i file di configurazione ma poi fila tutto liscio.
I dolori vengono al deploy, e qui speriamo che Microsoft ci metta una pezza, perché al momento la gestione di questi problemi porta via un sacco di tempo.