Windows Communication Foundation
Da Wikipedia, l'enciclopedia libera.
Windows Communication Foundation (WCF), conosciuto in fase di sviluppo con il nome in codice Indigo, è un "sottosistema applicativo" proprietario della Microsoft, che offre la struttura API per la creazione di applicazioni distribuite in ambienti Windows. Se da un lato ogni protocollo di rete (e.g. HTTP, FTP, SMTP, ecc.) ha un suo modello di programmazione, e necessita quindi di una conoscenza specifica da parte degli sviluppatori per poter essere utilizzata, WCF è stato realizzato con l'intento di ricondurre ad un unico modello diverse tecnologie, rendendo più semplice ed uniforme la programmazione in ambiente Windows. È stato sviluppato per Windows Vista, ma è disponibile anche per i sistemi Windows XP SP2 e Windows Server 2003.
Indice |
[modifica] Definizione del sottosistema
Un servizio WCF si basa sugli '"EndPoint", che sono le porte attraverso le quali le applicazioni comunicano con il mondo esterno; si può quindi affermare che un servizio WCF sia una collezione di EndPoint. A sua volta, un Endpoint è costituito da quelli che sono i pilastri di WCF: "Address", "Binding", "Contract".
[modifica] Cos’è l’Address
L'Address è l'indirizzo al quale il servizio risponde. L'indirizzo è composto da un URI, una "Identity" ed una lista di "Header". In fase di definizione di un Address, l'informazione principale è l'URI, che corrisponde all'indirizzo fisico del servizio. Header e Identity sono informazioni che invece sono necessarie solo in casi particolari. Ad esempio quando ci sono più EndPoint, può essere utile avere diversi Header a seconda dell'Endpoint che il client utilizza. In parole semplici si può definire l'address come il DOVE.
[modifica] Cos’è il Binding
Gran parte della soluzione proposta da WCF sta nei concetto di Binding. Infatti se ci si può occupare del codice senza preoccuparsi dell'infrastruttura di trasporto lo si deve soprattutto a questa feature. I Binding si occupano di quello che avviene tra il momento in cui il servizio spedisce logicamente il messaggio ed il momento in cui viene fisicamente trasmesso in rete. In questo lasso di tempo vengono eseguiti numerosi passi che seguono una precisa pipeline di cui i binding sono responsabili. Durante l'esecuzione della pipeline il messaggio deve attraversare due livelli: il primo si occupa dei Behaviour (comportamenti), ovvero delle trasformazioni che deve subire un messaggio, il secondo si occupa dei Canali (detti Channel), ovvero dell'instradamento verso il canale fisico di trasporto. Nel primo livello 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 Behaviour si occupano anche della sicurezza, della criptazione delle informazioni e di tutte le funzioni di gestione del dato. 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 instanzia il canale del protocollo originale su cui viaggeranno le informazioni. Poiché a livello di protocollo si possono controllare alcuni dettagli, in questo livello si possono aggiungere informazioni sulla modalità di trasmissione, protetta o meno, oppure sul Reliable Messaging. Come detto in precedenza; questo processo avviene per mezzo di una pipeline. Seguendo lo stesso concetto della pipeline di ASP.NET, possiamo vedere tutte le opzioni finora illustrate (protocollo, formattazione, ecc.) come moduli da inserire nel flusso di elaborazione del messaggio. Poiché la gestione dei Binding può essere interamente gestita in fase di configurazione, si può intuire come semplicemente cambiando poche voci si può passare dalla pubblicazione in modalità Web su HTTPS criptato con un certificato digitale, ad un trasporto diverso del messaggio come SMTPS (SMTP Secured) senza dover modificare il codice. Se si volesse dare una parola chiave ai binding questa sarebbe COME.
[modifica] Cosa sono i Contract
I Contract (o contratti) rappresentano l'interfaccia software vera e propria, ovvero le API, che il servizio pubblica. Poiché ne esistono diverse tipologie l'argomento è molto vasto, si rimanda alla sezione collegamenti esterni della voce chi volesse approfondire l'argomento. Si può comunque dire che i Contract rappresentano il COSA.
[modifica] Architettura
WCF è stato pensato sin dall'inizio tenendo in mente le architetture orientate ai servizi. In una tecnologia come questa è molto importante mettere a disposizione un'interfaccia software che l'utilizzatore del servizio ed il servizio stesso possano utilizzare per comunicare. In WCF quest'interfaccia di scambio è il Contract (ovvero contratti). I contratti non stabiliscono solo quali operazioni si possono invocare su un servizio, ma anche come e quali dati si debbano scambiare. Da questa considerazione si evince che esistono diverse tipologie di contratti racchiuse in tre tipologie: ServiceContract, DataContract e MessageContract.
[modifica] I ServiceContract
I ServiceContract definiscono il servizio e tutte le API che questi mette a disposizione. La definizione di un simile contratto vede la sua naturale implementazione in un'interfaccia .NET da sviluppare. Di per se, un'interfaccia non ha alcun senso parlando in termini di Service Oriented Architecture; infatti, pur definendo metodi e proprietà, non stabilisce se questi debbano essere resi pubblici o meno. Bisogna ricordare che in con SOA la visibilità di un metodo o di una proprietà all'interno di una classe non ha alcun collegamento con la visibilità che può avere all'interno del servizio. A seconda dei casi, un metodo privato di una classe potrebbe diventare un'API del servizio, mentre un metodo pubblico della stessa classe potrebbe non essere pubblicato dal servizio. In WCF, per definire i metodi da pubblicare, bisogna arricchirli con opportuni attributi dichiarati nella definizione dell'interfaccia. Gli attributi da utilizzare sono ServiceContract con la quale marcare l'interfaccia e OperationContract, per ogni metodo da pubblicare.
[modifica] I DataContract
Una volta che è stato stabilito quali operazioni mettere a disposizione dei client, arriva il momento di definire quali informazioni debbano essere pubblicate. Questo è compito dei DataContract. Supponiamo che un servizio pubblichi un metodo che dato il codice fiscale ritorni i dati della persona associata. Nel DomainModel l'oggetto Persona contiene informazioni come Nome, Cognome, Data di Nascita e altro ancora, tuttavia può nascere l'esigenza di non pubblicare tutti i dati della persona ma soltanto quelli che si ritengono opportuni. Per ottenere un risultato del genere bisogna corredare sia la classe che le sue proprietà con attributi, più precisamente alla classe va applicato l'attributo DataContract e alle proprietà l'attributo DataMember.
[modifica] I MessageContract
Per default, tutte le proprietà di una classe vengono mappate all'interno del corpo di un messaggio. A seconda delle esigenze, può capitare che si debbano piazzare delle informazioni nelle intestazioni invece che nel corpo; questa mappatura tra le classi ed il formato del messaggio viene impostato tramite i MessageContract. Anche in questo caso l'impostazione di queste opzioni avviene tramite attributi e, più precisamente, MessageContract per la classe e MessageBody o MessageHeader per le proprietà.
