Architetture Distribuite,
Middleware,
Distributed Object Computing e
Legacy System
Giuseppe Santucci &...
[email protected]
Argomenti
l
l
l
l
l
l
Concetti di base
Applicazioni Client/Server
Middleware “tradizionale”
Middleware WWW
Distributed Object Computing
Legacy System
2
Concetti di base
applicazioni distribuite
sistemi client/server
architetture a n livelli
middleware
3
Definizione di applicazione distribuita
l
Una semplice definizione di applicazione distribuita (che non
implica necessariamente semplici conseguenze) e’:
“Una applicazione è distribuita se le funzioni coinvolte nella sua
esecuzione sono distribuite tra 2 o più computer”
implica comunicazione
presuppone supporto per eterogeneita’
4
La distribuzione delle applicazioni
l
l
Fino a qualche tempo fa la maggior parte delle applicazioni
giravano all’interno di un singolo sistema
Con il diminuire delle dimensioni e dei costi della macchine, è
diventato vantaggioso distribuire le applicazioni su due o più
sistemi, con i seguenti benefici
» utilizzo di due o più macchine economiche in luogo di una
macchina costosa
» migliore sfruttamento di PC e workstation esistenti
» crescita facilitata dell’ambiente di calcolo
5
Esempio di applicazioni tradizionali
T
T
Applicazione
T
Applicazione
T
T
Database
Applicazione
T
T
6
Esempio di applicazioni distribuite
Applicazione
WS
WS
WS
WS
Database
WS
Applicazione
WS
WS
Applicazione
WS
7
Le “market forces” che guidano l’evoluzione dei
sistemi distribuiti
l
l
In generale le grandi trasformazioni sono guidate da una
combinazione di:
» nuove tecnologie
» nuove necessita’
L’affermarsi dei sistemi distribuiti e dei sistemi Client/Server
(C/S) viene influenzata da tre fenomeni:
» downsizing
» upsizing
» rightsizing
8
Downsizing
l
l
l
l
Migrazione verso il basso delle applicazioni di business da super
mini e mainframe verso PC e workstation
Il processo di Downsizing partiziona le grandi applicazioni pensate
per i mainframe in moduli che vengono fatti operare su uno o piu’
server connessi in rete
Le funzioni di interfaccia utente si spostano verso workstation
client. Vengono rimpiazzati i vecchi terminali a carattere con
moderne interfacce grafiche
Soluzioni C/S basate su hardware standard e low-cost sono gli
impulsi principali che governano il processo di downsizing.
9
Upsizing
l
l
Il processo di Upsizing rappresenta il processo bottom-up che
porta reti isolate di PC ad assumere le caratteristiche di sistemi
dipartimentali
Connessione dei PC in LAN
» In origine le LAN venivano usate per condividere costose
periferiche
» Poi si e’ passati a sistemi di e-mail, di file system distribuiti e
database condivisi
» Applicazioni distribuite C/S
10
Rightsizing
l
l
l
l
l
Il rightsizing rappresenta il processo attraverso il quale le
applicazioni vengono collocate nella più appropriata piattaforma
I client richiedono servizi sulla rete e tali servizi vengono forniti
dai “migliori server” che li offrono
In questo modello un server puo’ essere un PC un supermini o
anche un mainframe
Server differenti possono coesistere: la rete e’ il sistema
Il rightsizing fa in modo che la domanda e l’offerta di servizi
possano incontrarsi nel modo migliore
11
Evoluzione dei modelli architetturali
l
l
l
l
Anni ’60-’70: architettura centralizzata, monolitica
» host (mainframe, mini) a cui vengono collegati terminali
“stupidi”
» a tutt’oggi è l’architettura dominante
Anni ’80: reti locali di PC
» terminali dotati di intelligenza propria, che condividono risorse
“pregiate”, come stampanti, dischi, etc.
Fine anni ’80 - Inizio anni ’90: applicazioni pienamente
distribuite, modello client-server
» reti locali di PC e server, connesse su collegamenti geografici
Metà-fine anni ’90: Internet, WWW, Distributed Object
Computing
» sistemi network-centrici (“the network is the computer”)
12
Il middleware
Interfaccia
Utente
Applicazione
Software
di
Base
Hardware
Interfaccia
Utente
zione
Interfaccia
Utente
Interfaccia
Utente
Applicazione
Applicazione
Middleware e
servizi distribuiti
Software
di
Base
Software
di
Base
Hardware
Hardware
Interfaccia
Utente
plicazione
RETE
13
Il modello Client-Server
l
Una semplice definizione (che non implica ... ) è:
» “La divisione di un’applicazione in compiti eseguiti su due
computer diversi, uno dei quali è una stazione di lavoro
programmabile”
14
Caratteristiche delle applicazioni client-server
l
l
l
l
l
l
l
Il concetto di servizio
Condivisione delle risorse
Protocolli di comunicazione asimmetrici
Trasparenza della posizione fisica (location)
Indipendenza dalle piattaforme hardware/software (“mix and match”)
Scambi di informazioni basati su messaggi
“Incapsulamento” dei servizi
15
Architetture a più livelli
l
l
l
Diversi concetti di livelli architetturali
» livelli hardware
» livelli software fisici
» livelli software logici
» livelli applicativi
Il concetto sul quale ci concentriamo principalmente è quello di
livello applicativo
» vale a dire di quali moduli fondamentali si compone una
applicazione
Vedremo che esistono applicazioni a 2, 3, ed in generale n livelli
» il salto concettuale avviene tuttavia tra le architetture a 2 livelli
e quelle a 3 livelli
16
Modelli architetturali distribuiti
l
Identificazione preliminare di componenti dell’applicazione
» Frammentazione delle applicazioni in livelli (o strati)
applicativi
» Gli strati costitutivi di una applicazione sono 3
– Gestione Dati
– Applicazione
– Presentazione
l
Localizzazione dei componenti secondo la classificazione sopra
riportata
17
La classificazione del Gartner Group
Gestione Dati
Gestione Dati
Gestione Dati
Applicazione
Applicazione
Applicazione
Presentazione
R
Gestione Dati
Gestione Dati
Gestione Dati
ete
Applicazione
Applicazione
Applicazione
Presentazione
Presentazione
•
•
Presentazione
Presentazione
Presentazione
Œ
•
Ž
Fonte : Gartner Group, 1991
1 - Distributed Presentation
2 - Remote Presentation
3 - Distributed Function
4 - Remote Data Management
5 - Distributed Database
18
Gestione Dati
Distributed Presentation
Applicazione
Presentazione
Presentazione
Server
Centrale o
Sistema
Preesistente
Gestione Dati
Funzione Aziendale Automatizzata
“L’Applicazione”
Logica di controllo
Presentazione
Sito X
Rete
Locale o Geografica
Sito Y
Sistemi
Client
Terminale
Personal Computer
Workstation
19
Gestione Dati
Applicazione
Remote Presentation
Server
Centrale o
Sistema
Preesistente
Presentazione
Sito X
Logica di controllo
e Presentazione
all’interno dei
Gestione Dati
Funzione Aziendale
Automatizzata
“L’Applicazione”
Rete
Locale o Geografica
Sito Y
Sistemi
Client
Terminale
l
Personal Computer
Workstation
“Ultra-Thin” Client: la collaborazione del client
nell’elaborazione dell’applicazione è ridotta a funzioni minime
20
Gestione Dati
Applicazione
Distributed Function
Applicazione
Presentazione
Gestione Dati
Funzioni Aziendali
Automatizzate
Comuni
“L’Applicazione
Server”
Server
Centrale o
Sistema
Preesistente
Sito X
Rete
Locale o Geografica
Funzioni Aziendali Automatizzate
Specifiche per l’utente
“L’Applicazione Client”
Sistemi
Client
Personal Computer
l
Sito Y
Logica di controllo
Presentazione
“Thin” Client: la collaborazione del client nell’elaborazione
dell’applicazione è limitata alle funzioni di pertinenza dell’utente
del client
21
Gestione Dati
Remote Data Management
Applicazione
Presentazione
Server
di Gestione
dei Dati
Aziendali
Sito X
Base Dati Aziendale
Sistema di
Gestione delle
Informazioni
Memorizzate
Rete
Locale o Geografica
Funzioni Aziendali
Automatizzate
Specifiche per l’utente
“L’Applicazione Client”
Sistemi
Client
Personal Computer
l
Sito Y
Logica di controllo
Presentazione
“Fat” Client: il client non si limita a servire le specificità del
proprio utente, ma contiene la logica applicativa relativa
all’intera applicazione
22
Gestione Dati
Distributed Data Management
Gestione Dati
Applicazione
Presentazione
Base Dati Aziendale
Server di Gestione
dei Dati Aziendali
Centrale
Sito X
Sistema di Gestione delle
Informazioni Memorizzate
Rete
Locale o Geografica
Sistemi
Client
PC
Funzioni Aziendali
Automatizzate
Specifiche per l’utente
“L’Applicazione Client”
Logica di controllo
Presentazione
Sito Y
Server
di Gestione
dei Dati
Aziendali
Locale
Base Dati Aziendale
Sistema di Gestione delle
Informazioni
Memorizzate
23
L’evoluzione da due a tre livelli
2-Livelli con Scambio Dati
Monolitico
Host
Server
DBMS
DBMS
Dati
Programma Utente con Gestione dell’I/O su
Schermo
Data Stream verso il terminale ”stupido”
Server
DBMS
con “stored procedure”
Dati
Programma Utente con Gestione dell’I/O su
Schermo
Client
Server
Dati
Programma Utente
Messaggi
Programma Utente con Gestione dell’I/O su
Schermo
Messaggi
Gestione dell’I/O su Schermo
Client
2-Livelli con Scambio Msg
DBMS
Client
Client/Server a 3-Livelli
24
Il passaggio a n livelli
Server
Server
DBMS
Dati
Programma Utente
DBMS, eventualmente
con stored procedure
Dati/Messaggi
Programma Utente
Messaggi
Gestione dell’I/O su Schermo
Client
Client/Server a 3 Livelli
Messaggi
Programma Utente (eventuale) con Gestione
dell’I/O su Schermo
Client
Client/Server a n Livelli
25
Requisiti e problemi di un ambiente
distribuito: il ruolo del middleware
l
Classi di requisiti cui deve soddisfare un ambiente distribuito
»
»
»
»
»
»
comunicazione
parallelismo
localizzazione dei servizi
security
sincronizzazione dei clock
Supporto per client di tipo diverso
26
Middleware
l
l
l
Il termine middleware e’ usato per indicare tutto il software necessario
per supportare l’interazione tra Client e Server
E’ la “/” tra client e Server, cioe’ l’insieme delle funzioni software che
vengono utilizzate per consentire al cient di ottenere un servizio dal
server
Dove inizia e dove finisce il campo d’azione del middlware?
» inizia sulle API del lato Client usate per invocare i servizi
» copre la trasmissione della richiesta e della risposta sulla rete
» non include il software che produce il servizio
» non include l’interfaccia utente
27
Middleware
l
l
Una prima classificazione del middleware puo’ essere la seguente:
General middleware: il substrato piu’ comune per C/S.
»
»
»
»
»
l
directory distribuite,
servizi di autenticazione,
servizi di timing,
remote procedure call,
servizi per la gestione delle code di messaggi
Service specific middleware: necessario per particolari tipi di servizi.
»
»
»
»
»
Database (ODBC)
Transazioni (Tuxedo, Enchina...)
Groupware (workflow)
Object specific (ORB)
WWW middleware !!!
28
Un esempio famoso (storico ?) di middleware: OSF
DCE
Diskless Support
Service
Other Distributed
Services (Future)
OSF=Open Software Foundation (oggi
Open Group)
DCE = Distributed Computing Environment
Time
Service
y
Service
Other Fundamental
Services (Future)
t
Remote Procedure Calls
Threads
OPERATING SYSTEM AND TRANSPORT SERVICES
Modello architetturale indotto da DCE
PCs
Server
HOST
29
OSF/DCE struttura cellulare
Cellula A
LAN
Cellula C
LAN
WAN
Cellula B
LAN
30
Applicazioni Client/Server
(& general middleware)
Caratteristiche di un sistema C/S
l
Cosa rende i sistemi C/S differenti da altre forme di software
distribuito?
l
Relazione di Servizio: la relazione di C/S e’ una relazione tra
processi che possono essere localizzati su macchine differenti.
» Il processo server e’ un fornitore di servizi
» il processo client e’ un consumatore di servizi
32
Caratteristiche di un sistema C/S
l
l
l
l
Risorse condivise: un server puo’ servire piu’ client alla volta e
regolare il loro accesso a risorse condivise
Protocolli asimmetrici: Esiste una relazione molti ad uno tra client e
server. I client avviano il dialogo richiedendo un servizio. I server
attendono passivamente le richieste.
Trasparenza rispetto alla locazione: Un server e’ un processo che
puo’ risiedere sulla stessa macchina del client o su una macchina
diversa connessa in rete. Il software C/S tipicamente maschera la
locazione del server rispetto al client redirigendo l’invocazione del
servizio.
Comunicazione basata su messaggi: Client e server sono sistemi
accoppiati lascamente che interagiscono attraverso messaggi.
33
Caratteristiche di un sistema C/S
l
l
l
Incapsulamento del servizio: la definizione di un server e’ fatta
rispettando il principio dell’incapsulamento. Un messaggio comunica
al server quale servizio e’ richiesto. Sara’ poi il server a stabilire
come eseguire il compito. I server possono essere modificati
internamente senza comportare una modifica dei client che ne
utilizzano i servizi.
Scalabilita’: I sistemi C/S possono essere scalati orizzontalmente o
verticalmente.
» scalare orizzontalmente significa aggiungere o rimuovere client
con implicazioni esclusivamente a livello prestazionale
» scalare verticalmente significa migrare verso una macchina server
piu’ grande e piu’ veloce
Integrita’: Il codice e i dati del server vengono mantenuti
centralmente, con benefici economici e di sicurezza. Il client,
viceversa, rimane personale e indipendente
34
Architetture e sistemi C/S
l
Molti sistemi con architetture molto differenti tra loro sono stati
definiti sistemi Client/Server
» File servers
» Database servers
» Transaction servers
» Object servers
» Lan servers
» Windows servers
» Authentication servers
35
Fat server o Fat client?
l
l
l
l
l
Le applicazioni C/S possono essere differenziate sulla base di come
l’applicazione e’ suddivisa tra client e server.
Il modello fat server colloca piu’ funzionalita’ sul server
» groupware, transactions, object servers
Il modello fat client assegna maggiore responsabilita’ al client
» database e file server
Fat clients sono la forma piu’ tradizionale di C/S. Il cuore dell’applicazione
gira sulla parte client, i client sono a conoscenza di tutta la logica
dell’applicazione e dei dati.
Applicazioni di tipo fat server sono piu’ facili da manutenere su grandi
installazioni in quanto gran parte del software gira sul server.
» I fat server tendono a minimizzare i messaggi scambiati sulla rete
fornendo servizi a maggior livello di astrazione. Incapsulamento. Invece
di esportare solo dati vengono esportate anche procedure e/o metodi che
operano sui dati.
36
Anatomia di un programma server
l
l
Il ruolo di un programma server e’ quello di servire piu’ client
che hanno interesse ad accedere a risorse condivise
Un tipico programma server fa le seguenti cose:
» attende che i client effettuino delle richieste
» esegue piu’ richieste contemporaneamente
» si occupa di gestire priorita’ nello svolgere il servizio
» puo’ iniziare attivita’ in background
» si mantiene operativo anche in condizioni estreme
» cresce e puo’ richiedere piu’ risorse
37
Threads in ambiente Client/Server
l
l
Sfruttando l’inerente parallelismo dei sistemi distribuiti
» i server possono servire simultaneamente più client
» i client possono effettuare simultaneamente più richieste di
servizio
Flussi di elaborazione in parallelo si definiscono threads
Servers
Clients
38
C /S e sistema operativo
(general middleware)
l
l
l
Un sistema operativo deve fornire dei servizi utili per le tipiche
funzionalita’ richieste da un sistema C/S
Di particolare importanza i concetti di :
» Thread (programma concorrente guidato dagli eventi)
» IPC Interprocess communication (pipe, soket, ecc.)
In un ambiente distribuito, le funzioni del sistema operativo
possono essere:
» funzioni di base
» funzioni estese
39
Servizi di base del SO per il server
l
l
l
l
l
Elevato livello di concorrenza, sia come possibilita’ di gestire piu’
processi (piu’ indipendenza), sia come possibilita’ di gestire piu’ threads
nel singolo processo (piu’ efficienza, meno overhead)
Task Priority. Possibilita’ di differenziare il livello di servizio.
Task Preemption. Molto piu’ potente del multitasking cooperativo
Semafori. Per consentire la sincronizzazione.
Interprocess comunication. Per consentire la comunicazione tra processi.
» local
» remote
40
Servizi di base del SO per il server
l
l
l
l
Threads Per creare efficienti programmi con elevato grado di
parallelismo
Intertask protection Protezione dalle interferenze con le
altre risorse. Un task non deve essere in grado di mandare
giu’ il sistema
Multiuser High Performance file system Elevato numero di
file aperti, locks.
Gestione efficiente della memoria Gestione di
grandi/numerosi programmi, memoria virtuale
41
Servizi estesi del SO per il server
l
I servizi estesi devono consentire un accesso piu’ flessibile alle
informazioni condivise.
» Varieta’ di protocolli di rete
» Estensioni del Network Operating System per consentire un
accesso trasparente alle risorse
» Global directories e Yellow Pages
» Servizi di autorizzazione ed autenticazione
» Network time
» Database e Transaction services
» Servizi di object brokering
42
Anatomia di un programma Client
l
l
l
Il lato client fornisce il “look and feel” dei servizi che il sistema
fornisce
Tutti i client hanno in comune il fatto che richiedono servizi al
server, i programmi client si differenziano su cosa innesca la
richiesta e sul tipo di GUI necessaria.
Sulla base di queste caratteristiche una possibile classificazione
delle applicazioni client e’ la seguente:
» non GUI clients
» GUI client
» OOUI clients
43
Classificazione dei client
l
l
l
Non GUI client. Generano richieste al server con una
interazione umana minima o nulla . Due categorie:
» non richiedono multitasking (bancomat, lettore di codice a
barre)
» necessitano multitasking. Programmi demoni, Robots
GUI. Semplici GUI client sono applicazioni dove l’intervento
umano e’ occasionale. Dialoghi di tipo seriale, presentazione di
grafici.
OOUI client. Interfacce iconiche dove ogni oggetto sullo
schermo e’ un client. Molte sessioni parallele. Alta interazione.
44
Sistemi operativi
l
l
l
l
l
l
l
l
MS-DOS. praticamente non offre nessun servizio tra quelli utili
per una applicazione C/S
UNIX. Molti servizi di base, molte versioni
OS/2. Sistema completo, ma poco affermato
MAC OS. Buono, ma in via di estinzione.
Windows 3.1. Solo GUI, multitasking cooperativo.
Windows ‘95/98. Forma ancora non soddisfacente di
multitasking
Windows NT. Sistema abbastanza completo (task preemption)
ma ancora instabile.
Windows 2000 ?
45
C/S & middleware
API
(Application
Programming
Processo client
Middleware client
7
Processo server
Protocollo
middleware
API
Middleware server
5,6
Interface)
Servizi
Locali
Servizi
di rete
Servizi
Locali
Servizi
di rete
4,3
Sistema operativo
Sistema operativo
2
Hardware
Hardware
1
ISO/OSI
46
Middleware “tradizionale”
47
Livelli del middleware (1)
l
l
Servizi di rete a basso livello ? (soket, SNA logical unit,
NetBios)
servizi primitivi
– emulatore di terminale (location sensitive)
– file transfer (location sensitive)
– posta elettronica
l
servizi di base: permettono la comunicazione tra processi remoti usando il
paradigma C/S e l'accesso distribuito al file system e a risorse condivise
» Meccanismi per la comunicazione
– RPC remote procedure call
– RDA remote data access
– MOM message oriented middleware
48
Livelli del middleware (2)
l
WWW middleware
– WEB server - WEB browser
– HTML / HTTP
– Java
l
Middleware per dati distribuiti: permette l'accesso a piu' basi di dati
remote e gestite da differenti DBMS relazionali (e.g., Informix, Oracle) in modo
trasparente
– remote SQL gateway
l
Middleware per la gestione distribuita di transazioni: permette la
completa gestione di transazioni, garantendo:
– aggiornamenti trasparenti (gestione automatica della replicazione)
– transazioni trasparenti (decomposizione trans. automatica su piu' siti)
– trasparenza rispetto ai guasti (accesso ai dati replicati su siti alternativi)
» TP-heavy / TP-lite
49
Livelli del middleware (3)
l
Middleware per oggetti distribuiti: permette ad oggetti remoti di scambiarsi
messaggi. Componenti essenziali sono:
l
l
» ORB: Object Request Broker che trasferisce le richieste e le
risposte tra l'oggetto client e l'oggetto server
» Repository: descrizione di tutti gli oggetti disponibili utilizzato
dall'ORB per trovare gli oggetti di interesse sulla rete
» E.g., Corba, OLE/ActiveX, OpenDoc, Oracle WRB
Middleware specializzato
» Mobile computing
» Multimedia
» Legacy access/integration
» Groupware
Distributed operating system (DISOS) ??
50
Portabilita' ed interoperabilita' (1)
l
l
l
Le API influenzano la portabilita' delle applicazioni C/S. Ad
esempio, un client che usa le API di Informix deve essere
riscritto per utilizzare le API di Oracle.
Il protocollo di interazione tra il middleware client e quello
server influenza la interoperabilita' delle applicazioni C/S. Ad
esempio un middleware client Informix non riesce a scambiare
dati con un middleware server Oracle. Occorre prevedere un
eventuale "gateway".
E' quindi importante considerare i livelli di standardizzazione
possibili
51
Portabilita' ed interoperabilita' (2)
Totally
open
Open API
API
Protocollo
Open
Open
Open
Esempi
DCE RPC
Corba
Proprietary ODBC
Open
Proprietary Open
DRDA
protocol
ISO RDA
Proprietary Proprietary Proprietary OLE/ActiveX
52
Middleware di base ~= Network Operating
Systems (NOS)
l
l
l
l
Scopo del middleware NOS: fornire una singola immagine di
sistema per tutti i servizi di rete.
Il middleware NOS fornisce l’infrastruttura logica
indispensabile per sviluppare sistemi informativi distribuiti.
Senza il NOS lo sviluppo di applicazioni C/S sarebbe
enormemente difficoltoso e costoso.
Spesso i middleware commerciali si appoggiano sui servizi
forniti dal NOS. (e.g., un middleware per basi di dati si
appoggia su Netware di NT)
53
Servizi offerti dal NOS
l
l
Il NOS nasce con le LAN (essenzialmente : file server/ print
server). Successivamente introduce servizi utili per C/S:
» Comunicazione remota
» Servizio di directory
» Sicurezza
» Gestione dei guasti
» Scheduling dei task
» Time service
E' importante notare che il NOS offre servizi all'interno di una
LAN ! Occorrono quindi dei "gateway" per far colloquiare due
NOS distinti
54
RPC - Remote Procedure Call
l
l
l
l
l
l
Il middleware RPC fa in modo che l’invio di una richiesta da un
client verso un server avvenga come se fosse una normale chiamata
locale di procedura
Meccanismo che facilita la programmazione
L'interazione e' sincrona: il processo client viene sospeso finche’ la
procedura chiamata non termina.
I parametri vengono passati come una procedura ordinaria.
Il software run time raccoglie i parametri, li impacchetta
(Marshalling), forma un messaggio e lo invia verso il server remoto
Il server riceve la richiesta, spacchetta i parametri (Unmarshalling),
e manda la risposta al client.
55
Il meccanismo di Remote Procedure Call
Server
Client
ProcA
Proc A
Main
1
Main
Server
Proc B
Proc B
Server
Client
ProcA
2
Main
Client
Stub
Server
Stub
Server
Proc B
Una copia prototipo della procedura da chiamare viene inserita nel codice del client :
client stub. Il client stub riceve i parametri e si preoccupa di inoltrarli sulla rete fino
al server che implementa la procedura. Un server stub si occupa di ricevere tali
parametri ed inviare indietro il risultato.
(Gli stub sono il middleware!)
56
IDL - Interface Definition Language
l
l
l
l
l
l
Gli stub del client e del server vengono generati tramite un
opportuno linguaggio di specifica : IDL
IDL permette di specificare in modo dichiarativo la struttura
dell'interfaccia, ovvero:
» operazioni disponibili
» parametri necessari
Le specifiche della interfaccia vengono "compilate" nei
linguaggi del client e del server, ottenendo il server stub ed il
client stub
Il client ed il server vengono compilati ed eseguiti
Approccio tipico C/S
Ovviamente non esiste uno standard per IDL
57
Sviluppo di applicazioni con RPC
Interface
Definition
File (IDL)
Client
Source
Server
Source
IDL
Compiler
Client
Stub
Source
X
Compiler
Client
Executable
Header
File
RPC
Runtime
Library
Server
Stub
Source
Y
Compiler
Server
Executable
58
Riassumendo
l
l
l
l
l
Il client effettua una chiamata locale ad una procedura stub che la
trasforma in un messaggio di rete nel formato previsto (tipicamente
TCP/IP soket) e "scopre" l'indirizzo del server (bind) utilizzando, ad
esempio, una diretory distribuita
Il messaggio viaggia sulla rete e viene ricevuto dallo strato di trasporto
della rete del server (gateway?)
Il server stub riceve il messaggio, lo converte in una chiamata locale e
lo invia al server
Il server esegue la chiamata e restituisce al server stub il risultato
Il server stub ...
59
Caratteristiche del NOS per supportare
meccanismi RPC
l
l
l
l
l
l
Localizzazione delle funzioni del server ed avvio del server
Definizione dei parametri (NIDL) Network Interface Definition
Language. NIDL compiler, header stub e skeleton.
Gestione dei malfunzionamenti Automatic retry, only once semantics.
Connection-Oriented vs. Connectionless RPC
Sicurezza Specifica del livello di sicurezza richiesto.
Funzioni di ricerca del server. Binding = Associazione C/S. Hardcoded binding Vs. binding con ricerca su direttorio, dynamic binding.
Nel caso di dynamic necessità di “pubblicizzare” un server.
Rappresentazione dei dati Necessità di utilizzare una forma canonica di
rappresentazione per i dati.
60
Risoluzione delle differenze tra le
rappresentazioni dei dati
l
l
l
RPC risolve automaticamente le differenze di rappresentazione dei
dati tra sistemi eterogenei (ISO-OSI 6 presentazione)
Ciò avviene per mezzo di opportuno codice associato agli stub per
mezzo dell’IDL compiler
Esistono diversi approcci a questo problema:
» Rappresentazione canonica comune
– a volte inutile
» DCE impiega lo schema “receiver makes it right”
» Altri sistemi impiegano lo schema “sender makes it right”
– implicano la conoscenza di tutti i formati dei client e dei server
61
Workflow di una
comunicazione sincrona
client
1
client
si attiva
directory
riceve il
messaggio
Selezione
del servizio
Preparazione
del messaggio
Chiamata
sincrona
Il server
si attiva
server
3
Decodifica
messaggio
2
Esegue
il servizio
Middleware
62
RPC: ulteriori considerazioni
l
l
l
Generazione degli stub : manuale / automatica (IDL)
Nel caso di binding dinamico occorre trovare la coppia <host,server>
appropriata. Directory centralizzata/distribuita.
Semantica della chiamata in caso di malfunzionamenti server:
– Exactly once
– At most once
– At least once
l
Gestione degli errori
– timeout
– chiusura del server (automatica / da parte del client)
l
l
l
l
Passaggio dei parametri: valore, variabile ?
Interazioni asincrone ?
Dimensione del risultato non nota? (e.g., query SQL)
Estensioni : RPC + transazioni
63
Message Oriented Middleware (MOM)
l
l
l
l
l
l
l
MOM consente a client e server di scambiare generici messaggi utilizzando code di
messaggi gestiti in modo asincrono.
Le applicazioni comunicano in rete semplicemente mettendo messaggi in code e
prendendo messaggi dalle code.
MOM elimina tutti i dettagli della comunicazione fornendo un API molto semplice.
MOM consente la comunicazione senza la necessità di avere una connessione attiva
Client e server possono essere operativi in tempi differenti.
Grande disaccoppiamento ed indipendenza. Un programma può decidere quando
prelevare i messaggi dalla coda.
Possibilità di comunicazione one-to-many many-to-one.
64
Prodotti di middleware MOM
l
l
l
l
MOM è un componente chiave del middleware assolutamente
essenziale per una certa classe di sistemi distribuiti
Se l’applicazione può tollerare un certo livello di indipendenza dai
tempi di risposta, i meccanismi MOM forniscono il modo più
semplice per realizzare sistemi distribuiti
MOM risulta particolarmente indicato nel caso di mobile
computing
Standard IBM: MQI Messaging and Queuing Interface
65
MQI API
• L’API MQI consiste di un insieme di nove semplici chiamate
• L’API MQI definisce un interfaccia tra il programma applicativo ed il
gestore locale delle code.
• Il gestore delle code fornisce trasparenza sulla locazione dei soggetti
coinvolti e gestisce la consegna dei messaggi
• Anatomia di un programma MQI:
– stabilisci la connessione con il gestore locale delle code MQCONN
– apri una coda per lo scambio messaggi MQOPEN
– inserisci o prendi messaggi MQPUT MQGET oppure interroga lo stato della
coda MQINQ
– chiudi la coda MQCLOSE
– disconnetti MQDISC
66
Problemi con il middleware MQseries
• E’ una tecnologia sviluppata per risolvere problemi di
comunicazione relativi a piattaforme eterogenee
• Di vecchio stile
• Non sono previsti meccanismi di interoperabilità con altri MOM
• Usa un sistema proprietario di directory
• Non supporta lo scambio di messaggi di grandi dimensioni
come BLOB (Binary Large Object)
67
Confronto tra MOM ed RPC
Caratteristica
MOM
RPC
Metafora
Ufficio Postale
Telefono
Relazione tra
client e server
Asincrona
Sincrona
Sequenza di
attivazione
Nessuna
Il Server deve essere
attivo prima che il Client
possa comunicarci
Stile
Accodamento
Call-Return
Dati persistenti
Sì
No
No
Necessità di
disponibilità del
partner
Sì
Bilanciamento
del carico
Impiego di coda singola in
modalità FIFO o prioritybased
Per mezzo di servizi
aggiuntivi (TP Monitor)
Supporto di
transazioni
Sì (in alcuni prodotti)
No
Filtraggio di
messaggi
Sì
No
Prestazioni
Lente (c’è un passaggio in Veloci
più)
Elaborazione
asincrona
Sì
Limitata (per mezzo di
threads)
Fonte: Essential Client-Server Guide, 1994
68
Remote Data Access (RDA)
l
l
Permette ad un client di accedere, tramite uno statement SQL
(tipicamente una interrogazione), ad una o piu' basi di dati remote
La differenza essenziale rispetto a RPC e' la dimensione del risultato:
» RDA prevede, dopo la prima comnnessione, un dialogo tra client e server per il
reperimento di una tupla alla volta (SQL FETCH)
» dialogo sincrono
l
Tipi di API:
» Embedded SQL: il programmatore puo' aggiungere comandi SQL all'interno del codice
distinguendoli tramite indicatori speciali (e.g., $)
» Call level interface (CLI) : il comando SQL e' passato come stringa al server (chiamate
addizionali permettono di specificare il server, chiudere la connessione, ecc.) Il piu' noto
esempio e' Open Database Connect (ODBC)
» Non e’ necessario un IDL
l
Comandi SQL statici e dinamici
» dinamici : permettono di formulare query estemporanee
» statici : permettono di individuare piani esecutivi a tempo di compilazione
69
Stored Database Procedure
l
Procedure scritte in una estensione dell'SQL con istruzioni
condizionali e di ciclo (spesso linguaggio proprietario del DBMS).
Vengono compilate e memorizzate presso il server per poter essere
eseguite tramite una chiamata speciale. Vantaggi principali:
» efficienza
» migliore gestione della integrita' dei dati (e.g., tutte le funzionalita'
di update possono essere realizzate tramite stored procedure)
» introducono una sorta di "object orientation" per i server di basi di
dati
70
Dove e’ il server ?
l
l
l
l
RPC, MOM, RDA gestiscono la comunicazione tra il client ed il
server secondo differenti paradigmi di interazione
A monte della instaurazione della connessione, sincrona o
asincrona che sia, occorre localizzare il server
Un binding puramente statico, oltre ad implicare la conoscenza a
tempo di compilazione della locazione del server presenta
l’ulteriore difetto di non seguire l’evoluzione del sistema, in cui gli
utenti entrano ed escono continuamente dalla rete
Il middleware deve prevede, quindi, l’utilizzo di vari meccanismi
per registrare dinamicamente i client presenti nel sistema
71
Global Directory service
l
Idealmente un servizio di directory dovrebbe fornire una
immagine unica delle risorse che puo’ essere usata da tutte le
applicazioni
l
Il servizio viene implementato tipicamente come una base dati a
oggetti replicata e distribuita
» Distribuita per consentire agli amministratori dei vari
domini di controllare direttamente le proprie risorse
» Replicata per fornire una alta disponibilita’
» ad oggetti in quanto tutto puo’ essere visto come istanza di
una classe
72
Che cos’è un servizio di directory?
l
l
l
E’ un servizio che prende il nome simbolico di un oggetto e
restituisce informazioni sul conto dell’oggetto richiesto
Esempi:
» nome di una persona ð numero di telefono di quella persona
» indirizzo simbolico IP ð indirizzo numerico IP
» nome di un host ð informazioni circa quell’host
» nome di un server RPC ð informazioni per collegarsi a quel
server
Un servizio di directory efficace è critico per un ambiente
distribuito
73
Global Directory service
l
l
l
l
I direttori offerti dai moderni NOS presentano delle API ed
interfacce utente che consentono di localizzare entita’ sulla rete
attraverso l’interrogazione sul nome o su attributi
Tipicamente i servizi di directory sono organizzati in modo
gerarchico
In ogni nome c’e’ una componente locale ed una globale.
A livello globale esiste una federazione di sistemi lascamente
accoppiati
74
Lo standard X.500
l
l
l
l
X/Open Directory Service (XDS) API
L’API XDS consente di:
» leggere,
» comparare,
» aggiornare,
» aggiungere,
» e rimuovere directory entries
Ogni oggetto in una directory X.500 appartiene ad una classe, una
classe puo’ essere derivata da un’altra classe
Il protocollo definito e’ il DAP (Directory Access Protocol)
75
Sicurezza nell’elaborazione distribuita
l
Le reti di computer sono soggette a brecce nei meccanismi di security,
spesso definite security threats (minacce), quali:
» Masquerade
» Modifica dei dati
» Intercettazione dei dati
l
I servizi chiave richiesti da sistemi distribuiti protetti da accessi
indesiderati sono i seguenti:
»
»
»
»
»
»
l
Autenticazione: verificare che l'utente e' chi dichiara di essere
Autorizzazione : verificare che l'utente puo' accedere al servizio richiesto
Integrità : garantire l'esecuzione solo dei messaggi corretti
Confidenzialita’ : nascondere il contenuto dei messaggi
Non ripudiabilita’ : certezza di possedere informazioni che provano l’origine dei dati
Monitor : tenere traccia degli accessi
Tali servizi devono essere progettati in modo da consentire il giusto
compromesso tra livello di sicurezza e prestazioni
76
Kerberos
l
l
MIT Kerberos: sistema a tre livelli: client, server e security server
Il middleware centralizza in un solo posto (security server) tutte le
informazioni relative alla autenticazione ed autorizzazione.
» l'utente da’ una password al client
» la password viene cifrata e mandata al server Kerberos
» il server Kerberos crea un "biglietto" e lo manda al client
» il client manda il "biglietto" al server
» il server controlla il "biglietto" ed attiva la comunicazione
(1) password
Client
(2) ticket
Kerberos
Security server
(3) ticket
Server
77
Gestione dei guasti
l
l
l
l
l
l
Problema notevolmente complesso (client e server possono
"guastarsi" indipendentemente)
Gestione "proactive" dei guasti
Fault detection
Fault isolation
Fault resolution
Nel caso di piu' server che collaborano tra di loro per fornire un
servizio si adoperano protocolli tipo two-phase commit
78
Gestione del clock
l
l
l
l
Le applicazioni distribuite hanno esigenza di un singolo riferimento
orario:
» Per lo scheduling, la sequenzializzazione, la misura ed il reporting
di eventi di sistema
In caso contrario, le applicazioni distribuite non possono operare
correttamente
Un servizio di sincronizzazione regola i clock dei sistemi distribuiti per:
» Sincronizzarli l’uno con l’altro
» Aggiustarli ad un orario standardizzato
Tali servizi si basano normalmente sul protocollo Internet Network
Time Protocol (NTP)
79
NOS middleware: conclusioni
l
l
l
l
I NOS middleware sono fondamentali per sviluppare sistemi
distribuiti
Se non si dispone di tali servizi è necessario ricrearli a costi
elevati e con risultati di dubbia qualità
MOM, RDA e RPC come meccanismi di base per la
comunicazione e sincronizzazione
Servizi di sicurezza, naming e directory sono fondamentali per
una progettazione di sistemi distribuiti di qualità
80
Un esempio di NOS: Distributed Computing
Environment (DCE)
l
l
l
l
La proposta OSF DCE è un NOS aperto a più piattaforme
DCE fornisce un insieme di soluzioni NOS per integrare piu'
server in un ambiente eterogeneo
DCE consente ai client di interoperare con uno o più processi
server attivi su piattaforme differenti su differenti sistemi
operativi
DCE fornisce un approccio integrato per:
» sicurezza
» naming
» interprocess comunication
81
Caratteristiche di DCE
l
l
l
Le tecnologie chiave usate da DCE includono
» RPC
» Naming service
» time syncro service
» distributed file system
» network security service (Kerberos)
» threads
Incorporate da IBM, DEC, HP,Siemens, Cray
E' una implementazione, non una specifica !
82
DCE RPC
l
l
l
l
l
l
DCE fornisce un Interface Definition Language (IDL) ed un compilatore che facilita la
creazione di RPC. Il compilatore IDL crea codice C portabile per gli stub del client e
del server
Gli stub sono compilati e collegati alla RPC run-time library, responsabile della
localizzazione del server, dello scambio di messaggi, nonche' del packing e unpacking
degli stessi
Caratteristica fondamentale: integrazione con i servizi di sicurezza e di naming. Ogni
richiesta può essere autenticata ed il server può essere localizzato a run-time
(Kerberos)
DCE RPC fornisce indipendenza dai protocolli di trasporto
Non supporta transazioni
Rappresenta l'attuale standard di fatto
83
DCE distributed naming service
l
l
l
l
l
l
l
Il naming service di DCE consente a risorse come programmi, server, files, dischi,
code di stampa, di essere identificati da nomi user-oriented contenuti in una base di
dati specializzata che descrive gli oggetti d’interesse
I nomi degli oggetti sono indipendenti dalla locazione sulla rete
DCE divide l’ambiente distribuito in unità amministrative chiamate celle
Una cella DCE è una combinazione di workstation client e server
Il dominio della cella può essere definito dall’utente
Per ogni cella deve esserci almeno un cell directory server ed un security server
Il servizio di directory DCE consiste di due elementi:
» cell directoty service
» global directory service
84
DCE distributed naming service
l
l
l
l
Architettura a due livelli che consente di ottenere
» autonomia locale
» interoperabilità a livello globale
L’accesso globale è fornito utilizzando X.500 o il DNS di internet
Meccanismi di caching per migliorare l’efficienza
Il servizio di directory DCE può essere interrogato specificando
diversi attributi:
» yellow pages da attributi a nomi
» white pages da nomi ad attributi
» aliases
da nomi a nomi
» groups
da nomi a gruppi di nomi
85
DCE distributed Time service
l
l
l
l
l
Il servizio di timing fornisce un meccanismo per sincronizzare
ogni computer sulla rete
Il DCE timing service fornisce delle API per manipolare
timestamp e per ottenere il tempo universale da sorgenti
affidabili
Il time server è un nodo che è progettato per rispondere ad
interrogazioni sul timing delle risorse locali e remote
External time provider
Meccanismo di aggiustamento periodico
86
Lo schema di sincronizzazione usato da DCE
UTC Time Provider
Server
Time
Clerk
LAN
Global Server
Time Provider Server
LAN
Courier
Local
Server
87
DCE distributed security service e file system
l
l
I servizi di sicurezza di DCE sono ottenuti adottando il sistema
di autenticazione Kerberos del MIT
File system basato sul protocollo AFS (Andrew File System)
Carnegie Mellon University
» DCE DFS fornisce uno spazio dei nomi uniforme,
trasparenza sulla locazione dei files, elevata disponibilità
» Files e directories possono essere replicati trasparentemente
» Gestione della cache con propagazione automatica dei
cambiamenti
88
Alcune considerazioni su DCE
l
l
l
l
l
l
Tecnologia primi anni ‘90
L’insieme dei servizi risulta offerto in modo “piatto”, senza un
meccanismo efficace di aggregazione
Non sono previsti meccanismi di ereditarietà
In altre parole non è un sistema che offre in modo nativo
funzionalità di tipo object-oriented per la gestione di sistemi
distribuiti
Non prevede meccanismi espliciti per l’interazione con basi di dati
E’ una implementazione
89
Middleware WWW
Internet
l
Da ARPANET (1969) ---> "The Internet" basata su TCP/IP (1989).
Prime forme di middleware:
»
»
»
»
»
l
Email : posta elettronica (MOM middleware)
Telnet : collegamento remoto ad un sistema
FTP
: (File Transfer Protocol) semplice trasferimento di file
Gopher : prima interfaccia grafica per internet (icone x file, ecc.)
WAIS : (Wide Area Information Servers) primo motore di ricerca
1989 .... Nasce WWW: un insieme di prodotti middleware basato su
TCP/IP.
Applicazione Internet
WWW Middleware
HTTP, HTML, Web browser, Web Server
Protocolli TCP/IP
Soket, FTP, Telnet, TCP, UDP...
91
WWW middleware
l
l
Componenti essenziali:
» HTTP : Hypertext Transfer Protocol
» HTML : Hypertext Markup Language
» XML ?
» URL : Uniform Resource Locator
» Web server
» Web browser
» Gateways verso dati non WWW
» Java ?
» Corba ?
Per costruire applicazioni Internet / Intranet / Extranet
92
Architettura di base C/S
Web Browser
(Netscape, Internet Explorer...)
HTTP
Web site (e.g., www.dis.uniroma1.it)
Web server (applicazione)
File system
Pagine
HTML
93
HTTP / URL
l
Protocollo C/S basato su 4 fasi
Web
Client
(browser)
l
l
Connect
Request
Response
Close
Web
Server
Privo di stati: ogni singola connessione avviene in una sessione isolata
URL protocol://host:port/path
–
–
–
–
protocol indica il protocollo che si vuole utilizzare (il default e' http)
host e' l'indirizzo IP (simbolico/numerico) della macchina su cui risiede il server
port (opzionale) e' la porta su cui risponde il server (il default e' 80)
path e' un cammino nel file system dell'host
94
Object client
Architettura avanzata C/S
Object Server
TELNET Server
telnet
Telnet client
Corba
Web Browser
Ftp
FTP Server
Ftp client
HTTP
Web Server
Web
gateway
pagine
HTML
non web
stuff
95
Web Gateway
l
l
l
l
CGI (Common Gateway Interface ): e' un programma (script) che risiede sul server ed
e' attivato da un collegamento presente all'interno di una pagina HTML. Tipicamente
interagisce con il file system dell'host (o con un DBMS) e produce pagine HTML
dinamiche.
SSI (Server Side Include): comandi immersi all'interno di un documento HTML e
processati dal server. Non standard.
– accesso a basi di dati tramite ODBC
– controllo di flusso e cicli
Standalone server : e' un (database) server che, tra le altre cose, gestisce pagine
HTML. Ad esempio risponde ad una chiamata SQL eseguendola e generando una (o
piu') pagine html che contengono il risultato. (e.g., Interdev della Microsoft + Internet
Information Server o Oracle Web Server). Totalmente proprietario
Mobile code :
» applet: un applet java viene eseguito sul browser, attivando un dialogo con
un'altro server usando JDBC.
» servlet: il server attiva speciali processi java che diventano parte integrante del
server
96
Servlet java
l
l
l
l
l
Il client invia una richiesta HTTP al WEB server che supporta le servlet.
Sul server è presente un modulo chiamato “dispatcher” che si fa carico di assegnare
thread per servire le richieste in arrivo. Il dispatcher analizza la richiesta e controlla se
la servlet necessaria è o meno disponibile all’interno del Web server stesso.
Se la servlet non è disponibile viene scaricata dal server-deposito.
La servlet va in esecuzione, opportunamente inizializzata, e si connette, ad esempio,
ad un database tramite JDBC.
I risultati vengono opportunamente formattati in pagine HTML ed inviati al client.
97
Uno scenario piu' complesso
Traditional Server
Data Store
Traditional Client
Extensions
CGI
HTML
Java
applet
&
servlet
Server APIs
Web Server
HTTP
RPC, MSG,
OO, ...
TCP/IP
Internet/Intranet Server
Internet/Intranet Client
Browser (HTML)
Plug-Ins
Java VM
RPC, MSG,
HTTP
OO, ...
TCP/IP
Downloaded
Applets
98
Intranets, Extranets and the Internet
The Internet
Content Server
Web
Browser
Web
Server
CGI
Content
Legacy
Interfaces
API
Plug-ins
State Server
Extranets
Intranets
Content Server
Web
Browser
Web
Server
CGI
Content
Legacy
Interfaces
Global Internet
• Public applications
• Ubiquitous access
• Variable security
Extranet
• Trusted external partners
• Limited external access
• Bilateral Security
security
• Virtual private networks
Intranet
• Private applications
• No external access
• Content
Bilateral
security or
Content
Server Server
Disconnected
networks
disconnected
networks
CGI
Web
Web
Server
Browser
API
Content
Legacy
Interfaces
API
Plug-ins
Plug-ins
State Server
Intranets
State Server
Extranets
Content Server
Web
Browser
Web
Server
CGI
Content
Legacy
Interfaces
API
Plug-ins
State Server
= Security Mechanism (e.g., firewalls)
Intranets
99
Distributed Object Computing
100
Evoluzione verso il DOC
(Distributed Object Computing)
l
Crisi del mercato software. Parole d’ordine:
–
–
l
l
RIUSO
COMPONENTI
Necessità di sistemi distribuiti ma anche
INTEROPERABILI
Problemi con il middleware classico RPC/MOM
–
debolezza del modello di rappresentazione:
l
–
la funzione, un nome, parametri di input parametri di output
mancanza di uno standard e quindi di trasparenza tra linguaggi,
piattaforme, Sist. Op.
101
Distributed Object Computing
l
l
l
Paradigma “ideale” per sistemi informativi distribuiti
Un insieme di oggetti (nel senso Object Oriented) che comunicano
trasparentemente tra loro attraverso scambio messaggi.
Un oggetto puo’:
» identificare altri oggetti sulla rete,
» scoprire dinamicamente cosa un altro oggetto e’ abilitato a fare
» inviare un messaggio ad un altro oggetto e ricevere la risposta
in modo sincrono o asincrono
» utilizzare servizi generali, anche molto sofisticati, disponibili
in rete partecipando alla realizzazione di un sistema complesso
102
Caratteristiche tecniche ed organizzative del
DOC
l
l
l
Non c’e’ piu’ una chiara e netta distinzione tra Client e Server, un
oggetto puo’ essere client e server contemporaneamente
La granularita’ degli oggetti sulla rete puo’ essere molto piu’ fine
rispetto a qella implicitamente considerata nel C/S tradizionale
Attraverso l’incapsulamento di dati e servizi, un oggetto distribuito
si presta in modo naturale a modellare un Oggetto di Business per
una organizzazione: una risorsa che puo' essere acceduta
trasparentemente e che svolge un ruolo specifico nei processi
aziendali e interaziendali (e.g., fattura, cliente, ordine)
103
Interoperabilita’
l
Per realizzare questo concetto cosi’ evoluto di sistema distribuito e
per renderlo realmente attuabile risulta fondamentale non porre
vincoli:
» sulle piattaforme hardware
» sui sistemi operativi utilizzati
» sui protocolli di comunicazione
» sui linguaggi di programmazione utilizzati (anche non OO)
» sull’esistenza di sistemi chiusi ereditati dal passato (legacy)
104
Middleware per realizzare il paradigma
DOC: Object Request Brocker (ORB)
l
l
l
l
L’ORB e’ il middleware che stabilisce la relazione C/S tra oggetti
Usando un ORB un oggetto client puo’ trasparentemente invocare un
metodo su un oggetto server che puo’ risiedere sulla stessa macchina o
sulla rete
L’ORB intercetta la chiamata ed e’ chiamato in causa per identificare un
oggetto in grado di implementare il servizio richiesto, passargli i
parametri, invocare il suo metodo e restituire il risultato
Il client non deve essere a conoscenza della locazione dell’oggetto, il suo
linguaggio di programmazione, SO e tutto cio’ che non e’ parte della sua
INTERFACCIA
ORB
105
Consenso
l
Per realizzare un sistema in grado di offrire tali caratteristiche e
mantenere tutti i livelli di indipendenza necessari, risulta essenziale
stabilire un consenso tra i soggetti coinvolti nella definizione e
realizzazione dei sistemi informativi distribuiti. Ci dovra’ essere
consenso su:
» un modello a oggetti
» su un protocollo di comunicazione (tra ORB e oggetti)
» sul modo di specificare l’interfaccia esterna degli oggetti
106
OMG
(Object Management Group)
Organizzazione senza fini di lucro fondata negli Stati Uniti, con
sedi in Inghilterra, Giappone e Germania.
l
Nasce nell’aprile del 1989.
l
Circa 20 persone.
l
Obbiettivo principale: creazione e diffusione di standard OO
basati sull’utilizzo di tecnologie esistenti.
l
www.omg.org
107
Obbiettivi della proposta OMG
l
Sviluppare un’architettura distribuita OO garantendo:
• riusabilita’ dei componenti;
• interoperabilita’ e portabilita’;
• utilizzando software commercialmente disponibile
l
Per mezzo di
• Unica terminologia per il mondo OO
• Un quadro di riferimento comune
• Un modello di riferimento comune
• Interfacce e protocolli comuni
108
Worldwide Scope
Andersen
CI Labs
ICL
Sun Microsystems
Novell
APM
Data Access
Informix
Sybase
Object Design
Apple
Digital
Intel
Symantec
ASCII
EDS
IntelliCorp
Taligent
Object Tech.
Int’l.
AT&T
Expersoft
IBM
Telefonica I+D
Oracle
Bell Northern
Fujitsu
Micro Focus
Tivoli
OSF
Borland
Genesis
Microsoft
TRW
ParcPlace
Bull
HP
MITRE
Unisys
POSC
CA
HyperDesk
NeXT
Xerox
Siemens Nixdorf
Software AG
109
OMA: Object Management Architetcture
Documento di riferimento:
Motivazioni dell'approccio OO.
Obbiettivi di OMG.
Modello OO di riferimento.
Architettura di riferimento.
Glossario.
110
CORE Object Model
l
Oggetti: ogni tipo di entita' o concetto caratterizzato da una
propria identita'
l
Operazioni: Le operazioni sono servizi forniti dagli oggetti.
l
Ogni operazione ha una signature: nome, parametri e risultati
l
Richieste: invocazioni di operazioni.
l
Non oggetti: interi, boolean.....
l
Interfacce: Una collezione di operation signatures
l
Tipi: Ereditarieta' e sottotipi
111
CORBA
l L'architettura CORBA (Common Object Request Broker
Architectur) è un ambiente standard a livello di middleware
che permette l'interoperabilità tra oggetti in sistemi
distribuiti eterogenei. Il cuore di Corba e’ l’ORB
112
ORB+STUB&IDL
C,C++
Smalltalk
Cobol
C,C++
Smalltalk
Cobol
IDL
IDL
IDL
IDL
IDL
IDL
Client
Server
Object Request Broker (ORB)
113
Implementazioni di ORB
Client-and implementation-resident
ORB e' implementato come una libreria
(routines) e quindi risiede nel codice del
client e della applicazione
Server-based
ORB e' implementato come server
System-based
ORB e' parte del sistema operativo
114
OMG IDL
OMG IDL e' OO:
• ereditarieta' multipla, fortemente tipato;
• è molto simile al sottoinsieme del linguaggio C++ per la
dichiarazione dei tipi
• indipendente dal linguaggio/compilatore usato;
• compilatore IDL disponibile per vari linguaggi/compilatori;
• binding statico
• binding dinamico.
• trovare l'oggetto;
• trovare l'interfaccia dell'oggetto;
• creare la richiesta;
• inviare la richiesta;
• ricevere la risposta.
115
Decomposizione della chiamata
Caller
Stub
Interconnection Network
Skeleton
Callee
•Stub e skeleton vengono generati
compilando la loro definizione (IDL)
•Stub
= DCE client stub
•Skeleton = DCE server stub
116
OMA Overview
Le applicazioni non
sono standardizzate
da OMG
Application
Objects
Business Objects
Compound Docs
Object Linking
Help Facilities
Desktop Mgmt
Common Facilities
Object Request Broker
Lifecycle
Events
Naming
Persistence
Transactions
Common Services
Middleware
Concurrency
Security
Time
Properties
Query
117
Interfacce
Implementation
Installation
IDL Interface
Definitions
Interface
Repository
Accesses
Client
Stubs
Includes
Client
Implementation
Skeletons
Includes
Implementation
Repository
Describes
Object Implementation
» Ogni oggetto ha la sua interfaccia definita tramite IDL.
» Tali definizioni (oggetti a loro volta) sono memorizzati nell'
Interface Repository
» L'Implementation Repository contiene la descrizione della
implementazione degli oggetti.
118
Componenti CORBA
Object Implementation
Client
Dynamic
Invocation
Client
Stubs
ORB
Interface
Implementation
Skeletons
Object
Adapter
ORB Core
One interface
One interface per object adaptor
One interface per object operation
Proprietary interface
Normal call interface
Up call interface
119
Client stubs
Object Implementation
Client
Dynamic
Invocation
Client
Stubs
ORB
Interface
ORB Core
Skeletons
Object
Adapter
•Sono le interfacce ai servizi degli oggetti. Questi stubs precompilati
definiscono come i clients invocano i servizi corrispondenti sui servers.
•Un client deve avere uno stub IDL per ogni interfaccia che usa sul
server. Lo stub include: codice per effettuare “marshaling” che consiste
nel codificare l’operazione e i suoi parametri nel formato del messaggio
che deve essere inoltrato al server; file di header che consentono di
invocare il metodo sul server da un linguaggio di alto livello.
120
Dynamic Invocation Interface
Object Implementation
Client
Dynamic
Invocation
Client
Stubs
ORB
Interface
ORB Core
Skeletons
Object
Adapter
Consente di scoprire il metodo da invocare a run time.
Corba prevede delle Api che permettono di cercare i
metadati che definiscono l’interfaccia del server , di
effettuare una chiamata remota ed ottenere i risultati a
tempo di esecuzione.
121
Orb Interface
Object Implementation
Client
Dynamic
Invocation
Client
Stubs
ORB
Interface
ORB Core
Skeletons
Object
Adapter
Consiste di poche Api a servizi locali che possono
essere di interesse per un’applicazione. Ad esempio
fornisce Api per convertire un Object Reference
(identificatore dell’oggetto) in una stringa e viceversa.
122
Server IDL stubs
Object Implementation
Client
Dynamic
Invocation
Client
Stubs
ORB
Interface
ORB Core
Skeletons
Object
Adapter
Sono chiamati skeleton secondo la specifica OMG. Forniscono le
interfacce per ogni servizio esportato dal server. Questi stubs, come
quelli del client, sono creati usando un precompilatore IDL.
Non distinguono una chiamata statica da una dinamica
123
Object Adapter
Object Implementation
Client
Dynamic
Invocation
Client
Stubs
ORB
Interface
ORB Core
Skeletons
Object
Adapter
Accetta le richieste di servizi per conto degli oggetti server. I servizi principali forniti
dall’OA sono:
•istanziare gli oggetti server, ovvero creare delle istanze di oggetti a partire dalle classi
•passare loro le richieste dei clients
•assegnare agli oggetti degli IOR(Identifier’s Object Reference)
•registrare le classi implementate e le loro istanze a tempo di esecuzione(cioè gli oggetti)
nell’Implementation Repository.
•Ogni orb deve supportare un adapter standard chiamato Basic Object Adpter (BOA).
124
Implementazioni di CORBA
l
l
l
l
l
l
l
l
l
IONA Technologies ORBIX
IBM SOM/DSOM
ExpertSoft PowerBroker
Digital Object Broker
Sun NEO
ICL DAIS
Visigenic VisiBroker
HP ORB Plus
SNI Orblet
125
ORB to ORB Interoperability
Client
IDL
Obj Impl
IDL
ORB
ORB
Client
Obj Impl
IDL
IDL
ORB
ORB
IDL
IDL
Client
Obj Impl
126
Interoperabilita' di CORBA 2.0
l
l
l
l
l
Architettura globale per comunicazioni CORBA-CORBA;
Un API per aggiungere bridge;
Un formato generale per il trasporto di messaggi (GIOP:
General Inter-ORB Protocol);
Un Internet Inter-Orb protocol (IIOP) che specifica come
messaggi GIOP vadano scambiati su TCP/IP
Un API per gateways basato su ESIOPs: Environment-Specific
Inter-ORB Protocols (in alternativa a GIOP)
127
CORBA / DCE
l
l
l
Caratteristiche comuni
» funzionalita' ad alto livello simili
» basati su IDL
Differenze significative:
» Corba e' una specifica, DCE una implementazione
» DCE e' procedurale, Corba e' OO
» Corba prevede il binding dinamico
Efficienza
» DCE RPC prevede un insieme di funzioni aggiuntive che
appesantiscono il tutto
» ORB puo' effettuare collegamenti diretti
» La tendenza e' di implementare ORB tramite DCE RPC quindi...
128
Compound Document Middleware: OLE
(Object Linking and Embedding)
l
l
Introdotto da Microsoft nel 90 (OLE 1)
Viene aggiornato nel 93 (OLE 2) con utilizzando la tecnologia oo
COM (Component Object Model) simile a corba, in quanto prevede un
IDL, e poi (96) conosciuto come DCOM (Distributed COM) base per
ActiveX
Structured
Storage
Uniform
Data
Transfer
Compound
Document
Management
Automation
and
Scripting
Distributed Component Object Model (DCOM)
129
CORBA / DCOM
l
l
CORBA
» Pro: architettura matura (1990)
» Pro: modello ben definito
» Pro: multi fornitore
» Con: poco diffusa e non molte implementazioni grandi
DCOM
» Pro: architettura molto vicina alla user interface
» Pro: possibilita’ di grande diffusione
» Con: molto giovane (1996), modello ancora non maturo
» Con: attualmente mono-fornitore
130
OpenDoc
l
Progettato da Apple, alternativa a OLE, ora promosso anche da
Component Integration Laboratories (CI Lab) fondato da Apple,IBM,
Oracle, Novell, Sunsoft, Xerox e Word Perfect:
–
–
–
–
implemantazioni per Windows, OS/2, Unix e Macintosh
IBM System Model (SOM), Corba compatibile per object linking
Apple Open Scripting Architecture (OSA)
Futura compatibilita' con OLE
Bento
Storage
Uniform
Data
Transfer
Compound
Document
Management
Open
Scripting
Architecture
System Object Model (SOM)
131
OLE / OpenDoc
l
l
l
l
Simili obbiettivi e funzionalita'
OLE non prevede ereditarieta', polimorfismo, documenti su
piattaforme differenti, OpenDoc si'.
OLE e' legato a Microsoft ed e' molto piu' usato
OpenDoc e' Corba compatibile
132
ActiveX
Introdotto da Microsoft nel 96 con l'obbiettivo di integrare il desktop
con il WWW utilizzando DCOM come tecnologia di base (broker)
per i collegamenti remoti. Esempi:
– Un applet java puo' chiamare un documento word remoto
– Un web browser puo' contenere documenti word, excel, ecc..
– E' possibile collegarsi ad un SQL server da qualunque oggetto
Other
components
Transaction
Scripting
Java Applets
ActiveX
Documents
OLE
Compound
Documents
OLE2.0
l
Distributed Component Object Model (DCOM)
133
OCX: ActiveX controls
l
l
l
l
l
Simili ad un applet java
Possono essere scritti in altri linguaggi (C, C++)
Sono scaricati in binario (quindi il client DEVE essere
Microsoft)
Sono piu' efficienti
Possono essere immerse in altri contenitori (e.g., un programma
Visual Basic)
134
Oracle Network Computing Architecture NCA
l
l
l
l
Architettura C/S tre livelli:
Universal data server: Oracle DBMS
Application server: Oracle Web Application Server, ovvero un
server HTML + …
Universal client: apertura ad ogni possibile client:
» applicazione java
» client corba
» browser
135
NCA: architettura di massima
l
l
l
Cartridge: componenti software riusabili ed estendibili
Inter-Cartridge Exchange (ICX) : software che consente la
comunicazione tra cartridges mediante protocolli aperti e
interfacce standardizzate (e.g., IIOP, HTTP e POP3/IMAP4)
Client, Web Application Server, Universal Data Server
136
Cartridge
l
Possono essere scritti in Java, PL/SQL, Perl, e C :
» I client cartridge contengono logica di visualizzazione per estendere
ed aumentare i servizi di presentazione sul solo livello client (e.g,
Java UI applet).
» Gli application server cartridge contengono logica applicativa. I
servizi di load balancing, di sicurezza, di gestione delle transazioni
sono forniti dal Web Application Server 3.0 (!)
» I data cartridge contengono la logica di manipolazione dei dati e
possono essere scritti in PL/SQL, C/C++ o Java con IDL mapping e
plug nel database server.
137
Web Application Server
l
Supporta gli application cartridges per programmi basati su
HTTP/HTML. Fornisce i servizi di un ORB Corba-compliant ai
“web” cartidges, consentendo un’integrazione tra applicazioni
web-based e object-based.
Web Request Broker
E’ un gestore di richieste
asincrono
e
fornisce
un’architettura che permette
ad applicazioni Web serverside (cartridge) di girare sotto
un qualsiasi server http su cui
il WRB è trasportato. Il WRB
offre capacità simili ai CGI
offrendo, pero’, prestazioni
migliori grazie alla sua
architettura multi-processo
138
Struttura dell’interazione
1) Il client effettua una richiesta ad un cartridge WRB
2) Il Listener riceve la richiesta e la passa al Dispatcher, il cui compito
è di instradare la richiesta all’istanza del cartridge
3) Il Dispatcher fa una delle due cose seguenti:
» Se esiste un’istanza di cartridge libera, le invia la richiesta;
» altrimenti chiede al WRB di creare una nuova istanza di
cartridge che notifica al al Dispatcher, tramite WRB, la sua
esistenza. Il Dispatcher, poi, invia la richiesta alla nuova istanza
4) L’istanza del cartridge tratta la richiesta ed invia la risposta, diretta
al client, al Dispatcher
5) Il Dispatcher passa la risposta al listener e questo al client.
139
Cartrige supportati da WRB
l
l
l
l
l
PL/SQL cartridges: eseguono comandi PL/SQL memorizzati in un
database. Sono migliori dei Java cartridges per l’accesso ai databases
ma non hanno le stesse funzionalità
Java cartridges: consentono di eseguire java sul server per generare
pagine HTML dinamiche si può anche eseguire PL/SQL embedded
Live HTML cartridges: sono un’implementazione di Oracle e
consentono di includere in pagine HTML l’output di ogni
programma eseguibile dal corrente sistema operativo
Cartridges “dello sviluppatore”: Poiché il WRB utilizza API aperte,
si possono scrivere dei cartridges “propri”che le usino. Per ora e’
previsto solo il C.
Third Party Cartridges: poiché il WRB usa API aperte, diversi
vendors indipendenti stanno scrivendo cartridges per esso.
140
Legacy Systems
141
Legacy Systems
l
l
Un legacy information system (LIS) è un sistema che resiste ad evoluzioni e modifiche
necessarie per supportare i nuovi e mutevoli requisiti di una organizzazione
Caratteristiche fondamentali:
» e’ fondamentale per l’organizzazione
» risiede su mainframe (tipicamente IBM)
» è enorme (milioni di linee di codice)
» è vecchio (almeno 10 anni) e di vecchia concezione
» è scritto in un linguaggio di vecchia generazione (come il COBOL, PL1, assembler)
» è supportato da un DBMS anch’esso antiquato, sempre che esista un DBMS e non
si faccia ricorso al file system (e.g., VSAM)
» è autonomo, ovvero non è interfacciato con altre applicazioni e opera per lo più
indipendentemente
» Mission critical:deve rimanere operativo al 100% e spesso 24 ore su 24
» Non e’ ben documentato o non e’ documentato per nulla
» offre, a volte, elevati livelli di prestazioni e di affidabilita’
142
Strategie per il cambiamento
l
Problemi
– Manutenzione lenta e costosa
– Totale mancanza di flessibilita’
– Assenza di competenze
Tre macrostrategie per il cambiamento
– Taglio netto col passato
– Migrazione graduale
– Integrazione (leverage legacy)
l il DOC puo’ avere un ruolo essenziale
l
Attivita’
–
–
–
–
–
reverse engineering
forward engineering
reengineering
wrapping
revamping
143
Taglio netto (cold turkey)
l
l
Si tratta di riscrivere il LIS, utilizzando tecnologie moderne.
Questo approccio comporta dei rischi sostanziali:
» si deve fornire un sistema migliore. E’ probabile che il nuovo IS
richieda anche nuove funzionalità, il che comporta rischi aggiuntivi.
» le esigenze dell’organizzazione non stanno ad aspettare. Lo
sviluppo di un IS richiede anni, nel frattempo il LIS viene (nuove esigenze,
manutenzione,ecc) il che comporta che deve modificarsi di pari passo anche
il Target IS. Il rischio è in questa continua modifica durante lo sviluppo
dell’IS
» esistono raramente delle specifiche. La sola documentazione per il
LIS è tipicamente il codice stesso
» esistono spesso dipendenze non documentate. Inevitabilmente nel
corso degli anni varie applicazioni, non documentate, si sono appoggiate ai
LIS per informazioni o servizi.
144
Taglio netto: rischi
» il LIS può essere troppo grande per interrompere il suo accesso ai dati. Molti LIS
devono essere operativi per il 100% del tempo, mentre la migrazione dei dati richiede
settimane
» la gestione di grandi progetti è rischiosa. E’ un aspetto molto sottostimato che
comprende la complessità di ripartizione del lavoro, di formazione di nuovo
personale di sviluppo e di gestione delle interazioni
» i ritardi non sono sempre tollerati. Grandi progetti comportano quasi inevitabilmente
dei ritardi
» grandi progetti tendono a gonfiarsi. E’ tipico che una organizzazione che intenda
affrontare un progetto così ampio decida di arricchirlo di studi sull’introduzione di
nuove tecniche e tecnologie, ecc.
» timori. Le paure e incertezze legate a questo approccio spesso irrigidiscono le
organizzazioni, facendo loro preferire un inefficace ma tranquillo LIS
» l’analisi paralizza il processo di produzione del LIS. L’approccio con taglio netto non
può iniziare se prima non si è capita ogni cosa del LIS e delle nuove specifiche,
cosicché la fase di analisi cresce a dismisura senza vedere una linea di codice
145
L’approccio graduale
l
L’obiettivo di questo approccio è quello di mantenere costantemente in
attività l’IS ed al tempo stesso di venire incontro alle necessità del
committente
» L’approccio graduale comporta la migrazione del LIS in loco, con
piccoli passi incrementali fino a che l’obiettivo a lungo termine
pianificato non viene raggiunto.
» Ogni passo richiede un impiego di risorse relativamente basso (pochi
anni-uomo) e poco tempo. Si produce così un piccolo risultato nella
direzione dell’obiettivo (un incremento) , motivo per il quale si parla
di metodologia di migrazione incrementale.
» Questo approccio permette ai pianificatori di controllare il rischio
passo per passo, scegliendo opportunamente la dimensione
dell’incremento
146
Il ruolo dei gateway
TARGET GUI
LEGACY USER
INTERFACE
Gateway
LEGACY IS
TARGET IS
147
Travaso delle funzioni nel tempo
Target
funzioni
Legacy
tempo
148
Integrazione parziale
l
l
Processo di migrazione parziale che utilizza tecnologie DOC e basata sul
wrapping
WRAPPER: strato software che nasconde la sottostante implementazione
delle funzionalita’ disponibili, presentandole attraverso una interfaccia ben
definita
•Migrazione interfaccia utente
•Migrazione dei dati
•Costruzione insieme di oggetti DOC tramite wrapping sul LIS che rimane
intoccato
149
Strategie di trattamento
Legacy System
utilizza
trattamento
reverse e/o
reengineering
sostituzione
sostituzione a
taglio netto
integrazione
migrazione
(sostituzione
incrementale)
utilizza
wrapping
150
Decomposizione dell’IS ai fini della migrazione
l
Si può pensare di considerare tre componenti fondamentali per
un IS:
» le interfacce utente
» le applicazioni
» il servizio database
l
l
Piu’ le componenti sono distinte tra loro piu’ facile risulta il
processo di migrazione
Si individuano quattro casi, caratterizzati da un livello crescente
di difficolta’
151
Architetture
decomponibili
Progettati utilizzando tecniche strutturate
tradizionali (e.g., SADT) rappresentano il
caso migliore; le interfacce, le applicazioni, i
servizi di accesso ai dati sono componenti
distinte con interfacce precise.
I LIS decomponibili sono costituiti da un
insieme di moduli indipendenti, ovvero
senza struttura gerarchica e interagenti
ognuno con un servizio di accesso ai dati e,
potenzialmente, ognuno con la sua
interfaccia utente e di sistema con uno o più
IS, ma non tra di loro.
Presentazione
Logica
Applicativa
Accesso
ai Dati
152
Architetture semidecomponibili
I LIS semidecomponibili hanno la logica applicativa fusa con lo strato di
presentazione (data decomponibile) o con le procedure di accesso ai dati
(program decomponibile) o perche’ la sua struttura è complessa, o non
adeguatamente supportata da tecnologie standard, o ancora perché mal
progettata.
Tutto ciò rende la migrazione più complicata e suscettibile di errore.
Presentazione
Presentazione
Logica
Applicativa
Accesso
ai Dati
Data decomponibile
Logica
Applicativa
Accesso ai Dati
Program decomponibile
153
Architetture non decomponibili
I LIS non decomponibili sono scatole
nere attraverso le quali non è possibile
distinguere nessun componente
funzionale: gli utenti finali e gli IS
interagiscono attraverso un modulo o
componente del tutto non strutturato.
Evidentemente è il caso peggiore da
affrontare durante una migrazione
Presentazione
Logica
Applicativa
Accesso ai
Dati
154
Migrazione totale incrementale
l
l
l
l
Il metodo consta in un certo numero di passi che comportano piccole
migrazioni locali. Più indipendenti sono questi passi, maggiore è la
flessibilità del metodo rispetto alle particolari esigenze informative e
tecnologiche
Risulta evidente come siano i gateway uno degli strumenti fondamentali
della migrazione
La riduzione dei rischi è uno degli obiettivi fondamentali di questa
strategia, fornendo un punto di ritorno sicuro per ogni passo, che non
metta in pericolo tutto il progetto.
I passi possono essere riarrangiati per meglio aderire alle problematiche
e, se realizzati con effettiva indipendenza reciproca, possono anche
procedere in parallelo
155
Inizio della migrazione
I passi dell’approccio graduale
1 Analisi incrementale del LIS.
2 Decomposizione incrementale dell’architettura del
LIS.
3 Disegno incrementale delle interfacce del TIS.
4 Disegno incrementale delle applicazioni del TIS.
5 Disegno incrementale del database del TIS.
6 Installazione incrementale dell’ambiente del TIS.
7 Creazione e installazione incrementale dei gateway
necessari.
8 Migrazione incrementale del database del LIS.
9 Migrazione incrementale delle applicazioni del LIS.
10 Migrazione incrementale delle interfacce del LIS.
11 Distacco incrementale verso il TIS.
1
3
4
5
6
8
9
10
7
2
11
Fine della migrazione
156
Inizio della migrazione
Analisi incrementale del LIS
è importante che si comprenda il LIS in
un giusto livello di dettaglio e si
compiano progressi
nell’approfondimento dei requisiti lungo
una specifica direzione prestabilita:
procedere senza un obiettivo preciso può
paralizzare l’analisi. Spesso i requisiti
iniziali del LIS sono ormai inesistenti o
non attuali, ed è necessario il più delle
volte operare un reverse engineering per
ricostruirli,
in realtà si finisce per sviluppare le
specifiche del vecchio e del nuovo IS.
1
3
4
5
6
8
9
10
7
2
11
Fine della migrazione
157
Decomposizione incrementale dell’
architettura del LIS
si effettuano modifiche al sistema per
assicurarsi che sia decomponibile,
vengono quindi rimosse le chiamate di
procedura e si ispeziona l’esistenza di
interfacce ben definite tra moduli e
servizi database.
Il costo di questo passo dipende dalla
struttura del LIS, e se non è possibile
ristrutturarlo possono comunque essere
adottate e studiate varianti del metodo.
Inizio della migrazione
1
3
4
5
6
8
9
10
7
2
11
Fine della migrazione
158
Disegno incrementale delle
interfacce utente del TIS
si effettua il disegno e la specifica delle
interfacce del TIS con una effettiva
pianificazione della migrazione a questo
livello, che comprende anche la decisione
di utilizzare o meno un IS gateway.
Se non vengono aggiunte funzionalità
significative nella migrazione, i moduli delle
applicazioni legacy e target saranno
necessariamente simili
Inizio della migrazione
1
3
4
5
6
8
9
10
7
2
11
Fine della migrazione
159
Disegno incrementale delle
applicazioni del TIS
Inizio della migrazione
1
le applicazioni che vanno sviluppate per il
TIS vanno progettate in base ai processi e
alle norme dell’organizzazione e a volte
tagliate sulle vecchie applicazioni dopo una
fase di reengineering.
reengineering
Le decisioni vanno prese, in questo caso,
sulla base dell’analisi iniziale e su quella
dei rischi
Possibilità di realizzare oggetti di business
piuttosto che semplici applicazioni
3
4
5
6
8
9
10
7
2
11
Fine della migrazione
160
Disegno incrementale del
database del TIS
si disegna lo schema relazionale del TIS
basandosi sui risultati delle fasi precedenti e sulla
comprensione del target e legacy IS.
A meno che non si tratti di requisiti insoliti, è bene
utilizzare un DBMS relazionale basato sull’SQL.
Questo passo può essere anche molto complesso
per via del codice legacy o dei requisiti delle
applicazioni: può essere difficile derivare la
struttura dei dati, tipicamente distribuita su tutta
l’applicazione.
Parte dello schema relazionale può essere
dedicato alla implementazione dello stato
persistente degli Oggetti di Business
Inizio della migrazione
1
3
4
5
6
8
9
10
7
2
11
Fine della migrazione
161
Installazione incrementale
dell’ambiente del TIS
si identificano i requisiti dell’ambiente del
TIS sulla base dei requisiti globali, quindi si
seleziona l’ambiente stesso ed lo si testa in
modo approssimativo per ricavarne
informazioni sulle performance ed altro.
Dopodiché viene installato possibilmente in
un ambiente distribuito, passando da dumb
computer a PC o workstation connesse in
LAN, il che dovrebbe facilitare la
costruzione di programmi GUI e
l’alleggerimento del codice distribuendolo
opportunamente tra server e client, dove il
costo dei MIPS è praticamente nullo
Inizio della migrazione
1
3
4
5
6
8
9
10
7
2
11
Fine della migrazione
162
Creazione e installazione
incrementale dei gateway
necessari
vengono sviluppati e installati i
gateway in base alle esigenze delle
applicazioni (è probabile che si renda
necessaria la costruzione di più
gateway) e tenendo conto delle
funzionalità, della posizione
architetturale e dei requisiti non
funzionali. A questo punto si presenta
l’alternativa del make or buy dato che
esistono diversi prodotti commerciali
che offrono alcune di queste
funzionalità.
Possibilità di scelta di CORBA
Inizio della migrazione
1
3
4
5
6
8
9
10
7
2
11
Fine della migrazione
163
Migrazione incrementale del
database del LIS
Inizio della migrazione
1
viene implementato lo schema
disegnato al passo 5 ed effettuata la
migrazione del legacy database con
l’ausilio del gateway per supportare le
chiamate delle applicazioni del LIS.
Questa operazione comporta una
notevole quantità di lavoro, che può
essere affrontato anch’esso
incrementalmente, complicando le
funzionalità del gateway
3
4
5
6
8
9
10
7
2
11
Fine della migrazione
164
Inizio della migrazione
Migrazione incrementale delle
applicazioni del LIS
1
vengono selezionati e fatti migrare uno o
più moduli, con criteri tecnici ed
organizzativi (semplicità, costi, priorità),
sviluppandoli in modo tale che possano
interagire direttamente con il nuovo DBMS.
3
4
5
6
8
9
10
7
2
11
Fine della migrazione
165
Inizio della migrazione
Migrazione incrementale delle
interfacce del LIS
1
vengono selezionate e fatte migrare uno o
più interfacce. Se viene utilizzato un 4GL
per supportare lo sviluppo di interfacce ed
applicazioni, la relativa migrazione può
essere coordinata e le interfacce del TIS
gireranno direttamente su un ambiente
4GL/GUI, mentre le rimanenti interfacce
continuano ad convivere con esse. Può
essere utilizzato un IS gateway per
supportare la migrazione
3
4
5
6
8
9
10
7
2
11
Fine della migrazione
166
Distacco incrementale verso il
TIS
il distacco consiste nello switch dalle
componenti del LIS alle corrispondenti del
TIS, spesso accompagnato da problemi di
gestione della configurazione e controllo
della versione.
Inizio della migrazione
1
3
4
5
6
8
9
10
7
2
11
Fine della migrazione
167
Migrazione delle interfacce utente
l
l
l
l
l
Spesso cio’ che serve e’ solo “mettere il sistema su Internet” e dotarlo di una
interfaccia grafica.
Middleware ad hoc: screen scraper e linguaggi di scripting. Non richiedono alcun
intervento sul Legacy System (e quindi sono applicabili a tutti i tipi di sistemi, anche
quelli monolitici), ma soffrono di problemi di prestazioni.
Una scelta migliore è quella di sostituire l’interfaccia utente, riscrivendola, ma questo
è possibile solo nel caso di sistemi altamente decomponibili o program
decomponibili. Esistono comunque dei tool che, partendo dal codice sorgente della
vecchia interfaccia, aiutano nel processo di Reverse Engineering e di riscrittura della
nuova GUI.
Nella pratica, si adotta un approccio misto, per cui inizialmente, con lo screen
scraping, si offre subito la nuova interfaccia (verificandone anche l’accettabilità da
parte dell’utente – si fa cioè un prototipo) e nel contempo si comincia la riscrittura.
Alla fine del processo la vecchia interfaccia e lo screen scraper (che quindi si
configura come software “usa e getta” per il periodo della migrazione) verranno
ritirate.
168
Migrazione dei dati
l
l
l
l
l
l
conversione (ad esempio da database non relazionale a relazionale)
trasformazione (ad esempio creazione di viste o dati di sommario)
spostamento (ad esempio da database su mainframe ad uno su UNIX)
allocazione (ad esempio da un database centralizzato a più database
distribuiti)
e’ generalmente piu’ semplice della migrazione dell’applicazione e quindi
spesso avviene che il vecchio LIS diventi client di un DBMS basato su nuove
tecnologie (su cui, spesso, insistono anche applicazioni di DataWarehousing)
Sono disponibili, anche in questo caso, strumenti automatici di supporto, sia
per lo scaricamento dei dati in formati intermedi comprensibili che per la
traduzione automatica tra coppie prefissate di ambienti (e.g., il sistema
gerarchicoInformation Management System e DB2)
169
Integrazione tramite DOC
l
l
Si costruiscono sul LIS dei wrapper che presentano al mondo
esterno (OO) dei servizi ben definiti
Ad esempio, tramite screen scraper si puo’ pensare di costruire
il metodo dammi_targhe(Codice_Fiscale) sulla base di dati
legacy dell’ ACI che restituisce l’elenco delle targhe delle
macchine possedute dall’utente in questione, registrare tale
metodo come un metodo di un oggetto CORBA ed invocarlo
tramite ORB
» tramite un browser Corb compliant
» tramite una servlet java attivata su un Web Server
» tramite un client “tradizionale” usando IIOP
» ....
170
Riferimenti
• A. Umar - Object-Oriented, Client-Server, Internet Environments Prentice Hall, 1997
• A. Umar - Application (Re)engineering: Building Web-Based
Applications and Dealing with Legacies - Prentice Hall, 1997 OMG - The
Common Object Request Broker: Architecture and Specification OMG, 1991
• M.L.Brodie, M. Stonebraker - Migrating Legacy Systems Gateways,
Interfaces & The Incremental approach- Morgan Kaufmann Oublisher,
Inc, 1995Oracle 8 and Java- An Oracle Technical White Paper, 1997
• Sun Microsystems - The Java Language Environment: a White Paper 1995
• Oracle 8 Universal Data Server Release 8
http://www.oracle.com/support/products/o8s/sco/html/xo8wgds4.html
171
