7
panacea per tutti i mali, soluzione finale per il problema della
comunicazione connessione di applicazioni eterogenee.
Lo scopo di questa tesi è stato la definizione e la sperimentazione delle
tecniche e delle tecnologie open source che, allo stato attuale, consentono
l’interazione tra il mondo CORBA ed il mondo dei web services,
schematizzando un processo di sviluppo semplice e riproducibile per la
trasformazione di applicazioni CORBA based in API remote web services
based.
La ricerca è stata affrontata con costante riferimento alle esigenze di uno
specifico problema reale. La parte applicativa, infatti, è stata realizzata
presso i laboratori della Carlo Gavazzi Space s.p.a. nella sede di San
Giorgio del Sannio – BN.
La Carlo Gavazzi Space s.p.a. opera nel settore delle tecnologie spaziali e
in settori ad esse confinanti, che siano la naturale prosecuzione del
business satellitare, quali la telematica, la logistica ed il tele rilevamento.
La divisione telematica ha sviluppato, da alcuni anni, un proprio sistema
per il controllo e monitoraggio remoto di veicoli in movimento con
comunicazioni multi-device. La gestione dell’infrastruttura hardware e
software del loro sistema Global Positioning System è basata sul progetto
Multi Operator Station (MOSt), CORBA compliant, sviluppato sia
attraverso l’implementazione di Douglas Schmidt ACE+TAO (Adaptative
Comunication Environment+The Ace Orb) che attraverso l’orb integrato
in Java Standard Development Kit 1.4.
Il progetto MOSt è basato su un modello di programmazione a
componenti, proprietario, denominato Anthill. Questi è orientato al
raggiungimento di alcuni requisiti di qualità del software, considerati
strategici:
8
Scalabilità, indipendenza dalla posizione e dal linguaggio, facile
estensibilità e standardizzazione delle regole di comunicazione tra
componenti.
In tale ambito, si è presentato il problema di rendere utilizzabili alcuni dei
servizi sviluppati dall’applicazione esistente attraverso la rete internet. E’
stata definita e realizzata una soluzione che consente l’esposizione come
web services di un’applicazione CORBA based.
L’aspetto implementativo dei web services è stato affrontato studiando e
utilizzando il SOAP engine Axis, lo strumento open source maggiormente
user friendly oggi esistente. C’è da rilevare che riuscire a sfruttare la
potenza messa a disposizione da Axis, nonché i meccanismi di trasparenza
nella comunicazione tra i messaggi SOAP, significa possedere conoscenze
non banali in merito ad un gran numero d’argomenti. Il loro elenco può
dare un’idea della ripidità della curva d’apprendimento all’uso di questo
strumento piuttosto che alla programmazione dei web services in genere.
Per scrivere un web service bisogna conoscere [43]:
ξ I concetti fondamentali della programmazione in Java, tipi di
dato e classi in primis.
ξ Concetti e definizioni riguardo al meccanismo dei thread,
segnatamente sincronizzazione e sicurezza.
ξ Cos’è un classloader, quale gerarchia di classloader s’incontra
nell’uso degli strumenti di sviluppo, e quali sono le cause
usuali d’eccezioni del tipo “ClassNotFound”
9
ξ Il meccanismo delle eccezioni in Java, di alcune eccezioni
rilevanti come “NullPointerException” e come individuare la
causa di un errore risalendo la catene delle eccezioni.
ξ Concetti fondamentali sulle web application, definizione di
servlet e di struttura di una web application, con riferimento
alla suddivisione in classi, librerie e dati ausiliari.
ξ La configurazione iniziale di un application server e come
eseguire il deploy di una web application.
ξ Concetti fondamentali sulle reti, su TCP/IP.
ξ Cosa sia HTTP ed i concetti base sul protocollo ed i codici
d’errore, gli HTTP headers e i concetti base di autenticazione.
ξ Concetti base su XML e su come si definiscano documenti
well-formed.
In questo lavoro di tesi sono state variamente affrontate e sviluppate le
questioni fin qui accennate.
I primi capitoli introducono ai problemi che ambienti di sviluppo
middleware e modelli di programmazione più evoluti si propongono di
risolvere (capitolo 1), descrivono i concetti fondanti del middleware
CORBA (capitolo 2) e propongono una panoramica introduttiva su
definizioni e concetti legati al mondo dei web services (capitolo 3).
Il capitolo 4 affronta in maniera assai sintetica la descrizione del modello
di programmazione Anthill e alcuni dettagli del progetto MOSt, al fine di
comprendere lo sfondo e l’ambiente da cui si origina questa ricerca.
10
Il capitolo 5 entra più in dettaglio nell’analisi dei possibili modi
d’interazione tra un’applicazione CORBA based ed una SOAP based,
soffermandosi sulle possibili scelte progettuali necessarie ad una soluzione
presenti in letteratura.
I capitoli 6 e 7 affrontano il problema della generazione del web service
con le usuali tecniche dell’ingegneria del software. In particolare, uno
studio di fattibilità, basato su un sistema pilota, verificherà le possibilità
d’interazione secondo uno dei modelli previsti in letteratura (capitolo 6),
per poi applicare le conoscenze maturate allo sviluppo di un prototipo.
(capitolo 7).
Il capitolo conclusivo riepiloga il lavoro compiuto suggerendo alcuni
interessanti spunti per approfondire quanto intravisto o soltanto
accennato nel corso di questa ricerca.
Ogni qual volta sia stato possibile ed opportuno, si è fatto riferimento al
linguaggio di modellazione UML per descrivere, in maniera quanto più
icastica ed efficace, ambiti, ambienti, concetti ed interazioni.
11
“Le antiche case liguri hanno una strana caratteristica:
arroccate sulla montagna, a strapiombo sul mare,
si espandevano lentamente nel tempo,
con la creazione di nuove stanze,
assumendo le forme più disparate
in funzione delle esigenze del nucleo familiare” (*)
1. La programmazione in ambienti distribuiti
1.1. Introduzione
Per cercare di fornire immediatamente una visione della portata e della
prospettiva con cui mi sono confrontato per questo lavoro, mi piace citare
la metafora introduttiva (*) di uno degli articoli che ho consultato [12]. La
portata e la prospettiva sono quelle in cui ci si cala quando ci si vuole
occupare dello sviluppo di software per aziende od organizzazioni di
notevoli dimensioni e complessità: l’integrazione delle tecnologie, siano
esse hardware, software o di rete. Di fatto, come per la crescita della
casetta ligure, la sfida dell’ingegnere del software è far coesistere
applicazioni con un’architettura datata ancorché efficienti con applicazioni
sviluppate ex novo, per rispondere a mutate esigenze del business
aziendale. Peraltro la sfida diventa ancor più avvincente nel momento in
cui l’ingegnere del software è chiamato a supportare il moderno
paradigma di business aziendale: le interazioni collaborative.
La misura dell’efficienza di un’azienda contemporanea non risiede più
nella capacità di automatizzare ed ottimizzare i processi interni ed esterni,
ma nella capacità di creare valore aggiunto attraverso lo sviluppo di
sinergie. Tale risultato si ottiene pensando la propria rete di partner
(clienti e fornitori) come una rete di valori e proponendo la propria
12
capacità aziendale di esaltare i valori (prodotti e servizi) della propria rete
di relazioni, all’interno di un sistema neurale digitale globale in cui il ruolo
ricoperto dall’azienda è assimilabile ad una sinapsi.
Ci rendiamo conto che un’applicazione non è più pensabile come un’entità
indipendente ed avulsa dal contesto, ancor più quando diventa
un’esigenza indispensabile rendere fruibile il proprio sistema informativo
in ambito web.
Una delle caratteristiche principali di un software di qualità diviene
l’interoperabilità.
1.2. L’eterogeneità delle applicazioni
Il conseguimento dell’obiettivo di qualità cui facevamo riferimento si
scontra con il problema della diffusissima eterogeneità delle applicazioni
in qualsiasi ambiente di rete. Più di un fattore ha contribuito alla creazione
di questo stato di cose. Ad esempio:
¾ Molteplicità delle soluzioni: raramente c’è un’unica soluzione
accettabile per problemi complessi di ingegneria. Ciò
comporta che persone diverse spesso scelgano soluzioni
diverse per problemi simili.
¾ Efficacia dei costi: non tutti i fornitori sono in grado di offrire
la soluzione migliore al prezzo più basso. Ciò significa che
spesso un consumatore acquista un sistema non perché sia il
migliore ma solo perché ha un prezzo conveniente,
indipendentemente da chi lo abbia prodotto.
13
¾ Legacy system: spesso sostituire sistemi già esistenti, acquistati
molto tempo fa quando le nuove tecnologie non erano ancora
sviluppate, potrebbe essere una scelta troppo costosa e critica
per le attività di un’azienda. L’azienda stessa, allora, preferisce
continuare ad investire sul sistema già esistente (legacy
system) piuttosto che ristrutturarlo secondo le nuove e più
avanzate tecnologie.
¾ Caratteristiche differenti per i nodi della rete: spesso le
applicazioni sono distribuite su una rete di calcolatori dalle
caratteristiche differenti (mainframe, workstation, server,
personal computer), dotati di hardware e sistemi operativi
diversi e non interoperanti.
¾ Linguaggi di programmazione diversi: tipicamente si
preferisce o è necessario utilizzare linguaggi diversi in ambiti
diversi. In ambiente personal computer, per la parte
d’interazione con l’utente (presentation logic), si prediligono
linguaggi visuali quali Visual Basic o Visual C++. Linguaggi,
per così dire, tradizionali, quali COBOL, C, C++ sono spesso
utilizzati per lo sviluppo delle funzionalità di un’applicazione
(business logic). SQL è utilizzato per l’accesso ai dati (database
logic), Java per applicazioni multimediali o web oriented.
¾ Deployment dei dati: i dati sono distribuiti su più nodi di
elaborazione, memorizzati in archivi o con gestione di basi di
dati (DBMS) diversi, e, generalmente, devono essere condivisi
da applicazioni locali e remote.
14
¾ Problematiche inerenti alla sicurezza, alla tolleranza ai
guasti, contesa e condivisione delle risorse: queste
problematiche, presentandosi ad un livello di complessità
considerevolmente superiore al caso di sistema centralizzato o
di rete omogenea, costituiscono un ulteriore fattore aggravante
nella ricerca di soluzioni collaborative in ambienti di rete
eterogenei.
Da quanto detto, si evince come l’interoperabilità possa assumere forme
diverse, che vanno dalla possibilità di scambiare dati tra le applicazioni,
alla cooperazione applicativa ovvero l’integrazione tra le funzionalità
delle diverse tipologie di applicazioni (aziendali, web, automazione
d’ufficio, ecc.).
Le soluzioni proposte per venire incontro alle esigenze evidenziate sono
basate su una tecnologia più matura, quale i middleware, e una tecnologia
più recente e non ancora sufficientemente in grado di fornire tutte le
risposte necessarie, come più dettagliatamente vedremo in seguito: i web
services.
1.3 I middleware
Con questo neologismo inglese si suole indicare un elemento centrale delle
moderne tecnologie d’interconnessione di sistemi eterogenei in ambiente
di rete. Tale tecnologia può definirsi come un’infrastruttura software
d’interconnessione la cui caratteristica è quella di situarsi sopra il livello
delle apparecchiature hardware e dei sistemi operativi (figura 1.1)
fornendo servizi di cooperazione applicativa per le diverse tipologie di
applicazioni.
15
Distribuited
Middleware API
Middleware
Operating System API
ProcessComm Storage
Distribuited
Middleware API
Middleware
Operating System API
ProcessComm Storage
Networt ork
Figura 1.1: La posizione dello strato software middleware.
16
1.4 Caratteristiche generali
L’uso di una similitudine è, ancora una volta, un modo agevole per
specificare le caratteristiche generali di un framework middleware.
Riferendosi ai meccanismi realizzati da un sistema operativo quando
fornisce un insieme di servizi d’accesso alle risorse dell’elaboratore alle
applicazioni o agli utenti, a prescindere dalla conoscenza di dettagli
specifici sulle apparecchiature hardware, analogamente, una piattaforma
middleware può pensarsi costituita da un insieme di servizi, i quali
mettono le applicazioni in grado di interoperare scambiandosi dati su rete,
indipendentemente dai dettagli e dalle differenze tra i linguaggi di
programmazione, dai sistemi operativi e dai protocolli sottostanti.
Tipicamente le piattaforme middleware sono definite “glue tecnologies”
(tecnologie collanti), in modo da evidenziarne la caratteristica
predominante di tecnologie d’integrazione per le applicazioni. Come
vedremo, ogni tecnologia middleware fa riferimento ad un determinato
modello di elaborazione distribuita. Ciò nonostante, almeno due
prerogative sono da considerarsi caratteristiche comuni:
™ Offrire meccanismi d’interazione e comunicazione tra
applicazioni, ad un alto livello d’astrazione.
™ Rendere trasparente al programmatore l’eterogeneità tra i
sistemi dell’architettura distribuita.
17
Le eterogeneità possono essere mascherate quando la piattaforma
middleware fornisce meccanismi di:
” Trasparenza del sistema operativo e dei protocolli di rete.
Lo strato middleware è situato ad un livello d’astrazione
superiore al livello del sistema operativo e dei protocolli di
comunicazione. Conseguentemente, i servizi forniti dalle API1
middleware possono essere definiti in maniera indipendente
dagli strati software sottostanti, ottenendo la portabilità delle
applicazioni tra le diverse piattaforme.
” Trasparenza del linguaggio di programmazione.
La comunicazione tra i componenti di un’applicazione,
qualora siano sviluppati in linguaggi diversi, pone problemi
quali la differenza tra i tipi di dato supportati piuttosto che la
diversità dei meccanismi di scambio parametri quando
s’invocano sottoprogrammi. Il livello middleware può
consentire l’interoperabilità, superando le barriere tra i
linguaggi di programmazione, definendo un sistema di tipi
intermedio e regole non ambigue di corrispondenza con i tipi
dei linguaggi più diffusi.
” Trasparenza della posizione.
In un sistema distribuito, dati e servizi dovrebbero essere
accessibili a livello logico, senza conoscere l’effettiva locazione
fisica. In altri termini, i componenti di un’applicazione
distribuita dovrebbero poter comunicare mediante
1
API: Application Programming Interface
18
meccanismi d’alto livello, che nascondano la loro effettiva
distribuzione.
” Trasparenza della migrazione.
Dati e servizi possono, in generale, venir rilocati durante il
loro ciclo di vita. Lo strato middleware, se un componente
migra, può tenere traccia dei suoi spostamenti e consentire
l’accesso a componenti mobili sulla rete, in maniera
trasparente ai moduli clienti. In tal caso si dice che il
middleware supporta la proprietà di migration transparency.
” Trasparenza ai guasti.
I sistemi distribuiti, a differenza di quelli centralizzati,
presentano più punti di potenziali guasti. Un’elaborazione
distribuita può fallire anche solo in maniera parziale per
malfunzionamenti che avvengono nei singoli nodi o nel
sottosistema di comunicazione. La gestione dei
malfunzionamenti in un sistema distribuito richiede tecniche
raffinate per gestire lo stato complessivo della computazione.
Il middleware può offrire al programmatore meccanismi
d’alto livello per mascherare i guasti. Si parla in tal caso di
failure transparency.
” Trasparenza della replicazione.
La replicazione è una delle tecniche più comuni per realizzare
politiche di tolleranza ai guasti in un sistema distribuito. Tale
tecnica è utilizzata anche per altri obiettivi. Ad esempio, uno
di essi è migliorare le prestazioni attraverso il bilanciamento
del carico d’elaborazione. L’esistenza di più copie di un
19
componente dovrebbe essere trasparente agli altri componenti
che accedono ai suoi servizi. Piattaforme middleware avanzate
supportano tale proprietà, detta di replication transparency.
” Trasparenza delle implementazioni commerciali.
Alcune tecnologie, tra cui CORBA, si presentano in realtà
come specifiche di riferimento promosse da organizzazioni di
produttori, spesso poi accolte da enti di standardizzazione. Le
varie implementazioni commerciali sono realizzate in maniera
conforme allo standard, eventualmente differenziandosi tra
loro per aspetti secondari o per servizi aggiuntivi fuori
standard. In questo modo è resa possibile l’interoperabilità tra
applicazioni, su implementazioni commerciali diverse, dello
stesso tipo di middleware.
1.5. Modelli di middleware
Le piattaforme middleware diffusesi negli ultimi anni sono molteplici e
dalle caratteristiche significativamente differenti in merito a funzionalità
offerte, meccanismi di comunicazione, standard, modelli di
programmazione e ambito applicativo. C’è da rilevare, inoltre, che questa
tecnologia è in continua evoluzione.
Una classificazione delle diverse tecnologie presenti sul mercato non si
presenta né agevole né esaustiva. In genere le tecnologie middleware si
classificano o sulla base del contesto d’uso o sulla base del meccanismo di
comunicazione. Il primo criterio da vita ad una classificazione nelle
seguenti tre macrocategorie:
20
ξ Middleware di comunicazione tra applicazioni (Application
Communication Middleware).
ξ Middleware per l’accesso ai dati (Data Access Middleware).
ξ Middleware per l’integrazione di servizi base di rete (Network
middleware).
Mediante il secondo criterio si possono raggruppare le tecnologie presenti
sul mercato come:
ξ Middleware per comunicazioni sincrone
ξ Middleware per comunicazioni asincrone
ξ Middleware per la gestione di transazioni distribuite.
Un’ulteriore possibile classificazione si basa sui modelli di
programmazione per l’interazione, sia intra-applicazione che inter-
applicazione. In seguito si elencano i principali modelli con alcuni esempi
di tecnologie pertinenti presenti sul mercato.
ξ Il modello di chiamata di procedura remota (Remote
Procedure Call o RPC): Sun RPC, OSF Distributed Computing
Environment.
ξ Il modello orientato ai messaggi (Message-Oriented
Middleware o MOM): IBM mqseries.
ξ Il modello transazionale (transaction Processing o TP):
X/Open DTP.
Ricevi informazioni sui nostri servizi, sulle offerte e non perdere news e consigli su università e lavoro.
