Evoluzione delle Architetture Distribuite
1
Evoluzione dell’architettura
Dall’architettura centralizzata all’architettura distribuita
Applicazioni centralizzate
Terminali
Applicazioni Client/Server
Mainframe
Client
Applicazioni Multi-Tier
Server
Client-Tier
Middle-Tier
Resource-Tier
Dati
Dati
Dati
Dati
1980
1990
2
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
3
Modello centralizzato (continua …)
Pro:
• Sicurezza a livello di funzioni
• Efficiente
(non si ha l’overhead di
comunicazione remota)
• Sviluppo relativamente
semplice
1980
Terminali
Terminali
Contro:
• Hardware costoso
• Chiuso (problemi di
integrazione)
• Scalabilità solo verticale
Dati
Mainframe
4
Motivi dell’evoluzione
Tecnologia abilitante
• Nascita della rete
• Nascita del Client-Rich
Driver di business
• L’informatizzazione raggiunge le piccolemedie imprese
5
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
6
Modello Client/Server
Pro:
• Hardware e sviluppo
poco costoso
• Aperto
Contro:
Fat-Client
Server
Logica di
business
• Alti costi di amministrazione
(Total Cost of Ownership)
• Sicurezza a livello di dati
• Poco scalabile
Dati
7
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
8
Il Modello a Layer
Separazione delle funzionalità logiche del
software in livelli
Definizione chiara delle interfacce e dei
protocolli di comunicazione tra i livelli
Possibilità di ogni livello di chiedere e fornire
servizi a livelli diversi
Possibilità di apportare modifiche ai vari livelli
limitando al minimo l’impatto di tali modifiche su
altri livelli
9
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
10
Tre Livelli
Pro:
• Scalabile
• Sicurezza a livello di servizio
• Incapsulamento della
business logic
Client-Tier
Business-Tier
Resource-Tier
Contro:
• Difficoltà nel design,
sviluppo e amministrazione
Dati
11
Verso il modello distribuito
La necessità
La necessità
La necessità
La necessità
differenti
di
di
di
di
specializzare i server per servizi diversi
maggiore scalabilità
un’alta affidabilità e bilanciamento del carico
integrare servizi che risiedono su server
12
Verso il modello distribuito: rischi di un’evoluzione non controllata
Client-Tier
Web-Tier
Business-Tier
Resource-Tier
Dati
Dati
13
Il Middleware
I Middleware: letteralmente lo strato posto nel mezzo,
vanno a coprire le necessità di integrazione e
comunicazione delle applicazioni distribuite
Comunemente i Middleware sono suddivisibili in tre macroaree:
– 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
14
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
15
Application Server
Gli architetti di applicazioni distribuite notano che nel
disegno del livello intermedio si devono affrontare una
serie di problemi indipendenti dal business domain
16
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
17
Ambienti di esecuzione controllata
18
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
19
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
20
Interception
Queste problematiche vengono gestite dall’application
server (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
21
Interception
Container
Client
Smart Skeleton
Server
22
Lifecycle
• Creazione e distruzione degli oggetti server
• Gestione automatica dei momenti di sincronizzazione
col database
23
Lifecycle
24
Controllo della concorrenza
• Serializzazione degli accessi agli oggetti:
– Per oggetto
– Per metodo
• Gestione di pool di oggetti equivalenti
25
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
26
Controllo delle transazioni
• Delimitazioni delle transazioni a carico del container
• Il container gestisce le risorse di carattere
transazionale
– Database
– Sistemi di messaging
– Sistemi legacy
27
Controllo delle transazioni
Server
Container
Risorsa
getRisorsa()
beginTransaction()
Operazione1()
Operazione2()
releaseRisorsa()
commitTransaction()
28
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.
29
Container
IIOP
Listener
RMI
Listener
Controllo
Concorrenza
Autenticazione
Centralizzata
Server
Persistenza
Database
SOAP
Listener
30
Tipi di servizi
• Sincroni – direttamente invocati da un client
• Asincroni – innescati da eventi quali:
– Messaggi
– Timer
31
Confronto sistemi di elaborazione distribuita
32
Sistemi di elaborazione distribuita
• Esistono molti altri sistemi di elaborazione distribuita
oltre a CORBA
– RMI
– DCOM
– SOAP
• Quale scegliere in un progetto?
33
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)
34
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 serializzazione
degli oggetti java
35
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
36
SOAP
•
•
•
•
E’ uno standard (W3C)
E’ multilinguaggio
E’ multipiattaforma
Può usare molti protocolli, in particolare è importante
HTTP
• Come formato dati usa XML
37
Schema riassuntivo
CORBA
RMI
DCOM
SOAP
Standard
Sì
No
No
Sì
Multilinguaggio
Sì
No
Sì
Sì
Multipiattaforma
Sì
Sì
No
Sì
Protocollo
IIOP
RMI Wire
protocol
Proprietario
HTTP e altri
Formato dati
Proprietario
Proprietario
Proprietario
XML
38
Importanza dell’architettura: un esempio reale
39
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.
40
Architettura (attuale)
Servizi aziendali
Canali di accesso
Internet
CRM
CORBA
CORBA
Call Center
Motore di integrazione
Servizi bancari
Emulazione 3270
CICS
Agenzie
JDBC
Servizi Assicurativi
Database
41
Architettura (attuale)
Problemi:
– Impossibilità di effettuare transazioni che coinvolgano
più di una sorgente dati.
– Disomogeneità dei protocolli di comunicazione
– Disomogeneità dei formati di comunicazione
42
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.
43
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
44
Architettura (a tendere)
Canali di input
Servizi aziendali
Internet
CRM
Agenzie
CORBA
Call Center
JMS (XML)
Motore di integrazione
Coda di
messaggi
Servizi bancari
Servizi Assicurativi
JDBC
Two phase commit
Database
45
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 criteri
architetturali porta ad un sistema complesso e
difficilmente controllabile.
46
Aspetti principali dell’architettura enterprise
Architettura tecnologica
•
•
•
•
•
•
Hardware
Sistemi operativi
Linguaggi
DBMS
Middleware
…
Standard tecnologici
definiti internamente
all’azienda.
“Pattern di disegno
architetturale”
• Due livelli/multilivello
• Fat client/thin client
• Architettura
centralizzata o
distribuita
• …
Concetti riusabili spesso
raccolti in common
practices.
Gestione delle informazioni
•
•
•
•
•
•
•
Modello degli oggetti
Modello dei dati
Modello dei processi
Database condivisi
Riuso dei componenti software
Modello degli eventi
…
Modelli fortemente
dipendenti dal business
d’azienda. Riferimenti
disponibili in best practices
47
Problemi e difficoltà dell’evoluzione
Problemi di uniformità:
• Dell’architettura tecnologica
• Dell’architettura applicativa
• Dell’informazione
48
Problemi di uniformità tecnologica ed applicativa
•
•
•
•
Applicazioni legacy
Applicazioni acquistate
Progresso tecnologico
Sistemi sviluppati ad hoc
Applicazione Custom
Pacchetto commerciale
Applicazioni Legacy
49
Problemi di uniformità dell’informazione
Esposizione dell’oggetto
cliente
Modello degli oggetti
Modello dei dati
Modello dei processi
Database condivisi
Riuso dei componenti
software
Modello degli eventi
Cliente
Applicazione Legacy
Cliente
Applicazione Nuova
50
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à
51
Evoluzione delle architetture
Le esigenze di business rendono sempre più importante
l’integrazione tra componenti e sistemi
Applicazioni verticali
debolmente accoppiate
(batch), spesso
tecnologicamente
disomogenee
1970
1980
Insieme di applicazioni
distribuite che devono
potere comunicare fra loro
point-to-point
1990
Insieme di applicazioni
distribuite che devono
potere comunicare fra loro
in maniera sincrona
usando di un bus
Insieme di sistemi
informativi, o evoluzione di
un S.I., dove tipicamente i
dati sono scambiati in
maniera asincrona
2000
52
Modello ideale
Co
n
Marketplace
Applicazione a 2 livelli
Suite di applicazioni
fin
e
de
ls
is
te
m
a
in
fo
rm
at
iv
o
Bus di comunicazione Enterprise
Applicazione legacy
Applicazione acquistata
Applicazione ad hoc
Società prodotto
53
54
