Database
Il database è pure questa una componente fondamentale e importante, ci
sarà un database centralizzato che conterrà tutte le informazioni e i
dati di un determinato utente ed esso sarà accessibile da tutti i
Contenent Server così che se l’utente accedesse in mobile o tramite
desktop avrà accesso a tutti i suoi dati.
Un’alternativa è anche quella di avere un DB per ogni contenent server
che però sarà a conoscenza degli altri DB così in caso di necessità
andrà ad eseguire l’interrogazione sul DB interessato.
Vantaggi e Svantaggi
Vantaggi:
· Maggiore Portabilità
o Sfruttando la potenzialità del fatto che l’applicativo vero e proprio risiede sul server e che quindi l’utente per utilizzare l’applicazione dovrà interfacciarsi con il server non necessita alcuna modifica il lato back-end in quanto l’architettura che esegue l’applicativo è sempre la stessa di fatto andiamo a realizzare un’astrazione vera e propria.
· Maggiore Estensibilità
o In quanto per poter estendere il software andando ad aggiungere ulteriori funzionalità ci basterà lavorare su di un unico back-end e poi apportare le modifiche opportune su ciascun front-end. Sfruttando poi il principio di località fornito da dispatcher server potremo aggiungere nuove funzionalità senza che il client vada ad appesantirsi
· Maggiore Sicurezza
o Perché con questa architettura il software risiedendo all’interno del server possiamo realizzare tutti i sistemi di sicurezza necessari, soprattutto con il fatto che non abbiamo la centralizzazione delle chiamate, ma abbiamo un reticolato di server specializzati che andranno ad operare ognuno con proprie metodologie di sicurezza.
· Aggiornamenti dell'applicativo lato server
o In funzione del fatto che l’applicativo risiede all’interno dei server dello sviluppatore e soprattutto abbiamo un unico back-end lo sviluppo di aggiornamenti risulta essere molto più veloce, ma anche l’installazione risulta essere molto più veloce in quanto non dovremo richiedere l’installazione dell’aggiornamento agli utenti, ma sarà tutto a discrezione dello sviluppatore lato server, salvo aggiornamenti necessari per allineare il client con il server.
· Semplicità Client
o Il client risulta essere molto più minimale e semplificato, così da agevolare l’utilizzo da parte dell’utente e pesare meno (sotto l’aspetto di risorse hardware)per il dispositivo che ne fa uso.
· Unico BackEnd per tutti i tipi di Client
o Come detto già in precedenza andiamo in questa maniera a sviluppare un unico Back-end risiedente su i nostri server in quanto si va a realizzare un’astrazione vera e propria
· Sviluppo FrontEnd dedicato
o Mentre abbiamo un unico Back-end altro punto forte di questo modello è la possibilità di sviluppare il front-end dedicato per ogni tipo di dispositivo così da renderne l’utilizzo più facile, confortevole e soprattutto adeguato per il dispositivo utilizzato andando a lavorare secondo la strategia delle View
Svantaggi:
· Architettura Server più complessa
o Se da un lato andiamo a semplificare il client, dall’altro andiamo a rendere più complesso il lato server in quanto andiamo a delegare il 95% delle funzionalità e dell’esecuzione ai server delegati in questo, quindi richiedere una progettazione ed uno sviluppo dei server più rigorosa e precisa.
· Sviluppo gestione comunicazione Server
o Il lato server come si è visto è composto da più server specializzati in varie mansioni, questo richiede però un complesso e ottimizzato processo di comunicazione tra i vari server e il/i database, in quanto fulcro di questo modello è la comunicazione e l’interoperabilità di questi server per far si che si abbia una piena compatibilità, sicurezza, supporto e velocità nell’esecuzione dell’applicativo.