evoluzione delle architetture distribuite · 5 motivi dell’evoluzione tecnologia abilitante •...
TRANSCRIPT
![Page 1: Evoluzione delle Architetture Distribuite · 5 Motivi dell’evoluzione Tecnologia abilitante • Nascita della rete • Nascita del Client-Rich Driver di business • L’informatizzazione](https://reader030.vdocuments.mx/reader030/viewer/2022021809/5c65922e09d3f2876e8cd70f/html5/thumbnails/1.jpg)
1
Evoluzione delle Architetture Distribuite
2
Dall’architettura centralizzata all’architettura distribuita
Evoluzione dell’architettura
Applicazioni centralizzate Applicazioni Client/Server
Dati
MainframeTerminali
Resource-TierClient-Tier
Dati
Middle-Tier
Applicazioni Multi-Tier
ServerClient
Dati
Dati
1980 1990
![Page 2: Evoluzione delle Architetture Distribuite · 5 Motivi dell’evoluzione Tecnologia abilitante • Nascita della rete • Nascita del Client-Rich Driver di business • L’informatizzazione](https://reader030.vdocuments.mx/reader030/viewer/2022021809/5c65922e09d3f2876e8cd70f/html5/thumbnails/2.jpg)
3
Il Modello Centralizzato
• L’applicazione gira su una unica macchina (necessariamente potente)
• L’applicazione deve gestire i dati, la logica di business e l’interfaccia utente
4
Modello centralizzato (continua …)
Pro:• Sicurezza a livello di funzioni• Efficiente
(non si ha l’overhead di comunicazione remota)
• Sviluppo relativamente semplice
Contro:• Hardware costoso• Chiuso (problemi di
integrazione)• Scalabilità solo verticale
Dati
Mainframe
Terminali Terminali
1980
![Page 3: Evoluzione delle Architetture Distribuite · 5 Motivi dell’evoluzione Tecnologia abilitante • Nascita della rete • Nascita del Client-Rich Driver di business • L’informatizzazione](https://reader030.vdocuments.mx/reader030/viewer/2022021809/5c65922e09d3f2876e8cd70f/html5/thumbnails/3.jpg)
5
Motivi dell’evoluzione
Tecnologia abilitante• Nascita della rete• Nascita del Client-Rich
Driver di business• L’informatizzazione raggiunge le piccole-
medie imprese
6
Il Modello Client Server
• Il Client richiede dei servizi al server• Il Server esegue le richieste ed eventualmente
restituisce il risultato• Parte consistente della logica di business gira sul
Client• Client e server comunicano mediante un protocollo
ben definito • Client e server possono essere sviluppati da enti
differenti • Più client possono interrogare lo stesso server
![Page 4: Evoluzione delle Architetture Distribuite · 5 Motivi dell’evoluzione Tecnologia abilitante • Nascita della rete • Nascita del Client-Rich Driver di business • L’informatizzazione](https://reader030.vdocuments.mx/reader030/viewer/2022021809/5c65922e09d3f2876e8cd70f/html5/thumbnails/4.jpg)
7
Modello Client/Server
Pro:• Hardware e sviluppo
poco costoso • Aperto
Contro:• Alti costi di amministrazione
(Total Cost of Ownership)• Sicurezza a livello di dati• Poco scalabile
ServerFat-Client
Dati
Logica di business
8
Motivi dell’evoluzione
Tecnologia abilitante• Standardizzazione dei protocolli di rete• Ampliamento della banda
Driver di business• Necessità di distribuzione dell’informazione e dei
servizi su nuovi canali• Necessità di gestire on-line volumi molto maggiori
di transazioni• Necessità di evitare il single point of failure
![Page 5: Evoluzione delle Architetture Distribuite · 5 Motivi dell’evoluzione Tecnologia abilitante • Nascita della rete • Nascita del Client-Rich Driver di business • L’informatizzazione](https://reader030.vdocuments.mx/reader030/viewer/2022021809/5c65922e09d3f2876e8cd70f/html5/thumbnails/5.jpg)
9
Il Modello a Layer
Separazione delle funzionalità logiche del software in livelliDefinizione chiara delle interfacce e dei protocolli di comunicazione tra i livelliPossibilità di ogni livello di chiedere e fornire servizi a livelli diversiPossibilità di apportare modifiche ai vari livelli limitando al minimo l’impatto di tali modifiche su altri livelli
10
Tre Livelli
• Client-tier: livello dell’interfaccia utente, generalmente un client “leggero”
• Business-tier: livello dove risiedono i componenti che implementano la logica di business
• Resource-tier: livello dei sistemi informativi di back-end che si occupano della gestione dei dati e nel caso delle banche della gran parte delle funzioni core
![Page 6: Evoluzione delle Architetture Distribuite · 5 Motivi dell’evoluzione Tecnologia abilitante • Nascita della rete • Nascita del Client-Rich Driver di business • L’informatizzazione](https://reader030.vdocuments.mx/reader030/viewer/2022021809/5c65922e09d3f2876e8cd70f/html5/thumbnails/6.jpg)
11
Tre Livelli
Pro:• Scalabile• Sicurezza a livello di servizio• Incapsulamento della
business logic
Contro:• Difficoltà nel design,
sviluppo e amministrazione
Resource-TierClient-Tier
Dati
Business-Tier
12
Verso il modello distribuito
La necessità di specializzare i server per servizi diversiLa necessità di maggiore scalabilitàLa necessità di un’alta affidabilità e bilanciamento del caricoLa necessità di integrare servizi che risiedono su server differenti
![Page 7: Evoluzione delle Architetture Distribuite · 5 Motivi dell’evoluzione Tecnologia abilitante • Nascita della rete • Nascita del Client-Rich Driver di business • L’informatizzazione](https://reader030.vdocuments.mx/reader030/viewer/2022021809/5c65922e09d3f2876e8cd70f/html5/thumbnails/7.jpg)
13
Verso il modello distribuito: rischi di un’evoluzione non controllata
Resource-TierClient-Tier
Dati
Web-Tier
Dati
Business-Tier
14
Il Middleware
I Middleware: letteralmente lo strato posto nel mezzo, vanno a coprire le necessità di integrazione e comunicazione delle applicazioni distribuiteComunemente i Middleware sono suddivisibili in tre macro-aree:– Basic Middleware ad esempio: Remote Procedure Call Based
Middleware (RPC), Message Oriented Middleware (MOM), Distributed Object Computing Middleware (DOC)
– Platform Middleware ad esempio: gli Application Servers, i TPMonitor, gli ORB e i Web Integration Servers
– Integration Middleware ad esempio: gli Integration Broker e i Business Process Managers
![Page 8: Evoluzione delle Architetture Distribuite · 5 Motivi dell’evoluzione Tecnologia abilitante • Nascita della rete • Nascita del Client-Rich Driver di business • L’informatizzazione](https://reader030.vdocuments.mx/reader030/viewer/2022021809/5c65922e09d3f2876e8cd70f/html5/thumbnails/8.jpg)
15
Vantaggi dei Middleware a oggetti distribuiti
• Permette di razionalizzare le comunicazioni• Porta ad un’uniformità tecnologica e applicativa• Espone un’interfaccia chiara per l’accesso ai servizi
16
Gli architetti di applicazioni distribuite notano che nel disegno del livello intermedio si devono affrontare una serie di problemi indipendenti dal business domain
Application Server
![Page 9: Evoluzione delle Architetture Distribuite · 5 Motivi dell’evoluzione Tecnologia abilitante • Nascita della rete • Nascita del Client-Rich Driver di business • L’informatizzazione](https://reader030.vdocuments.mx/reader030/viewer/2022021809/5c65922e09d3f2876e8cd70f/html5/thumbnails/9.jpg)
17
Problemi comuni
• Lifecycle degli oggetti server (persistenza dei dati)• Controllo della concorrenza degli accessi• Autenticazione centralizzata• Controllo delle transazioni• Trasparenza rispetto allo strato di comunicazione
18
Ambienti di esecuzione controllata
![Page 10: Evoluzione delle Architetture Distribuite · 5 Motivi dell’evoluzione Tecnologia abilitante • Nascita della rete • Nascita del Client-Rich Driver di business • L’informatizzazione](https://reader030.vdocuments.mx/reader030/viewer/2022021809/5c65922e09d3f2876e8cd70f/html5/thumbnails/10.jpg)
19
Ambienti di esecuzione controllata
• Tipicamente si trovano in architetture a tre livelli• Il livello 2 (business logic) deve affrontare una serie
di problemi indipendenti dall’ambito dell’applicazione e generalmente trasversali rispetto a tutti i tipi di applicazioni
20
Problemi comuni
• Lifecycle degli oggetti server (persistenza dei dati)• Controllo della concorrenza degli accessi• Controlli di sicurezza• Controllo delle transazioni• Trasparenza rispetto allo strato di comunicazione
Alcuni di questi ricalcano da vicino i temi affrontati dai CORBA Services
![Page 11: Evoluzione delle Architetture Distribuite · 5 Motivi dell’evoluzione Tecnologia abilitante • Nascita della rete • Nascita del Client-Rich Driver di business • L’informatizzazione](https://reader030.vdocuments.mx/reader030/viewer/2022021809/5c65922e09d3f2876e8cd70f/html5/thumbnails/11.jpg)
21
Interception
Queste problematiche vengono gestite dall’applicationserver (container) con la tecnica dell’interception:– Il componente server non è direttamente in ascolto delle
richieste di servizio. – Gli viene anteposto un server controllato dal container
che esegue delle preelaborazioni
22
Interception
Container
Server
Smart Skeleton
Client
![Page 12: Evoluzione delle Architetture Distribuite · 5 Motivi dell’evoluzione Tecnologia abilitante • Nascita della rete • Nascita del Client-Rich Driver di business • L’informatizzazione](https://reader030.vdocuments.mx/reader030/viewer/2022021809/5c65922e09d3f2876e8cd70f/html5/thumbnails/12.jpg)
23
Lifecycle
• Creazione e distruzione degli oggetti server• Gestione automatica dei momenti di sincronizzazione
col database
24
Lifecycle
![Page 13: Evoluzione delle Architetture Distribuite · 5 Motivi dell’evoluzione Tecnologia abilitante • Nascita della rete • Nascita del Client-Rich Driver di business • L’informatizzazione](https://reader030.vdocuments.mx/reader030/viewer/2022021809/5c65922e09d3f2876e8cd70f/html5/thumbnails/13.jpg)
25
Controllo della concorrenza
• Serializzazione degli accessi agli oggetti:– Per oggetto– Per metodo
• Gestione di pool di oggetti equivalenti
26
Controlli di sicurezza
La gestione dei controlli di sicurezza non dovrebbe essere a carico dell’applicazione. – Integrabile con sistemi di directory esterni – Definita sulla base di una configurazione passata
all’application server, la definizione può essere per• Dominio applicativo • Oggetto• Singolo metodo• Metodo
Ci sono due temi da affrontare:– Autenticazione– Autorizzazione
![Page 14: Evoluzione delle Architetture Distribuite · 5 Motivi dell’evoluzione Tecnologia abilitante • Nascita della rete • Nascita del Client-Rich Driver di business • L’informatizzazione](https://reader030.vdocuments.mx/reader030/viewer/2022021809/5c65922e09d3f2876e8cd70f/html5/thumbnails/14.jpg)
27
Controllo delle transazioni
• Delimitazioni delle transazioni a carico del container• Il container gestisce le risorse di carattere
transazionale– Database– Sistemi di messaging– Sistemi legacy
28
Controllo delle transazioni
Server Container Risorsa
getRisorsa()
beginTransaction()
Operazione1()
Operazione2()
releaseRisorsa()commitTransaction()
![Page 15: Evoluzione delle Architetture Distribuite · 5 Motivi dell’evoluzione Tecnologia abilitante • Nascita della rete • Nascita del Client-Rich Driver di business • L’informatizzazione](https://reader030.vdocuments.mx/reader030/viewer/2022021809/5c65922e09d3f2876e8cd70f/html5/thumbnails/15.jpg)
29
Trasparenza rispetto allo strato di comunicazione
• Il container può essere in grado di ricevere richieste di servizio su più di un protocollo e quindi “tradurre” queste richieste in chiamate al server
• Questa è una caratteristica avanzata:– Primi tentativi di avere server CORBA e di WebServices.
30
Container
IIOPListener
RMIListener
SOAPListener
ControlloConcorrenza
AutenticazioneCentralizzata DatabaseServer Persistenza
![Page 16: Evoluzione delle Architetture Distribuite · 5 Motivi dell’evoluzione Tecnologia abilitante • Nascita della rete • Nascita del Client-Rich Driver di business • L’informatizzazione](https://reader030.vdocuments.mx/reader030/viewer/2022021809/5c65922e09d3f2876e8cd70f/html5/thumbnails/16.jpg)
31
Tipi di servizi
• Sincroni – direttamente invocati da un client• Asincroni – innescati da eventi quali:
– Messaggi– Timer
32
Confronto sistemi di elaborazione distribuita
![Page 17: Evoluzione delle Architetture Distribuite · 5 Motivi dell’evoluzione Tecnologia abilitante • Nascita della rete • Nascita del Client-Rich Driver di business • L’informatizzazione](https://reader030.vdocuments.mx/reader030/viewer/2022021809/5c65922e09d3f2876e8cd70f/html5/thumbnails/17.jpg)
33
Sistemi di elaborazione distribuita
• Esistono molti altri sistemi di elaborazione distribuita oltre a CORBA– RMI– DCOM– SOAP
• Quale scegliere in un progetto?
34
CORBA
• E’ uno standard (OMG)• E’ multilinguaggio• E’ multipiattaforma• Usa come protocollo di trasporto IIOP su reti IP• Usa come formato dati un formato proprietario
(definito con IDL)
![Page 18: Evoluzione delle Architetture Distribuite · 5 Motivi dell’evoluzione Tecnologia abilitante • Nascita della rete • Nascita del Client-Rich Driver di business • L’informatizzazione](https://reader030.vdocuments.mx/reader030/viewer/2022021809/5c65922e09d3f2876e8cd70f/html5/thumbnails/18.jpg)
35
RMI
• E’ il sistema di elaborazione distribuita del mondo java
• E’ monolinguaggio• E’ multipiattaforma• Come protocollo di trasporto usa RMI Wire protocol di
default ma può usare IIOP o HTTP (con alcune limitazioni)
• Come formato dati usa il formato di serializzazionedegli oggetti java
36
DCOM (.Net Remote)
• E’ il sistema di elaborazione distribuita del mondo microsoft
• E’ multilinguaggio (il linguaggio deve essere supportato da microsoft)
• E’ monopiattaforma • Come protocollo usa un protocollo proprietario • Come formato dati usa un formato proprietario
![Page 19: Evoluzione delle Architetture Distribuite · 5 Motivi dell’evoluzione Tecnologia abilitante • Nascita della rete • Nascita del Client-Rich Driver di business • L’informatizzazione](https://reader030.vdocuments.mx/reader030/viewer/2022021809/5c65922e09d3f2876e8cd70f/html5/thumbnails/19.jpg)
37
SOAP
• E’ uno standard (W3C)• E’ multilinguaggio• E’ multipiattaforma• Può usare molti protocolli, in particolare è importante
HTTP• Come formato dati usa XML
38
Schema riassuntivo
XMLProprietarioProprietarioProprietarioFormato dati
HTTP e altri ProprietarioRMI WireprotocolIIOPProtocollo
SìNoSìSìMultipiattaforma
SìSìNoSìMultilinguaggio
SìNoNoSìStandard
SOAPDCOMRMICORBA
![Page 20: Evoluzione delle Architetture Distribuite · 5 Motivi dell’evoluzione Tecnologia abilitante • Nascita della rete • Nascita del Client-Rich Driver di business • L’informatizzazione](https://reader030.vdocuments.mx/reader030/viewer/2022021809/5c65922e09d3f2876e8cd70f/html5/thumbnails/20.jpg)
39
Importanza dell’architettura: un esempio reale
40
Un esempio Reale
Istituto assicurativo che diventa banca e vuole offrire tutti i propri servizi via web– I servizi assicurativi sono gestiti dal CED interno– I servizi bancari sono appaltati ad un ASP esterno– Si introduce un’applicazione di CRM con l’obiettivo di
avere un’anagrafica unica del cliente.
![Page 21: Evoluzione delle Architetture Distribuite · 5 Motivi dell’evoluzione Tecnologia abilitante • Nascita della rete • Nascita del Client-Rich Driver di business • L’informatizzazione](https://reader030.vdocuments.mx/reader030/viewer/2022021809/5c65922e09d3f2876e8cd70f/html5/thumbnails/21.jpg)
41
Architettura (attuale)
Internet
Call Center
Agenzie
Canali di accesso
Motore di integrazione
CRM
Servizi bancari
Servizi Assicurativi
CO
RB
A
Servizi aziendali
CORBA
CICS
Emulazione 3270
JDBC
Database
42
Architettura (attuale)
Problemi:– Impossibilità di effettuare transazioni che coinvolgano
più di una sorgente dati.– Disomogeneità dei protocolli di comunicazione– Disomogeneità dei formati di comunicazione
![Page 22: Evoluzione delle Architetture Distribuite · 5 Motivi dell’evoluzione Tecnologia abilitante • Nascita della rete • Nascita del Client-Rich Driver di business • L’informatizzazione](https://reader030.vdocuments.mx/reader030/viewer/2022021809/5c65922e09d3f2876e8cd70f/html5/thumbnails/22.jpg)
43
Operazioni su più sorgenti dati
Necessaria per qualunque operazione perché l’applicazione utilizza sempre un’applicazione aziendale e il proprio database.
Soluzione:– Introduzione del protocollo two phase commit.
44
Disomogeneità dei dati e dei protocolli
Non è un problema insormontabile, ma complica la vita al programmatore che deve rifare le stesse cose per ogni formato dati e per ogni protocollo (avere diversi protocolli introduce sempre dei problemi di carattere tecnologico)
Soluzione:– Introduzione di un’unica interfaccia verso le applicazioni
aziendali.– Definizione di un unico formato dati per descrivere le
transazioni
![Page 23: Evoluzione delle Architetture Distribuite · 5 Motivi dell’evoluzione Tecnologia abilitante • Nascita della rete • Nascita del Client-Rich Driver di business • L’informatizzazione](https://reader030.vdocuments.mx/reader030/viewer/2022021809/5c65922e09d3f2876e8cd70f/html5/thumbnails/23.jpg)
45
Architettura (a tendere)
Internet
Call Center
Agenzie
Canali di input
Motore di integrazione
CRM
Servizi bancari
Servizi Assicurativi
Database
CO
RB
A
Servizi aziendali
JDBC
Coda di messaggi
Two phase commit
JMS (XML)
46
Necessità di un’architettura controllata
• A fronte delle richieste del business il sistema informativo è costretto a crescere, modificarsi e adeguarsi.
• Uno sviluppo non coordinato secondo criteriarchitetturali porta ad un sistema complesso e difficilmente controllabile.
![Page 24: Evoluzione delle Architetture Distribuite · 5 Motivi dell’evoluzione Tecnologia abilitante • Nascita della rete • Nascita del Client-Rich Driver di business • L’informatizzazione](https://reader030.vdocuments.mx/reader030/viewer/2022021809/5c65922e09d3f2876e8cd70f/html5/thumbnails/24.jpg)
47
Aspetti principali dell’architettura enterprise
“Pattern di disegno architetturale”
• Hardware• Sistemi operativi• Linguaggi• DBMS• Middleware• …
• Modello degli oggetti• Modello dei dati• Modello dei processi• Database condivisi• Riuso dei componenti software• Modello degli eventi• …
• Due livelli/multilivello• Fat client/thin client• Architettura
centralizzata o distribuita
• …
Gestione delle informazioniArchitettura tecnologica
Concetti riusabili spesso raccolti in common
practices.
Modelli fortemente dipendenti dal business d’azienda. Riferimenti
disponibili in best practices
Standard tecnologici definiti internamente
all’azienda.
48
Problemi e difficoltà dell’evoluzione
Problemi di uniformità: • Dell’architettura tecnologica• Dell’architettura applicativa• Dell’informazione
![Page 25: Evoluzione delle Architetture Distribuite · 5 Motivi dell’evoluzione Tecnologia abilitante • Nascita della rete • Nascita del Client-Rich Driver di business • L’informatizzazione](https://reader030.vdocuments.mx/reader030/viewer/2022021809/5c65922e09d3f2876e8cd70f/html5/thumbnails/25.jpg)
49
Problemi di uniformità tecnologica ed applicativa
• Applicazioni legacy• Applicazioni acquistate• Progresso tecnologico• Sistemi sviluppati ad hoc
Applicazione Custom Pacchetto commerciale Applicazioni Legacy
50
Problemi di uniformità dell’informazione
Modello degli oggettiModello dei datiModello dei processiDatabase condivisiRiuso dei componenti softwareModello degli eventi
Applicazione Nuova
Cliente
Applicazione Legacy
Cliente
Esposizione dell’oggettocliente
![Page 26: Evoluzione delle Architetture Distribuite · 5 Motivi dell’evoluzione Tecnologia abilitante • Nascita della rete • Nascita del Client-Rich Driver di business • L’informatizzazione](https://reader030.vdocuments.mx/reader030/viewer/2022021809/5c65922e09d3f2876e8cd70f/html5/thumbnails/26.jpg)
51
Benefici di un’architettura
• Standardizzazione– Efficienza– Sfruttamento della tecnologia– Controllo dei costi
• Workflow– Processi di business modellati nel sistema– Interoperabilità delle funzioni di business– Integrazione delle applicazioni
• Vision– Agilità nel cambiamento– Capacità di cogliere le opportunità di business– Competitività
52
Evoluzione delle architetture
Applicazioni verticali debolmente accoppiate
(batch), spesso tecnologicamente
disomogenee
Insieme di sistemi informativi, o evoluzione di un S.I., dove tipicamente i
dati sono scambiati in maniera asincrona
Insieme di applicazioni distribuite che devono
potere comunicare fra loro point-to-point
Insieme di applicazioni distribuite che devono
potere comunicare fra loro in maniera sincrona usando di un bus
1970 1980 1990 2000
Le esigenze di business rendono sempre più importante l’integrazione tra componenti e sistemi
![Page 27: Evoluzione delle Architetture Distribuite · 5 Motivi dell’evoluzione Tecnologia abilitante • Nascita della rete • Nascita del Client-Rich Driver di business • L’informatizzazione](https://reader030.vdocuments.mx/reader030/viewer/2022021809/5c65922e09d3f2876e8cd70f/html5/thumbnails/27.jpg)
53
Modello ideale
Bus di comunicazione Enterprise
Suite di applicazioni Applicazione a 2 livelli
Applicazione legacy Applicazione acquistata Applicazione ad hoc
Società prodotto
MarketplaceConfine del sistem
a informativo
54