Dependency Injection con Ninject

Riprendendo il post introduttivo alla dependency injection, sono numerosi i pacchetti in nuget che consentono di creare injection in maniera semplice. Ninject è un dependency injector open-source per .NET e vanta un numero piuttosto cosistente di scaricamenti ed installazioni.  Alcuni dei punti di forza che vengono enfatizzati dal team di sviluppo sono la semplicità e la facilità di utilizzo.

Nello sviluppo di applicazioni Web, in particolare MVC, l’utilizzo di un dependency injector consente di realizzare velocemente soluzioni “switchando” tra repository differenti. Questo significa che è possibile realizzare applicazioni con dati “demo” facilmente testabili e successivamente passare ai dati in produzione.

Continua a leggere Dependency Injection con Ninject

Outh2 – Il protocollo per l’autenticazione

Outh2 è un protocollo di comunicazione open, che può essere utilizzato nello sviluppo di applicazioni che necessitano di fornire un servizio di autenticazione. Outh2 è l’evoluzione del protocollo Outh ideato da Blaine Cook nel 2006, originariamente sviluppato come un’implementazione Twitter di OpenId come alternativa a competitors come  Google AuthSub, AOL OpenAuth, Yahoo BBAuth, Flickr API. Le specifiche del protocollo sono descritte dall’RFC 8252  .

Continua a leggere Outh2 – Il protocollo per l’autenticazione

Design Patterns

I design patterns sono un’elemento fondamentale per lo sviluppo di architetture software complesse. Durante le fasi della progettazione, prima della fase di scrittura, è importante porre l’attenzione sulla riusabilità o meglio sulla possibilità di riutilizzare lo stesso codice all’interno della stessa soluzione ma anche in progetti diversi.

Riutilizzare codice all’interno dello stesso progetto, ma anche in nuovi progetti

Le architetture software, sviluppate ad oggetti e ben strutturate, sono composte da pattern. Una delle metriche utilizzabili per valutare la qualità di un software potrebbe essere proprio l’attenzione posta dagli sviluppatori nel riutilizzo del codice e l’applicazione di pattern.
Continua a leggere Design Patterns

Docker – Usiamo i container!

Nell’ambito IT le macchine virtuali hanno portato ad una vera rivoluzione: la possibilità di installare più sistemi operativi (magari comunicanti tra loro) sulla stessa architettura hardware, ha permesso di risparmiare sui costi e sull’hardware. L’unico vero e proprio problema riguarda il modo di istanziare il sistema operativo: anche se virtuale, necessita comunque di spazio disco e ram (che è quella dell’hardware dove viene fatta girare).

Continua a leggere Docker – Usiamo i container!

Architettura Microservice – Comunicazione

Per la comunicazione interna tra microservices ci sono diverse scuole di pensiero!

In un mondo ideale, ogni singolo servizio dovrebbe essere indipendente da ogni altro, ma ovviamente solo in un mondo ideale. Se si rende necessaria l’iterazione tra microservices per soddisfare una singola richiesta, non siamo in presenza di un problema di protocollo, bensì  di un problema di architettura.  In questo caso non è importante quale tipo di comunicazione si sia scelta (HTTP, AMQP, messaggi asincroni ecc…), ma il tempo con il quale verrà soddisfatta la richiesta e soprattutto l’affidabilità dei singoli servizi.

Nel caso in cui sia necessario creare un meccanismo di comunicazione, quest’ultimo dovrebbe essere asincrono.

In un comunicazione asincrona (Async I/O) le chiamate non sono bloccanti per il processo ( o il thread) che le hanno effettuate. In questo modello di comunicazione, la chiamata non risulta bloccante fino alla ricezione di una risposta da parte del servizio destinatario, ma è libera di procedere nel normale flusso di esecuzione. Per poter intercettare la risposta da parte del processo destinazione, è possibile utilizzare callback, promise e streams.

Non  è però sempre possibile evitare l’utilizzo di operazioni sincrone: basti ad esempio pensare all’iterazione con un database, che deve avvenire all’interno delle ciclo richiesta-risposta.

La necessità di strutturare le comunicazioni in modalità asicrona, si basa sul principio tale per cui i microservices debbano essere indipendenti l’uno dall’altro e soprattutto dovrebbero funzionare anche se gli altri servizi fossero temporaneamente non disponibili.

Alla base della comunicazione tra servizi, c’è sicuramente la necessità di ottenere risposte nel piu’ breve tempo possibile. In questo scenario, il protocollo HTTP è sicuramente il metodo piu’ semplice, e forse più affidabile, possibile. Inoltre consente di essere impiegato sia in scenari sincroni, sia in scenari asincroni.

L’ HTTP  è un protocollo sincrono: a seguito di una richiesta fatta dal client, si attende la risposta.

Volendo implementare una soluzione asincrona, il thread del client potrebbe non attendere, eseguire altro codice, e gestire le operazioni solo alla ricezione della risposta da parte del server.

Una soluzione possibile per disaccopiare i servizi è quella di effettuare una ridondanza dei dati: in questo modo vengono replicati nei vari servizi, con l’evidente vantaggio di delegare la responsabilità ad ogni singolo contesto locale. Ad esempio utilizzando sistemi indipendenti SCS (self-contained system).

Ma come ridondare? Ad esempio, utilizzando processi di polling monitorando richieste RESTFul. L’utilizzo di un’architettura basata su protocollo HTTP consente di utilizzare meccanismi di caching, senza dover implementare nuove astrazioni.

Altri metodi fanno uso di sistemi di messaggistica come Akka o Erlang che consentono di semplificare le funzioni di scambio dati tra servizi.