Che materia stai cercando?

Anteprima

ESTRATTO DOCUMENTO

È necessario che interfaccia utente si abboni.

Un tipo di evento è inizio nuova vendita- allora saleframe si registra presso il controller per

eventi proprietà. Il register notifica eventi proprietà come nuova vendita e quando saleframe

viene notificata alcuni eventi cambiano registrazioni abbonamenti provocando

comportamento utile a fini implementazione sistema..

elemtni principali di publish subscriber e observer:

oggetti che generano eventi e interfaccia (superclasse) che definisce operaizoni comuni ad

abbonati. Come registrare nuovo abbonato

COLLEGAMENTO TRA STRATI

Progettazione del collegamento tra strati.

I design pattern sono utili per descrivere collegamento da dominio vs servizi tecnici e da

dominio vs strato di presentazione.

Figura con struttura a strati. Come collegare questi strati? 115

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

Collegamenti verso il basso

di solito basati su Facade (presentazione parla con strato dominio tramite controller e

• nello strato dominio può parlare con servizi tecnici come facade per la persistenza.

Facade è buona soluzione per collegamenti vs basso in architettura a strati)

Collegamenti verso l’alto

pull o polling verso una Facade (ma talvolta non è adeguato) – presentazione chiama

• periodicamente facade strato dominio ma questa soluzione a volte non è adeguata.

push, tramite Observer oppure una Facade ( da basso vs alto in cui risalgono notifiche

• mediante observer o mediante facade. Introdurre in strato piu alto facade da basso vs

alto cosi che strato basso notifica strato alto con facade.)

Collegamenti verso sistemi o servizi esterni

di solito tramite Adapter

Lez.14 - Introduzione alle architetture software

DALLA PROGETTAZIONE OO (orientata agli oggetti) ALLE ARCHITETTURE SOFTWARE

Definizione precedente di Progettazione del software:

È un’attività di decomposizione del sistema software da realizzare in un insieme di elementi

software a cui sono assegnate delle responsabilità e di specifica delle relazioni tra questi

elementi

Finora abbiamo affronta la tematica della progettazione oo in cui abbiamo oggetti e classi. Ma

dobbiamo studiare ulteriori argomenti…

Progettazione OO

gli elementi software utilizzati finora sono sono oggetti e classi (grana piccola) e le loro

• interaioni sono interazioni tra oggetti (scambio messaggi per richiedere esecuzione

metodo)

(in questo corso) enfasi sulla progettazione per i requisiti funzionali.

Non è sufficiente ragionare in termini di oggetti e classi… 116

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

I grandi sistemi software oggi

