Esempi applicativi pattern
architetturali
Corso di Ingegneria del Software Avanzata
a.a. 2014-2015
Docente:
Marina Mongiello
Sommario
•
•
•
•
Architectural Pattern
Pattern for cloud environment
Pattern for big data management
Architetural decision problems:
– Software gestione punti vendita di una catena di libri.
– Context-aware system: Sistema adattativo: SIEM
(Security Information and Event Monitoring)
sottosistema adaptive authentication
• Trasposizione in contesto cloud
Architettura software
Definizione
L'architettura di un sistema software è
l'insieme delle principali decisioni di progetto
relative al sistema. Le decisioni progettuali
contemplano ogni aspetto del sistema quali
la struttura, il comportamento, l'interazione
e le proprietà non funzionali
Pattern
• Un pattern documenta una soluzione ad
un problema ricorrente in un dato
contesto.
• È molto di più del solo problema di
progetto o della struttura della soluzione:
– include sia il problema che la soluzione, uniti
alla logica che li lega.
Pattern architetturali
Definizione:
• Un pattern architetturale descrive lo
schema organizzativo della struttura che
caratterizza un sistema software.
– Individua le parti del sistema a cui sono
associate responsabilità omogenee e le
relazioni che esistono tra i diversi sottoinsiemi.
Pattern broker
• Area problematica: gestione della comunicazione
Il pattern Broker:
• Viene utilizzato per la strutturazione di sistemi software
distribuiti
con
componenti
indipendenti
che
interagiscono attraverso invocazione di servizi remoti.
• È responsabile:
1.
2.
della coordinazione delle comunicazioni, come
l'inoltro delle richieste
della trasmissione dei risultati e delle eccezioni.
Broker e requisiti non funzionali
•
•
•
Costruire un sistema complesso costituito da un insieme di componenti
indipendenti ed inter operanti, piuttosto che un'applicazione monolitica, produce
maggiore flessibilità, manutenibilità e predisposizione al cambiamento.
Un sistema in cui si partizionano le funzionalità in singole componenti debolmente
accoppiate risulta potenzialmente distribuibile e scalabile. Tuttavia, quando i
componenti distribuiti devono comunicare tra loro, è necessario un inter-processo
per la gestione della comunicazione.
Se le componenti gestissero in autonomia le loro comunicazioni, il sistema
risultante riscontrerebbe diverse dipendenze e limitazioni. Ad esempio:
– il sistema diventerebbe dipendente dal meccanismo di comunicazione utilizzato,
– i client dovrebbero conoscere la posizione dei server e,
– in molti casi, le soluzioni sarebbero vincolate al linguaggio di programmazione utilizzato.
•
L'introduzione di un Broker riduce la complessità dello sviluppo di applicazioni
distribuite poiché rende la distribuzione trasparente al programmatore.
Vantaggio derivante dall’uso del broker
• L'utilizzo dell'architettura Broker permette di
bilanciare le seguenti forze in gioco:
1. Ogni componente ha accesso ai servizi degli altri
componenti attraverso un'invocazione remota e
location-transparent, ovvero indipendente dalla
posizione del componente.
2. I componenti possono essere scambiati, aggiunti o
rimossi a run-time.
3. L'architettura nasconde i dettagli implementativi
delle singole componenti e del sistema su cui i servizi
si trovano ad operare.
Schema funzionale
• I fornitori di servizio si registrano presso il
broker, rendendo così disponibili i loro servizi
ai consumatori tramite delle interfacce.
• Chi necessita di quel determinato servizio:
1. invia una richiesta attraverso il broker
2. Il broker individua il fornitore, inoltra la richiesta e
ritrasmette il risultato al richiedente o,
eventualmente, l'eccezione generata.
Broker
Architettura del broker
•
Il pattern Broker prevede la partecipazione di sei diverse componenti:
1.
2.
3.
4.
5.
6.
•
•
Client
Server
Broker
Bridge
Client-side proxy
Server -side proxy.
Un server implementa dei servizi che espongono le loro funzionalità attraverso delle
interfacce che sono costituite da operazioni e attributi. Tali interfacce sono rese disponibili
attraverso un IDL (Interface Definition Language). Ci sono server che offrono servizi comuni a
molti domini di applicazione mentre altri che forniscono funzionalità specifiche per un
determinato contesto o task.
Un client è un'applicazione che accede ai servizi di almeno un server. Per richiamare un
servizio remoto, i client si avvalgono del broker.
–
–
Dopo che un'operazione è stata eseguita, ricevono il responso o l'eccezione dal broker. L'interazione tra client e server
è basata su un modello dinamico, ovvero un modello in cui il server può anche comportarsi da client.
Il client, quindi, non ha necessitò di conoscere la posizione del server, poiché è il Broker a preoccuparsi di questo
aspetto e ad aggiungere eventualmente nuovi servizi mentre il sistema è in esecuzione.
Architettura del broker
• Il broker è un il messaggero responsabile della trasmissione delle
richieste dai client ai server e dell'invio delle risposte o delle
eccezioni al client:
– deve individuare il ricevente di una determinata richiesta attraverso un
identificatore univoco all'interno del sistema.
– offre delle API (Application Programming Interfaces) ai client e server
che includono operazioni di registrazione ed invocazione dei servizi.
1.
Quando una richiesta arriva al broker locale, esso la passa
direttamente al server interessato.
a.
2.
3.
Se il server risulta inattivo, il broker lo attiva.
Tutte le eccezioni relative all'esecuzione di un servizio sono
inoltrate dal broker al client che ha inviato la richiesta.
Se il server specificato è registrato presso un broker remoto, il
broker locale cerca una strada per raggiungere broker remoto ed
inoltra la richiesta a quest'ultimo.
Architettura del broker
• Il client-proxy rappresenta un layer tra client e broker
• il server-proxy rappresenta un layer tra server e broker.
– Questo layer aggiuntivo fornisce trasparenza e permette
ad un oggetto remoto di essere visualizzato come
componente locale.
• Il bridge è un componente opzionale usato per
nascondere i dettagli di implementazione quando due
broker diversi devono interoperare. Ad esempio:
– se due broker sono localizzati su due sistemi di rete
eterogenei o su due sistemi operativi diversi, il bridge
permette di garantire ugualmente la comunicazione tra
loro
Publish/subscribe
Publish/subscribe
•
Il pattern Publisher/Subscriber definisce una infrastruttura per la propagazione del
cambiamento in un'applicazione distribuita che permette ai componenti
identificati come "publisher" di diffondere degli eventi che trasmettono
informazioni che potrebbero interessare ad altri componenti.
– L'infrastruttura notifica a queste entità interessate, chiamate "subscriber", i cambiamenti che
si verificano.
•
I componenti nelle applicazioni distribuite sono solitamente debolmente
accoppiati ed operano indipendentemente.
– Alcune applicazioni hanno, però, necessità di propagare talune informazioni ad alcuni o a tutti
i componenti che la compongono. A tal fine, è necessario utilizzare un meccanismo che
permetta di informare questi componenti che le informazioni di cui hanno bisogno sono a
disposizione.
•
•
Il pattern Publisher/Subscriber assolve proprio a tale compito, evitando allo stesso
tempo che venga meno il basso accoppiamento e l'indipendenza tra i componenti.
Gestisce anche la modalità in cui far giungere a destinazione i vari messaggi
tenendo traccia della posizione nel sistema di tutte le componenti.
Uso del Publish/subscribe
– Ogni publisher si registra all'infrastruttura per la propagazione del
cambiamento per informarla sul tipo di eventi che vuole pubblicare.
– Similmente, ogni subscriber si registra presso l'infrastruttura per informarla
degli eventi a cui è interessato.
• L'infrastruttura utilizza queste informazioni di registrazione per instradare
gli eventi dal publisher al subscriber.
• I subscriber che ricevono determinati eventi dall'infrastruttura, possono
utilizzare le informazioni in essi contenute per coordinare il proprio lavoro.
• L'infrastruttura è la sola a conoscere i componenti collegati, dove solo
localizzati e come gli eventi sono trasmessi attraverso il sistema.
Svantaggio:
• Un inconveniente di questa "comunicazione anonima" è l'eccessivo
overhead che viene a crearsi in quelle situazioni in cui i subscriber
ricevono eventi di un certo publisher il cui contenuto non soddisfa
determinati criteri, con conseguente eliminazione delle informazioni
inviate.
Proxy
Container
Container
• Il pattern Container definisce un contenitore che fornisce
l'ambiente di esecuzione per un componente che supporta
la necessaria infrastruttura tecnica per integrare i
componenti nei possibili scenari di utilizzo
dell'applicazione, mantenendo accoppiamento lasco tra
loro.
• I componenti implementano una propria logica di business
o infrastrutturale che è utile ai fini della composizione di
un'applicazione.
• Poiché tali componenti possono essere rilasciati su diversi
applicativi o piattaforme, essi non possono implementare
scenari di esecuzione o caratteristiche tecniche specifiche
di un certo ambiente.
Container diagramma delle classi
Applicabilità del container
• Il pattern Container permette di integrare i vari
componenti in diversi scenari di deployment e di
eseguirli su diverse piattaforme senza l'esplicito
intervento del programmatore.
• Il contenitore:
– permette di inizializzare e fornire il contesto a run-time per
ogni componente che integra al suo interno
– definisce le operazioni che consentono ai componenti di
accedere ad altri componenti o a servizi esterni forniti da
un middleware.
• Il programmatore, quindi, può focalizzarsi sulla logica di
base dei propri componenti piuttosto che gestire
manualmente gli aspetti ambientali.
Observer
Struttura dell’Observer
• Pattern Observer: definisce una dipendenza uno a molti tra oggetti
diversi, in modo tale che quando uno di questo cambia il suo stato
tutti gli oggetti ad esso dipendenti ricevono una notifica di tale
cambiamento.
• Il pattern Observer descrive in che modo è possibile stabilire le
relazioni tra i vari componenti. I componenti chiave sono subject e
observer. Il subject può avere un qualsiasi numero di dipendenze di
observer. Tutti questi observer vengono interpellati nel momento in
cui il subject subisce un cambiamento di stato.
• Un effetto indesiderato comune dovuto al partizionamento del
sistema in diversi oggetti cooperanti è la necessità di mantenere la
loro consistenza nonostante la loro natura di componenti
debolmente legati.
Observer
Partecipanti dell’observer
• Nel dettaglio, i componenti totali coinvolti sono subject,
observer, concretesubject e concreteobserver.
• Il subject conosce i proprio observer e fornisce una
interfaccia per agganciare e sganciare un observer.
• L'observer definisce una interfaccia di aggiornamento per la
notifica agli oggetti collegati del cambio di stato del subject.
• Il concretesubject memorizza informazioni di stato utili al
concreteobserver e contatta l'observer quando cambia il
suo stato.
• Il concreteobserver mantiene il riferimento ad un
concretesubject ed implementa l'observer aggiornando le
proprie interfacce per essere consistente con il subject.
Model view control
Model View Control
• Il pattern Model-View-Controller (MVC) divide
un'applicazione in tre componenti:
• La componente model contiene le funzionalità di base e i dati,
• la componente view mostra le informazioni all'utente
• la componente controller gestisce l'input dell'utilizzatore.
– View e controller rappresentano l'interfaccia utente.
– Un meccanismo di propagazione dei cambiamenti garantisce la
consistenza tra la user interface e il model.
• Il pattern MVC suddivide l'applicazione interattiva in tre
aree: processing, input e output.
• Nell'ambito di applicazioni interattive, costruire un sistema
flessibile è molto costoso e può portare ad errori se
l'interfaccia utente è strettamente legata alle funzionalità di
base.
Struttura del MVC
Uso del pattern MVC
•
•
La separazione del model dalla view a dal controller permette di associare più view allo stesso
model. Se l'utente modifica i dati contenuti nel model attraverso il controller di una determinata
view, tutte le altre view ricollegate a quel model riflettono la variazione.
Oltre ai componenti model, view e controller il pattern prevede un componente che si occupa del
meccanismo di propagazione dei cambiamenti. Tale componente è solitamente rappresentato dal
pattern Observer. Questo mantiene un registro con tutti i componenti collegati ad un determinato
model. Tutte le viste e i controller si registrano presso l'Observer per restare informati su eventuali
cambiamenti. Il meccanismo di propagazione dei cambiamenti è l'unico collegamento tra il model
ed le altre componenti.
Vantaggi derivanti dall'applicazione del pattern Model-View-Controller:
1.
Più viste possono essere ricollegare allo stesso model.
2.
Le viste sono sempre aggiornate.
3.
Le viste e i controller si possono facilmente sostituire con altri anche a run-time.
4.
Essendo i tre componenti indipendenti, possono essere riutilizzati in altre applicazioni.
Svantaggi:
• incremento della complessità generale dell'applicazione
• necessità di buona potenza di calcolo quando si verificano molti aggiornamenti di stato
Database Access Layer
DAL
•
•
•
Il pattern Database Access Layer introduce un strato tra l'applicazione e i database relazionali che
fornisce una interfaccia orientata agli oggetti stabile per l'applicazione, basata su
un'implementazione vicina al modello relazionale.
I sistemi object-oriented spesso utilizzano i database relazionali per garantire la persistenza dei
propri dati. C'è, però, una debole interconnessione tra i due tipi di approcci che rende difficoltoso
implementare le relazioni tra gli oggetti e le tabelle appartenenti ai database.
Le applicazioni possono memorizzare e recuperare i loro dati chiamando un metodo dedicato
messo a disposizione dal pattern. Tale stato ha, quindi, il compito di provvedere alla mappatura tra
le strutture dati dell'applicazione e il formato dati richiesto dal modello logico del database.
Vantaggi dal punti di vista dei requisiti:
Il pattern Database Access Layer:
1.
riduce l'accoppiamento delle applicazioni object-oriented dai dettagli interni del database. Tutte
le mappature concrete sono incapsulate nello strato, pertanto l'applicazione avrà l'impressione di
memorizzare e recuperare un oggetto piuttosto che una tabella di un database.
2.
eventuali modifiche allo strato messo a disposizione dal Database Access Layer non influiscono
sugli altri componenti dell'applicazione.
3.
ha il compito di notificare all'applicazione eventuali modifiche effettuate al database da parte di
altre applicazioni. Senza questo tipo di meccanismo, i dati recuperati dall'applicazione
risulterebbero obsoleti e potrebbero portare a comportamenti imprevisti.
Pattern per cloud
Hypervisor
Watchdog
Strict consistency
Strict Consistency
•
•
•
•
•
•
•
•
Il pattern Strict Consistency permette di replicare i dati in diverse località al fine di aumentare la
disponibilità del sistema, migliorare i tempi di risposta ed evitare la perdita dei dati dovuta a
malfunzionamenti, il tutto mantenendo i dati consistenti.
Per garantire una buona tolleranza agli errori (fault tolerance), una unità di storage deve replicare i propri
dati su diversi supporti. Queste repliche memorizzano gli stessi dati, perciò nel caso in cui una di queste
repliche vada perduta è sempre possibile eseguire il ripristino delle informazioni da altri supporti.
Affinché tale processo sia praticabile, è necessario garantire la consistenza dei dati replicati in ogni istante.
Ciò può essere garantito se ogni replica viene aggiornata ogni qualvolta i dati vengono modificati.
Questo, però, può portare al decadimento delle prestazioni complessive del sistema poiché, vista la
necessità di eseguire scritture su tutti i dati replicati, se una delle repliche diventa non disponibile o se la
rete in cui risiede presenta problemi, l'intero sistema ne viene influenzato.
Il pattern Strict Consistency permette di ottenere la consistenza sui dati senza sacrificare in modo
eccessivo le prestazioni complessive del sistema.
Questo grazie alla suddivisione dei dati in sottoinsiemi, i quali permettono di accedere solo a determinate
repliche che contengono i dati interessati invece che a tutte le repliche. In questo modo, non è necessario
che siano disponibili tutte le repliche, ma solo quelle contenenti i dati di nostro interesse.
Con questo meccanismo ci si assicura che almeno una replica tra quelle create conterrà il dato più
aggiornato.
Tutte le operazioni di scrittura e lettura sulle repliche vengono eseguite come un'unica transazione, al fine
di garantire le proprietà ACID.
Stateless component
Stateless component
•
•
•
•
•
•
Il pattern Stateless Component permette di incrementare l'elasticità e la robustezza di
un'applicazione fornendo un componente esterno all'applicazione che si occupadi gestire lo stato
dei servizi utilizzati in essa ed in particolare dello scaling-out. Inoltre viene migliorata la faulttolerance complessiva.
I componenti di un'applicazione distribuita vengono rilasciati su diverse risorse dell'ambiente Cloud
per eneficiare delle sue proprietà intrinseche.
Tale struttura implica che se si verifica un guasto di uno dei componenti, la disponibilità
complessiva dell'applicazione dipende da quella delle altre risorse disponibili.
In queste situazioni, il fattore che complica maggiormente l'aggiunta o la rimozione di un
componente è il suo stato, il quale è mantenuto all'interno dell'applicazione. In caso di guasto, le
informazioni di stato vanno perse e l'istanza di un servizio deve necessariamente essere avviata con
le informazioni iniziali.
Con il pattern Stateless Component, le informazioni di stato non sono salvate internamente
all'applicazione ma sono memorizzate in uno storage esterno gestito da un componente esterno
all'applicazione, il quale riconosce ogni componente attraverso un identificativo (ID).
Si creano, quindi, diverse sessioni di stato, una per ogni istanza di un certo servizio. Quando si
verifica un guasto, il componente esterno può recuperare le informazioni di tale sessione e
ripristinare il servizio senza problemi.
Private cloud
Pattern per big data
Esempio n.1
Si vuole progettare un sistema per gestione dei punti vendita
di una catena di negozi di libri. Il cliente ha necessità di gestire
tutti i suoi punti vendita dislocati in locazioni geograficamente
diverse. Ogni punto vendita deve poter interagire con gli altri.
E' necessario che il sistema software risulti manutenibile e
flessibile al fine di garantire in futuro la possibilità di
modifiche dovuto ad un cambio di infrastruttura della catena
di negozi. E', inoltre, indispensabile garantire la sicurezza dei
dati interscambiati tra i vari punti vendita nonché la loro
consistenza e portabilità. Infine, tutte le funzionalità devono
essere fornite tramite un software usabile che garantisca un
accoppiamento basso tra le varie componenti.
Progettazione sistema per gestione punti vendita di una
catena di libri.
Requisiti non funzionali richiesti:
Manutenibilità, Flessibilità, Sicurezza, Portabilità, Low
coupling, Usabilità
Soluzione
Utilizzo modello ad oggetti distribuiti con implementazione
di meccanismo client-server.
Modello three-tier: presentazione, business logic, dati.
Interfaccia di login, ricerca libri, vendita libri, report clienti
e fornitori.
Gli aspetti non funzionali sono soddisfatti tramite l'utilizzo
dei pattern seguenti:
Pattern adottati:
Broker per Menutenibilità, Flessibilità
Proxy per Sicurezza
Database access layer per Portabilità
Model-view-controller per Low coupling, Usabilità
Soluzione proposta
• L'architettura immaginata si basa sul modello ad
oggetti distribuiti in cui viene implementato per
ogni punto vendita un sistema di tipo clientserver.
• Il client è di tipo “thin”, ovvero che presenta solo
funzionalità legate all'interfaccia per l'accesso alle
informazioni.
• Il modello client-server di ogni punto vendita è a
tre livelli (Three-tier ): presentazione (client),
business logic (application server), dati (server
dati).
Model view control
• Usabilità, Low coupling – Ogni client installa
un SW che permette di accedere al sistema
attraverso una interfaccia user-friendly.
• L'utilizzo di una visione modulare del sistema
permette di avere un basso livello di
accoppiamento tra le varie componenti.
• Questo consente modifiche sostanziali senza
influenzare le altre componenti.
Dettaglio oggetti distribuiti
Dettaglio livello di presentazione
Application server
DAL
• I dati recuperati da i DB sono rielaborati
attraverso un layer che struttura i dati in modo
tale che possano essere trasferiti nel sistema
senza problemi.
• Tale layer, inoltre, rende trasparente il sistema
alla tecnologia del RDMBS.
Dettaglio
Livello dati:
Server dati
Broker
• Broker per Manutenibilità, Flessibilità– E'
presente un Broker per la comunicazione tra i
vari sistemi remoti.
• Questo garantisce una possibile variazione del
sistema con l'aggiunta di nuovi punti vendita
(flessibilità) e la funzionalità degli altri punti
vendita quando uno è in manutenzione
(manutenibilità)
Diagramma delle classi:
pattern broker
Proxy
Sicurezza:
• L'accesso al sistema è possibile solo tramite riconoscimento dell'utente. La
comunicazione attraverso gli altri sistemi avviene con un Proxy che
comunica con il Broker utilizzando un algoritmo crittografico.
• Il Proxy si occupa di crittografare e decodificare i dati inviati ed è l'unico in
grado di contattare il Broker.
Consistenza, Persistenza dati:
• Sono presenti due server di backup: uno locale ed uno remoto condiviso
da tutti i punti vendita. Questi garantiscono persistenza e consistenza. Lo
scheduler è sempre locale e si occupa di contattare il server remoto per il
retrieval dei dati.
• Il server dati remoto deve prevedere un DB per ogni sistema. Quando
viene aggiunto un nuovo punto vendita viene creato anche un nuovo DB
remoto.
• Il DB dei fornitori è mantenuto integro e consistente con un sistema di
Backup manuale (un addetto effettua una copia manualmente).
Diagramma delle classi:
pattern proxy
Esempio n.2
Si consideri un dominio context aware nell'ambito di sistemi di
gestione di eventi.
Nello specifico, si vuole progettare un sistema/sottosistema
per adaptive authentication che, nel momento in cui un
generico l'utente ha intenzione di autenticarsi, prenda in
considerazione alcuni parametri di contesto (IP, luogo, data
ora, ecc.) e decida se consentire all'utente di autenticarsi e
con quale meccanismo farlo in base al livello di sicurezza
necessario.
Come requisito non funzionale è richiesta l'adattabilità ma allo
stesso tempo è necessario garantire un'accettabile
percentuale di falsi positivi/negativi (reliability), e la
availability.
Discussione
• Problema: progetto di un sistema context-aware:
• Sistema adattativo: SIEM (Security Information and Event Monitoring).
– Topic: 'context-aware' security: il sistema valuta eventi e policy di sicurezza in
base al contesto - quindi si adatta al contesto.
– Sistema di 'adaptive authentication', quando l'utente si autentica, il sistema
prende in considerazione una serie di parametri di contesto (IP e luogo, ora e
giorno, etc.) e decide se autenticare o meno l'utente e con quale meccanismo
(piu o meno sicuro).
• Requisiti: qui dovrebbero essere chiaramente l'adattabilità, attendibilità e
la stabilità o disponibilità: visto che se il sistema e' giù nessuno entra o
magari entrano tutti...
Applicabile anche al cloud: se una azienda sposta una applicazione nel
cloud probabilmente vuole proteggerla meglio visto che e' accessibile da
tutti via internet.
Soluzione
1. L'architettura-soluzione è immaginata come un sotto-componente di un sistema
più grande, che utilizza le funzionalità messe a disposizione da tale architettura.
Ogni utente interagisce con il sistema con delle proprietà che variano di volta in volta. A seconda del tipo
di status, l'utilizzatore è indirizzato su uno dei sistemi di sicurezza disponibili.
2. L'architettura complessiva, quindi, prevede i pattern Container, Adapter,
Publisher/Subscriber, Observer che contribuiscono tutti al miglioramento di
adattabilità, disponibilità e reliability.
I sistemi di sicurezza sono gestiti all'interno di un contenitore allo scopo di renderli
trasparenti al sistema sottostante ed al middleware.
Il contenitore ha la capacità di riconoscere un nuovo contesto e di registrarlo presso il
contenitore.
Per realizzare l'adattabilità, gli stili da utilizzare sono in genere quelli che supportano
l'interazione event-based come publish-subscribe, mentre devono essere evitati stili
che richiedono dipendenze dirette tra le componenti come le macchine virtuali o gli
oggetti distribuiti perché possono ostacolare l'adattabilità.
Bilanciamento tra parametri
L'adattamento dinamico che caratterizza la problematica può compromettere
sia l'affidabilità che la stabilità e, quindi, il modello architetturale risolutivo
deve essere il risultato del migliore bilanciamento tra tali parametri.
Nello scenario descritto è necessario integrare i componenti in diversi scenari
di deployment di applicazioni ed eseguirle su varie piattaforme di sistema
senza l'intervento esplicito del programmatore.
Inoltre vi è anche l'esigenza di avere diverse modalità di accesso alle risorse di
sistema e diverse politiche di sicurezza. Quindi è necessario inizializzare e
fornire un contesto a run-time per il componente. Questo è uno scenario
tipico per l'applicazione del Container.
Ad ulteriore garanzia di adattabilità, si utilizza il pattern Adapter il quale
permette ad ogni componente registrato a run-time di fornire al container
un'interfaccia che si adatta al contesto.
Spostamento nel cloud
•
•
•
L 'utilizzo di un Observer ha la funzione di individuare un nuovo contesto e
registrarlo presso il Container, nonché pubblicare presso il Publish/subscribe il
nuovo meccanismo di sicurezza registrato.
Vista la sua natura di sotto-componente, l'architettura progettata può essere
spostata in un contesto Cloud in cui essa diviene un singolo nodo di cui possono
usufruire più applicazioni o sistemi che desiderano integrare quella particolare
funzionalità al loro interno.
Lo spostamento permette di sfruttare le caratteristiche del modello Cloud al fine di
soddisfare alcuni requisiti non funzionali che talvolta è difficile esplicitare
all'interno della singola architettura.
– Ad esempio, si può pensare di garantire la scalabilità del sistema complessivo. Per far ciò si
può pensare di progettare un'architettura multicloud i cui servizi sono duplicati sulle varie
Cloud. In questa situazione, quando il carico su una singola cloud diviene insostenibile, questo
ha la possibilità di migrare verso una cloud vicina.
– La gestione del carico, delle istanze dei singoli servizi e delle varie Cloud avviene attraverso lo
Scalability Manager che include al suo interno diversi moduli, ognuno dei quali svolge uno
specifico compito.
– Le varie componenti dell'architettura si interfacciano attraverso un middleware. La struttura
appena descritta coincide con il pattern per il Cloud Stateless Component.
Architettura generale
Proposed solution
•
•
•
•
Publish/subscribe
Container
Observer
Adapter
Publish/subscribe
1. La classe “ConcreteContext” rappresenta il publisher.
2. Tramite il metodo “publish” contatta il P/S il quale a
seconda del tipo di contesto richiama tramite il metodo
“Callback” l'interfaccia messa a disposizione dal container,
passando contestualmente l'ID del componente da
richiamare.
3. E' il container, quindi, che si occupa di avviare il
componente corrispondete all'ID passato dal P/S.
4. Nel caso specifico, il componente è il metodo di sicurezza
da applicare al contesto.
5. L'observer, invece, interagisce con il P/S che si preoccupa
si sottoscrivere presso il P/S un nuovo subscriber
(rappresentato dal singolo metodo di sicurezza).
Container ed observer
1.
2.
3.
Il container si preoccupa di fornire l'interfaccia per gestire
dinamicamente i vari componenti al suo interno.
Il P/S richiama il container per utilizzare un componente (il
metodo di sicurezza rappresentato dal subscriber) passando come
parametro l'ID del subscriber.
L'observer si occupa di registrare presso il container un nuovo
metodo di sicurezza tramite il metodo “registernewsecurity”.
–
4.
In entrambi i casi, il container utilizza una classe “SecurityMethod”
che rappresenta il metodo di sicurezza vero e proprio.
Ogni singolo metodo di sicurezza può interagire anch'esso con il
container per accedere alle funzionalità del middleware.
Container Class diagram
Publish/subscribe class diagram
Observer class diagram
Adapter class diagram
Architettura in contesto cloud
Dettaglio architettura in contesto cloud
Esempio n.3
•
•
•
•
•
•
•
Si ha necessità di un sistema in ambiente Cloud che deve garantire dependability
(availability, fault tolerance, reliability) per la gestione Big Data prelevando le
informazioni utili da OpenStreetMap.
La piattaforma Big Data, utilizzata per gestire grandi quantità di dati dislocati in
diversi server, deve fornire un servizio orientato alla disponibilità, senza alcun
point of failure.
I requisiti sono quindi essenzialmente di dependability.
I dati devono essere replicati automaticamente su più nodi.
La replica deve avvenire mediante diversi datacenter e la sostituzione dei nodi
deve essere effettuata senza alcun downtime, in modo da garantire la continuità
del servizio.
Sono richieste, inoltre, consistenza dei dati ed elasticità, ovvero il throughput di
lettura o scrittura deve scalare linearmente con l'aggiunta di nuove macchine
(nodi), senza downtime e senza interruzione di alcun applicativo.
E' necessario, pertanto, un certo grado di ridondanza, in modo da assicurare
l'eliminazione di point of failure, che in caso di anomalia causi disfunzione
all’intero sistema.
Soluzione
• L'applicazione permette di estrapolare generiche informazioni da
Openstreetmap in previsione di successive elaborazioni ed analisi su
questi dati. L'architettura prevede quattro nodi principali:
• 1. Openstreetmap: E' il nodo rappresentante le API messe a disposizione
da OpenStreetMap con cui gli altri nodi dell'architettura Cloud devono
interfacciarsi per reperire dati.
• 2. Data Access: E' un nodo che permette a tutti gli altri nodi di accedere ai
dati presenti nei vari datacenter
• 3. Big Data Analysis: Offre servizi relativi al processing dei dati presenti
nella infrastruttura di storage dell'applicazione. Il nodo comunica con il
Data Access per reperire le informazioni dai vari datacenter e provvede poi
ad analizzare i dati.
• 4. Data Retrieval: Offre servizi con i quali il consumer può effettuare delle
query atte a reperire dei dati da OpenStreetMap. Sfrutta i servizi offerti
dal Data Access per immagazzinare i dati ottenuti da OSM nello storage
dell'applicazione.
Pattern utilizzati
• STRICT CONSISTENCY
• STATELESS COMPONENT
STRICT CONSISTENCY
• I dati sono replicati su diversi nodi per migliorare i tempi di risposta
(performance) e per evitare perdite di dati in caso di fault (faulttolerance) il tutto mentre i dati sui nodi replicati vengono
mantenuti consistenti (consistency). Si ottiene, quindi, buona
dependability.
• La consistenza è garantita perché ogni operazione di scrittura viene
effettuata in un unica transazione la quale, una volta terminata,
garantisce che tutti i nodi replicati siano allineati. In fase di lettura,
invece, è sufficiente leggere da uno solo dei nodi replicati.
• Sono previsti più datacenter, ognuno dei quali è identico agli altri
ma è collocato su una rete separata ed indipendente dalle altre. Al
suo interno, ogni datacenter dispone di più cluster, tutti con dati
diversi tra loro. Ogni cluster, invece, prevede la duplicazione di ogni
singolo database contenente una parte delle informazioni
complessive.
Diagramma generale Cloud
STATELESS COMPONENT
• Lo stato dei vari nodi è gestito da componenti esterne che
gestiscono lo scaling-out dei singoli nodi e rendere così il
sistema adattabile alle varie condizioni di lavoro (elasticità).
• L'applicazione complessiva soffre di meno dei failure dei
componenti (point of failure, fault-tolerance, Availability).
• Lo scaling-out è gestibile grazie alla presenza di più nodi
identici, i quali vengono chiamati in causa al momento
opportuno dal componente esterno (Elasticity Controller),
ovvero quando quel singolo nodo non è più in grado di
soddisfare il carico attuale o quando non è disponibile a
causa di un failure.
Dettaglio Stateless
Component
Dettaglio Strict
Consistency
Esempio n.4
• Si vuole progettare un'applicazione Cloud che
integri al suo interno i servizi offerti da
Dropbox. Si deve garantire dependability
(availability, reliability, fault tolerance) per
consentire a più utenti di utilizzare il servizio
anche in caso di fault. A livello di architettura
di servizio, il modello deve essere basato su
macchina virtuale.
Esempio n. 5
• Si vuole sviluppare un’applicazione Cloud che
permetta di effettuare acquisti utilizzando la
moneta virtuale Bitcoin. Il consumer deve
avere la possibilità di visualizzare i negozi che
accettano questo metodo di pagamento ed
accedere al proprio account Bitcoin per
confermare i pagamenti che si vogliono
effettuare. I requisiti non funzionali da
soddisfare riguardano principalmente security
e availability.
Esempio n. 6
• Si vuole progettare un'applicazione di sentiment
analysis che, attingendo alle informazioni degli
utenti disponibili su Facebook che permetta di
individuare qual è il più gradito tra due generi
musicali. Utilizzando i servizi offerti da Facebook,
l'applicazione permette di verificare se un certo
genere musicale è gradito più di un altro tra un
numero limitato di utenti. In questo scenario, si
vuole utilizzare un pattern per Big Data per
l'analisi dei dati recuperati. I requisiti non
funzionali da soddisfare risultano performance,
elasticità e consistenza dei dati.
