Evoluzione delle Architetture Distribuite · 5 Motivi dell’evoluzione Tecnologia abilitante •...
Transcript of Evoluzione delle Architetture Distribuite · 5 Motivi dell’evoluzione Tecnologia abilitante •...
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
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
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
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
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
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
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
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
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
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
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
23
Lifecycle
• Creazione e distruzione degli oggetti server• Gestione automatica dei momenti di sincronizzazione
col database
24
Lifecycle
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
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()
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
31
Tipi di servizi
• Sincroni – direttamente invocati da un client• Asincroni – innescati da eventi quali:
– Messaggi– Timer
32
Confronto sistemi di elaborazione distribuita
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)
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
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
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.
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
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
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.
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
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
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
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