Windows Communication Foundation: differenze tra le versioni

Contenuto cancellato Contenuto aggiunto
Nessun oggetto della modifica
Nessun oggetto della modifica
Riga 9:
== Cos’è l’address ==
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ù EndPoint 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.
== Cos’è il binding ==
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 Behaviours, 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 modalità 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.
== Cosa sono i Contracts ==
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.
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 possono utilizzare per comunicare. In WCF quest'interfaccia di scambio è il contratto.
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.
 
I ServiceContract definiscono il servizio e tutte le API che mette a disposizione. La definizione di un simile contratto vede la sua naturale definizione in un'interfaccia .NET da implementare. 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 decorarli 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.
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 decorare sia la classe che le sue proprietà con attributi, più approfonditamente alla classe va applicato l'attributo DataContract e alle proprietà l'attributo DataMember.
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; questo mapping tra le classi ed il formato del messaggio viene impostato tramite 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à.
Un'occhiata al codice
= Esempi e dettagli tecnici =
DopoNel tanta teoria, è arrivato il momento di passare al codice. Comeseguente esempio verrà creato un servizio che riceve in input un codice prodotto e restituisce tutte le informazioni legate al prodotto con quel codice.
La prima cosa da fare quando si costruisce un servizio con WCF è stabilire il contratto di comunicazione tramite interfaccia che nel nostro caso è la seguente:
[ServiceContract]