sono caratterizzati da una grande complessità (grande sistema sw può richiedere

• moltissime linee di codice e usando tecnologie ad oggetti ci servono moltissime classi

sw (oggetti sw a grana piccola) ma è utile aggregare oggetti con elementi a grana

grande. Inoltre occorre gestire dati e interagire in modi complessi non catturati dai

meccanismi di base della programmazione oo.

i requisiti di qualità (che derivano da molte parti interessate) rivestono un ruolo

• sempre più significativo per il successo di questi sistemi. Non è sufficiente progettare e

implementare funzionalità richieste da utenti ma occorre che queste vengano fornite

con elevata qualità (usabilità, disponibilità, sicurezza ecc..)

quindi requisititi funzionali e di qualità sono importanti..

quindi occorre ragionare in termini di elementi sw a grana grossa considerando anche

requisiti di qualità.

Per la qualità è necessario seguire approccio basato su architetutra sw.

L’architettura software è il vettore principale delle qualità di un sistema software

(come prestazioni, sicurezza e modificabilità), nessuna delle quali può essere ottenuta senza

una visione architetturale unificante.

Non è una definizione di cosa si intende per architettura sw ma è caratterizzaizne obbiettivi

della architettura sw. È necessaria per progettare per le qualità e questa affermazione dice

che non è possibile ragionare separatamente sulle qualità, ma occorre avere approccio globale

su tute le qualità e questa disciplina promette di essere in grado di progettare per tutte le

qualità di un sistema sw.

Disciplina di Architetture software

progettazione di sistemi complessi – in cui sono rilevanti le parti e le loro relazioni. la

• progettazione per relazioni tra elementi ha valore fondamentale. Qualità sw garantite

da approcci per progettare le relazioni tra elemnti.

Ha a che fare con progettazione elementi software a grana grossa – come architettura a

• astrati o elementi del sistema sono in numero limitato per comprenderli tutti

Orienta a progettazione per i requisiti di qualità

ARCHITETTURA SOFTWARE: DEFINIZIONE

Esistono numerose definizioni. Noi ci riferiamo alla seguente:

L’architettura software di un sistema software è l’insieme delle strutture del sistema, necessarie

per ragionare su di esso, che comprendono elementi software, le relazioni tra di essi, e le loro

proprietà

Definizione complessa con diversi termini da discutere…

Osserviamo che definizione parla di architettura di sitema sw. Non esistono sistemi composti

solo da sw perché si richiede anche hw. I sistemi informatici comprenono sw, hw e processi

che guidano esecuzine applicazioni sw con definizione ruoli per gestire applicazioni. 117

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

Parliamo sistema sw intensive dove parte sw svolge ruolo importante nel raggiungimento

obbiettivi del sistema (che può essere organizzazione). Si parla di sistema sw intensive se la

parte sw è fondamentale per raggiungere obbiettivi del sistema.

Elementi

un’architettura comprende/definisce un insieme di elementi. Sistema è composto da

• elementi a gran piccola. Qui ragioniamo invece a grana grande e quindi parliamo degli

elementi fondamentali che sono pochi. Fondamentali rispetto alla possibilità del

sistema di soddisfare obbiettivi di qualità.

elementi software e elementi non software. Elementi sw sono di diversa natura.

• Possono essere moduli del codice (statici) o elementi runtime come processi,

componenti runtime di tecnologie specifiche come servizi… si può ragionare anche su

elementi non sw come hw su cui si esegue il sw e anche team di sviluppo del sw. Anche

il modo in cui elementi sw sono posti in relazione con elementi non sw può essere

importante per raggiungere obiettivi di qualità.

Ogni elemento software è caratterizzato da

un insieme di responsabilità (attribuiremo responsabilità funzionali a ogni elementi sw

• per gestire operazioni e gestire info)

un confine (se responsabilità dice cosa fa il componente e il confine dice consa

• elementi sw non deve fare. Ese: ricevere ordini clienti ma non memorizzare gli ordini.)

un insieme di interfacce (normalmente elementi in architettura sono a scatola nera

Tipi di elementi software

necessario scrivere codice istruzioni metodi e classi per implementare questi elementi. Questi

moduli sono di due tipologie:

componenti, responsabili di funzionalità e dati

• connettori, responsabili delle interazioni tra componenti

se si dice che responsabilità funzionali sono componenti ma non si dice di chi sono

responsabilità per requisiti di qualità. Ma sono i connettori a essere responsabili del sistema

sw – ovvero il modo in cui elementi sono collegati (relazioni tra elementi). Elementi che

mediano comunicazione sono connettori…

Strutture

una struttura comprende un insieme di elementi e di relazioni tra questi elementi:

• struttura comprende insieme elementi e relazioni tra elementi. Elementi sono

omogenei coesi. Ese: codice organizzato in moduli e struttura comprende moduli e loro

relazioni (dipendenze di compilazione o altre dipendenze di uso tra moduli. Struttura

statica). Processi o thread necessari in esecuzione sw e questa è dinamica.

(comunicazione sincrona o asincrona) altra struttura è rilascio che riguarda

piattaforme hw e sw in cui si esegue il sistema…

un’architettura comprende di solito più strutture (ese: struttura statica, dinamica e

• rilascio e di allocazione del lavoro. Ogni struttura non è sufficiente da sola ma

architettura è composta da più strutture.)

strutture e viste (in generale strutture comprendono elemnti mentre vista è

• descrizione di struttura. Modello odiagramma per comprendere struttura. Modulo o

processo per struttura. Vista contiene rettangolo che denota modulo o processo.

Strutture composte da elementi e viste sono descrizioni di strutture. Struttura e vista

vengono anche usati come sinonimi ma è sbagliato!) 118

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

Relazioni

relazioni tra gli elementi di una struttura (quale modulo dipende da altro modulo e

• processo che comunica con processo)

relazioni tra gli elementi di strutture diverse (quale team è responsabile di

• implementare modulo. Quale piattaforme deve occuparsi di un certo processo?)

Proprietà degli elementi

le proprietà di un elemento sono le ipotesi (all’interfaccia) che si possono fare

• sull’elemento (all’interno architettura diversi elementi sono tra loro opachi elementi

comunicano solo all’interfaccia e queste proprietà definiscono interfacce di ogni

elemento)

proprietà sono di due tipi:

• comportamento (quali servizi offerti da componente o quali messaggi possono

o essere inviati a un componente)

qualità (livelli di qualità in prestazione servizi – come sicurezza, affidabilità,

o disponibilità per accesso ad operazione)

queste cose servono per Ragionare sul sistema

ci interessano le proprietà complessive dell’intero sistema. Il suo comportamento

complessivo e le sue qualità complessive. In generale ci sono elementi di comportamento e il

comportamento totale del sistema è la somma dei singoli comportamenti. Ma è interessante

ragionare sulle qualità complessive del sistema che sono legate a quelle degli elementi del

sistema e dal modo in cui elementi sono correlati. Architetture sw ragionano tra architettura

interna del sistema e le sue qualità complessive esterne.

ciò che interessa davvero sono le proprietà complessive del sistema (comportamento

• complessivo e qualità complessive)

La disciplina delle architetture software studia le relazioni tra la struttura interna di un

sistema e le sua proprietà complessive.

Solo conoscendo questa relazione si valuta sistema per capire proprietà e qualità di un

sistema e sfruttare questa conoscenza per progettare sistema. Se devo avere qualità x, quali

strutture adottare?

C’è relazione tra struttura interna e proprietà esterna. La vedremo più avanti.

Esempio per avere intuizione: si parla di hw ma è di facile comprensione: pensiamo a due

dischi di 1 tera e tempo medio tra guasti di 10 anni. un controller ride per combinare le unità.

Come combinarle? Quali qualità?

In modalità raidzer (senza ridondanza) così le due unità vengono viste come una singola

unità. In questo caso però il tempo medio fra guasti è pari alla metà del tempo medio fra

guasti di una singola unità (5 anni). Oppure facciamo ridondanza per cui i dati vengono

replicati da un disco ad un altro e quindi la capacità complessità sarà di 1 tera e disponibilità -

il tempo medio tra guasti - passerà a 10 anni.

Sceglieremo una o altra struttura a seconda delle qualità che vogliamo ottenere nel ns

sistema. 119

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

Per riassumere, la ns definizione è:

L’architettura software di un sistema software è l’insieme delle strutture del sistema,

necessarie per ragionare su di esso, che comprendono elementi software, le relazioni tra di

essi, e le loro proprietà

Esempio di architettura sw:

consideriamo Piattaforma Eclipse (ambiente integrato per sviluppo architettura sw.) è uno

degli opensource più diffuso. Esistnon molte diverse versioni per gesitre diverse esigenze di

sviluppo (java, c++ ecc..)

un ambiente integrato per lo sviluppo del software

• obiettivi: sostenere la costruzione di una varietà di strumenti per lo sviluppo del

• software e la loro integrazione

strumenti possono essere sviluppati in eclipse ma anche integrati da 3e parti e poi integrati.

Eclipse sostiene creazione e integrazione di questi strumenti esterni.

Bisogna quindi conoscere architettura per raggiungere obiettivi.

2 tipi di elementi:

platform runtime (funge da nucleo per gestitone altri elementi)

plug-in

all’avvio il platform Runtime vede i plugin installati nel sistema in cui eclipse si esegue. Ogni

plugin viene interrogato per vedere quali operazioni esegue.

Quando utente richiede tramite plugin una funzionalità, questa richiesta è mediata da

platform runtime che vede in un registro dei plugin e poi richiede funzionalità al plugin che

esegue quella operazione.

Questo è vero per plugin realizzati da eclipse e anche per quelli realizzati da 3e parti.

Architettura a plugin sostiene flessibilità della piattaforma eclipse e consente aggiunte

dinamiche di nuovi strumenti che possono anche interagire tra loro. Questa architettura è la

base del successo di questa piattaforma.

Anche il browser web ha architettura a plugin. Visualizza in modo nativo dati multimediali

(html ecc.) ma non nasce come strumento per visualizzare ogni info multimediale (magari non

in grado di visualizzare pdf o animazione di realtà virtuale) ma sicuramente è estensibile con

plugin così da visualizzare elementi di tipologie specifiche. Plug-in favorisce estensibilità del

sistema. 120

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

ALTRI CONCETTI

Parte interessata

è un individuo, un gruppo di persone o un’organizzazione che ha interessi nel sistema

• in discussione (in sviluppo del sistema sw ci sono molte parti interessate. Come utenti

che usano sistema, ma anche acquirente che paga sistema e anche organizzazioni

governative o team di sviluppo e anche architetto che definisce architettura ecc…) in

generale queste parti sono individui o gruppi. Ogni parte può avere degli interessi…

Interesse

è un obiettivo, un requisito, un vincolo, un’intenzione o un’aspirazione che una parte

• interessata ha sull’architettura di un sistema (interessi sono obbiettivi. Obbiettivi di

business che danno luogo a dei requisiti. Termine interesse è più generale di termine

di requisito.) interessi implicano qualità e funzionalità che sistema dee avere.

Trinangolo con 3 qualità:

- alta qualità

- costo basso

- rapido sviluppo 121

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

le parti interessate devono accordarsi per scegliere solo due angoli di queste qualità.

Parti interessate hanno spesso interessi contrastanti. Architetto deve capire i conflitti e

mediare tra questi conflitti.

In generale se parti interessate non hanno conflitti allora architettura affronta con successo

interessi ma se ci sono conflitti, architettura buona è quella che bilancia interessi.

Descrizione architetturale

è un insieme di prodotti che documenta un’architettura, in modo comprensibile alle

• parti interessate, e che dimostra che l’architettura soddisfa i loro interessi (nella

progettazione architettura si documenta una descrizione architetturale che documenta

architettura perché architettura va comunicata e sviluppata ma se il sistema è di

successo questo vivrà a lungo e dovrà evolvere e la sua documentazione è importante

per la successiva evoluzione del sistema) descrizione deve essere comprensibile e

usabile nella comunicazione con le parti interessate. Se non si comunica bene

acquirente potrebbe bocciare proposta del sistema. Se architettura è perfetta ma

scritta male e team di sviluppo la fraintende potrebbe realizzare un sistema poco

buono… giustificazione logica dell’architettura: è importante perché e in che modo le

scelte fatte sodisfano o in modo bilanciato i vari interessi. Un buona documentazione

ha alla base le qualità del sistema.

Definizione dell’architettura

è il processo di definizione (analisi, progettazione e validazione) dell’architettura di un

sistema software.

Questo processo vene chiamato progettazione dell’architettura ma da definizione è più

generale e comprende analisi requisiti e interessi e progettazione delle scelte e scelte

convalidate confrontandole con interessi e obbiettivi proposti. 122

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

spunti:

perché sono importanti le parti interessate nella scrittura della architettura sw?

Lez.15 - Punti di vista e viste

VISTE ARCHITETTURALI

Definzione di Descrizione architetturale (AD – architectural description)

è un insieme di prodotti che documenta un’architettura, in modo comprensibile alle

• parti interessate, e che dimostra che l’architettura soddisfa i loro interessi

architettura sistema complesso è complesso e anche sua descrizione è complessa..

perché fornire buona definizine architetturale?

Una buona AD

base per l’analisi delle decisioni di progetto iniziali (il progettista durante definizione

• architettura prende decisioni di progetto e le riporta nella definizione e poi scelte

vanno valutate per vedere se soddisfa i requisiti richiesti)

sostiene la comunicazione con le parti interessate (in particolare con acquirenti perché

• se questi non sono convinti del modo in cui il sistema sostiene i loro interessi e quindi

se architettura non è venduta bene…)

guida per lo sviluppo e l’evoluzione del sistema (fatta dal team di sviluppo. Se

• architettura non comunicata bene il team la sviluppa male… se il sistema di successo

starà in vita per molto e molte persone se ne occuperanno della sua evoluzione ecc..)

Durante la definizione dell’architettura

vanno prese decisioni architetturali (per capire come organizzare una AD bisogna

• capire portata decisioni architetturali da riportare nella AD. Decisioni sono variegate e

riguardano aspetti e interessi diversi: quali funzionalità da offrire, come sistema

interagisce con altri attori e sistemi esterni, a runtime quali elementi sw costituiscono

sistema, su quali elementi hw rilasciare sw, come gestire sicurezza e disponibilità del

sistema,. Come garantire modificabilità funzionalità del sistema. Si è tentati di

rispondere a tutto con un diagramma ma questo sarebbe sovraccarico, difficile da

comprendere e usare come base di comunicazione e difficile da comprendere per

sviluppatori… quindi meglio usare molti modelli (viste)

queste decisioni vanno riportate nell’AD

Viste architetturali

una vista rappresenta un insieme coeso di elementi architetturali e le relazioni tra di

• essi (ogni vista rappresenta elementi omogenei. Vista contiene elementi funzionali,

altra contiene elementi runtime, altra vista contiene allocazione sw in elementi hw

ecc.. vista = descrizione struttura. Capire strutture rilevanti e descriverle

separatamente con una vista diversa…)

ciascuna vista illustra come l’architettura affronta un insieme specifico di interessi

• architetturali (una vista contiene elementi omogenei ma aspetto imporntante è che

ogni vista deve affrontare in modo completo un interesse specifico o insieme di 123

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

interessi specifici, ovvero si parla di qualità del sistema… idea di vista nasce da

esperienza degli architetti nel descrivere architettura. Mentre modificabilità è legata a

organizzazione moduli e quindi vista per moduli e dipendenze di uso tra elementi di

moduli può essere usato per disponibilità.

un’AD è composta da un insieme di viste, separate ma correlate (un insieme id viste

• per ogni struttura ogni vista deve essere comprensibile in modo separato dalle altre

ma le viste devono essere indipendenti ma non devono essere completamente

indipendenti devono essere correlate. Ragionare su relazioni tra elementi viste

diversi…)

spunti:

cos’è una vista?

Perché AD non va definita in termini di singola vista?

PUNTI DI VISTA

Modo con cui scegliere viste da usare viste per descrivere architettura sw.

Problemi con le viste

quali viste creare in un’AD?

• come creare ciascuna vista?

Possiamo ragionare in termini di pattern sw. In questo caso le buone pratiche ci suggeriscono

di ragionare in termini di punti di vista.

Punto di vista

è un tipo standard di vista (tipo di vista usato nella descrizione di diversi sistemi. Ese:

• usare vista che contiene elementi funzionali. Altra scelta comune è vista che

rappresenta elementi runtime.)

per affrontare un insieme specifico di interessi (ogni vista e punto di vista viene

• definito in termini degli interessi che possono essere affrontati con quella vista. Ese:

vista con elementi funzionali consente di affrontare interessi funzionali del sistema.

Mentre vista runtime per interessi come prestazioni e scalabilità)

è una collezione di modelli, linee guida e convenzioni per costruire una vista da quel

• punto di vista (una soluzione esemplare a punto di vista, supponiamo che è utile usare

vista funzionale per interessi funzionali, quali linee guida, convenzioni, standard da

usare in questo ambito? Questo si fa con riferimento a ciascun punto di vista. In

generale per AD si realizzano diverse viste ognuna delle quali guidata da specifico

punto di vista.

Interesse -> punto di vista (best practice) -> vista

Esistono diversi Cataloghi di punti di vista

un “catalogo” è una specifica collezione di punti di vista (suggerisce che per AD si usa

• un certo numero di viste per certi interessi, create usando certe linee guida.)

esistono diversi cataloghi (nessuno è catalogo standard. Alcuni cataloghi sono più

• diffusi. Spesso in cataloghi diversi sono presenti punti di vista simili. Non facciamo

analisi di tanti cataloghi ma ne presentiamo qualcuno per capire i punti di vista

comuni) 124

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

primo punto di vista:

punto di vista “Modello a 4+1 viste”

una di queste viste ha spirito diverso da quello delle altre 4 e per questo si chiama modello a 4

+ 1 viste (quella degli scenari – anche detta casi d’uso) del ’45. I nuovi modelli sono basati su

questo modello.

- vista logica

- vista dei processi

- vista fisica

- vista di sviluppo

- vista degli scenari (+1)

Vista logica

modello del progetto che comprende elementi funzionali, ispirato dal dominio

• (normalmente sistema deve affrontare fornire funzionalità e scopo di questa vista

affronta elementi funzionali del sistema. Elementi sono assegnati a responsabilità

funzionali e sono presenti delle relazioni tra elementi (dipendenze uso o chiamati) e

sono ispirati al dominio del problema. ese: se sistema deve gestire ordini dei prodotti il

sistema contiene elementi per gestioni degli ordini e gestione prodotti

affronta interessi funzionali

Vista dei processi

comprende elementi runtime (processi, thread o in genere compiti), riguarda aspetti

• come concorrenza, sincronizzazione e comunicazione (aspetti rappresentati da

relazioni tra elementi. Ese: sincronizzare due processi o due thread che comunicano

con sincrono o asincrono) scalabilità̀

affronta interessi come prestazioni e (identifica compiti da svolgere a quali

• elementi affidarli e quali caratteristiche temporali per gestire questi compiti ecc.. vista

processi è buon luogo per affrontare questi interessi)

Vista di sviluppo

elementi software statici e loro organizzazione (relazioni tra moduli. Relazioni

• dipendenze di compilazione o suo o estensione funzionalità di un modulo. Se ragioni in

questi moduli affronti modificabilità e attribuzione da svolgere al team di sviluppo se il

team è grande e quindi moduli sviluppati da team differenti.

modificabilità̀

affronta interessi come la e l’attribuzione del lavoro al team di sviluppo

Vista fisica

elementi e piattaforme hw/sw e reti, e info su rilascio degli elementi software su questi

• elementi (chiamata anche vista di rilascio. Utile replicare processi che gestiscono

qualità ma anche necessari replicare ridondanza in ambiente di esecuzione (in server)

per ragionare su queste qualità si deve ragionare in termini di elementi hw)

affronta interessi come disponibilità e scalabilità

Vista degli scenari (+1)

Da una parte considera requisiti più importanti espressi negli scenari e vede come

architettura affronta gli scenari. In progettazione sistema sw sono importanti scenari 125

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

funzionali e di qualità. Scenario è problema da affrontare e descrizione di risposta da parte del

sistema. Ese: scenario di disponibilità: se si rompe un certo server… malgrado questo guasto

esecuzione operazione può essere portata avanti e descrizione dice anche in che modo viene

fatto…) si dice quali sono elementi usati per soddisfare un certo scenario. Ogni scenario dice

quali elementi consentono di affrontare lo scenario. Vista scenari dice come fa il sistema a

affrontare lo scenario e serve a correlare le altre viste. Scenari diversi spiegati con viste

diverse, analisi di tutti gli scenari definisce correlazione tra elementi di diverse viste.

considera i requisiti più importanti, espressi sotto forma di scenari

• illustra come l’architettura affronta ciascuno di questi scenari

immagine che mostra le viste e le qualità sostenute dalle viste.:

ci sono cataloghi di punti di vista più moderni che nasocno come evoluzione di questi modelli

catalogo punti di vista di SSA – system sw architecture

pdv = punto di vista

- pdv del contesto (quali attori e altri sistemi esterni ci sono)

- pdv funzionale, della concorrenza e delle informazioni (scrive ltipo info che sistema

deve gestire ma anche in che modo queste info sono ripartite la responsabilità di

gestione info viene ripartita tra elementi architettura)

- pdv di sviluppo (come quello di sviluppo visto nel 4+1)

- pdv dei deployment e operazionale (da un lato come quello 4+1 di rilascio, ma anche

operazionale: amministrazione sw, gestione sw e aspetti che riguardano

amministrazione sistema e non tanto il suo uso.

Pdv contesto in immagine sotto, sistema a scatola chiusa e altri attori presenti nel contest.

Ese sistema interagisce con sistemi esterni al pos per contabilità e inventario e sistemi per

gestione pagamenti con carta di credito 126

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

vista funzionale immagine sotto:

pensiamo agli elementi come componenti (con responsabilità funzionali). Ogni componente

ha interfacce fornite (servizi forniti da altri componenti – pallini) ma un componente deve

interagire con altri servizi per poter erogare il suo servizio.

Interfacce richieste sono individuate da frecce

Un componente può avere più di una interfaccia. Ese: interfaccia per interrogare DB prodotti e

interfaccia per modificare DB prodotti.

vista informazioni in figura sotto:

vista dello sviluppo in figura sotto:

elementi moduli in package uml. Dipendente tra moduli o tra package. Sistema è

organizzazione a strati in figura con dipendenze tra elementi in stesso strato o tra strato

sopra e quello sotto. 127

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

tipi di vista SAP (sw architecture in pratice)

qui ha caratterizzazione sintattica e si riferisce a tipo di elementi.

- viste a moduli (relazioni tra moduli)

- viste a componenti e connettori (runtime)

- viste di allocazione (ibrida. elementi sw e non sw)

- viste per qualità (viste specifiche per descrivere come sistema affronta specifica

qualità. Queste viste derivano dalle altre e non hanno info indipendenti. Sono viste

riassuntive.)

benefici nell’uso di vista e punti di vista:

- separazione interessi

- gestione complessità

- focalizzazione

- comunicazione

Rischi:

- frammentazione (se sistema organizzato in mote viste allora difficile avere idea

complessiva organizzazione sistema. Anche se catalogo è ampio, il suggerimento è di

usare non tutte le viste ma usare solo le viste che affrontano interessi davvero rilevanti

e complessi nel sistema in esame)

- inconsistenza tra viste (possibile che sviluppatore nel ragionare su viste diverse abbia

preso scelte di progetto incompatibili. Per risolvere questi problemi una buona

soluzione è usare approccio basato su scenari. Ragionando in termini di scenari,

siccome ogni scenario descrive come organizzare elementi delle viste, si identifica e

risolve inconsistenze tra viste)

- gestione di interessi trasversali (interessi possono risolversi in una singola vista ese:

modificabilità sistema risolta in vista sviluppo – che è vista a moduli. Tuttavia ci sono

interessi che richiedono ragionamenti attraverso 2 o più viste. Una di questi interessi

trasversali è quello della sicurezza. Per garantire sicurezza si usano meccanismi di

autenticazione e autorizzazioni che usano info provenienti da vista id info inoltre

fornire password e certificati da parte vista operazionale e fare ragionamento su

organizzazione hw e altro.. quindi non si può ragionare su singola vista ma occorre

ragionare su molte viste..) 128

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

questa figura riassume quanto detto:

spunti:

cos’è vista funzionale?

quali interessi affronta?

Quali interessi affrontati da vista della concorrenza?

Lez.16 - Processo di definizione dell'architettura

DEFINIZIONE DELL’ARCHITETTURA

Definizione precedente:

La definizione dell’architettura è il processo di analisi, progettazione e validazione

dell’architettura di un sistema software

Questo processo sistematico comprende progettazione architettura e attività di analisi e

analisi di verifica dell’architettura. Obbiettivi generali sono cogliere interessi parte interessati

fare scelte progetto per garantire qualità desiderati catturare queste decisioni progetto in AD

e poi convalidare decisioni progetto con riferimento a interessi posti.

Per capire processo facciamo riferimento alla figura sotto.

3 attività del processo:

- catturare interessi parti interessate (analisi)

- prendere decisioni architetturali e riportarle nella AD

- valutare architettura e le sue qualità confrontando obbiettivi raggiunti da decisioni

progetto con interessi delle parti interessate 129

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

è processo iterativo. Dopo valutazione architettura il ritorno non è su attività progettazione

ma può coinvolgere anche aspetti di analisi. Se valutazione positiva allora AD conclusa. Se non

è positiva o si cambiano decisioni di progetto o si capisce che gli interessi che sono posti per

architettura non sono raggiungibili. Ci sono combinazioni di interessi che non possono essere

raggiunti ese: costo sviluppo e tempo sviluppo. Quindi potrebbe essere necessario rinegoziare

interessi da soddisfare. Si richiede a volte riduzione obiettivi e interessi oppure si può capire

che si possono migliorare qualità con poco costo e quindi si possono alzare interessi.

La definizione dell’architettura

un processo iterativo

• analisi architetturale

• sintesi architetturale

• valutazione dell’architettura

molto vero in generale in senso che i principali approcci usati in industrie prevedono che

attività sia iterativa e che comprenda queste attività.

si prevede anche attività implementazione parziale dello scheletro architettura. In UP, AD è

iterativa in fase di elaborazione (scopo di definire e implementare scheletro architettura)

quindi in alcuni processi AD non conclusa se non si realizza scheletro sistema.

La definizione dell’architettura è un’attività a cavallo fra

tra requisiti e progettazione

• tra progettazione e sviluppo

questa idea si discute guardando figura sotto: modello a tre picchi.

il dettaglio cresce dal basso vs alto.

AD a cavallo tra analisi e costruzione.

Prima si definiscono requisiti, si propone quindi architettura iniziale e su base valutazione

architettura si può ridefinire requisiti e quindi modificare architettura.

Mentre definita architettura aumenta comprensione requisiti.

Può essere utile sviluppare scheletro sistema per avere delle verifiche sperimentali sulla

bontà architettura. Verifiche che danno feedback da usare per migliorare AD in modo

iterativo. Questo raffinamento di livello dettaglio e comprensione sistema avvengono in

parallelo. 130

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

Input e risultati

Input: portata (cose che sistema deve e non deve fare), contesto e interessi (iniziali –

• tipo di attori interessati a sistema compresi sistemi esterni)

Risultati analisi AD: una descrizione architetturale, con una giustificazione logica

• (motivazione del perché e come la scelta struttura di sistema consente di raggiungere

obbiettivi del sistema. Chiarificare anche requisiti e implementare scheletro del

sistema)

AD comprende seguenti Attività

consolida l’input sotto forma di scenari (interessi di solito forniti inizialmente per AD

• sono focalizzati su aspetti funzionali del sistema mentre scopo principale architettura è

sostenere qualità… quindi interessi vanno espansi per catturare per catturare interessi

di qualità e vanno definiti sotto forma di scenari di qualità. A questi scenari vanno

associate delle priorità )

crea un’architettura candidata iniziale (prendere in considerazione più architetture

• candidate e sceglier e pian piano la più adatta)

raffina l’architettura (attività iterativa. Se architettura non soddisfa tutti gli interessi e

• quindi si effettua raffinamento architettura cambiando progetto per sostenere meglio

alcuni obbiettivi di qualità)

valuta l’architettura con le parti interessate (per vedere se sono stati presi interessi e

• se architettura progettata soddisfa gli interessi)

rielabora l’architettura e/o rivisita i requisiti (possibile comprendere nella valutazione

• che architettura non può sostenere tutti i requisiti e quindi alcuni vanno ridotti oppure

prendere in considerazione maggiori requisiti perché non sono difficili da gestire nel

ns sistema. Questo si discute in modo iterativo)

OTTENERE QUALITA’

Architetture sw hanno ruolo rilevante nel modo un cui il sistema soddisfa requisiti non

funzionali (qualità).

Utile discutere un minimi alcune Qualità del sistema software

prestazioni (capacità del sistema di rispondere eseguendo operazioni in tempi previsti

• in anticipo) 131

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

scalabilità (essere in grado di accomodare variazione del carico del sistema come

• accessi concorrenti e mole dati gestiti)

modificabilità̀ à sicurezza (capacità di flessibilità a fronte di modifiche richieste al

• sistema sw dopo rilascio del sistema bilanciandone i costi)

disponibilità (protezione del sistema da uso non autorizzato e fornire possibilità di

• richiedere servizi. essere pronto a eseguire operazione come e quando richiesto anche

a fronte di guasti del sistema)

usabilità (facilità con cui utenti raggiungono loro obbiettivi usando sistema. Riguarda

• anche supporto fornito agli utenti)

interoperabilità (scambiare info in modo utile con altri sistemi. Aspetti sintattici –

• scambio dati con altri sistemi e aspetti semantici – capire significato dati)

time to market (realizzare sistema in tempi brevi accettabili e modificare sistema per

• erogare nuovi servizi in tempi accettabili. È FCS per organizzazione che usa sistema sw

perché un’organizzazione non può erogare nuovi servizi se prima il sistema

informatico non viene adattato per questi nuovi servizi)

integrità concettuale (è qualità interna del sistema importante perché se progetto è

• semplice e semplice far evolvere il sistema stesso. Questa qualità supporta le altre

altre... ese: qualità energetica: consumo energetico della applicazione su dispositivi

• mobili..

Ottenere qualità

tattiche architetturali

• stili architetturali

• molti altri modi…

Tattica architetturale

è una decisione di progetto che influenza il controllo di un attributo di qualità

• è un’opzione di progettazione per raffinare l’architettura

bisogna prendere molte decisioni di progettazione. Alcune relative a garantire funzionalità

agli utenti mentre altre decisioni riguardano il modo in cui i servizi sono offerti (quindi

qualità) tattiche influenzano attributo di qualità. Si usano nel raffinamento dell’architettura e

non nell’inizio. Quando abbiamo architettura definita ma capiamo che non sostiene alcuni

interessi/qualità in questo caso si raffina il progetto per controllare meglio qualità non

soddisfacenti (come sicurezza o prestazioni). È un opzione di progettazione che ha lo scopo di

migliorare il controllo di una specifica qualità.

Esempi di tattiche per le prestazioni (se tempo non soddisfacente)

migliora l’efficienza dell’algoritmo scelto per eseguire la stessa operazione (sto

• migliorano qualità prestazioni ma decido anche che ho bisogno di più tempo per

sviluppare sistema o sviluppo più costoso. Questo è comune.. spesso si migliora una

qualità ma a scapito di altre qualità (come costo)

utilizza risorse migliori (mantengo il mio algoritmo origniale e lo eseguo su processore

• migliore con reti migliori o dischi migliori. Anche qui potrei avere prestazioni

temporali migliori. Anche qui sarà necessario investimento maggiore su hw quindi si

influenza costo attesto realizzazione sistema. Le tattiche sono in certi casi sinergiche

mentre in altri cosi sono in alternativa fra loro)

introduci la concorrenza (se identifico algoritmo sequenziale per gestire prestazione

• posso suddividere algoritmo in attività parallele concorrenti in modo che il tempo

totale non sia somma dei tempi ma pari al tempo massimo) 132

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

Stile architetturale

Pattern architetturale = pattern sw (coppia problema soluzione):

sostiene gruppo di qualità con insieme elementi che forniscono struttura principale del

sistema sw. Sono pattern sw a livello di elementi architetturali e architettura. Ese: architettura

a strati. Il problema è decomporre sistema complesso in modo che le parti sono sviluppate in

modo indipendente e che possono anche evolvere indipendentemente.

esprime uno schema per l’organizzazione strutturale fondamentale di un sistema

• software, per risolvere un particolare problema di progettazione

fornisce un insieme di tipi di elementi, specifica le loro responsabilità, e comprende

• regole per organizzare le relazioni tra di essi (in caso di architettura a strati c’è un solo

tpo di elementi (strati) in altri stili architetturali ci sono diversi tipi di elementi. Quella

astrati definisce criteri per assegnare responsabilità agli elementi sulla base del livello

distrazione delle funzionalità (presentazione, logica applicativa, servizi tecnici) e

interazioni che guidano relazioni tra elementi (strati in sequenza verticale e

dipendenze e interazione da strati alti vs strati bassi.)

Esempi di stili architetturali

layers (a strati)

• pipes & filters (stile utile per sistemi che elaborano flussi di dati con 2 elementi pipe e

• filtri.) i primi due sono stili generali indipendenti da tecnologie e poi usati in contesti

o diversi

client/server (due elemini: client che chiede servizi ai serventi. Tipo particolare di

• architettura a strati. Strato client e strato server)

peer-to-peer

• questi ultimi due sono per sistemi di categoria specifica come sistemi

o distributivi.

Confronto

stili architetturali: consentono di fornire una architettura candidata per affrontare in

• modo congiunto un gruppo di qualità e sono utili nella fase inziale della definizione

dell’architettura.

tattiche architetturali: forniscono suggerimento per raffinare architettura ma non

• efficaci per scegliere architettura candidata iniziale. Quindi si usano in fase di

affinamento dell’architettura

stili usati prima e tattiche usate dopo. Sono complementari nella progettazione

dell’architettura sw.

VALIDAZIONE DELL’ARCHITETTURA

Obiettivi generali della validazione:

comunicare e convalidare le decisioni prese durante definizione architettura (siccome

• si parla anche di analisi (comprensione da parte delle parti interessate) si deve

validare che gli interessi scelti per il sistema siano soddisfatti.

valutazione della bontà della soluzione proposta rispetto al problema identificato ( in

• termini di interessi scelti) 133

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

comprendere le conseguenze delle decisioni di progetto sulle diverse qualità (scopo di

• verificare quali sono conseguenze decisioni di progetto sulle diverse qualità

analisi dei compromessi e dei rischi (effettuare analisi dei compromessi. Alcune scelte

• sono scelte di compromesso. Capire quali sono le scelte di compromesso e quelle che

non lo sono.) ese: scelta influisce vene su prestazioni e male su sicurezza:

esempio scelta rischiosa: come il numero di bit per la cifratura influenza prestazioni e

sicurezza: se una piccola variazione del numero di bit influisce in modo significativo su

prestazioni e sicurezza, allora questa è da considerarsi una scelta rischiosa. Allora conviene

valutare altre architetture candidate con compromessi che non sono fonte di rischio.

Molti approcci della valutazione servono a valutare compromessi e rischi.

Tecniche di validazione

Alcune sono semplici altre complesse e costose. Forniscono diverso livello di valutazione.

Valutazione architettura fatta in modo iterativo quindi valutazione continua.

presentazione informale (in fase iniziale. Architetto comunica a altre parti interessate

• quello che lui ha compreso su interessi e riassume le decisioni prese e parla delle

conseguenze. Presentazione è breve e si ottiene feedback parziale e validazione

limitata di architettura. In fase iniziale consente di trovare errori significativi in

comprensione interessi.

revisione formale (fatto da piccolo gruppo di lavoro fatto di parti tecniche e

• interessate. Deve essere preparato in dettaglio e poi si riunisce per discutere tutte le

decisioni di progetto per capire se ci sono errori su quanto compreso e deciso.

valutazione basata su scenari (richiedono qualche giorno di lavoro. Forte preparazione

• e coinvolgimento parti interessate. Il lavoro si organizza discutendo prima interessi

per avere un accordo su questi, poi discusse le qualità e le scelte che sostengono gli

interessi, poi discussi gli scenari per sostenere la qualità e poi discusso come la

architettura progettata sostiene quegli scenari. Quando si pensi di aver definito

abbastanza in dettaglio l’architettura ma non si è scritto molto codice quindi si ha

spazio per miglioramenti)

prototipazione (si usa il prototipo per un feedback ma poi prototipo viene gettato)

• sistema scheletro (verificare empiricamente il sistema ma lo scheletro non viene

• abbandonato ma resto del sistema si costruisce sullo scheletro.)

diverse tecniche hanno costi diversi e danno risposte diverse sul sistema e sulla architettura.

Spunti:

cos’è la validazione dell’architettura

perché è importante nel contesto del processo di definizione dell’architettura?

Lez.17 - Tattiche architetturali

È argomento molto ampio, qui si da introduzione e panoramica sul tema.

INTRODUZIONE ALLE TATTICHE

Definizione precedente di tattica architetturale: 134

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

Una tattica architetturale è una decisione di progetto che influenza il controllo di un

Attributo di qualità

Nella progrttazione di architettura prendiamo numerose decisioni, alcune riguardanti

attributi di qualità. Decisioni dettate da tattiche architetturali.

Quando abbiamo già architettura di riferimento e abbiamo capito che non soddisfa una certa

qualità ese. Le prestazioni. Allora dobbiamo trasformare una architettura (cambiare scelta

elementi, o modo in cui questi interagiscono o cambiare assegnazione responsabilità agli

elementi dell’architettura).

Consideriamo questa porzione di architettura:

eventi arrivano, elaborati da elemento E e poi si hanno risultati.

Supponiamo che tempo di risposta di elemento E sia troppo alto.

Vogliamo ridurre tempo di attesa.

Tempo elaborazione accettabile ma tempo attesa non accettabile.

Introdurre 2 copie di E e bilanciamento a carico.

Eventi arrivano a bilanciamento al carico, questo smista eventi ai due elemtni E e poi si ha

flusso risultati.

Tempo elaborazione singolo evento non cambia ma si riduce tempo attesa per gestione eventi

e quindi tempo risposta complessivo ridotto a livello accettabile

Questa tattica ha conseguenze

Caratteristiche delle tattiche

codificano esperienza

• opzioni di progettazione (normalmente avremo tante possibili opzioni e architetto

• deve capire quali opzioni sono applicabili e tra queste quali preferibili. Alcune sono in

alternativa, altre sono sinergiche.)

trasformazioni a grana fine (riguardano una manciata di elementi di una delle

• strutture di architettura e non influenzano architettura complessiva del sistema.)

attenzione agli effetti collaterali (applicando tattica posso migliorare controllo qualità,

• con effetti collaterali positivi e negativi su altre qualità. Occhio ai compromessi con

effetti negativi su altre qualità) 135

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

spunto:

quando si applicano tattiche architetturali ?

TATTICHE PER LE PRESTAZIONI

Consideriamo tattiche per le prestazioni, per controllare il tempo di risposta a un evento

Prestazioni hanno a che fare con profilo temporale delle operazioni.

Qui ci concentriamo su tempo di risposta.

Tempo risposta = tempo di elaborazione + tempo di attesa

Tempo di elaborazione= tempo di processore, tempo di accesso a rete ecc..

Tempo di attesa= evento è in coda in attesa di essere elaborato, oppure si richiede più

operazioni ed una di queste è in attesa di essere processata.

Si interviene su uno o su entrambi i tempi (elaborazione e attesa)

Diverse categorie di tattiche sulle prestazioni volte a entrambi i tipi di tempo.

Tattiche per le prestazioni

migliora l’efficienza (supponiamo di dover gestire evento e abbiamo algoritmo per

• gestirlo ma tempo di elaborazione algoritmo non è accettabile. Possiamo intervenire su

algoritmo per migliorarne efficienza. Oppure mantengo algoritmo e uso

processori/reti migliori. La prima tattica aumenta costi sviluppo sw la seconda

aumenta costi HW. In entrambi i casi abbiamo effetto negativo su costi. Tattiche che

possono essere usate insieme perché non sono concorrenti)

utilizza risorse migliori (migliorare HW vedi sopra)

• riduci l’overhead (legati a presenza di intermediari che potrei eliminare. Ma

• intermediari utili per modificabilità quindi sempre da considerare il trade-off)

introduci la concorrenza (identificato algoritmo sequenziale di elaborazione, posso

• spezzare algoritmo per eseguire attività in modo concorrente. Usare più thread o

processi nella gestione del singolo evento)

introduci più copie della computazione e/o dei dati (più processi o thread componenti

• ognuno gestito in modo indipendente. In questo caso tempo elaborazione non si riduce

ma si riduce tempo di attesa. Questo è esempio della figura sopra. Mantenere copie dei

dati temporanei (caching) per evitare di ripetere calcoli costosi)

schedula l’utilizzo delle risorse (assegnare priorità diverse a diversi eventi.)

spunti:

qual è obbiettivo delle tattiche di prestazioni e come può essere raggiunto?

TATTICHE PER LA MODIFICABILITÀ

Consideriamo tattiche per la modificabilità, per controllare il costo per implementare e

rilasciare un cambiamento atteso 136

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

Modificabilità è importante molto spesso vengono fatti sforzi in fase di evoluzione del sistema.

Scopo di queste tattiche è minimizzare costi di manutenzione ed evoluzione sistema magari

anticipando costi in fase di sviluppo inziale del sistema.

Costi in termini economici e di capitale umano.

Facciamo riferimento a cambiamenti attesi. Utile che sistema sia flessibile a fronte di alcune

modifiche che possono essere previste in fase iniziale di sviluppo.

Cambiamenti che non si fanno in fase di sviluppo, in questa fase ci si prepara solamente.

Costo atteso di una modifica M di una responsabilità R

R

modifica dell’elemento E responsabile di R

• R

modifica degli elementi a cui si propaga questa modifica

esperienza ci dice che Il costo di queste modifiche dipende da

coesione dell’elemento E e degli altri elementi da modificare

R

• accoppiamento verso gli elementi da modificare

• la coesione (deve essere alta) è una misura della forza delle relazioni tra le

• responsabilità di uno specifico modulo

l’accoppiamento è una misura della forza delle dipendenze tra moduli

elemento a coesione alta è più facile da modificare.

Accoppiamento è misura di probabilità che la modifica di un elemento si ripercuota su altri

elementi.

Obbiettivi generali della modificabilità:

alta coesione

• basso accoppiamento

quindi abbiamo tattiche volte alla coesione e tattiche volte all’accoppiamento

Tattiche per aumentare la coesione

separa un modulo (con riferimento a cambiamenti attesi. Ese: responsabilità

• assegnata ad un modulo che ha anche altre responsabilità. Meglio se responsabilità è

assegnata a modulo singolo.. questa tattica suggerisce moduli più piccoli e di scegliere

moduli in base ai cambiamenti attesi del sistema.

aumenta la coerenza semantica (coesione è forza sintattica perché non considera

• cambiamenti attesi. Se cambiamento è trasversale a vari moduli meglio estrarre da

tutti i moduli la responsabilità da modificare ed assegnarla ad un modulo unico

separato. Ese: i protocolli di rete sono organizzati per far si che le modifiche avvengano

in un unico protocollo).

Tattiche per ridurre l’accoppiamento

incapsulamento (progettare elementi in modo da separare interfaccia elemento

• pubblica e privata. Se elemento dipende solo da interfaccia di un altro elemento allora

accoppiamento è più basso.) 137

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

usa un intermediario (in alcuni casi 2 o più elementi sono accoppiati. In questo caso

• utile avere intermediario che si accolla l’accoppiamento e libera altri elementi da

accoppiamento indesiderato. Ese: sistema che interagisce con sistema esterno e non lo

fa dallo strato della logica applicativa ma opera con un adattatore che si accolla la

responsabilità di interagire con sistema esterno. Questo è utile se comunichiamo con

un altro sistema.)

astrai servizi comuni (si applica quando ci sono diversi elementi che danno servizi

• simili. Se servizi sono soggetti a variazioni meglio estrarre variazione del servizio e

metterle in un singolo modulo e che può essere usato in modo parametrico. Se bisogna

modificare servizio lo modifichiamo in un solo posto senza modificarlo in tutti i

moduli. Qui si suggerisce di accorpare responsabilità anziché separarle)

Tattiche per posticipare il collegamento

finché c’è un’opportuna preparazione, più tardi nel ciclo di vita si può applicare una

• modifica, minore è il suo costo (supponiamo che il ns sistema si comporta in un certo

modo prima della modifica prevista M e dopo modifica si comporta diversamente.

Quando modifica richiesta, il codice è già scritto e basta solo abilitarlo. Tempo di

applicazione di M è breve. Tempo preparazione in fase inziale è alto. Se

comportamento sistema dopo M non è implementato allora occorrerà scrivere codice

ecc.. per avere modfiche rapide è bene prepararsi a queste modifiche. )

ciclo di vita del sistema… modifiche riferite a:

al tempo della codifica (uso di parametri o polimorfismo o programmazione orientata

• agli aspetti)

al tempo della compilazione (script di compilazione)

• al tempo del rilascio (separare momento del rilascio così da scegliere quali componenti

• usare)

all’inizializzazione (file di configurazione per gestire parametri da usare in esecuzione

• sistema)

a runtime (se ho già previsto modifiche e sono implementate allora basta solo attivarle,

• anche da parte di un utente del sistema)

più tardi possiamo fare la modifica maggiore è la preparazione e minore il costo.

TATTICHE PER LA DISPONIBILITÀ

Disponibilità

la proprietà di un sistema di essere pronto a svolgere i compiti quando gli vengono

• richiesti

proprietà che è interessata ai guasti e ai fallimenti di un sistema

guasto: problema interno al sistema. Ese: errore nel sw o rottura server o disco o rete. Quando

c’è guasto si può verificare un fallimento.

fallimento: esterno al sistema. Sistema non è disponibile a erogare i servizi

disponibilità: quando guasti sono mascherati e non producono fallimenti o quando sistema è

capace di essere ripristinato dopo un fallimento. Se torno a erogare il servizio rapidamente il

sistema è considerato disponibile 138

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

Un fallimento si verifica quando il sistema non eroga più un servizio

interruzione di servizio (quando c’è fallimento per un certo tempo sistema non eroga

• servizio. Quel tempo è tempo di interruzione del servizio.)

perdita di dati (perdita dati all’indietro: su ultime transazioni. In alcuni casi si tollera

• per un certo periodo di tempo, in altri casi non si tollera. )

altra def. di Disponibilità di un servizio

la percentuale di tempo in cui il sistema è operativo e in grado di erogare quel servizio

un sistema che ha disponibilità di servizio per 99% tempo significa che in un anno 1% è fuori

servizio

99,9% disponibilità a 4 nodi che corrisponde ad un minuto a settimana.

Sistema con servizi diversi e ogni servizi richiede certa misura di disponibilità riferimento a

periodi di giornata.

Committente investe su disponibilità in visione delle conseguenze negative possibili a fronte

di indisponibilità. Pensare a commercio online… se non è disponibile la conseguenza è perdita

vendita. Pensare anche a sistema di volo di aereo…

Consideriamo tattiche per la disponibilità, allo scopo di

impedire ai guasti di provocare fallimenti

• limitare l’effetto del fallimento e rendere possibile il ripristino

2 modi per aumentare disponibilità:

diminuire possibilità fallimenti

• ridurre tempo ripristino

tutti approcci per aumentare disponibilità eliminano punti fallimento singoli (che se falliscono

provocano fallimento sistema). Si ricorre a copie ridondanti degli elementi del sistema e si

usano elementi di controllo per monitorare questi elementi.

Gruppo di protezione per un servizio S si intende:

un insieme di nodi (server) utilizzati per l’erogazione del servizio S (consideriamo solo

• guasti ai nodi del sistema ma tattiche simili si usano per proteggersi da guasti di

elementi diversi da server)

nodi attivi e nodi di riserva (nodi attivi: sono fruiti direttamente da client del servizio.

• Nodi di riserva: non usati direttamente da client per fruire servizio. Riserva impegnati

anche attivamente in erogazine servizio o anche di riserva per un servizio ma attivo

per altro servizio. Nozione dinamica: un nodo attivo si guasta e uno di riserva diventa

attivo per sostituire quello guasto. La configurazione più semplice è la 1+1 cioè uno

attivo e uno di riserva.)

Tattiche per rilevare guasti

monitoraggio tra nodi di gruppo di protezione (nodi di riserva monitorano nodi attivi.

• Tattica ping eco. Nodo monitor manda ping e se non ricevo eco allora significa che c’è

guasto. Ma segnale eco può perdersi nella rete.. per avere più affidabilità si usa anche

ridondanza della rete. Queste tattiche capiscono se nodi sono vivi) 139

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

monitoraggio delle interazioni fra nodi di gruppo di protezione (per monitorare stato

• salute di elementi di gruppo di protezione. Monitorati messaggi scambiati tra elementi

per capire se risposte hanno senso o se hanno degli errori)

tempo di sostituzione di elementi comprende tempo perso per accorgersi del guasto. Se non ci

accorgiamo del guasto è tempo di fuori servizio. Rilevare guasti velocemente aumenta

disponibilità.

Tattiche per il ripristino da guasti

nel momento in cui si verifica guasto e occorre sostituzione (failover). Prima della

sostituzione, stato nodo riserva deve essere sincronizzato con ultimo stato noto del nodo

guasto.

ridondanza attiva (hot spare): tutti i nodi elaborano gli eventi ricevuti dal servizo. Così

• sono sincronizzati. Client fruisce servizio da nodo attivo, nel momento che nodo

fallisce, la sostituzione è immediata. Tempo ripristino di millisecondi ma costo elevato

perché nodo riserva è dedicato)

riserva (cold spare): no sincronizzazione. Questa avviene solo a fronte del guasto. Ese:

• nodo riserva prende stato da copia di backup o rieseguendo oltre a ripristino anche

log. Si chiede qualche tempo (ore o minuti) ma soluzione meno costosa. Nodo riserva

può essere usato anche per altri servizi)

ridondanza passiva (warm spare): periodicamente nodo attivo invia info su

• cambiamenti di stato a nodo di riserva. A fronte di guasto, nodo riserva è abbastanza

sincronizzato, riesegue solo le ultime transazione da log di transazioni. Poco tempo

richiesta. Questa è tattica intermedia tra i primi due.

Si usano gruppo di tattiche insieme e non una singola

Lez.18 - Stili architetturali (prima parte)

INTRODUZIONE AGLI STILI architetturali

Definizione Stile (o pattern) architetturale

un pattern software che guida l’organizzazione di un’architettura software

si tratta di una soluzione esemplare a problema ricorrente di progettazione a cui è associato

un nome. È problema di qualità. Garantire certo insieme di qualità.

Suggerisce che per avere certa combinazione di qualità si può organizzare sistema in base a

certo tipo di elementi organizzati in un certo modo.

Caratteristiche stili

codificano esperienza (descrivono modo semplice da comprendere quanto fanno

• architetti)

problema e soluzione a grana grossa (problema è relativo a progettazine intero

• sistema e anche soluzione. Diverso da design pattern dove soluzione è a grana piccola

che affronta problema specifico locale non complessivo per intero sistema.)

riguardano l’architettura complessiva (del sistema o di una sua struttura) (dice come

• organizzare intero elemento. In certi casi elementi architetturali vanno ulteriormente

140

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

decomposti. Utile applicare stili a inizio progettazione architettura. Stile serve a dare

forma a intero sistema mentre in fase raffinamento è preferibile usare tattiche

architetturali che sono interventi locali e mirati. In molti sistemi vista sviluppo

organizzata a strati e architettura rilascio che riguarda esecuzione codice in SW-HW

sono organizzati in client-server)

un pacchetto di decisioni di progetto (a differenza di tattiche, quando si applica stile

• non si applica singola decisione ma gruppo di decisioni per un gruppo di qualità. Utile

analizzare stili architetturali per avere migliore comprensione delle decisioni.

Stili Spesso organizzati in Linguaggi di pattern e stili architetturali

una famiglia di pattern e stili correlati (non sono definiti in isolamento ma meglio

• studiarli in famiglie. Alcune famiglie sono per supporto di qualità specifiche

(Sicurezza) altri relativi invece a problemi specifici (sistemi distribuiti o integrazione

applicazioni.)

pattern POSA – pattern oriented sw architecture. Libro del ’96 che descrive pattern

• architetturali generici riusati in molti contesti.

Figura illustra stili architetturali che presenteremo nelle lezioni:

DOMAIN MODEL E DOMAIN OBJECT

Molto astratti, chiave di lettura per altri stili.

Domain Model

contesto: inizio della progettazione di un sistema software (necessario avere struttura

• per il sistema. Definendone la sua architettura)

problema: il progetto deve essere facile da comprendere, comunicare, valutare

• (esperienza dimostra che se non c’è buona intuizione, il sistema è difficile da

sviluppare e implementare.)

Soluzione: 141

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

crea un modello (modello di dominio) che definisce le responsabilità del dominio

• (modello di dominio è termine generale che parla del modello del problema che il

sistema deve affrontare. Esistono tante modellazioni di dominio sul problema che il

sistema deve affrontare. A seconda tipo di sistema usare modello che descriva

responsabilità di alto livello del dominio.

utilizza questo modello come fondamenta per l’architettura del sistema da realizzare

• (organizzare architettura a partire da elementi del dominio. Scegliere elementi

architettura sw in base a quelli del modello di dominio e anche per le relazioni. come in

OOA abbiamo modello di dominio e veniva poi ripreso per modellazione oggetti sw)

Esempi di “modelli di dominio”

modello delle informazioni (elementi sono entità, relazioni e attributi)

• modello dei casi d’uso (contiene molti elementi come attori del sistema e casi d’uso.

• Caso è funzionalità offerta dal sistema. Ogni attore deve poter raggiungere un

obbiettivo specifico di valore.)

modello delle attività e dei flussi di dati (modello comportamentali che contengono

• moti elementi: attività compiti e servizi da svolgere in organizzazione e flussi di dati

che si muovono tra attività e organizzazione di questi elementi deve rappresentare

responsabilità e processi di business svolti dall’organizzazione. In sistema architettura

contiene elementi ispirati a queste info.)

modello dei processi di business

Domain Object – oggetto di dominio

Astratto e correlato a domain model

contesto: decomposizione di un sistema (o di un elemento architetturale): applicato a

• inizio – definizione sistema o quando occorre decomporre elementi architetturali, la

decomposizione può essere guidata da domain object.

problema: la decomposizione del sistema deve sostenere i suoi interessi, sia funzionali

• che di qualità (noi conosciamo interessi da sostenere ma non sappiamo come

decomporre sistema in modo semplice. Importante decomporre sistema per 142

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

minimizzare complessità strutturale. E se non si fa decomposizione si rischia di influire

negativamente sulle qualità.

soluzione: incapsula ciascuna responsabilità funzionale dell’applicazione in un

• elemento auto- contenuto (oggetto di dominio)

concentrarsi su responsabilità funzionali per scegliere elementi architettura. Elementi

architettura devono avere responsabilità funzionali (comportamento o info significative).

Ogni elemento deve essere incapsulato (ogni elemento caratterizzato da interfaccia e

implementazione distinte e interazione elementi basata su interfaccia). Elementi architettura

possono essere chiamati oggetti di dominio e quindi si rafforza importanza domain model.

Usare criteri progettazione generali come OOD.

In questa soluzione is parla di scelta elementi, si suggerisce che la decomposizione non deve

essere indipendente dalle qualità del sistema ma scelta deve influenzare interazioni e

relazioni tra elementi.

Domain object è quindi utile per partizionamento interno di intera architettura o di elementi

di architettura

LAYERS

Architettura a strati. Stile molto diffuso.

Contesto

decomposizione di un sistema (o di un elemento architetturale) in diverse parti

applicato quando si ha bisogno di effettuare decomposizione del sistema. Ese: diverse parti

del sistema implementate da diversi team di sviluppo.

Problema 143

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

le parti devono poter essere sviluppate ed evolvere in modo indipendente

• il sistema si deve occupare di aspetti diversi, a diversi livelli di astrazione (caso

• comune. Ese: dobbiamo gestire sistema per gestire telefonate. Questo sistema deve

gestire traffico telefonico quindi segnali che riguardano canali di trasmissione ma deve

calcolare anche bollette da pagare a utenti ecc.. concetti di traffico telefonico,

telefonata, tariffe, utenti ecc sono concetti diversi tra loro. Questi concetti devono

essere rappresentati e gestiti da elementi diversi dell’architettura. Anche perché le

eventuali modifiche riguarderanno un singolo livello di astrazione.

Soluzione

organizza il sistema in una gerarchia verticale di strati (strati = elementi architetturali

• a grana grossa con dipendenze verticali da alto vs basso)

assegna a ciascuno strato una responsabilità distinta e specifica (per avere coerenza

• semantica – impatto cambiamenti in un livello di astrazione possa essere gestito in

ambito di un singolo strato)

ogni strato fornisce un’interfaccia separata dalla sua implementazione

• (incapsulamento. Distinzione tra interfaccia e implementazione ecc…)

costruisci gli strati in modo che ciascuno dipenda solo da se stesso e dagli strati

• inferiori (strati ordinati da relazione di dipendenza cioè relazione di uso.)

esistono due varianti:

rilassato (quella descritta in figura sotto – ogni stato può dipendere da qualsiasi altro

stretta (strato dipende solo da quello inferiore)

frecce tratteggiate = dipendenze da alto vs basso.

Generalmente in architettura a strati: Scendono richieste e risalgono risposte e notifiche di

eventi. 144

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

Protocolli di rete nella pila ISO/OSI

Livello fisico si occupa solo trasmissione di sequenze di bit su canale di comunicazione.

Questo dipende da canale di comunicazione a livello fisico e dipendenza nascosta agli altri

livelli.

Questa è architettura a strati e ogni strato fa riferimento a un livello di astrazione diverso così

si può intervenire su un singolo livello.

Utente richiede a livello alto (http) questa decomposta in richieste di servizi a livello più basso

fino a livello fisico più basso…

Scenari principali

Scenario: situazione in cui può trovari un sistema e descrizione di reazione del sistema

comunicazione top-down (richieste da strato alto e decomposte in richieste successive

• vs strati bassi finche richieste non sono soddisfatte)

comunicazione bottom-up (interazione inizia dal basso. Ese: comunicazione di rete tra

• due PC quindi 2 pile iso/osi. Da una parte abbiamo top-down, dal ricevente arrivano

segnali elettrici riconosciuti da livello basso data-link e si notifica a strato superiore la

ricezione di sequenza di bit e si notificherà lo strato più alto.)

scenari che non coinvolgono tutti gli strati (ese: in sistema informatico, se utente fa

• richiesta di accesso a DB per avere info, se info sono in cache non occorre arrivare a

strato basso e quindi richiesta può essere fornita senza attraversare tutti gli stati.

Criteri per la scelta degli strati

Obbiettivo fondamentale layer è modificabilità quindi strati scelti in modo compatibile con

questo obiettivo.

livello di astrazione e dipendenza dall’applicazione (scegliendo strati alti quelli

• corrispondenti a concetti più astratti e strati più bassi più concreti. Questo fa si che le

richieste di modifica riguardano responsabilità in un singolo livello di astrazione e

quindi ogni modifica gestita in singolo strato) 145

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

tasso di cambiamento atteso (mettere elementi stabili in strati bassi e quelli più

• variabili in alto. Dipendenze da alto vs basso, quindi cambiamento che riguarda

solitamente strato alto, non influisce su strato basso che non dipende da quello alto.

granularità (elementi piccoli in basso e grandi in alto)

• distanza dall’hardware (elementi che dipendono da HW sono in strati bassi, così da

• avere portabilità mentre elementi che dipendono meno da HW sono in alto.)

Conseguenze

buona modificabilità (se strati sono organizzati rispetto a cambiamenti attesi allora

• cambiamento localizzati in singoli strati)

problemi di prestazioni (richieste fanno elaborazioni in tutti o quasi tutti gli strati con

• overhead. Questo mitigato se richiesta gestita in modo concorrente in thread diverso

buona sicurezza (strati dedicati alla sicurezza per proteggere info in strati sottostanti)

• buina affidabilità (gestione errori è facile in layers e buon monitoring delle info

• scambiate negli strati.)

Lez.19 - Stili architetturali (seconda parte)

PIPES AND FILTERS

Tubi e filtri. Stile molto diffuso anche se meno noto di layers.

Contesto

un sistema (applicazione o componente) che deve elaborare flussi di dati

elemento che riceve in ingresso flusso di dati deve farci una trasformazione ed avere in uscita

un nuovo flusso di dati.

Ese: commercio elettronico: flusso di quote in input e flusso di ordini in uscita.

Problema 146

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

l’elaborazione è complessa ma può essere decomposta in passi di elaborazione

• successivi (se fosse semplice allora elaborazione poteva farsi con un solo elemento. Per

ipotesi trasformazione può essere fatta tramite sequenza di passi di trasformazioni

successive. Ogni passo trasforma una parte della sequenza.)

i dettagli dei diversi passi possono cambiare indipendentemente tra loro (richiesta

• modificabilità. Talvolta cambiare trasformazione complessiva.)

si assume che la comunicazione richiesta- risposta non è adeguata (normalmente

• questa richiede sincronizzazione tra elementi del sistema. Questa sincronizzazione

potrebbe inficiare su scalabilità e prestazioni di sistema)

Soluzione

suddividi l’elaborazione in una sequenza di passi di elaborazione auto-contenuti (vero

• per ipotesi. Tipicamente decompoosizione fatta con modellazione di dominio con

modellazione delle attività in cui abbiamo dei compiti (passi di trasformazione)

identificare anche movimenti dei dati.)

implementa ciascun passo mediante un componente filtro (in generale pipes and filter

• suggerisce due tipi di elementi sw. Filtri e i tubi. Ogni filtro ha lo scopo di

implementare singolo passo di trasformazione complessa. componenti sw hanno

responsabilità funzionali. Ogni filtro implementa una trasformazione elementare su

flusso di dati.)

componi questi filtri in una pipeline di elaborazione dei dati (pipeline è sequenza di

• filtri ogni filtro fa parte di trasformazione. Filtri messi in sequenza come richiesto da

trasformazione. Sequenza di flitri forma pipeline.)

collega filtri successivi nella pipeline mediante connettori pipe (non collegare

• direttamente uscita filtro con ingresso filtro successivo ma usare connettori pipe come

intermediari. Connettori non sono responsabilità di comportamento ma solo di

collegare elementi. Pipe servono per abbassare accoppiamento di filtri successivi e

gestire aspetti di comunicazione come bufferizzazione dei dati e sincronizzazione)

figura sotto:

flusso ingresso collegato direttamente a 1° filtro. Dopo 1° filtro c’è intermediazione di pipe e

poi si arriva a 2° filtro ecc…

importante: trasformazioni non in sequenza. Non opera prima il 1° poi il 2° ecc ma ciascun

flusso di dati del flusso di ingresso vengono elaborati da uno dei filtri poiché questi lavorano

in modo concorrente (lavorano insieme). 147

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

figura sotto:

esempio concreto del compilatore.

Questa è applicazione che traduce un programma da codice sorgente in versione eseguibile di

programma. Codice visto come flusso di dati che viene trasformato in programma..

Decomposizione in fasi.

4 fasi di compilazione di programma:

- analisi lessicale (suddivide codice sorgente in token che vanno in flusso in uscita. Ogni

token è elemento lessicale come identificatore, parola chiave, operatore ecc…)

- analisi sintattica (svolta da analizzatore sintattico – o parser. Che capisce lo scopo della

grammatica del codice e riscostruisce applicazione delle regole sintattiche. Albero

sintattico è l’output dell’analizzatore sintattico.

- analisi semantica (analizzatore semantico verifica validità semantica del programma e

ha output albero sintattico modificato)

- generazione del codice (in ingresso visita albero sintattico modificato e output

sequenza di istruzioni binarie)

utile sare filtri da libreria di filtri predefiniti

figura sotto: 148

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

ogni ordine incoming associato a certificato di validità. Ordini in ingresso devono avere ordini

duplicati. In output vogliamo flusso ordini pulito ovvero non cifrati, senza duplicati e per i

quali è verificato il certificato.

In figura sotto non mostriamo pipe per semplicità.

1° filtro decripta, 2° verifica autenticità, 3° de-duplica, e in uscita finale abbiamo ordini puliti.

Ogni filtro è relativo a responsabilità diversa (decifrare, de-duplicare ecc, quindi fanno passi

di trasformazione indipendenti tra loro quindi questi filtri possono essere riusati in contesti

diversi.)

in pipes e filters ci sono diversi scenari:

- pipeline push (unico elemento attivo è sorgente di dati che spinge dati in filtro attivo)

- pipeline pull (unico elemento attivo è destinazione dati che richiede dati a ultimo filtro

che richiede a quello precedente finché dati non vengono presi dalla sorgente e portati

come risposta alla destinazione. In entrambi i casi dati vanno da sorgente a

destinazione. Cambia il controllo. In primo caso abbiamo controllo da parte del primo

elemento, in pull controllo detenuto da ultimo elemento di destinazione.)

- scenario misto pull-push (elemento attivo è filtro centrale, che chiede dati da sorgente

in pull e li spinge vs destinazione. Tutti i filtri a monte operano in pull, quelli a valle

operano in push)

- scenario con più filtri attivi (vedi figura sotto)

scenario con più filtri:

doppie barre accanto agli elementi significa che elemnti sono attivi e che qundi operano in

proprio therad o processo.

Linee blu sono confini di comunicazione tra elementi

Filtro 1 opera in pull-push. Legge da sorgente, trasforma dati e li scrive in push vs la pipe

successiva.

Filtro 2 opera in modalità analoga attiva. Legge dati trasforma e li scrive vs elemento

successivo.

In questo scenario occorre capire ruolo pipe. Questa è intermediario tra filtri per ridurre

accoppiamento tra filtri e ha scopo di gestire sincronizzazione tra filtri e gestire

bufferizzazione dei dati. 149

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

sincronizzazione dei filtri da parte della pipe:

se filtro 2 prova a leggere dei dati dalla pipe, ma se la pipe è vuota perché ancora in attesa di

dati da filtro 1. Allora la pipe blocca esecuzione filtro 2 finche non ottiene dati da filtro 1.

Quando ottiene dati sblocca filtro 2 e lo rimanda in esecuzione. Così viene gestita

sincronizzazione filtri.

Bufferizzazione da parte della pipe:

filtro 1 vuole scrivere dati che ancora non sono stati richiesti da filtro 2. Allora pipe

memorizza i dati e li manda a filtro 2 quando questo li richiede.

Ruolo di pipe è di disaccoppiare filtri successivi, gestirne sincronizzazione e bafferizzare dati.

Conseguenze applicazione pipes e filters:

- modificabilità sostenuta: modificabilità della trasformazione nella misura che la nuova

trasformazione come rielaborazione della pipeline modificano ordine o scelta filtri.

Soprattutto quando filtri possono essere scelti da libreria predefinita. Anche in caso in

cui modifica riguarda dettagli comportamento singolo filtro si richiede modifica filtro

che è facile perché filtri sono molto coesi.

- Positive e negative sulle prestazioni: positive perché filtri sono concorrenti quindi

lavorano in modo concorrente riducendo il tempo. A volte si può avere più copie di

stesso filtro. Negative perché Ogni filtro deve ricevere dati decodificarli e poi codificare

di nuovo

- Affidabilità negativa: difficile gestire errori ma in alcuni casi pipe sono supporto alla

affidabilità (vedi avanti).

- Supporto alla sicurezza: con filtri dedicati alla sicurezza ese: filtri dedicati a cifratura

dei dati

Figura sotto:

In operaizoni su DB interrogazioni SQL vengono ottimizzate con espressoni di algebra

relazionale con riferimento ad operatori fisici.

Operatori di algebra possono essere istanziati in memoria e mandati in esecuzione e questi

operatori sono in effetti filtri perché hanno dati in ingresso e in uscita e vengono messi in

modo concorrente. Interrogazioni relazionali vengono effettivamente gestiti così. 150

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

figura sotto:

altro esempio di pipes e filters: framework map-reduce di adup.

Lo scopo è calcolare data analytics. Dati complessi di ordine di teraB di dati. Si vuole fare

riduzioni di dati. Filtri di tipo reduce. Programmatore scrive programmazione e framework

distribuisce compiti di elaborazione su nodi cluster computer in modo affidabile perché se

nodo fallisce allora il compito viene dato a altro nodo senza dover ricominciare elaborazione.

riassumento:

PeF si occupa di elaborazione flusso di dati da ingresso in uscita.

PeF suggerisce trasfromazione tramite filtri organizzati in pipeline. Filtri fanno

trasformazione e pipe gestiscono sincronizzazione, bufferizzazione e sostengono affidabilità

trasformazione e si accollano accoppiamento. 151

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

MODEL-VIEW-CONTROLLER

MVC: modello vista controller

Molto usato per sistemi interattivi dotati di interfaccia utente.

Contesto

un’applicazione interattiva, con un’interfaccia utente (UI) flessibile

flessibile in molti sensi (guarda problema sotto)

Problema

le UI sono soggette a richieste di cambiamento frequenti (esperienza dice che richieste

• cambiamento più frequensti riguardano presentazione ed UI. Modifice UI devono

applicarsi senza degradare altre qualità del sistema.)

cambiamenti nell’UI non devono ripercuotersi sulle funzionalità di dominio (devono

• limitarsi a elementi di strato di presentazione)

UI personalizzabile (perché si vuole che dati si visualizzano in modo diverso e che

• utente possa interagire con applicazione in modo diverso – mouse, tastiera, touch ecc..)

Soluzione MVC:

suddividi l’applicazione in tre parti: modello (elaborazione all’interno del sistema),

• controller (gestione input dato da utente) e viste (output ovvero presentazione dato a

utente)

il modello incapsula le funzionalità dell’applicazione, in modo indipendente dalla

• specifica UI (in MVC c’è solo un modello ma molti viste e controller. Le funzionalità si

implementano nel modello indipendentemente da interfaccia utente. Se vogliamo che

sforzo di sviluppo e manutenzione sia minimizzato sulle funzionalità, queste devono

essere definite una volta sola indipendentemente da presentazione.

per ogni aspetto del modello che deve essere presentato nella UI, introduci una o più

• viste (ogni vita presenta a utente dati specifici in modo specifico. Se ci sono più dati

vanno usate più viste. Se stessi dati devono essere presentati in modo diverso 152

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

occorrono più viste. Ese: dati statistici in formato tabellare e poi in formato grafico. Se

app deve visualizzare info su utente, queste info saranno gestite da altra vista.)

associa a ogni vista un insieme di controller, che ricevono l’input dall’utente e ne

• delegano la gestione al modello (un controller si può occupare di modifica vista dati

con mouse e altro per visualizzazione touch. Controller deve delegare esecuzione al

modello, quindi il controller interpreta solo la richiesta utente e la comunica)

collega modello, viste e controller mediante un meccanismo di propagazione dei

• cambiamenti (meccanismo notifica di eventi si può basare su observer (vedi design

pattern) per garantire coerenza elementi. Ese: dati visualizzati in più modi e utente

chiede di visualizzare dati interagendo con un controller, i dati devono essere

aggiornati in modo da avere stesse info. Così si garantisce coerenza tra elementi.

Figura sotto esempio applicazione MVC

Sulla destra abbiamo il modello.

Vista visualizza dati a utente

Controller gestisce richieste input dell’utente.

Insieme di viste e controller formano interfaccia utente

Interazione:

utente interagisce con controller che capisce richiesta e delega esecuzione a modello

invocando una funzione. Modello può modificare dati che gestisce. La modifica di dati deve

essere notificata. I cambiamenti sono notificati a tutte le viste e controller. Sulla base di

observer ogni elemento reagisce alla notifica.

conseguenze:

- UI flessibile: più visualizzazione stessi dati e più modi di fruire delle funzionalità

- Complessità: si hanno molti elementi e va gestita propagazione notifica eventi. Ma

complessità gestita con framework MVC

- molti framework basati su MVC o su qualche sua variante (ese MVP – model view

presenter) 153

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

Lez.20 - Stili architetturali (terza parte)

SHARED REPOSITORY

Deposito condiviso. Deposito inteso come deposito di dati.

Stile molto diffuso soprattutto se repository è DB condivisa.

Contesto e problema

un sistema guidato dai dati (sistema composto da più componenti o applicazioni in cui

• il ruolo dei dati è molto importante.)

le interazioni tra componenti non sono guidate da processi specifici, ma dipendono dai

• dati su cui operano

insieme di componenti che devono interagire ma per qualche motivo non è bene che questi

elementi interagiscano direttamente. Possono quindi agire su dati che condividono.

Ese: commercio elettronico. Applicazione per cliente per ordini e applicazione per

organizzazione per evasione ordini a clienti.

Ese: cliente ordina prodotto già presente in magazzino – caso facile. Se invece non è presente

in magazzino, per evadere ordine occorre attendere fornitura in magazzino.

Come interagiscono applicazioni: ogni app interagisce con tutte applicazioni con cui deve

condividere dati. Ese: applicazione che consegna prodotti interagisce con app gestione

magazzino e ordine clienti. Ma spesso queste interazioni non sono accettabili. Allora soluzione

proposta è che le app agiscano mediante repository.

Soluzione

mantieni i dati in un repository condiviso dai vari componenti (diversi componenti

• interagiscono indirettamente tramite intermediario reposiroty) 154

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

fa guidare la logica applicativa dalla disponibilità, qualità e stato dei dati nel repository

• (disponibilità intesa come presenza dati in repository)

la soluzione suggerisce repository condiviso con info. Quando ordine ricevuto questo viene

messo in repository, quando questo viene mesos in repository, allora altre app possono essere

notificate dell’evento e quindi applicaizone per evasione ordini può essere notificata, così

verifica in magazzino e in caso evade ordine direttamente

quando fornitori consegnano in magazzino, viene notificato dal repository alle app.

anche qui le app devono interagire fra loro ma interagiscono scrivendo/leggendo dati in

repository o venendo notificate da cambiamento di repository.

Figura sotto illustra funzionamento shared rep.:

diverse app del sistema. Una per ricezione e consegna prodotti fornitori, un'altra app per

evasione clienti. Dati condvisi in repository, quando vengono ricevuti articoli da fornitore

questa info viene messa in repository e repository notifica altra app che può quindi consultare

le info..

discussione:

- integrazione di elementi guidata da dati (interazione tra elementi può essere guidata

anche da processo business che ci dice quale Wf occorre seguire, ma a volte questo è

difficile perché molto complesso. Allora si fanno interagire le app tramite shared

repository.

- Shared DB è caso particolare di shared repository

- Accesso al repository (conoscere modalità di accesso al repository da parte di app. se ci

sono operazioni complesse delle applicazioni, allora meglio usare DB relazionale.

Senno si può usare un repository in memoria o altra forma di repository per collegare

elmenti evitando cosi overhead dato dai RDB)

- Notifica dei cambiamenti (ad esempio basato su observer. In RDB le notifiche sono

gestite da regole attive o trigger. Applicaizoni specificano quali notifiche vogliono

ricevere.

Conseguenze:

- sostiene modificabilità: applicazioni future si integrano facilmente grazie a presenza di

repository. A volte app deve gestire nuove info allora occorre cambiare struttura dati

155

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

in repository. È bene che ci sia uno schema logico del repository così da tenere basso

accoppiamento vs il repository. Può accadere che sia necessario modificare le altre app

a seguito di introduzione nuova app.

- buona Affidabilità: soprattutto se questa gestita centralmente dentro repository con

backup recovery e gestione transazioni come in RDB

- pericolo di basa sicurezza: poiché tutti i dati sono solo in repository la sicurezza può

degradarsi

MICROKERNEL

Piccolo kernel o piccolo nucleo

Contesto

applicazione adattabile a diversi scenari di deployment (stessa app che in istallazione

• in sede di rilascio diverso si deve comportare in modo leggermente diverso)

Problema

si devono realizzare versioni multiple di un’applicazione (ci sono molte app in versioni

• multiple. Famiglia di applicazioni o famiglie di prodotti (enterprise, professional ecc.)

si vuole minimizzare lo sforzo di sviluppo ed evoluzione delle diverse versioni

• dell’applicazione (rappresentare ciascuna funzionalità in un solo posto così da pagare

costo funzionalità una volta sola e così che se occorre modificare funzionalità, si

possono modificare in un posto solo. Avere stessa architettura con più cose comuni

possibili) 156

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

Soluzione

componi le diverse versioni dell’applicazione come estensione di un nucleo comune ma

• minimale, tramite un’infrastruttura “plug-and-play” (diversi elementi: microkernel,

server interni e de esterni. Microkernel definisce funzionalità comuni a tutte le app e

favorisce possibilità di estendere funzinalità con alcune aggiuntive per altre versioni

della app, quindi fornisce servizi infrastrutturali)

il microkernel implementa le funzionalità condivise da tutte le versioni della app (che

• vengono scritte una sola volta)

inoltre fornisce l’infrastruttura per estendere le sue funzionalità alle funzionalità della

• app e della famiglia della app. (estensione funzionalità avviene con due elementi server

interni e esterni)

ciascun server interno implementa funzionalità auto-contenute, di interesse per una o

• più versioni (funzionalità aggiuntive di ogni versione sono implementate in server

interno diverso)

ciascun server esterno implementa la UI o un’API specifica per una versione della app

• (server esterni non implementano funzionalita aggiuntive ma si occupano di

interazione con utente UI o con altri sistemi informatici API

ciascuna versione dell’applicazione è realizzata connettendo il microkernel (unico per

• uttte le versioni) con i server interni e i server esterni corrispondenti (posso avere

molte versioni, unico microkernel e combinazione diversa di server int/ext

figura sotto:

al centro microkernel, dx server interni e sx server esterni + utenti app.

microkernel: 2 respo

implementare funzinalità comuni a tute le app (funzioni 1 e 2)

register servizi e funzionalità e espone interfaccia per registrare servizi e funzionalità

aggiuntive.

server int: funzionalità aggiuntive. Collegato a microkernel per servizi aggiuntivi.

Server esterni: UI e API

Utenti interagiscono solo mediante server esterni e inoltrano richieste a interfaccia del

microkernel. Ese: richiesta funzinalità 1 e microkernel vede chi deve gestire quella

funzionalità. In questo caso è microkernel che svolge il servizio. Se invece si richiede la 3

allora il microkernel consulta registry per capire chi fornisce la funzionalità 3 e poi gira la

richiesta al server interno di competenza. 157

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

discussione:

- gestione di versioni multiple di un’applicazione

- realizzazione di una nuova versione

- lo sforzo di sviluppo e manutenzione è minimizzato

Architettura di Eclipse:

basato su microkernel.

Ci sono varie versioni di Eclipse, alcune per java e alcune per C.

La sua architettura è basata su variante di microkernel chiamata plug-in.

Alcuni plugin sono sviluppati in ambito di progetto eclipse ma altri servizi sono forniti da 3e

parti. i plugin di eclipse corrispondono a server interni ed esterni. Il platform runtime è simile

a microkernel ma implementa solo infrastruttura per plugin ma non implementa nessuna

funzionalità.

Plugin sono memorizzati in opportuna cartella e poi abilitati durante esecuzione

dell’applicazione. 158

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

REFLECTION

Riflessione: capacità di sistema sw di eseguire elaborazioni che riguardano struttura interna e

comportamento del sistema. Si chiama anche introspezione.

Contesto

un sistema che deve consentire variazioni funzionali, anche a runtime

Problema

il supporto per le variazioni è fondamentale nelle applicazioni di lunga vita (le app di

• lunga vita sono app di successo e devono essere flessibili per cambiare quando

necessario.)

è difficile prevedere a priori le modifiche specifiche e quando dovranno essere

• applicate (spesso possibile identificare tipologie geenrali di modifiche da fare e questo

159

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

può essere sufficiente per gestire modifiche. Però si parla di modifiche anche a runtime

quindi si possono fare solo se c’è opportuna preparazione)

Soluzione proprietà̀

rappresenta esplicitamente le variabili del sistema, mediante un insieme di

• meta-oggetti (metadati. Sono punto di variazione del comportamento del sistema. Da

punto vista metodologico identifichiamo metadati vedendo comportamento sistema di

base senza variazione poi si vedono variazioni e si chiede quali variazioni funzionali

possono essere applicati. Variazioni indicati come parametri dei metadati)

suddividi il sistema in due parti principali: un meta- livello e un livello base

• (metalivello è livello di metadati e dice comportamento attuale. Livello base è come

sono implementate funzinalità. sono Parti non indipendenti )

connetti il livello base con il meta-livello, in modo che cambiamenti nei meta-oggetti

• influiscano sul comportamento del sistema (utente richiede esecuzione funzionalità a

livello base che eroga funzionalità. Ma quando ci sono variazioni il livello base delega al

metalivello la fornitura del servizio)

fornisci un protocollo per amministrare dinamicamente i meta-oggetti (meta object

• protocol che è usato direttamente da utente per cambiare comportamento sistema

oppure gestito da amministratore sistema per effettuare cambiamenti)

figura sotto è soluzione di reflection:

2 livelli principali

livello base e metalivello

metalivello: fatto da Meta oggetti che definiscono comportamento attuale

utente richiede funzionalità, quando ci sono punti variazioni si interagisce con metalivello per

capire qual è il comportamento desiderato.

Amministratore interagisce con meta object protocol per modificare comportamento sistema

Quando si chiede di nuovo stessa funzione questa potrebbe essere eseguita in modo diverso in

accordo all’ultimo cambiamento effettuato.

figura sotto:

catalogo sistema è dizionario di sistema con metadati che danno info su DB. Ese: quali tabelle,

colonne, indici ecc. questi dati hanno impatto su modo in cui dati vengono rappresentati in

160

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

base di dati. Frecce sono dipendenze e dicono che molti elementi sono dipendenti da system

catalog

metadati possono cambiare nel tempo perché amministratore può scegliere di avere nuove

tabelle, nuovi dati ecc..

conseguenze:

- sostiene modificabilità: ammesso che tipi di modifiche sono previste e rappresentate in

metadati in fase iniziale di costruzione del sistema. Se modifiche non sono identificate

prima allora occorre cambiare codice implementarlo e cc..

- complessità: giustificata solo per sistemi di lunga durata. Molti sono i sistemi basati su

reflection come RDB, molti linguaggi di programmazione ecc…

- prestazioni basse: si richiede consultazione metadati in metalivello e si introduce

overhead che peggiora prestazioni. 161

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

Lez.21 - Connettori e middleware

Connettori sono elementi sw utili per interconnettere altri elementi

Middlw insieme tecnologie utili per i connettori nei sistemi distribuiti

CONNETTORI

Elementi sw di sue tipi

- componenti

- connettori

Tipi di elementi software

Questa distinzione ha motiviazione di separazione di interessi (componenti > interesse

funzionali e responsabili di qualità come affidabilità, disposnibilità e scalabilità)

Connettori sono resp di relazioni tra elementi.

Sono entrambi elementi sw quindi occorre progettare sviluppare e valutare il codice oppure

vanno acquisiti.

componenti, responsabili di funzionalità e dati

• connettori, responsabili delle interazioni tra componenti

Esempi di componenti

un modulo (componente di natura statica. Insieme di codice package o di classi)

• un processo (componente sw di natura runtime.)

• un componente di una tecnologia specifica (java enterprise edition, dotnet o

• webservice)

una base di dati

Esempi di connettori – realizzano interazione comunicazione tra componenti

una chiamata locale (la chiamata di un sottoprogramma – invocazione – che fa

• connettere dei moduli, chiamata fatta localmente in un singolo processo e non riguarda

processi e pc distinti)

una chiamata remota (estende chiamata locale a contesto distribuito in cui diversi

• moduli sono in esecuzione in processi diversi. È connettore complesso e utile. Realizza

interazione richiesta risposta di tipo sincrono perché il chiamante si blocca finche

chiamato non esegue)

l’invio di un messaggio (comunicazione comune tra componenti sw in cui

• comunicazione è unidirezionale – senza attesa risposta. È comunicazione asincrono

perché chi invia messaggio non aspetta risposta)

l’accesso a una base di dati da parte di componente (connettori gestiscono interazioni

• tra componenti)

Motivazioni

la progettazione dei connettori è importante quanto quella dei componenti (alcuni

• connettori consentono di supportare alcune qualità del sistema. Qualità che non

devono essere considerate in ambito dei componenti – quindi vera separazione

interessi. In effetti ci sono sistemi di integrazione nel cui sviluppo si realizza

soprattutto connettori mentre non è necessario realizzare componenti. 162

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

la progettazione dei connettori può essere separata da quella dei componenti (grazie a

• una sostanziale indipendenza tra aspetti computazionali – componenti – e quelli di

interazione – connettori. Realizzazione connettori è come cablaggio in edificio per

trasmissione corrente elettrica. Si ritiene che non sono importanti ma quando c’è

guasto capiamo importanza tubature… i connettori sono ugualmente improntanti.)

i connettori sono tipicamente indipendenti dalle applicazioni (mentre i componenti

• sono specifici a dominio applicativo e poco riusabili in sistemi diversi, i connettori

definiscono paradigmi e possono essere generalizzati e riusati in contesti diversi)

caratteristiche dei Componenti

luogo della computazione e dello stato (responsabili di funzionalità)

• ogni componente ha un tipo (tipo di elementi può essere previsto da stile

• architetturale – strato, filtro ecc…)

ogni componente ha una specifica di interfaccia (xon cui altri componenti possono

• interagire. Specifica interazioni possibili, messaggi che può ricevere/inviare e può

indicare alcune qualità del componente come prestazioni. Può prevedere ruoli con ci

quel componente può interagire. Ese: interfaccia per essere server o client nei

confronti di servizio. Essere client o server per un servizio sono ruoi svolti da

componenti)

caratteristiche Connettori

luogo delle relazioni tra componenti

• ogni connettore ha un tipo (tipo deriva da stile architetturale. Ese: pipes sono

• connettori.)

ogni connettore ha una specifica di protocollo (una specifica di protocollo che ha scopo

• di specificare alcune caratteristiche della interazione realizzata da connettore ese: tipo

di ruoli che può collegare come sulla base di protocollo richiesta risposta… può

specificare le qualità di cui il connettore si prende carico. Ese: connettori si può

occupare di affidabilità della comunicazione o della sicurezza: dati trasmessi in forma

cifrata. Quindi specifica di connettore può assumeresti responsabilità relative ad

alcune qualità)

i componenti vengono composti mettendo in relazione i ruoli dei componenti con i

• ruoli dei connettori (ruoli di componenti con ruoli connettori sono interfacci dei

connettori. I componenti sono composti mediante uso di connettori. Ese: in pipes e

filter i componenti sono i filtri che hanno ruoli di ingresso e uscita mentre pipe è

connettore che connette uscita e ingresso di componenti successivi. Figura sotto

mostra composizione coppia filtri tramite pipe) 163

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

una stessa tipologia di connettore può essere implementata in modi diversi, per

• sostenere qualità differenti (aspetto improntante. Ogni connettore a tipologia. Molti

connettori possono avere stessa tipologia di comunicazione in modi diversi. Ese:

comunicazione remota (richiesta risposta) implementato in modo sicuro o meno.

Alcune implementazione di pipes di junix che sono meccanismo comunicazione inter

processo in ambito singolo computer quindi no processi remoti. Netcat invece collega

pipes e filtri in esecuzione in processi e pc diversi.)

Ruoli svolti dai connettori- ogni connettore può svolgere uno o più dei ruoli sotto:

Comunicazione (trasmettere dati, info , messaggi, richieste, risposte ecc)

• Coordinamento (trasmettere controllo. Come chiamata remota, controllo trasferito da

• chiamante a chiamato)

Conversione (componenti interagenti sono eterogenei e quindi occorre convertire

• formati dei messaggi scambiati)

Facilitazione (gestire aspetti comunicazione come la gestione della sincronizzazione o

• distribuzione del carico)

Tipi di connettori:

- chiamata di procedura (locale ma anche remota- richiesta risposta sincrono)

- scambio messaggi: unidirezionale asincrono

- accesso ai dati: per consentire a componente di accedere ai dati di DB o repository

- collegamento: attività preparatoria alla comunicazione con altri componenti. In

microkernel questo deve conoscere server interni e questa conoscenza è forma di

collegamento.

- Flusso: connettori composti con altri connettori per avere connettori composti

- Arbitratori: prevengono conflitti tra componenti come gestione transazioni distribuite

- Adattatori: trasformano formato messaggi scambiati tra componenti

- Distributori: instradamento messaggi e info tra componenti sulla base dei nomi

simbolici tra componenti

Spunti:

cos’è un connettore?

Perché progettazione connettori è importante?

MIDDLEWARE

Insieme tecnologie e strumenti realizzati in realizzazione connettori in ambito sistemi

distribuiti.

Motivazioni

i connettori sono complessi da sviluppare, verificare e far evolvere (se connettore deve

• svolgere più ruoli o sostenere diverse qualità. Riguardano sistemi distribuiti e

coinvolgono affidabilità, guasti, sincronizzazione ecc…)

diversi connettori di uso comune sono stati generalizzati (prima quando si necessità di

• nuovo connettore questo si implementa ex-novo. Poi se questo è utile lo si generalizza

definendo framework per avere strumento di middelware. Questi sono strumenti sw in

commercio. Per questo si diceva che i connettori possono essere sviluppati o acquisiti.

Perché questi possono essere comprati.) 164

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

figura sotto:

architettura strati. Base abbiamo HW, sopra abbiamo sw di base come OS cioè piattaforma in

esecuzione per il sw.

Poi abbiamo servizi da sviluppare, questo sw è distribuito con diversi componenti che devono

interagire e che lo fanno usando servizi di base offerti da OS per la comunicazione come

protocolli di rete o pipes o socket ma tipicamente questi sono troppo difficili da usare per

implementare connettori quindi si usa uno strato sw chiamato middelware utile per sistemi

distribuiti. In mezzo a sistemi applicativi e piattaforma. È un paradigma che si pone tra app e

piattaforma e fornisce trasparenza e indipendenza da piattaforma e consente interazione tra

componenti app e servizi su piattaforme diverse.

figura sotto

ruolo middelware in sistema distribuito. Sistema fatto da più componenti con più pc ognuno

con propria piattaforma.

Middleware sta in mezzo tra piattaforma e componente e anche in mezzo tra i due pc. 165

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

caratteristiche improntanti middleware:

- strato sw che fornisce astrazione distribuita (nasconde alcuni dettagli allo sviluppatore

perché se ne occupa direttamente e quindi semplifica la vita dello sviluppatore e tempo

sviluppo)

- può sostenere alcune qualità (come sicurezza, affidabilità e scalabilità. Diciamo “può”

perché non si sostengono tutte le qualità insieme. Ogni middlw ne sostiene una o un

po’)

- può mascherare alcune eterogeneità degli elementi coinvolti (eterogeneità inevitabili

in sistemi distribuiti.)

ogni middleware può offrire trasparenza (capacità strumento di mascherare la necessità di

dipendere da alcuni dettagli perché è il middlw che gestisce quei dettagli.

- Accesso: componente può accedere a servizio o risorsa indipendente dal fatto che la

risorsa è locale o remota

- Locazione: dipende solo da tipo servizio e non da localizzazione

- Concorrenza: risorsa acceduta in modo concorrente da più componenti e questi non

devono risolvere conflitti e neanche la risorsa li deve gestire

- Replicazione: se la risorsa è replicata o meno i componenti la devono accedere allo

stesso modo

- Fallimenti: middlw si occupa di trasmettere messaggi in rete

- Mobilità: spostarsi in pc della rete e senza modificare componenti

- Prestazioni e scalabilità: se risorse possono essere riconfigurate per sostenere

prestazioni e scalabilità senza che chi usa le risorse debba essere modificato per

fruirne.

Un esempio:

realizzazione connettore per chiamata di procedura remota (remote procedure call – RPC)

figura sotto:

2 moduli X e Y. è diagramma sequenza con tempo da alto vs basso.

In modulo X si vuole chiamare esecuzione sottoprogramma Y.

Y restituisce risultato e poi controllo torna a X.

In procedura locale avviene tutto in un singolo processo. 166

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

in procedura remota X e Y sono in esecuzione in processi diversi.

Quando X vuole chiamare Y si può incapsulare chiamata in messaggio in rete che rappresenta

chiamata.

X trasmette richiesta a Y in ambito altro processo, questo capisce richiesta fa in modo di

eseguire Y e risultato di Y viene incapsulato in messaggio risposta che viene estratto da primo

processo e poi controllo torna a X.

Si può fare connettore scrivendolo da zero o usando un middleware di tipo RPC.

RPC:

prevede uso di diversi elementi:

- interface definition language (IDL) linguaggio per definizione di interfaccie: usato per

definire interfaccia del sottoprogramma da invocare. In esempio sopra interfaccia di Y.

quali operazioni definite da quel module insieme ai tipi rilevanti per quell’operazione.

IDL può essere linguaggio programmazione noto o più generale. Il programmatore

definisce X e Y modulo chiamato e chiamante e definisce interfaccia modulo chiamato

mediante IDL.

- Compilatore di interfaccie che da luogo a due moduli generati da compilatori chiamati:

167

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

- Stub e skeleton. Stub usato in X senza essere usato. Skeleton è modulo da modificare

che va usato da lato del chiamato Y. X chiamerà lo Stub pensando di chiamare Y.

- Supporto runtime in comunicazione distribuita:.

Figura sotto:

diagramma di seguenza per interazione RPC:

in modulo X chiamata a Y scritta come chiamata locale. Come se si chiama direttamente Y ma

la chiamata va allo stub. Questo riceve comando di eseguire operazione Y.

la linea zigzag indica confine tra processi. Comunicazione stub skeleton è comunicazione tra

più processi. Messaggio richiesta inviato in rete e ricevuto da skeleton che estrae contenuto,

capisce chiamata desiderata, fa chiamata locale a modulo Y che esegue funzionalità richiesta.

Questa viene data a skeleton che la impacchetta invia in rete e ricevuta da stub che estrae

contenuto e lo riferisce a X.

X ha fatto chiamata locale che causa chiamata remota. Y riceve chiamata locale e risponde

localmente.. X e Y interagiscono fra di loro anche se sono remoti come se fossero elementi

locali.

In realtà interazione RPC può essere più complessa di questa perché i messaggi inrete

possono perdersi a causa inaffidabilità della rete e quindi stub e skeleton ppossono sopperire

a questo ripetendo trasmissione messaggi persi per garantire affidabilità comunicazione.

tecnologia RPC nata in anni 90 nei contesti client server.

Discussione:

- il middleware consente di sostener comunicazione fra componenti tra sistemi

distribuito. Utile comprendere relazione middleware e stili architetturali: utile capire

ogni strumento middleware quale stile può sostenere e per ogni stile quale

middleware può semplificarlo. Capire funzione middleware è importante perché certi

aspetti non possono essere ignorati quando si prendono decisioni di progetto.

- Il middleware risolve problemi di comunicazione di sistemi distribuiti e di supporto ad

alcune qualità

- Middleware non risolve tutti problemi se usatto non modo sbagliato crea problemi: ese

non si può sostituire ogni chiamata locale con una remota per via di problemi di 168

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

prestazioni. Bisogna capire che chiamata remota può porre problemi di prestazioni

affidabilità e sicurezza ecc. scelta middelware va fatta in modo opportuno. Solo

conoscenza approfondita del middleware può dare benefici senza avere conseguenze

negative date dall’uso inappropriato del middelware.

Lez.22 - Architettura dei sistemi distribuiti

INTRODUZIONE AI SISTEMI DISTRIBUITI

Molti sistemi sono distribuiti…

Definizione di Sistema distribuito

un sistema software in cui un numero di componenti coopera comunicando in rete

sistema con molti componenti che sono in esecuzione su più pc remoti connessi in rete. La

comunicazione avviene con messaggi in rete escludendo la memoria condivisa.

Sistema in cui un pc che non conoscevo a reso inutilizzabile il mio pc.

> difficile garantire certe qualità e difficile verificarle.

Benefici

sistemi inerentemente distribuiti (come sistemi di cooperazione, social network, siti

• web, app business to business che mettono in contatto sistemi informatici di

organizzazioni diverse)

condivisione di risorse (risorse di diversa natura. Risorse informative di dati condivisi

• o risorse informatiche come servizi o risorse hw come condivisione stampante)

prestazioni, scalabilità, tolleranza ai guasti (prestazione come distribuzione carico su

• pc, scalabilità come gestire carichi maggiori e guasti basati su uso ridondanze)

economicità (spesso più economici rispetto a sistemi centralizzati come main frame)

• apertura (spesso basati su protocolli aperti come quelli definiti in web per

• interoperabilità tra piattaforme hw e sw diversi)

Svantaggi e rischi

complessità (sono più coplessi dei sistemi non distribuiti. Si pensi a gestione

• transazione mediante base di dati su singolo pc Vs sistema distribuito)

controllo delle qualità (controllare qualità o verificarne supporto. Ese: sicurezza che è

• problema tipico in sistemi distribuiti) 169

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

ipotesi errate (è comune fare ipotesi errate come la rete affidabile, latenza zero, banda

• disposizione infinita, rete sicura, presenza amministratore che risolve tutti i problemi

ecc.. sono tutte ipotesi false in sistemi distribuiti)

utilizzo di metodi e tecniche non adeguati (ese: spesso vengono studiati metodi per

• sviluppo sw monothread che non sono adeguati per sistemi distribuiti con ampia

concorrenza. O usare modo inappropriato tecnologia di middleware come chiamata

remota gestita come chiamata locale)

in generale sviluppo sistemi distribuiti cerca di raggiungere i suoi benefici minimizzando

svantaggi.

Spunti:

cos’è sistema distribuito?

quali i benefici e rishci?

STILE CLIENT-SERVER

Molto diffuso in sistemi distribuiti

Contesto

il sistema deve fornire l’accesso a risorse e/o servizi condivisi a un insieme di client

• distribuiti

due caratteristiche:

- condividere risorse (info, servizi, funzionalità o risorse hw)

- insieme di cliente in rete che vogliono accedere alle risorse

Problema

consentire l’accesso a risorse e/o servizi condivisi

• sostenere qualità come scalabilità e disponibilità (si aumenta risorse a disposizione e

• replicandole per distribuire carico su risorse e fare che se si guasta una risorsa si può

usare una ridondanza)

sostenere riuso e modificabilità (gestione centralizzata di risorse per modificare

• servizio in un solo posto e tutti i client fruiscono del miglioramento)

Soluzione

organizza il sistema come un insieme di servizi, server e client (tre elementi di questo

• stile. Servizio è centrale e rappresentato da interfaccia del servizio.)

ciascun servizio è caratterizzato da un’interfaccia, basata su un protocollo richiesta-

• risposta (servizi sono centrali, normalmente in questo stile accesso a servizio avviene

con interfaccia procedurale. Su base protocollo sincrono richiesta risposta)

un server è un componente (o processo) in grado di erogare uno o più servizi (che

• quindi implmementa uno o più servizi. Server è componente runtime di processo. In

questa terminologia server non è un pc ma è elemento sw)

un client è un componente runtime sw (processo) interessato a fruire di uno o più

• servizi da parte di uno o più server

i client richiedono servizi ai server (i server normalmente non svolgono lavoro ma

• svolgono lavoro solo su richiesta client che richiedono servizi a server) 170

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

ci possono essere molti client concorrenti (numerosi client anche tantissimi e

• implementazione server non deve dipendere da caratteristiche client e loro numero

così che in ogni momento si può aumentare numero client che fruiscono del servizio)

alcuni componenti possono agire sia da server (di alcuni servizi) che da client (di altri

• servizi) (la relazione client server è fra coppie di componenti ma componente può

avere ruoli diversi perché può essere server di un servizio ma per erogarlo può avere

bisogno di servizio di un altro componente) organizzazione servizi è gerarchica e

annidata e quindi i server sono organizzati in modo gerarchico.

Servizio da server a client. Ovale = processo runtime

Rettangoli = pc.

Freccia = servizio

servizi offerti in modo concorrente.

i client e server sono in modo gerarchico.

Server per erogare servizi può diventare client per un altro server.

Nello stile client server c’è organizzazione servizi gerarchica o detta anche a livelli.

Ogni livello è insieme funzionalità coese (insemee client o server) in una dipendenza alto vs

basso come architettura a strati. Infatti client server è caso specifico di architettura a strati.

171

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

in client server i server possono essere replicati. Possono esserci più processi in esecuzione su

più pc che erogano stesso servizio. Possono esserci connettori per gestire carico. Client

richiede tramite connettori che gestiscono richiesta a server che sono in grado di erogare

servizio.

Si usa di solito middleware per ottenere qualità come scalabilità – per gestione carico – e

affidabilità – perché ridondanza sostituisce server guasti.

molti servizi internet sono client server (come posta elettronica)

possono essere collo di bottiglia se non c’è replicazione servizi. Stile può avere problemi di

distribuzione come sicurezza e comunicazione remota… 172

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

stile CS e livelli:

livello è gruppo nodi o pc in cui è distribuito il sistema CS.

Un sistema CS può organizzarsi come sequenza livelli.

Le responsabilità assegnate a diversi livelli. Ogni livello ha insieme responsabilità coese per

gestire servizi di tipo coeso.

Spesso CS ha anche propria organizzazione a strati. Magari il codice è a strati e la vista di

rilascio organizzata secondo CS. Opportuni considerare relazione tra strati e livelli…

Andiamo ora a discutere architetture a livelli con codice organizzato a 3 strati: presentazione,

logica applicativa e gestione risorse e dati.

figura:

architettura a 2 livelli:

cliente sottile: ha solo presentazione con utente

server: logica applicativa e gestione risorse.

Questa è la prima CS introdotta in anni 80 i client dipsnibili erano PC con capacità

elanorazione scarse e quindi avevano solo responsabilità di presentazine ma il server ha tanto

carico e quidni poco scalabile 173

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

figura sotto:

cliente ha presentazione e logica applicativa.

Il client è thick invece che sottile e quindi client ha capacità migliore. Si riduce carico de

lserver e si ha quindi scalabilità migliore ma se server è implementato in singolo pc ci sono

sempre problemi di scalabità.

figura sotto:

3 livelli:

client per presentazione

server intermedio (application server) per logica applicativa

e server per gestione dati e risorse

distribuzione migliore di carico.

Architettura complessa che usa middleware anche con implementazione distribuita dei livelli

server per sostenere scalabilità e disponibilità. 174

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

figura sotto

join enterprise edition:

4 livelli

1 client

2 per logica applicativa intermedia

1 livello per gestione dati risorse e altri sistemi informatici.

Numero maggiore di componenti aumenta complessità e richiede middlw sofisticati ma offre

flessibilità per realizzare applicazioni.

tipi di servizi:

- un servizio è stateful se mantiene informazioni sulle conversazioni – sessioni – con i

propri client (con stato): client interagisce con servizio richiedendo operazioni in

sequenza e bisogna considerare effetto operazioni precedenti. Ese: aggiungere

prodotto in carrello spesa in commercio elettronico quindi occorre mantenere info su

stato conversazione per avere info su prodotti aggiunti prima

- altrimenti è stateless (senza stato): ese: se chiedo previsioni tempo a milano domani è

indipendente dal fatto che ho chiesto previsioni a roma prima. 175

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

Stateful sono più complessi e hanno bisongo di middleware sofisticato e hanno problemi di

scalabilità

Ulteriori considerazioni

la comunicazione di solito è asimmetrica e sincrona (asimmetrica perché iniziata da

• client e proseguita da server e sincrona perché client rimane in attesa del server)

ma talvolta sono possibili chiamate asincrone, notifiche e callback (rompono vincoli

• comuni. Client fa richiesta ma non attende risposta. Si attendono notifiche da server a

client. Callback operazione da parte del client richieste da server)

STILE PEER-TO-PEER

Stile diffuso in sistemi file sharing soprattutto.

Contesto

un insieme di entità computazionali distribuite possono collaborare per fornire servizi

• a una comunità di utenti distribuiti

insieme di entità computazionali che condividono risorse. Risorse sono capacità memoria o

capacità di elaborazione o gestione risorse informatiche. Queste entità collaborano per servire

servizi. Possono anche essere Client che appartengono a insieme esterno a quello delle entità

che condividono risorse

Problema

organizzare un insieme di entità computazionali distribuite per condividere le loro

• risorse o servizi

le entità sono tra loro “equivalenti” (sono dei pari. In senso che entità hanno bisogno di

• servizio ma in altri momenti sono loro stessi disposti a dare servizio. Quindi non c’è

gerarchia di richiesta servizi. Nessuna entità è più importante delle altre.)

sostenere scalabilità e disponibilità (Scalabilità come gestione client maggiori o risorse

• maggiori. Disponibilità è fornire accesso a risorse e servizi anche se guasto di alcune

entità)

soluzione

organizza il sistema come un insieme di componenti che interagiscono tra loro come

• “pari” (peer) (un solo tipo di elementi che sono i peer. Ogni peer gestione risorsa e

fornisce accesso a risorsa o eroga servizio)

connetti i peer sulla base di un protocollo comune, facendoli comunicare sulla base di

• interazioni richiesta-risposta (un protocollo comune significa che tutti i peer hanno

stesso unico protocollo. In CS invece ci sono protocolli diversi. Interazioni sono

richiesta risposta ma non come CS perché peer può fungere da client e da server in

interazioni diverse)

figura sotto:

peer to peer. I peer son ocomponenti sw ovali in esecuzione su pc diversi (rettangoli).

Le freccie sono relazioni di conoscenza (adiacenza) relazioni virtuali. Freccie bidirezionali

perché interazioni tra peer sono tra pari quindi peer può fare o ricevere richieste da altri peer.

176

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

È sistema che gestisce risorse come file (A, B, C) ogni peer offre risorse per memorizzare e

condividere file. Ese: risorsa A può essere replicata e distribuita su più nodi. Un certo peer

può essere interessato ad accedere a risorsa A tramite accesso a peers.

scenari sono interazioni possibili in uno stile architetturale:

- avvio peer: quando viene nuovo peer, questo contatta altro peer che conosce e chiede a

questo delle info su altri peer in modo da poterli contattare e poi li contatta per dire

quali sono le sue risorse che può condividere.

- Richiesta di una risorsa o servizio: peer fa richiesta a peer che conosce direttamente se

questi hanno risorsa gli danno accesso a risorsa, senno la richiesta si propaga finche

non si incontra peer che ha risorsa. E questo viene messo in contatto diretto con peer

richiedente. Un peer può richiedere risorsa e ottenerla da altro peer o dare risorsa a un

altro peer

- Rimozione peer: le capacità computazionali di quel peer vengono rimosse dal sistema e

quelle risorse non sono più accessibili a meno che risorse non sono state replicate. Di

solito si usano pc di un cluster di data center in peer to peer.

- Reti controllate di peer: peer non si rimuovono da soli a meno che non ci sono guasti.

Replico file in tutti i peer così non si perdono risorse.

Figura sotto:

scenario di applicazione CS con cliente che vogliono servizio che si implementa da insieme di

server. Questi server sono peer to peer.

Ese: gestione info su cloud computing. Si usano sistemi no sequel che hanno scalabilità e

disponibilità su base peer to peer. 177

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

discussioni:

- peer to peer è diffuso per condivisione risorse di diversa natura

- applicato sia in contesti fortemente decentralizzati (come file sharing) ma anche in

contesti controllati

spunti:

descrivere stile peer to peer

descrivi benefici di questo stile architetturale

Lez.23 – oggetti distribuiti

ARCHITETTURA A OGGETTI DISTRIBUITI

1 Solo tipo di elementi sw che sono gli oggetti distribuiti. Passo intermedio vs architettura a

componenti.

In un programma OO ogni oggetto incapsula stato e comportamento.

Ogni oggetto ha interfaccia che è insieme operazione che oggetto sa definire. Ogni oggetto ha

riferimento univoco in ambito processo in cui oggeto risiede.

Un programma è formato da inseme di oggeti che risiedono in ambito stesso processo.

Oggetti (non distribuiti)

stato e comportamento à interfaccia

• riferimento

• un insieme di oggetti

Oggetti distribuiti è variante di paradigma a oggetti.

Ci sono oggetti remoti che possono chiedere remotamente a altri oggetti di eseguire

operazioni. Ci sono in realtà oggetti remoti e distribuiti.

oggetto remoto

• 178

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

interfaccia remota (insieme operazioni che possono essere invocate remotamente)

• riferimento remoto (univoco in rete. Riferimenti simbolici. Diverso da riferimento

• oggetti tradizionali che hanno invece senso solo nel processo in cui oggetto risiede)

un insieme di oggetti

Architettura a oggetti distribuiti

un insieme di oggetti remoti

• gli oggetti forniscono e richiedono servizi

• oggetti distribuiti in modo flessibile

è stile architetturale con solo tipo di elementi. Oggetti che interagiscono su scambio servizi.

Questo stile è evoluzione stile CS. Maggiore flessibilità in organizzazione servizi. Perché se si

parla di CS si parla di singola interazione mentre in interazioni successive gli oggetti possono

invertire il loro ruolo. È anche possibile che la posizione id un servizio cambi dinamicamente

o che si aggiungono nuovi oggetti distribuiti nel sistema.

Figura sotto:

esempio minimale di architettura Oggetti distribuiti.

Ovali sono processi in cui si eseguono oggetti remoti

Rettangolo grandi sono i PC in cui oggetti risiedono

Rettangoli piccoli sono oggetti.

A richiede remotamente servizio a B e B richiede remotamente servizio a D

oggetti locali vicino a B. in questa architettura ci sono anche oggetti locali. Ogni oggetto

implementa servizio cooperando con oggetti locali che vivono in ambito dello stesso processo.

B viene definito come facade al servizio e questa viene resa remota. In generale oggetti locali e

remoti convivono. In architettura oggetti distribuiti si raggiona in termini di oggetti remoti e

si ignora oggetti locali perché considerati dettaglio implementativo 179

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

figura sotto:

5 oggetti distribuiti progettati come oggetti di dominio e frecce tratteggiate sono dipendenze.

Non è peer to peer perché interfacce di diversi oggetti sono diverse.

Non dice come oggetti sono distribuiti in rete ma è importante capire come sono collocati in

rete.

Broker:

stile in cui elemnti sw sono due tipi: componenti (oggetti distribuiti) e connettori (broker) che

abilita comunicazione remota tra oggetti distribuiti 180

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

figura sotto

ruolo broker in oggetti distribuiti:

broker come bus che consente comunicazione tra oggetti distribuiti

il borker è novità rispetto a CS. Tutte le tecnologie successive si basano su evoluzione idea di

broker quindi importante capire ruolo broker in architettura oggetti distribuiti.

Benefici

architettura aperta, flessibile e scalabile

• è possibile riconfigurare il sistema dinamicamente

• l’incapsulamento favorisce la modificabilità

tecnologie nate in anni 90. Quando sono migliorati protocolli e standard aperti per sistemi

distribuiti (CORBA). Oggetti ridistribuiti dinamicamente per scalabilità e disponibilità.

Accesso a oggetti fatto con modo simbolico o con broker.

Svantaggi e rischi

prestazioni

• complessità

• 181

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

PROXY

design pattern diffuso. Utile per capire pattern broker di cui in seguito.

Affronta problema e propone soluzione.

Problema

l’accesso diretto da parte di un client a un servizio di un componente è possibile, ma è

• inadeguat

per motivi di sicurezza o efficienza, perché il componente è remoto

il client non deve accedere direttamente a servizio perché ad ese: client vuole avere servizio

di un server ma servizio deve essere protetto da credenziali di accesso. Chi deve gestire

accesso? Client no perché può truffare. Server no perché non deve implementare politiche

accesso al servizio. Quindi meglio avere altro elemento responsabile di controllare accesso al

servizo per motivi di sicurezza. Quindi si può avere proxy che verifica credenziali di accesso al

client. Quindi client interagisce con proxy questo verifica credenziali d accesso e poi consente

accesso al server.

Soluzione

il client comunica con un proxy, che è un rappresentante del componente che

• implementa il servizio

nell’accesso al componente, il proxy svolge anche delle funzioni aggiuntive di gestione

• dell’accesso per controllare qualità dell’accesso

figura:

diagramma sequenza di proxy

proxy come intermediario tra client e server.

Il cliente chiede erogazione servizo a proxy questo accede a servizo nel server ma fa pre

elaborazione e poi fa post elaborazioni. Queste operazioni controllano qualità in accesso al

servizio. Ese: controllo credenziali accesso prima di accedere al servizio.

Ese: cache proxy: server fa operazioni costose ma per motivi prestazioni le risposte vengono

memorizzate in proxy. Quindi client consulta cache invece di accedere a servizio. Il proxy

prima di andare dal server consulta la cache per vedere se già ha il servizio. Quindi proxy

implementa stessa interfaccia del servizio. Utile mettere tra client e server una sequenza di

proxy che controllano una qualità diversa di accesso al servizio. Il client non sa se sta

accedendo a vero server o dal proxy e server non sa se la richiesta di servizio viene da proxy o

da client. 182

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

tipi di proxy:

- cache proxy: per le prestazioni

- protecion proxy: per sicurezza

- virtual proxy: creare oggetto solo quando è necessario

- synchronization proxy: servizio sequenziale ma client ad accesso concorrente. Proxy

riceve richieste e le mette in fila

- remote proxy

- altri…

figura sotto:

remote proxy

consente accesso a servizi remoti rispetto al client. Linea zigzag confine tra processi.

Coppia proxy (proxy lato client e lato server) accesso a servizio remoto avviene con client che

richiede localmente al proprio proxy questo incapsula richiesta e la invia a proxy lato server

che estrae richiesta e la invia a server. Il server invia risposta a lato server, questo la incapsula

ec…

Questa interazione è come C/S RPC con stub e skeleton.

In questo caso la coppia di proxy consente chiamata remota ma client fa chiamata locale e

riceve risposta in modo locale anche server >>> questa si chiama trasparenza nell’accesso 183

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

Discussione

diversi tipi di proxy

• un proxy migliora il controllo dell’accesso a un servizio (controllare specifca qualità

• come sicurezza o prestazioni)

un proxy remoto nasconde al client il fatto che un servizio sia remoto

spunti:

descrivere design pattern proxy

BROKER

Questo pattern architetturale descrive infrastruttura comunicazioni in architettura a oggetti

distribuiti. Utile per capire funzionamento middelware perché questi sono basati su broker o

sue evoluzioni.

Contesto

un insieme di componenti distribuiti in grado di erogare dei servizi

ci sono molti componenti e molti servizi. È quindi contesto complesso.

Problema

fornire un modello semplice di accesso ai servizi, che offre trasparenza nell’accesso e

• nella locazione dei componenti distribuiti che li implementano (modello semplificato

di programmazione riduce tempi sviluppo e riduce errori sviluppatori quindi

affidabilità migliore del sistema. Utile avere livelli trasparenza dati dal middelware.

Trasparenza significa che oggetti non sanno che sono remoti. Accesso avviene

indipendentemente dalla locazione)

organizzazione flessibile dei componenti distribuiti (ese: si vuole offrire nuovi servizi o

• modificare componenti. Oppure si vuole modificare locazione componenti in rete per

migliorare scalabilità e disponibilità)

Soluzione

introduci un componente intermediario broker che disaccoppia i client dei servizi dalle

• implementazioni dei servizi

utilizza come intermediari anche dei proxy remoti

• 184

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

figura sotto:

client e server (ce ne possono essere molti) c’è broker e coppia di proxy lato client e lato

server.

Client e server vivono in processi diversi e anche broker ha processo diverso

Client chiama proxy locale che chiama broker che seleziona offerente servizio e gira richiesta

a proxy server e richiesta torna indietro.

Broker registra servizi. Ogni nuovo servizio deve registrarsi al broker. Quindi broker deve

avere register servizi.

Responsabilità del broker

trasmettere richieste e risposte tra client e server

• registrare i servizi offerti dai server

• selezionare il server per erogare un servizio a un client

intermediazione del broker soprattutto è utile per registrazione servizi disponibili in sistema

distribuito e selezionare servizio per soddisfare al meglio richiesta di client.

Scenari principali

registrazione di un server presso il broker

• accesso a un servizio da parte di un client

figura sotto:

diagramma sequenza per accesso servizio da parte di client

processo client, del server e del broker

client richiede servizio a proxy client che trasmette richiesta a broker

questo prima consulta proprio registry servizi per capire chi è il miglior server poi invia

messaggio a proxy lato server che estrae richiesta chiede servizio ecc…

comunicazione tra processo client e server è indiretta per aumentare flessibilità perché il

broker cerca il servizio in grado migliore di soddisfare la richiesta. Se fallisce un server si può

spostare un server da un pc ad un altro riregistrare servizio e quindi quando client chiede di

nuovo servizio sarà possibile locare il servizio anche se la posizione è cambiata in rete. Questo

è vantaggio principale del broker. 185

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

Discussione

trasparenza nell’accesso e nella locazione dei servizi

• flessibilità nella distribuzione dei servizi

• passo intermedio verso le tecnologie più moderne

spunti:

pattern broker descrivilo

limiti e benefici di infrastruttura con broker

SEMANTICA DELLE CHIAMATE REMOTE

Meccanismi chiamata remota che se trasparenza accesso sembrano chiamate locali grazie a

proxy. La semantica di una chiamata remota è diversa da quella di chiamata locale

Semantica di una chiamata remota

possibilità di fallimenti nella comunicazione

• concorrenza

• legame dei parametri

Problemi nella comunicazione

messaggi persi o trasmessi male

• messaggi fuori ordine

• messaggi trasmessi più volte

Opzioni 186

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

ripetizione del messaggio di richiesta da parte del client

• filtraggio di richieste duplicate lato server se valida opzione sopra. (ogni richiesta deve

• avere numero d’ordine della richiesta)

ritrasmissione di risposte

Semantiche possibili sulla base delle opzioni di cui sopra

non ripetere richieste (semantica è maybe)

• ripeti richieste, non filtrare duplicati (at least once)

• ripeti richieste, filtra duplicati, ritrasmetti risposte (at most once)

in generale in chiamata remota il cliente quando chiama può avere risposta o può avere

timeout. A seconda della semantica richiesta e di questi due casi, il client può csapire o meno

cosa è successo.

Ese: se non ci sono risposte, non si sa se operazione non è partita o se si è persa la risposta

In at least once, si possono perdere molte richieste ma venga ricevuta una sola richiesta e

quindi operazione viene una sola volta ma anche le risposte possono perdere e server ripete

operazione finche client non riceve risposta.

In at most once, se vengono perse richieste e risposte, se operazione viene eseguita una volta

e basta quindi se client ottiene una risposta significa che la operazione è stata eseguita.

Di solito si usa la terza semantica ma in nessuna di queste semantica si ha la comunicazione

locale.

Concorrenza

un oggetto remoto può essere condiviso da più client

• ciascuna chiamata remota viene gestita da oggetto remoto in un thread concorrente

• (oggetto esegue istruzioni in modo concorrente)

quindi sono possibili interferenze (capire se oggetto è condiviso, se ci sono

• concorrenze e come evitare. Ese: mutua esclusione in caso che operazione si esegue in

modo concorrenze.)

motivo di differenza tra chiamata locale e remota Legame dei parametri

in una chiamata locale, per valore o per riferimento

• in una chiamata remota, di solito per valore-risultato (ogni sottoprogramma ha

• parametri di ingresso e uscita. Quelli di ingresso sono per valore legati alla chiamata

quelli di uscita sono legati per valore a momento termine esecuzione per valore)

serializzazione di parametri e risultati (soprattutto se parametri sono oggetti locali che

• in chiamate remoti si serializzano sia se sono parametri che risultati. Serializzare

significa trasformare in binario. E un oggetto viene quindi ricostruito ma se processo

server modifica oggetto nella ricostruzione, il lato client non vede queste modifiche e

quindi ci sono effetti collaterali che sono differenza nella semantica)

Lez.24 – Messaging

Importante paradigma di interazione nei sistemi distribuiti 187

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

INTRODUZIONE AL MESSAGING

I sistemi distribuiti sono basati su due modalità principali d’interazione:

invocazione remota (chiamata “remota”. Interazione CS su base protocollo richiesta

• risposta di tipo sincrono.)

messaging

Paradigma di interazione del messaging

comunicazione tra un componente produttore e un componente consumatore

• (produttore produce messaggio elaborato poi da consumatore)

il produttore produce un messaggio (ese: richiesta di ordine che vuole essere elaborato

• da altro componente)

il produttore invia il messaggio a un canale per messaggi (che ha lo scopo di

• intermediario tra produttore e consumatore)

un consumatore riceve il messaggio dal canale (ma non necessariamente subito ma

• anche in modo asincrono)

il consumatore elabora il messaggio (ese: se messaggio relativo a un ordine si

• verificherà che prodotti sono presenti e poi invia messaggio che dice che prodotti sono

ordinati)

figura:

3 componenti A B C

canali comnicazioni X Y

gestiti da broker

due tipi di messaggi: rettangoli e rombi

A produttore messaggi rettangolari inviati a canale X

Componente B consuma messaggi a canale X e si produce messaggio romboidale da inviare a

canale Y.

Il componente C sarà poi consumatore di messaggi romboidali da canale B

Ci sono anche filtri e pipes.

In architettura messaging architettura di rete può essere più complessa di quella in figura

sotto.

Invocazione remota 188

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

protocollo basato su richiesta-risposta (client chiede operazione a server e resta in

• attesa di risposta)

comunicazione diretta o indiretta (diretta in CS in cui client comunica con server e

• indiretta in caso oggetti distribuiti in cui comunicazione intermediata da broker)

conoscenza interfacce procedurali (client deve sapere quali operazioni sa fare il server.

• Conoscere anche i tipi procedurali)

comunicazione sincrona (client resta fermo finchè non ha risposta da server. Questa è

• possibile solo se client server sono contemporaneamente attivi. Senno non è possibile

comunicare)

comunicazione molti-a-uno (ogni clinet interagisce solo con un server)

• accoppiamento forte (accoppiamento sincrono e procedurale. Mentre in messagging

• interazione ha accoppiamento debole)

Messaging

interazione basata su scambio di messaggi/ documenti/ notifiche (ogni interazione

• relativa a scambio messaggio tra produttore e consumatore. Quindi non richiesta

risposta ma singolo messaggio)

comunicazione indiretta (produttore non conosce consumatore)

• invocazione implicita (produttore non richiede a consumatore di eseguire operazione.

• Quindi non c’è accoppiamento produttore e interfaccia procedurale consumatore. Il

consumatore decide quale operazione deve eseguire. Quindi invocazione è implicita)

comunicazione asincrona (produttore si scorda del messaggio dopo averlo inviato e

• non resta in attesa di risposta perché non ne ha bisogno. Si parla anche in questo senso

di comunicazione asincrona)

messagging consente comunicazione molti-a-uno e uno-a-molti

• accoppiamento debole

nel messagging accoppiamento tra componenti è meno forte che non nel caso della

interazione e invocazione remota.

Nel messagging l’idea importante è dei canali per messaggi che sono destinazione intermedia.

Canali per messaggi

un canale per ciascuna tipologia di messaggi

• per ogni canale ci possono essere molti produttori e molti consumatori (associati a

• quel canale e quindi relativi a quel tipo di messaggio. Molti componenti concorrenti. Sia

produttore che consumatori. Questo legato a motivi di prestazioni e scalabilità.

Consumatori diversi che operano in modo concorrente per ridurre tempo.)

ciascun componente può essere sia produttore di messaggi di un certo tipo e consumatore di

messaggi di altro tipo.

Due tipi di canali

canali punto-punto (code)

• canali publish-subscribe (topic)

in un punto-punto il messaggio viene consumato da un singolo consumatore. Al canale

possono però essere associati più consumatori. 189

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

In un topic i messaggi vengono consumati da tutti i consumatori iscritti a quel canale.

P = produttore

C1 e C2 sono consumatori

Canale di tipo punto punto. Messaggi m2 m3 ricevuti solo da consumatore C2.

Dipende anche da quello che decide di fare infrastruttura intermedia di messaggio

figura sotto:

topic. Tutti i messaggi ricevuti da tutti i consumatori.

Questo è utile quando si devono notificare eventi utili a tutti i consumatori come esempio

notifica di variazione prezzo di prodotto.

Discussione

sostiene accoppiamento debole

• prestazioni alte (tipicamente consegna messaggio avviene con latenza bassa perché il

• sistema cerca di smistare messaggi velocemente e anche perché non si aspetta

risposta.

scalabilità alta: perché consumo concorrente del messaggio da parte di consumatori

• affidabilità

• 190

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

Livelli di affidabilità

non affidabile (best effort): prova a consegnare il messaggio ma se non ci si riesce il

• messaggio viene scartato ed ese per timeout.

Persistente: i messaggi vengono sicuramente consegnati al consumatore anche a fronte

• di fallimenti nel sistema di messagging. I messaggi si memorizzano in modo persistente

così che i messaggi non consegnati possono essere ritrovati

Consegna transazionale del messaggio: se la transazione non viene completata, i

• messaggi non consumati vengono rimessi nelle code o destinazioni intermedie a cui

appartenevano. Se consumatore va in crash il messaggio non viene considerato

consumato ma viene rinviato ad altro consumatore.

Nei sistemi di messagging si possono associare qualità di comunicazione non tanto ai

componenti che devono interagire ma ai canali (connettori) coinvolti nella comunicazione.

Molte qualità sono infatti assegnate ai connettori

Quando usare il messaging?

componenti che non sono attivi contemporaneamente (quindi possono essere attivati

• in momenti diversi)

componenti che inviano messaggi, senza attendere risposte (o perché possono

• attenere in secondo momento o perché scopo è solo inoltrare messaggi)

integrazione di componenti e di applicazioni che sono state sviluppate separatamente

• grazie ad accoppiamento basso caratteristico del messagging

PATTERN PER IL MESSAGING

Dopo il paradigma di interazione messaging capiamo come e dove applicarlo

Pattern architetturale messaging.

Messaging

problema:

• integrare più componenti o servizi autonomi in un sistema coerente

applicazione di applicazioni di tipo enterprise. Molte organizzazioni che si fondono o una

acquista un'altra. Occorre definire nuovo sistema informatico come integrazione sistemi

informatici preesistenti che vanno fatti interagire.

soluzione:

• collegai componenti o servizi mediante un bus per messaggi, per scambiare messaggi

in modo asincrono e affidabile

molto generale. Una parola importante è collegare. Definire quindi collegamenti definire

connettori per collegare componenti preesistenti.

Quindi si cambia i connettori che collegano gli elementi. Connettori sono propri del

messagging.

Uso di messaggi (Message) è un pattern di per sé.

problema:

• connettere componenti per consentire lo scambio flessibile di pezzi di informazione,

con un accoppiamento basso 191

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

componenti devono interagire flessibilmente. In modo richiesta risposta o

notificandosi degli eventi… come permettere di interagire in tante modalità? >>>

occorre accoppiamento più basso rispetto a richiesta/risposta sincrona. Si vuole

collegare componenti senza avere accoppiamento forte tra componenti che devono

interagire.

soluzione:

• incapsula i dati da scambiare in un messaggio, composto da un’intestazione e da un

corpo

i dati scambiati devono racchiudersi in un messaggio che è fatto dai dati veri e propri e da

intestazione

intestazione ha info aggiuntive sui dati scambiati.

Sono metadati. Come interpretare i dati o avere info non funzionali o informazioni come

periodo validità del messaggi.

Uso message presenta queste caratteristiche

flessibilità nei dati scambiati

• flessibilità nei formati usati

• sostiene un accoppiamento basso

• introduce un overhead

altro pattern facente parte di questa soluzione è

Message Channel

problema: per sostenere un accoppiamento basso, i componenti non dovrebbero conoscere

chi è interessato a quali messaggi

il produttore non deve sapere chi è in grado di consumare il messaggio. Il canale per messaggi

ha lo scopo di ridurre accoppiamento tra elementi. Quindi produttori e consumatori non si

devono conoscere. Devono solo conoscere i canali.

soluzione: connetti i componenti che devono interagire tramite un canale per messaggi, che

gli consente di scambiare messaggi

Discussione

comune l’uso di molti canali per messaggi (ogni canale si occupa di una certa tipologia

• di messaggi)

sostiene un accoppiamento basso

• controllo dell’affidabilità e altre qualità

• richiede la gestione di risorse nel sistema framework middelware di messaging e la

• gestione di queste risposte è costosa quindi se chiediamo da passare da best effort a

transazionale allora uso risorse è ancora maggiore.

Point-to-Point Channel

un canale per messaggi che garantisce che un solo consumatore riceverà un messaggio

in alcuni casi si vuole che i messaggi i elaborano una sola volta. Ese: pagamento che vogliamo

effettuare una sola volta. In questo caso possiamo fare che ogni canale per messaggio sia

assegnato ad un singolo consumatore. 192

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

Publish-Subscribe Channel

un canale per messaggi che consente di comunicare un evento a molti componenti

• interessati, consegnando a ciascuno una notifica dell’evento

un altro tipo di canale rivolto invece alla comunicazione di notifica che è altro tipo di info nei

sistemi distribuiti.

Sia code che topic sono basati su meccanismo di registrazione consumatori presso canale che

garantisce le semantiche

Altro pattern di messagging: Message Endpoint

problema: consentire lo scambio di dati tra componenti, con un accoppiamento basso

• (o nullo) verso l’infrastruttura di messaging

è necessario qualche accoppiamento con infrastruttura di messagging. Si preferisce non

toccare componenti preesistenti ma assegnare responsabilità di interazione ad elementi che

sono end point che permettono interazione con accoppiamento basso o nullo vs infrastruttura

di messagging.

soluzione: connetti i componenti che devono interagire mediante degli endpoint per

• messaggi specializzati, usati per inviare o ricevere messaggi

end point sono usati per ricevere o trasmettere messaggi.

Figura sotto:

una delle tante possibili configurazioni

Componente può avere operazione in sua interfaccia per inviare messaggi e B ha interfaccia

per ricevere messaggi.

Invio messaggi basato su endpoint.

A interagisce con primo endpoint e questo riceve dati li incapsula a messaggio inviato a una

coda. Ricevuto a endopoint di B e li manda a B. B non sa che riceve messaggio tramite

infrastruttura di messagging. Questi endpoint nascondono intera infrastruttura di

messagging. Questi si usano per nascondere la specifica tecnologia usata per messagging.

Nascondere parzialmente infrastruttura in certi casi è sufficiente. In altri casi si usa un

messaging point chiamato channel adapter

channel adapter

endpoint per messaggi che nasconde completamente infrastruttura di messagging a un

componente

connettore che riceve messaggi che interpreta come richiesta estrae dati da messaggi,

costruisce richieste che fa a server e ottiene risposte. E su base risposta invia messaggi canale

successivo. Questo adattatore si sostituisce a client successivo. 193

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

Alcuni tipi di channel adapter si sostituiscono a server…

Nascondono completamente infrastruttura di messagging ai componenti che fa interagire.

altro tipo di pattern è Message Router

un elemento che instrada messaggi, muovendo ciascun messaggio verso il destinatario

• più opportuno

un messaggio deve essere mosso da produttore iniziale messaggio vs consumatore finale. Ci

possono essere destinazioni intermedie. Nessun elemento deve conoscere intero percorso.

Messagge router sono connettori ausiliari che analizzano alcuni elementi del contenuto

messaggio. Questo tiene basso accoppiamento tra elementi del sistema

altro pattern è Message Translator

un elemento in grado di tradurre messaggi da un formato a un altro, per far interagire

• componenti che adottano formati dei dati diversi

in integrazione applicazione non serve i componenti sono d’accordo sul formato del

messaggio.

Message translator è elemento intermedio che traduce e converte messaggi scambiati.

Realizzati con tecnologie standard xml.

Anche questi tengono basso accoppiamento fra elementi.

Discussione:

- architettura di un sistema di messaging può essere basata su pipes e filters

- il modello di dominio può essere basato su modellazione attività e processi perché

questo tipo di modellazione prevede identificazione flusso di dati scambiati tra

elementi ed è quindi utile alla realizzazione di un sistema di messaging.

Lez.25 - Architettura a componenti (prima parte)

COMPONENTI

Un sistema sw composto solo da una tipologia di elementi chiamata componenti. 194

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

Accezione generale: Componente (architetture software)

un tipo di elemento software

• responsabile di offrire funzioni e/o gestire dati

• interfacce esplicite

• un sistema software è realizzato mediante la composizione di componenti

termine component e composizione sono correlati.. la composizione avviene collegando

interfacce dei componenti tramite connettori.

Componente (tecnologia a componenti)

un’entità software runtime (specializzazione lieve rispetto al componente)

• implementa funzioni e/o gestisce dati (non ha responsabilità di controllare qualità del

• sistema.)

caratterizzato da insieme di interfacce esplicite (che descrivono i servizi che può

• richiedere e offrire)

un’applicazione software è formata da un insieme di componenti, composti sulla base

• delle loro interfacce (collegando interfacce richieste con interfacce fornite con gruppo

di componenti)

i componenti vanno rilasciati in un contenitore, che ne gestisce l’esecuzione (nozione

• di contenitore definisce ambiente runtime specializzato. Ci sono tanti componenti ma

solo un connettore che è il contenitore. Questo fornisce qualità in modo opportuno)

Esempi di tecnologie a componenti

CORBA (1991) – nasce come tecnologia a oggetti distribuiti poi evolve come tecnologia

• a componenti

Microsoft COM –component object model - (1993), DCOM – distributed COM (1996) e

• .NET – dot net(dal 2OO2)

Java EJB (dal 1999) – enterprise java bin – ancora molto diffusa ed attuale.

Una promessa comune delle tecnologie a componenti:

consentire agli sviluppatori di concentrarsi sull’implementazione delle funzionalità nei

• componenti

un sistema sw richiede sia funzionalità che qualità come prestazione, sicurezza disponibilità e

la promessa è che lo sviluppatore non deve pensare alle qualità che sono gestite da

contenitore.

Basati su modello programmazione più semplice rispetto alle altre tecnologie a sistemi

distribuiti quindi qualità migliori a tempi di sviluppo minori.

I componenti sono un’evoluzione degli oggetti distribuiti:

per superarne alcuni limiti

• per fornire un supporto migliore per le qualità

il broker qui diventa un contenitore.

Vengono evoluti limiti di oggetti distribuiti. Questi richiedono sforzo per comporre app

perché ogni oggetto server deve registrare servizi al broker e ogni client deve richiedere al

broker un servizio mentre in contenitore semplifica collegamento tra componenti.

In componenti questi interagiscono in modo sincrono e asincrono. Lo scopo di componenti è

anche dare supporto migliore alle qualità.

Componenti e interfacce 195

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

interfacce fornite (insieme servizi che componente offre a altri componenti.)

• interfacce richieste (servizi che devono essere offerti affinché il componente possa

• funzionare correttamente)

ogni componente può avere molte interfacce (in generale ogni componente ha almeno

• una interfaccia richiesta)

stile procedurale e stile orientato ai messaggi delle interfacce (in stile procedurale ci

• sono insieme di parametri e valore restituiti dalla operazione su base protocollo

richiesta risposta. Mentre in messaggi dichiara messaggi che componente può

produrre o consumare.)

figura sotto:

gestione prodotti è tipologia di componente

i simboli a dx sono interfacce fornite al componente

mezza luna è invece interfaccia richiesta per accedere a base di dati prodotti.

Ci fa capire che componente gestisce prodotti ma non gestisce DB prodotti perché deve

delegare la funzionalità ad altro componente mediante interfaccia a mezza luna

due interfacce gestione prodotti: una di ricerca una di gestone completa

Questo componente può essere usato in e-commerce dai cliente che leggono catalogo

prodotto tramite lettura sola di catalogo prodotti.

Ma amministratore può usare interfaccia gestisci prodotti per modificare il catalogo prodotti.

Componenti e composizione

la composizione di un’applicazione avviene, in sede di deployment, collegando un

• insieme di componenti tramite le loro interfacce

la composizione di app a componenti ha due livelli:

- specifica di componente: fatta da interfacce tipologie di componenti e interfacce dei

componenti. Questa viene definita per prima

- implementazione: per implementare il componente. Si specifica in termini di

interfacce. I componenti dipendono solo dalle interfacce e non dalla loro

implementazione.

Figura sotto:

Applicazione web acceduta da browser: 196

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

brow interagisce con app web per cliente. che si occupa della presentazione.

UI basata su protocollo http.

App web cliente interagisce con molti componenti come quello per gestire inserimento irdine.

Avremo casu uso rilevante per app web.

UN ESEMPIO DI TECNOLOGIA A COMPONENTI

Java Enterprise Edition

una piattaforma per lo sviluppo di applicazioni di tipo enterprise (cioè app che

• gestiscono big data con operazioni transazionali di pochi dati alla volta operazioni

concorrenti tra client concorrenti. Requisiti stringenti di qualità. Promessa è di

consentire sviluppare queste app su base di modello semplice perché molte qualità

sono offerte da contenitore e quindi sviluppatore si concentra sulle funzionalità)

supporto per distribuzione, prestazioni, scalabilità, sicurezza, affidabilità, disponibilità

• ecc…

figura sotto:

idea che architettura app sia client server a più livello con 4 livelli. Sempre presente un livello

client. Possibile livello web per gestire interazione coi clienti sul web.

Livello business per gestione logica applicativa e livello per gestione informazioni e dati. 197

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

figura sotto:

ruoli contenitori in Java EE

Servlet HTTP

un tipo di componente web per la gestione di richieste HTTP

• 198

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

Enterprise Bean (EJB)

componenti lato server per implementare la logica di business di un’applicazione

Tipi principali di enterprise bean

session bean

• message-driven bean

Session Bean

incapsula logica applicativa

• può offrire servizi a client locali o remoti

• un’istanza rappresenta un singolo client all’interno di un’applicazione

Session bean e interfacce

interfacce di business

• interfacce fornite e richieste

• composizione al momento del rilascio

Session bean e il contenitore

gestione del ciclo di vita

• collegamento dinamico

• intercettazione delle richieste

Tipi di session bean

session bean stateful: mantiene informazioni sulle conversazioni (sessioni) con i suoi

• client

session bean stateless

• 199

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

Lez.26 - Architettura a componenti (seconda parte)

CONTENITORI

Hanno un ruolo molto importante nelle tecnologie a componenti.

“non esiste niente che di per se è componente, ma i componenti esistono solo perché i

contenitori li definiscono” 200

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

Componente

entità software runtime

• implementa funzionalità

• interfacce esplicite (richieste e fornite)

• composizione di componenti.

• rilascio e gestione in un contenitore

Contenitore

un ambiente runtime per i componenti (di solito in ambiente lato server)

• i componenti, per essere eseguiti, devono essere configurati, assemblati e rilasciati in

• un contenitore (la registrazione componenti in contenitore è più complessa di

registrazione server in broker)

il contenitore gestisce il ciclo di vita dei componenti

• il contenitore gestisce la comunicazione tra componenti

• il contenitore fornisce servizi utili e qualità ai componenti

responsabilità principale contenitore: Gestione delle risorse:

risorse: componenti, servizi distribuiti, connessioni, sessioni, ...

• molte qualità di un sistema software dipendono dalla gestione delle risorse (ese:

• gestione corretta delle risorse => scalabilità.)

la gestione delle risorse è una capacità critica nella realizzazione dei sistemi software

• distribuiti

è opportuna una gestione trasparente del ciclo di vita delle risorse

gestire risorse è difficile… è necessario seguire compromesso tra qualità.

Un’alternativa è gestire risorse sulla base di pattern e standard.

Il supporto standard alle qualità non è ottimale.. ma quello fornito da un contenitore è

migliore di quello che può fare un medio team di sviluppo.

Un modo per avere soluzioni standard di tecnologie componenti è dare allo sviluppatore la

possibilità di fare interventi locali ma anche questo è realizzato nelle tecnologie a componenti.

Container:

stile architettura evoluzione di broker

problema: componenti che possono essere composti in applicazioni, ciascuna con un

• diverso scenario di utilizzo (non si vuole accoppiare componenti per riutilizzarli in più

applicazioni. App possono avere scenari di utilizzo diverso. Una app può richiedere

migliori prestazioni e un’altra può richiedere sicurezza. Quindi no accoppiamento a

scenario di utilizzo e no accoppiamento ad applicazione.)

soluzione: definisci un contenitore (container) che fornisce un ambiente di esecuzione

• opportuno per componenti e realizza l’infrastruttura per comporre componenti in

applicazioni

Component Configurator (è una parte di un contenitore)

problema: consentire una configurazione flessibile delle applicazioni e dei loro

• componenti 201

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

soluzione: separa le interfacce dei componenti dalle loro implementazioni e fornisci un

• meccanismo per (ri)configurare dinamicamente i componenti in applicazioni

utilizzare meccanismo di incapsulamento con separazione tra interfacce e implementazioni.

Ogni interfaccia deve poter essere caricata individualmente. Configurazione app riguarda

scelta componenti e la gestione delle qualità che il contenitore fa nei confronti

dell’applicazione.

Queste info vengono prese in carico dal contenitore che fornisce le qualità richieste.

Object Manager è un'altra responsabilità del contenitore.

problema: gestire l’accesso ai componenti, nonché le loro risorse e relazioni

per uso efficiente applicazione, molte risorse devono essere gestite in modo opportuno.

Quindi si richiede controllo accurato ciclo di vita di queste risorse.

soluzione: separa l’utilizzo degli oggetti dal controllo del loro ciclo di vita e uso,

• mediante l’introduzione di un gestore degli oggetti (object manager) che rappresenta

altra responsabilità del contenitore. I client di oggetto possono richiedendo a object

management di usarlo ma senza occuparsi del ciclo di vita della risorsa.

Lifecycle callback

problema: garantire che gli oggetti gestiti rispondano ad eventi relativi al loro ciclo di vita.

Ogni risorsa ha ciclo di vita caratterizzato da eventi. Alcune risorse ad ese alcuni componenti

richiedono ciclo vita complesso perché possono essere temporaneamente deallocati. Come

gestire questi componenti in modo efficiente?

soluzione: rappresenta gli eventi del ciclo di vita di una tipologia di oggetti mediante

• operazioni di callback

quando un componente è creato deve acquisire risorse ma le risorse vanno rilasciate prima di

distruggere l’oggetto.

Spunti:

descrivi principali responsabilità contenitore e tattiche e pattern usati in creazione

contenitore

CONTENITORI E CLUSTER

Il contenitore fornisce qualità ai componenti che gestisce.

Cluster

un gruppo di due o più computer (nodi o membri) interconnessi che lavorano insieme

• per offrire un servizio come un sistema singolo

cluster (insieme di pc) che fioriscono servizio, insieme a questi ci sono altri elementi. In ogni

nodo è in esecuzione un servizio che gestisce appartenenza nodo a cluster. I client vedono il

cluster come se fosse un singolo pc che offre servizio. Sostenere mediante cluster scalabilità

orizzontale (se aumenta client è possibile gestire carico maggiore a parità di prestazioni

aumentando numero nodi del cluster e disponibilità usando cluster in modo che se nodo 202

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

fallisce, questo è sostituito da altro nodo del cluster. Cluster sostengono scalabilità e

disponibilità sia individualmente che congiuntamente.)

Tipi di cluster

per alte prestazioni (calcoli scientifici)

• per alta disponibilità (operazioni brevi richiesti da client concorrenti)

• per il disaster recovery (business continuity avere sistema informatico in pc dispersi

• geograficamente)

figura sotto

configurazione base di cluster:

nodi collegati da rete unificazione. Interfaccia che fa sembrare che il cluster sia un unico pc.

figura sotto

cluster asimmetrico

in normali funzionamento, il cluster eroga servizio e solitamente solo un server viene usato.

Se il server si guasta, il secondo server si accende e le richieste di cluster vengono mandate al

secondo server.

Questa è soluzione costosa perché server di riserva sono inusati per molto tempo 203

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

ogni server in funzione è dedicato a singolo servizio.

Se server fallisce, allora il suo servizio viene dato al server 1 che farà quindi 2 servizi.

Meglio organizzazione nodi ma nel momento in cui server fallisce si richiusa di superare la

capacità di elaborazione del server di riserva.

figura sotto:

più nodi cluster che erogano servizio.

Il carico viene bilanciato in base alla disponibilità del server. 204

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

Cluster per application server

due o più nodi (duo o più pc)

• su ciascun nodo, due istanze dell’AS (application server.) i due nodi possono fallire

• indipendentemente fra loro quindi di solito se uno fallisce l’altro sopravvive. Quindi su

ciascun nodo si mandano in esecuzione due istanze che a loro volta possono fallire

individualmente e indipendentemente.

ogni istanza dell’AS ospita tutte le applicazioni (senza distribuire le app sui diversi

• nodi, tutto il carico di ogni app si distribuisce mediante bilanciamento del carico su

tutti nodi del cluster)

un database server separato (server separata in base ad architettura multilivello CS)

Gestione delle sessioni

lo stato delle sessioni è una risorsa critica

ese:

caso d’uso con esecuzione lunga quindi tante interazione tra client ed app e quindi app è

stateful che gestisce varie interazioni.

Se stato sessione preservato durante tutta esecuzione caso d’uso anche a fronte di guasti del

sistema significa che client non si accorge dei guasti e porta avanti sessione. Se invece il

guasto interrompe la sessione il cliente deve ricominciare sessione da capo con conseguenze

sgradevole e a volte inaccettabili perché si perdono informazioni.

Figura sotto:

esistono due soluzioni

la prima è la gestione centralizzata delle sessioni:

client fanno richieste in sessione a server che sono istanze di application server in esecuzione

nel cluster e c’è bilanciamento carico.

Stato sessione è gestita in starto basso (blu) ed abbiamo una DB per failover server.

Il client gestisce identificatore sessione.

Il bilanciamento carico individua server e questo interagisce con strato sotto per avere stato

della sessione. Ese: sessione riguarda acquisto commercio elettronico e le info salvate nella

205

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

DB e poi al cliente viene data risposta. Quando client fa altra richiesta in stessa sessione e

server carica stato sessione nella DB e poi fa servizio.

Se server fallisce, le operazioni continuano in modo trasparente al cliente (che non si accorge

del fallimento di un server).

Lo svantaggio è che ogni esecuzione operazione richiede una coppia di accessi allo stato delle

sessioni e questo introduce overhead che può penalizzare prestazioni.

Si potrebbe usare un sistema newsequel o neosequel invece di RDB per gestire stato sessioni.

un’alternativa per gestione sessioni è la gestione asincrona:

ogni sessione gestita da server che è responsabile principale di quella sessione da un altro

server che replica dati sessione.

Il server esegue la sessione e poi comunica in modo asincrono lo stato dei messaggi ad un

altro server. Se server fallisce allora richiesta viene girata ad altro nodo del cluster che

gestisce replica sessione così che lui possa eseguire operazione. Lui comincerà a mandare

messaggi asincroni sullo stato di sessione per far si che ci siano sempre 2 server.

Non si ha overhead necessario alla memorizzazione stato sessioni e accesso a stato in DB

esterno perché stato sessioni è gestito solo in memoria principale.

Ma lo svantaggio è la minore tolleranza ai guasti perché non sopporta fallimento congiunto di

coppia nodi dei cluster tipo se fallisce il server principale e il suo backup. 206

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

Lez.27 - Architettura orientata ai servizi (prima parte)

Introduzione ai servizi

In architettura orientata ai servizi, gli elementi del sistema sono i servizi.

Motivazioni per SOAP e gli obbiettivi generali dell’architettura

l’architettura orientata ai servizi è uno stile per organizzare e usare capacità distribuite

• che possono essere controllate da diverse organizzazioni (obbiettivo generale è

consentire a organizzazione di fruire servizi da parte di altra organizzazione). (le

tecnologie a componenti sono ottime soluzioni in ambito di singola organizzazione ma

non quando ci sono più organizzazioni)

l’interoperabilità̀

le tecnologie a servizi sostengono tra tecnologie di middleware

• diverse, senza cercare di sostituirle (queste tecnologie a servizi risolvono problemi

pragmatici con soluzioni concrete per nascondere eterogeneità di organizzazioni

diverse. Non sostituiscono le tecnologie esistenti ma si affiancano ad esse). Si assume

che eterogeneità sia costante..

Interoperabilità

la capacità, per due o più sistemi, di interagire in modo effettivo, scambiando tra loro

• informazioni significative, tramite interfacce, in un contesto particolare

la capacità di comunicare anche a fronte di eterogeneità (linguaggio progettazione,

piattaforma sviluppo, rappresentazione info ecc.) significa essere in grado si scambiare dati

ed interpretarli correttamente.

Ese: assicurazione che vuole fruire servizi di una banca. 207

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

Interoperabilità significa fare scelte neutrali rispetto alle piattaforme. Questa interoperabilità

va perseguita usando standard.

Servizi e standard

le tecnologie a servizi sono basate su un insieme di standard tecnologici per

• l’interoperabilità, indipendenti dalle piattaforme e neutrali rispetto ad esse.

Successo di uno standard dipende dal livello di adozione dello standard. Oggi le tecnologie a

servizi sono supportate da tantissimi produttori dei sw.

Oggi le tecnologie a servizi più diffuse sono quelle legate a standard di internet e web.

Web Services

insieme di tecnologie che consentono di esporre le funzionalità di un componente o

• sistema software, per renderle disponibili a client software, mediante tecnologie web

standard

consentono di esporre funzionalità non tanto di implementarle. Si pensa che si implementino

in altro modo come tecnologie a componenti. Idea è rendere funzinalità disponibili a client sw.

Dare possibilità a persone di fruire info sul web. Ma i client sw non possono usare info per

persone. I web service incapsulano funzionalità che siano utili ai sw e non alle persone.

Web Service

un componente software, accessibile mediante Internet, in modo indipendente dalla

• piattaforma

che ha lo scopo di svolgere un compito o di incapsulare un “servizio”

si notino le due parti di questa definizione. La prima parte è aspetto tecnologico (accessibile

mediante internet. Componente sw ecc).

improntate capire che quando si parla di servizi si pensa a caratterizzazione funzionale

business di uso elementi sw. Ogni servizio deve svolgere compito di business ben preciso. In

contesto architettura a servizi entrambi aspetti sono improntanti.

Capacità

di descrivere servizi (descrivere interfaccia servizio così che si fruisce

• indipendentemente da implementazione e solo dipendente da interfaccia. Descrizione

interfaccia in modo neutrale rispetto a piattaforma)

di scoprire servizi (alcuni servizi possono essere esterni all’organizzazione. Importante

• anche quando servizi sono interni a organizzazione così che servizi si possono riusare.)

di invocare servizi (fruire servizi. Capacità fondamentale)

• di comporre servizi (definire nuovi servizi come composizione di servizi preesistenti.

• Ese: gestione pratiche assicurative che invocano servizio per effettuare bonifico

bancario)

2 Tecnologie principali

SOAP

• REST

Spunti:

cosa si intende per servizio?

quali gli obbiettivi principali delle tecnologie a servizi? 208

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

WEB SERVICES SOAP

Molto diffusa e importante.

Figura sotto:

SOAP basati su insieme protocolli organizzati a strati con obbiettivi diversi.

Basso: protocolli trasporto http SMTP ecc.. usati per realizzare comunicazione tra servizi.

Sono tecnologie abilitanti e non nuovo contributo.

Altro protocollo standard usato è xml che è linguaggio per formattare documenti e usato in

formattazione messaggi scambiati in ambito SOAP

Salendo abbiamo 3 standard fondamentali SOAP WSDL UDDI

Soap usato per invocazione servizi

WSDL definizione interfaccia

UDDI usato per scoperta servizi

Sono universalmente accettati implementati con riferimento alle principali piattaforme e sono

base di interoperabilità

Sopra a questi protocolli ci sono WS star sono oltre 100 protocolli e standard relativi a qualità

del servizio (sicurezza, affidabilità, stato sessione ecc…) sono standard ma non tutti accettati

come quelli fondamentali quindi da usare solo se si è sicure che altre organizzazioni hanno

stessi standard…

Sopra ci sono altri standard protocolli e linguaggi per processi business definiti come

composizione di servizi. BPEL; CDL BPMN ecc per modellazione processi business.

figura sotto:

3 standard fondamentali con loro interazioni

in basso ci sono due sistemi informatici di due organizzazioni

a dx abbiamo fornitore servizio

a sx abbiamo utilizzatore servizio che vuole fruire del servizio.

Il provider deve pubblicare su register servizi (entità terza) e il servizio deve avere la sua

interfaccia pubblicato tramite WSDL (webservices description language). Utente servizio deve

cercare e trovare nel registry il servizio e lo fa con UDDI. Questo standard rende una

descrizione WSDL del servizio. Una volta trovato il servizio il richiedente può ricevere

servizio tramite SOAP direttamente vs il provider. 209

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

Questa struttura sembra BROKER dove c’è registro.

Gli standard sono neutrali e sostengono interoperabilità

SOAP un semplice protocollo basato su XML per lo scambio di messaggi tra servizi

lo scopo è consentire interazione in rete basato su scambio messaggi che è unico modo di

interazione tra servizi.

Scambio messaggi come in pattern message è legato a possibilità di comunicare flessibile

perché messaggio può trasmettere dati, documenti, richieste ecc e c’è basso

accoppiamento con uso messaggi.

SOAP riguarda struttura singolo messaggio.

Messaggi SOAP basato su xml

Messaggio SOAP formato da due parti

il corpo contiene le informazioni da trasmettere (contiene info che hanno significato

• funzionale in ambito di interazione)

l’intestazione contiene metadati o altre informazioni (informazioni su controllo

• qualità come credenziali da usare per validare il messaggio ecc. le info qui contenute

fanno riferimento ad altri protocolli e standard come WS* per avere info elaborate e

ricche fruibili da altri servizi)

SOAP non si cura del significato e contenuto messaggi.

WSDL Web Services Description Language (definisce interfaccia servizio. In RPC o CS

• abbiamo IDL (linguaggio per definizione interfacce) anche qui la descrizione

interfaccia viene fatta ma si usa questo standard indipendente da tecnologie specifiche.

Scopo è descrivere l’interfaccia di un servizio

Elementi di un’interfaccia WSDL (parte astratta e parte concreta)

Parte astratta:

• tipi di dato

o formato dei messaggi

o descrizione delle operazioni

o definizione dei servizi

o

parte concreta:

• la parte concreta lega la definizione astratta di un servizio con la sua locazione

o (indirizzi di rete, protocolli e collegamenti) lo stesso servizio può essere fruito

210

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

da client in modi diversi. Ogni modalità di servizio si chiama collegamento ed è

definito in termini di protocollo e di servizio di rete.

ese di parte astratta : interfaccia per avere ordini di acquisto:

interfaccia per effettuare ordine di acquisto. Ogni operazione ha messaggio in entrata e uscita

per esecuzione operazione. Ese: messaggio che specifica ordine che si vuole porre. Un

messaggio ha info su cliente, su prodotti ecc…. ogni servizio PortType ha un nome ecc…

diversi Scenari di utilizzo

- generazione proxy lato client

- generazione bottom-up di un servizio (usato da sviluppare di servizio, sviluppare

realizza componente e vuole esporre funzionalità componente come webservice.)

- generazione top-down di un servizio

UDDI Universal Description, Discovery, and Integration (descrizione scoperta e integrazione

• universale dei servizi. Protocollo per la registrazione servizi in un registro. Registro

importante per far conoscere servizi ad altre organizzazioni mediante questi strumenti

di ricerca. Uso registro improntante anche in singola organizzazione perché questa può

gestire migliaia di servizi ed improntate sostenere riuso dei servizi quindi improntate

pubblicarli.)

Scopo principale dello standard è la pubblicazione e la scoperta di servizi

Composizione di servizi

aggregazione di servizi in servizi più ampi o in processi di business.

Integrazione servizi è simile a composizione componenti ma con differenze: in architetture a

componente ogni componente è parte di singola applicazione. La composizione dei

componenti da luogo ad applicazione direttamente usabile. In composizione servizi ogni

servizi viene usato per più applicazione- è bene riusare servizi in contesti interni ed esterni a

organizzazione. Se non riusabile servizio ha valore basse. Insieme di servizi non da luogo ad

applicazione. Composizione di servizi da luogo a processo di business che è importante

attività di organizzazione e il processo business tipicamente ha durata lunga (giorni, mesi

anni ecc…) mentre le applicazioni ottenute come composizione componenti sono dedicate a d

attività di breve durata. Esempio; servizi per acquistare viaggi quindi prenotare aereo,

albergo ecc. questo servizio si può ottenere come composizione servizi semplici come aereo

albero e pagamento.

la composizione di servizi è basata sul coordinamento, la gestione e il sequenziamento

• dell’invocazione di un insieme di servizi (invocazioni possono essere sincrone ed

asincrone. Definire composizione servizi è attività complessa)

due approcci principali alla composizione di servizi:

• l’orchestrazione di servizi è basata sull’uso di un mediatore (c’è un servizio

o mediatore che chiede ad altri servizi di eseguire funzionalità per svolgere

compito complessivo)

la coreografia è una modalità di composizione collaborativa, senza un

o coordinamento centralizzato (scambio messaggi e notifiche in modo asincrono

e altri servizi capiscono in base a ricezione notifica che devono svolgere compiti

senza controllo centralizzato) 211

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

approccio usato in composizione servizi è usare linguaggi visuali per specificare

composizione servizi con diagrammi per modellare processi ed attività organizzazione per poi

compilare servizi

Discussione

i Web Services SOAP sono una soluzione completa per l’interoperabilità tra servizi

• autonomi

basati su tanti standard alcuni abilitanti altri fondamentali altri aggiuntivi.

Sono in grado di fornire indipendenza da piattaforme che realizzano servizi e forniscono

supporto alle qualità visto che implementazione servizi è effettuata con tecnologie a

componenti quindi ci sono contenitori che danno qualità.

Standard complessi a gestione onerosa e quindi SOAP sono completi ma non semplici né

leggeri da usare

WEB SERVICES REST

Altra tecnologia per webservices molto diffusa.

Molto più semplice di SOAP ma con supporto alle qualità più limitato rispetto a SOAP.

Certamente più semplice da usare e richiede overhead migliore quindi prestazioni e

scalabilità migliore di SOAP.

È stile architetturale che esiste indipendentemente da REST

REST Representational State Transfer

• uno stile per la realizzazione di applicazioni web, per la gestione di risorse mediante il

• protocollo http (descrive come si deve comportare una buona app web)

una risorsa è un elemento informativo di interesse (identificato mediante

• identificatore univoco in internet URI) (ese: ad ogni docente università viene associato

una URI)

un client può accedere a una risorsa mediante la sua URI

• al client viene restituita una rappresentazione della risorsa (non la risorsa

o stessa ma una sua rappresentazione come pagina HTML che descrive risorsa)

applicazione si muove e app definisce un nuovo stato per l’applicazione

o ovvero, l’applicazione cambia (trasferisce) il proprio stato ogni volta che accede

o a una risorsa ( da questa risorsa prosegue navigazione accedendo ad altre

risorse ecc ecc)

questo stile si usa anche in realizzazione webservices rest che sono basati su:

identificazione di risorse tramite URI (assunzione che servizio per risorse informative

• semplici. Ogni risorsa ha identificatore)

accesso alla risorsa avviene mediante interfaccia uniforme (risorse definite da http

• (operazioni quali: get, put, post, delete) finalità di questi servizi molto più limitate

rispetto a SOAP perché basata su http

messaggi auto-descrittivi (i messaggi sono autodescrittivi perché richieste devono

• essere tali che servizi capisca operazione richiesta da client e risposte devono essere

interpretabili dal client)

rappresentazione ipermediale (mediante link tra risorse. Ese accedendo a risorsa si

• restituiscono URI e riferimento a risorse associate ed operazioni associate) 212

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.


ACQUISTATO

6 volte

PAGINE

218

PESO

17.30 MB

AUTORE

jstew

PUBBLICATO

+1 anno fa


DETTAGLI
Corso di laurea: Corso di laurea in ingegneria informatica
SSD:
A.A.: 2017-2018

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher jstew di informazioni apprese con la frequenza delle lezioni di Progettazione del software e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università Uninettuno - Uninettuno o del prof Cabibbo Luca.

Acquista con carta o conto PayPal

Scarica il file tutte le volte che vuoi

Paga con un conto PayPal per usufruire della garanzia Soddisfatto o rimborsato

Recensioni
Ti è piaciuto questo appunto? Valutalo!

Altri appunti di Corso di laurea in ingegneria informatica

Appunti di Sistemi per la gestione delle informazioni. Tutte le lezioni
Appunto
Appunti di Sistemi giuridici per i Big Data. Tutte le lezioni
Appunto
Calcolatori Elettronici - lezione 3
Appunto