SOA vs Accesso diretto ai DB

Buongiorno a tutti,

di recente mi è capitato spesso di parlare con alcuni colleghi di quale sia il metodo più efficiente per recuperare i dati presenti su un DB remoto da parte di un’applicazione mobile (sia essa iOS, che Android che Windows Phone). Come sempre in questi casi, ne è nata una discussione quasi filosofica dove le posizioni prese sono state forti ma che, con il senno di poi richiedono una necessaria mediazione.

Come primo step identifichiamo le due architetture e come esse lavorano in teoria:

  • S.O.A. (Service Oriented Architecture): con questo acronimo si intende l’esposizione da parte di un server di un gruppo di servizi atti a svolgere determinati compiti. Se ad esempio voglio ottenere l’elenco delle aziende appartenenti ad una determinata categoria richiamo il servizio preposto (attraverso uno specifico protocollo, in genere SOAP) fornendo il parametro della categoria ed ottengo in risposta i risultati estratti (strutturati, generalmente, in XML) e quindi posso passare ad un’elaborazione locale.
  • Accesso diretto al DB: attraverso delle apposite API invio la query al DB ed ottengo in risposta i dati estratti che posso così sviscerare tramite le API di cui sopra.

Entrambi i metodi offrono vantaggi e svantaggi e la scelta dell’uno o dell’altro dipendono principalmente da un’accurata progettazione e da vincoli esistenti. Vediamoli di seguito:

  • S.O.A.: l’adozione di una S.O.A. permette di ottenere due grandi vantaggi: flessibilità, scalabilità, vediamoli in dettaglio: la flessibilità è rappresentata dalla possibilità di nascondere il metodo in cui vengono recuperati i dati, essi infatti possono essere il risultato di una query o di una elaborazione, entrambe possono essere eseguite su una sola macchina o su un cluster, tutto comunque resta nascosto al chiamante che ottiene, semplicemente il risultato del servizio; anche l’aggiunta di un nuovo servizio è trasparente permettendo così di avere più versioni del chiamante funzionanti contemporaneamente, se la struttura delle risposte è invariante o varia in modo tale da non richiedere un aggiornamento massivo dei chiamanti, allora la flessibilità è totale. La scalabilità è un altro fattore importante, difatti quando si sviluppa una struttura Client/Server (sia essa a due che a tre o più livelli)  per dimensionare i costi si parte da alcune assunzioni di base (ad esempio dimensione del database, numero di accessi contemporanei, transazionalità delle query), il che fa propendere verso la scelta di determinate combinazioni di Hardware/Software; col tempo, però, le esigenze possono cambiare, le risorse richieste o quelle disponibili potrebbero essere differenti, così come il numero di utenti, o anche i contratti con i fornitori. In questo caso l’adozione di una SOA permette di non doversi preoccupare dei client concentrando tutti gli sforzi verso la parte di business raggiungendo i risultati in modo più trasparente. Infine una nota particolare per il mondo mobile: l’adozione di un approccio SOA permette di realizzare i servizi indipendentemente dai dispositivi che li utilizzeranno essi infatti risponderanno, a meno che non sia richiesto, sempre nello stesso modo indipendentemente dal dispositivo che li richiama; inoltre se pur vero che i moderni dispositivi mobile sono molto più potenti che in passato, elaborazioni pesanti che coinvolgono diverse interrogazioni remote dovrebbero essere limitate al massimo proprio per risparmiare la batteria e la banda, due risorse estremamente ridotte ed importanti, creando servizi in grado di eseguire la maggior parte della logica di business riduciamo sia il numero che la quantità di dati viaggianti a tutto vantaggio dei dispositivi client. Ma se l’adozione delle SOA offre questi indubbi vantaggi, di contro richiede un grado di complessità, sia nella progettazione che nella realizzazione della soluzione, decisamente più elevato. Come detto prima la SOA prevede un server fornitore dei servizi, quindi un costo aggiuntivo, inoltre nella fase di progettazione bisogna identificare correttamente i servizi ed i protocolli per interloquire con essi. Tali servizi vanno quindi realizzati e manutenuti ed in applicazioni di media complessità il loro numero può essere impressionante. Tutto si traduce in un costo di realizzazione che non sempre è sostenibile dall’acquirente.
  • Accesso diretto ai DB: l’accesso diretto ai DB è tipico delle strutture Client/Server a due livelli; esso in genere consiste nell’inviare la query direttamente al server DB per ottenere i dati RAW da elaborare sul dispositivo. Il più grande vantaggio di questo approccio è la velocità, è infatti possibile richiedere le informazioni senza intermediari e quindi senza dover attendere che i dati siano inpacchettati dai servizi per poi essere spacchettati in locale (operazioni tutt’altro che indolore), inoltre se la procedura è concepita su due livelli non è necessario aumentare il grado di complessità. Altro motivo fondamentale per cui quest’approccio è perseguibile è che la struttura della procedura è rigida e quindi non è possibile aggiungere server intermedi che offrano dei servizi. Gli svantaggio sono principalmente nella perdita di flessibilità e di scalabilità. Lo sviluppatore deve necessariamente conoscere la struttura del DB ed ogni sua variazione impone la modifica del client e la sua celere ridistribuzione. Le elaborazioni non ottenibili sul server (grazie all’uso di query mirate, trigger e stored procedure) devono essere necessariamente eseguite sul client con gran consumo di batteria e banda. Al variare delle esigenze delle risorse ci si può trovare ad intervenire massivamente sul codice del client ed in caso di cambio di DBMS (Database Management System) ci si può trovare nella condizione di indisponibilità delle API necessarie. Infine l’aspetto sicurezza diviene un nervo scoperto, il dover accedere al DB porta a dover esporre il relativo server sulla Intranet o peggio ancora su Internet esponendolo ad attacchi di malintenzionati. Ovviamente è possibile lenire questi aspetti negativi, progettando con cura il DB, prevedendo una roadmap evolutiva abbastanza ampia nel tempo proteggendo il server con un firewall ben configurato, ma questo non li elimina del tutto.

Quando usare quindi l’una o l’altra soluzione?

In generale l’architettura S.O.A. dovrebbe essere la preferenziale, nel nostro mondo è molto facile ritrovarsi a dover gestire architetture che crescono esponenzialmente sia in funzionalità che in potenza e quindi le SOA sono l’approccio migliore. Se, però, dovete intervenire su un’architettura rigida nella quale non potete inserire un nuovo livello (rappresentato dalle SOA) allora la soluzione dell’accesso al DB è l’unica perseguibile.

Nei prossimi articoli parleremo di quali DBMS offrono delle API che permettano l’accesso dai dispositivi mobile in modo nativo (o quasi). Spesso le soluzioni possibili sono estremamente diverse da Sistema Operativo a Sistema Operativo ed alcuni potrebbero anche non prevedere una soluzione valida al tipo di approccio. Bisogna quindi essere coscienti che oltre a rischiare un grosso lavoro a livello di implementazione vi sarà sempre la limitazione rappresentata dal minimo comune multiplo dei database che supportano tutti i sistemi operativi su cui la soluzione è destinata e per i quali l’investimento è lecito.

Arrivederci al prossimo articolo,

Roberto S.



Related Posts Plugin for WordPress, Blogger...

Questa voce è stata pubblicata in Articoli e contrassegnata con , , , , . Contrassegna il permalink.
Wordpress Code Snippet by Allan Collins