Una volta avviata l'applicazione questa resterà in ascolto in base alle informazioni specificate nel .config relative all'address, binding e contract.
Nel caso del nostro servizio, la creazione manuale di un Host è alquanto inutile in quanto possiamo sfruttare IIS. Con l'installazione di WinFX, viene inserito un nuovo mapping nel metabase di IIS che associa l'estensione .SVC alla pipeline di asp.net. Grazie a questa estensione, il runtime capisce che quando arriva una richiesta con estensione SVC questa deve essere passata al motore di WCF che istanzia il servizio per soddisfare la richiesta.
La tecnica è molto simile ai file .asmx e consiste nel creare un file .svc contenente la dichiarazione del servizio da utilizzare:

Sfruttare il servizio: il Client

Quando si parla di servizi, ci sono sempre due entità: una è il servizio che, una volta avviato, rimane in attesa di essere invocato; l'altra è il client che invia messaggi al servizio.
Il client può essere una qualsiasi applicazione, sia essa WinForm, Web, un secondo servizio WCF o ovviamente una qualsiasi altra piattaforma. Per poter invocare un servizio, il client deve conoscere l'interfaccia di comunicazione che in WCF è il contratto, quindi, analogamente a quanto avviene ora per i WebService, è necessario creare un proxy che si interfacci al servizio.
Attualmente, Visual Studio non ha un'interfaccia grafica per costruire in automatico il proxy, quindi la sola possibilità è utilizzare il tool SvcUtil.exe, incluso in WinFX, da riga di comando. Questo tool risulta molto comodo perchè non solo crea automaticamente il proxy, ma anche il file di configurazione che il client può utilizzare per la connessione. Quest'ultima frase lascia capire che anche il client può essere pilotato da configurazione senza bisogno di codice esattamente come si fa con il servizio.

Avendo anche il client un EndPoint, le informazioni da pubblicare sono le stesse del servizio: l'Address, il Binding ed il Contract. I primi due corrispondono ai dati dell'endpoint utilizzato dal servizio, mentre il contract corrisponde alla classe automaticamente generata nel proxy. L'altra differenza rispetto alla configurazione del servizio è il nome del nodo principale che contiene i dati: invece di avere un nodo <services> con diversi <service> innestati, esiste un nodo client con tutti gli endpoint figli:

Anche qui, una volta stabilita l'interfaccia si passa al codice per invocare il servizio e ricevere i dati. Nel nostro caso il client sarà una classica Windows Application che al click di un bottone invoca il servizio.

Questo snippet illustra come il codice sia in realtà molto banale e simile a quello che si fa ora per i WebService: si crea un'istanza del proxy e si invoca il metodo. Anche per il client, qualunque sia il protocollo, i behaviour e altro ancora, sarà sempre compito di WCF eseguire la pipeline che porta alle trasformazioni e all'invio fisico del messaggio e viceversa alla ricezione della risposta, ripercorrendo la pipeline al contrario.

Conclusioni

In questo articolo è stata grattata solo la superficie di Windows Communication Foundation. Le potenzialità di questa piattaforma sono veramente vaste e con il tempo verranno ampiamente approfondite. WinFX uscirà a fine anno come framework incluso in Windows Vista, quindi è arrivato il momento di cominciare a dedicare un pò di tempo a questa nuova tecnologia destinata a soppiantare tutte quelle esistenti per lo sviluppo di applicazioni distribuite.

Contenuti dell'articolo

• Pagina 1
  • Si parte dall'ABC
• Pagina 2
  • Cosa sono i Contracts
  • Un'occhiata al codice
• Pagina 3
  • Hosting del servizio
• Pagina 4
  • Sfruttare il servizio: il Client
  • Conclusioni