Windows Communication Foundation (WCF), meglio conosciuto con il nome in codice di INDIGO, è quella parte di WINFX che offre la struttura per la creazione di applicazioni distribuite.

Attualmente esistono diverse tecnologie per creare questo tipo di applicazioni e tutte ottimamente supportate dal .NET framework. Si ricorrono ai WebService, quando si ha l'esigenza di interoperabilità con il maggior numero di sistemi eterogenei, Remoting, nel caso in cui si devono mettere in comunicazione due sistemi .NET ed avere un forte controllo su entrambi, e, ancora, Microsoft Message Queue (MSMQ) per sviluppare applicazioni asincrone basate su messaggi. Visto il supporto già esistente per ogni tipo di esigenza, ci si può chiedere quale sia stato il motivo che ha spinto Microsoft a creare un nuovo Framework per applicazioni distribuite; la risposta è più semplice di quanto si possa immaginare. Ogni tecnologia ha un suo modello di programmazione e necessita quindi di una conoscenza specifica, da parte degli sviluppatori, per poter essere utilizzata.
WCF pone fine a questa Babele unificando in un unico modello di programmazione tutte le attuali tecnologie. Infatti, in WCF, il codice da sviluppare diventa unico qualunque sia la modalità di trasporto delle informazioni (HTTP, HTTPS, TCP, ecc).

Si parte dall'ABC

Un servizio WCF si basa sugli Endpoints che sono le porte attraverso le quali l'applicazione comunica con il mondo esterno; si può quindi affermare che un servizio WCF sia una collezione di Endpoints. A sua volta, un Endpoint è costituito da quelli che sono i pilastri di WCF: Address, Binding, Contract.

L'Address è l'indirizzo al quale il servizio risponde. L'indirizzo è composto da un Uri, un Identity e una lista di Headers. In fase di definizione di un Address, l'informazione principale è l'URI che corrisponde all'indirizzo fisico del servizio (es http://localhost/ws/svc). Headers e Identity sono informazioni che invece sono necessarie solo in casi particolari. Ad esempio quando ci sono più Endpoints può essere utile avere diversi Headers a seconda dell'Endpoint che il client utilizza. In parole semplici si può definire l'address come il DOVE.

Gran parte della magia dietro WCF sta nei Bindings. Infatti se ci si può occupare del codice senza preoccuparsi dell'infrastruttura di trasporto lo si deve soprattutto a questa feature. I Bindings si occupano di quello che avviene tra il momento in cui il servizio spedisce logicamente il messaggio ed il momento in cui viene fisicamente messo in rete. In questo lasso di tempo vengono eseguiti numerosi passi che seguono una precisa pipeline di cui i bindings sono responsabili.

Durante l'esecuzione della pipeline il messaggio deve attraversare due layer: il primo si occupa dei Behaviour, ovvero delle trasformazioni che deve subire un messaggio, il secondo si occupa dei Channels ovvero dell'instradamento verso il canale fisico di trasporto. Nel primo layer ci si occupa della conversione dei dati dal formato 'codice' al formato messaggio; ad esempio, vengono trasformate le informazioni da una classe al formato xml di un messaggio SOAP. In aggiunta i Behaviours si occupano anche della sicurezza, del criptaggio delle informazioni e di tutte le feature relative ai dati. Durante la seconda fase il messaggio viene messo sul canale di trasporto secondo quanto specificato in fase di configurazione. Quindi è in questa fase che si istanzia il canale (HTTP, HTTPS, MSMQ, TCP) su cui viaggeranno le informazioni. Poichè a livello di protocollo si possono controllare alcuni dettagli, in questo layer si possono aggiungere informazioni sulla modalita di trasmissione, protetta o meno, oppure sul Reliable Messaging. Come detto in precedenza, questo processo avviene attraversando una pipeline.
Seguendo lo stesso concetto della pipeline di asp.net, possiamo vedere tutte le opzioni dette finora (protocollo, formattazione, ecc) come moduli da inserire nel flusso di elaborazione del messaggio.

Poichè la gestione dei Bindings può essere interamente gestita in fase di configurazione, si può intuire come semplicemente cambiando poche voci nel config si può passare dalla pubblicazione in modalità WebService su HTTPS criptato con un certificato digitale, ad un formato su TCP con ReliableMessaging senza dover intaccare il codice. Se si volesse dare una parola chiave ai bindings questa sarebbe COME.

Dopo l'A e la B è il momento della C dei Contracts. I Contracts rappresentano l'interfaccia software, ovvero le API, che il nostro servizio pubblica. Poichè esistono diversi tipi di contratti e l'argomento è molto vasto è giusto creare una sezione a parte. Si può comunque dire che i Contracts siano il COSA.