Tesi Di Laurea

Università della Calabria
Facoltà di Ingegneria
Corso di Laurea in Ingegneria Informatica
Dipartimento DEIS
TESI DI LAUREA
Sviluppo di un sistema per la configurazione della rete “UTRAN”
tramite un Enterprise Service Bus Open Source
RELATORE
Prof. Sergio FLESCA
CANDIDATO
CO-RELATORE
Dott. Ciro ROMANO
Francescantonio ALBANESE
Indice
Introduzione
4
Capitolo 1: Enterprise Application Integration
9
1.1 L‟importanza di “integrare”
9
1.2 Enterprise Application Integration
14
1.3 Dall'Enterprise Integration alle architetture orientate ai
servizi
15
Capitolo 2: Service-Oriented Architecture e Web Services:
concetti base
18
2.1 Service-Oriented Architecture (SOA)
18
2.2 Caratteristiche di una Service-Oriented Architecture
20
2.3 Come funziona una Service-Oriented Architecture
22
2.4 I Web Services
25
2.5 Web Services e architettura di tipo non SOA
31
2.6 Web Services e architettura SOA
35
Albanese Francescantonio, 79117
Pagina 1
Capitolo 3: Service-Oriented Architecture e gli Enterprise
Service Bus
38
3.1 Enterprise Service Bus come infrastruttura di supporto ad
architetture Service-Oriented
38
3.2 Perché Enterprise Service Bus?
43
3.3 Enterprise Service Bus: Funzionalità supportate
48
Capitolo 4: Una piattaforma di integrazione applicativa
51
4.1 Perché GreenVulcanoESB?
52
4.2 Componenti Base e Architettura di GreenVulcanoESB
53
4.2.1 Il Virtual Layer
53
4.2.2 Il Core
54
4.2.3 Integration Suite
55
4.2.4 Connectivity Layer
56
4.3 Amministrazione e controllo del sistema
58
4.4 VulCon
58
4.5 DataHandler
59
4.6 UDDI
60
4.7 I Vantaggi dell'utilizzo di GreenVulcanoESB
61
Albanese Francescantonio, 79117
Pagina 2
Capitolo 5: Configurazione di GreenVulcanoESB per la
gestione della rete “UTRAN”
63
5.1 L‟ambiente di lavoro
63
5.2 Che cos è la rete “UTRAN”?
65
5.2.1La tecnologia “UMTS”
65
5.2.2 Architettura di base del sistema “UMTS”
71
5.3 Scenario del sistema
76
5.4 Configurazione di GreenVulcanoESB
79
Testing
106
Conclusioni
114
Bibliografia
115
Albanese Francescantonio, 79117
Pagina 3
Introduzione
Tra gli obbiettivi primari di ogni azienda c‟è quello di rimanere sempre a
passo con i tempi, seguendo l‟evoluzione tecnologica, in modo da poter offrire
ai propri clienti nuovi servizi a prezzi competitivi. Ogni azienda pertanto ha
la necessità di evolversi continuamente, riorganizzandosi periodicamente sia
in termini di tecnologia utilizzata, eventualmente adottandone delle nuove,
sia della propria struttura interna, fondendola in alcuni casi con quella di
altre aziende evitando, allo stesso tempo, di perdere investimenti passati.
Risulta indispensabile, quindi, per un‟azienda, costruire un sistema
informativo che sia capace di assorbire in maniera flessibile gli impatti delle
nuove
tecnologie
salvaguardando
il patrimonio
informativo
esistente.
Vediamo quindi che il modo migliore per fornire nuovi servizi senza cambiare
le basi del corebusiness delle compagnie è l‟integrazione dei vecchi sistemi
con quelli nuovi.
La necessità di integrare nasce in maniera naturale nell‟evoluzione dei
sistemi. Lo scopo principale di questa attività è di riuscire ad integrare
sistemi informativi eterogenei e autonomi, in modo da sviluppare il business
e mantenere stabilità a quanto già presente nell‟azienda.
Con l‟obbiettivo di avere un integrazione ideale in cui i sistemi e gli
applicativi di un‟azienda sono tutti interconnessi e i processi operativi
semplificati, sono stati sviluppati software integrativi specializzati, noti come
Albanese Francescantonio, 79117
Pagina 4
Enterprise Application Integration (EAI), che trasferiscono i dati da un
sistema all‟altro e correlano i complessi processi operativi di un‟azienda ai
sistemi informativi e al software in uso.
I progetti EAI risultano però, di grandi dimensioni, complessi, non flessibili,
costosi per l‟elevatissima tassa di licenza software e molti di essi non sono in
grado di rispettare tempi e budget.
Con l‟avvento del Web, ambiente eterogeneo per eccellenza, e lo sviluppo di
standard che descrivono come i sistemi informatici debbano comunicare, il
software EAI è progettato e sviluppato in modo da utilizzare questi ultimi con
una netta riduzione dei costi di sviluppo e manutenzione. Nasce la necessità
di avere un modo “standard” per esporre un software su una rete attraverso
un‟interfaccia comprensibile da tutte quelle aziende che, volendo far
interagire le proprie applicazioni con quelle di altre compagnie, riconoscono
tale standard, così, si assiste alla definizione di una serie di best-practices
indicate con il termine Service-Oriented Architecture (SOA, Architettura
Orientata ai Servizi) e all‟ introduzione dei Web Services.
Queste
nuove
tecnologie
hanno
guadagnato
l‟attenzione
dei
leader
dell‟Information Technology, dei venditori e degli analisti. L’Enterprise
Service Bus (ESB) racchiude le caratteristiche migliori di queste tecnologie.
Un ESB è generalmente progettato per permettere che applicazioni di diverso
tipo si scambino messaggi con lo scopo di estendere le funzionalità di
ciascuna applicazione con quelle fornite dalle altre applicazioni e di rendere
virtuali le risorse aziendali, permettendo alla logica di business dell‟azienda
Albanese Francescantonio, 79117
Pagina 5
di essere sviluppata e gestita indipendentemente dall‟infrastruttura della
rete. Le applicazioni che si collegano all‟ESB, possono inserire documenti
aziendali, quali fatture, andamento titoli o transizioni commerciali. Tali
documenti, viaggiano attraverso il bus da un applicativo all‟altro e vengono
tradotti e trasformati in modo che ciascun applicativo veda il documento in
un formato e in una struttura comprensibile.
L‟ESB consente un‟integrazione su vastissima scala. A differenza delle
tradizionali soluzioni EAI, che richiedono un significativo esborso iniziale,
l‟ESB può essere utilizzato per connettere anche due soli sistemi aziendali in
modo assolutamente economico. Gli altri sistemi possono essere aggiunti
anche uno alla volta, permettendo alle aziende di mantenere il controllo sulle
priorità, la portata e il costo dei rispettivi progetti. Quando viene collegato
all‟ESB, ogni successivo sistema si rende disponibile a tutti gli altri sistemi
collegati.
Questo strumento risulta essere un rivoluzionario approccio all‟integrazione
applicativa. Essendo una soluzione aperta e basata su standard, offre
vantaggi fondamentali rispetto alla tradizionale EAI.
Le aziende possono integrare i processi con sistemi terzi e interni, possono
integrare applicativi legacy, non sono "vincolate" a un particolare fornitore,
possono sviluppare e gestire una soluzione ESB senza doversi affidare a
consulenti esterni e possono cominciare a sviluppare piccoli progetti
integrativi da ampliare successivamente, riducendo i rischi e utilizzando i
budget in modo più razionale. Il basso costo di sviluppo di questa tecnologia
Albanese Francescantonio, 79117
Pagina 6
basata su standard si riflette in una tassa di licenza software inferiore
rispetto alla EAI.
Ad oggi, diverse compagnie di Information Technology hanno realizzato o
intendono realizzare un proprio prodotto ESB da proporre sul mercato, lo
scopo di questa tesi è quello di proporre l‟implementazione che è stata
sviluppata nell‟azienda presso la quale ho svolto il tirocinio “l‟E@I Software”,
azienda
operante
nel
campo
dell'integrazione
applicativa
in
ambito
Enterprise, presentando poi un esempio di utilizzo dello strumento per
mostrarne alcune funzionalità.
La tesi è articolata nel modo seguente:
Nel Capitolo 1 è affrontato il problema dell‟integrazione in ambito aziendale
e l‟avvento delle nuove tecnologie che tentano un miglioramento del processo
di integrazione, la SOA e i web services.
Nel Capitolo 2 è stata fatta una panoramica sulle caratteristiche e sul
funzionamento di una Service-Oriented Architecture e sui web services.
Nel Capitolo 3 viene presentato l‟Enterprise Service Bus (ESB) come
infrastruttura di supporto ad architetture Service-Oriented ed è messa in
evidenza l‟importanza dell‟utilizzo di questo strumento come supporto alle
aziende per incrementare la connettività ed aggiungere flessibilità per
facilitare il cambiamento e avere un maggiore controllo sull‟utilizzo delle
importanti risorse che unisce.
Il Capitolo 4 è dedicato alla descrizione di GreenVulcanoESB, l‟Enterprise
Service Bus prodotto dall‟azienda presso la quale ho svolto il tirocinio.
Albanese Francescantonio, 79117
Pagina 7
Vengono descritti in particolare le componenti base dello strumento,
l‟architettura e i vantaggi del suo utilizzo.
La tesi si conclude con il Capitolo 5 in cui è descritto nei dettagli il lavoro
svolto in azienda, in particolare, la configurazione del bus per sviluppare il
sistema di gestione per la rete “UTRAN”.
Albanese Francescantonio, 79117
Pagina 8
Capitolo 1
Enterprise Application Integration
1.1 L’importanza di “integrare”
Lo sviluppo dei sistemi informativi di un‟azienda non avviene in maniera
continua e omogenea: spesso, l‟avvento di nuove tecnologie e i bisogni legati
al business1 producono ciclicamente la necessità di creare nuovo software.
Quando questo accade, bisogna affrontare diverse problematiche sia dal
punto di vista tecnologico che economico e organizzativo.
L‟aspetto economico rappresenta per un‟azienda, con un sistema informativo
complesso, uno dei punti primari da considerare, infatti, questa è
consapevole che il cambiamento è inevitabile pertanto il suo principale
obiettivo è gestirlo in modo tale da minimizzarne l‟impatto. Ciò significa
evolversi conservando allo stesso tempo prodotti, tecnologie e applicazioni
che già si possiedono.
1
Il termine inglese business identifica in generale un'attività economica. Approssimativamente può essere
tradotto con il termine italiano affari.
Albanese Francescantonio, 79117
Pagina 9
Tra le sollecitazioni che inducono all‟evoluzione del sistema informativo c‟è il
business, che è in continuo e rapido cambiamento, la competizione, che
diventa sempre maggiore e gli standard, che impongono alle aziende una
sempre maggiore reattività e apertura del sistema informativo.
Oltre a queste sollecitazioni “esterne”, ce ne possono essere altre, di varia
natura, come ad esempio il raggiungimento di obiettivi legati alla
ottimizzazione dei processi aziendali, oppure, la necessità di integrare
applicazioni esistenti.
L‟obiettivo delle aziende è di rispondere sempre più velocemente a queste
continue sollecitazioni, costruendo un sistema informativo capace di
assorbire
in
maniera
flessibile
gli
impatti
delle
nuove
tecnologie,
salvaguardando il patrimonio informativo esistente.
La necessità di effettuare attività di integrazione nasce, quindi, in maniera
naturale nell‟evoluzione dei sistemi con lo scopo principale di riuscire ad
integrare sistemi informativi eterogenei e autonomi, per sviluppare il
business e mantenere stabilità a quanto già presente nell‟azienda.
Nel corso degli anni, infatti, i sistemi informativi si sono evoluti in una
stratificazione di prodotti, tecnologie e architetture eterogenee, data la
presenza congiunta di soluzioni differenti, magari sviluppate in tempi e con
prospettive
differenti
e
ogni
ambiente
informatico
risulta
essere
caratterizzato da un‟ampia eterogeneità e quindi, quasi inevitabilmente, da
svariati problemi di interoperabilità e integrazione tra i diversi componenti.
Albanese Francescantonio, 79117
Pagina 10
Con lo sviluppo della rete è diventato concreto il problema dell‟integrazione a
livello business, cioè la creazione di processi Business to Business (B2B) 2
ottenuti componendo funzionalità esposte da organizzazioni differenti.
Possiamo quindi parlare di integrazione “interna”, normalmente legata a una
estensione dei sistemi con nuove o vecchie tecnologie e integrazione
“esterna”.
Il problema è, quindi, molto complesso e va affrontato da un punto di vista
architetturale, pertanto è necessario fare una classificazione delle strategie
architetturali che è possibile utilizzare per l‟integrazione.
Possiamo supporre di avere un sistema informativo a layer (“strati”) che sia
possibile suddividere in:

Data Layer

Business Layer

Presentation Layer
Le strategie di integrazione sono classificabili in base al layer su cui vanno
ad agire. Possiamo quindi pensare di integrare a livello di presentazione
(presentation), a livello di logica applicativa (business) oppure a livello di dati
(data).
2
Business to Business (letteralmente "azienda-verso-azienda"), spesso indicato con l'acronimo B2B, è un
termine comunemente utilizzato per descrivere le transazioni commerciali elettroniche tra imprese.
Albanese Francescantonio, 79117
Pagina 11
La scelta del livello su cui effettuare l‟integrazione dipende da molti fattori e
spesso non è consapevole, perché guidata da considerazioni più di natura
tecnologica
che
architetturale
(esempio
tipico:
bisogna
utilizzare
un
determinato strumento e/o prodotto e/o tool.
La classificazione che è possibile fare sulle strategie di integrazione è:
1. Portal Integration (PI) costruita a livello di interfaccia utente. Questo tipo
di strategia è molto comune dato che è semplice da implementare, non è
invasiva nei confronti delle applicazioni integrate e permette di effettuare in
maniera semplice e rapida l‟aggregazione di sistemi molto eterogenei tra loro.
Mentre l‟integrazione a livello di logica di business aggrega elaborazione di
sistemi diversi, l‟integrazione a livello di portale visualizza in una singola
finestra le informazioni provenienti da sorgenti multiple e differenti. Quello
che viene realizzato è quindi un “accorpamento” di diverse applicazioni su
un‟interfaccia comune. Ad esempio,
è possibile pensare di integrare
un‟applicazione di customer-care e un‟applicazione di gestione di dati
bancari: l‟operatore può visualizzare sulla stessa schermata il conto corrente
associato a un utente (sulla “zona” dedicata all‟applicazione di customercare) e effettuare delle operazioni sul conto corrente di questo utente sulla
seconda applicazione (sull‟altra
zona). Il portale diventa di fatto il punto
centrale di accesso per un insieme eterogeneo di applicazioni.
2. Enterprise Information Integration (EII) è un approccio incentrato
sull‟integrazione a livello dati. Si basa sul concetto che in alcune
organizzazioni il problema è legato non tanto alla condivisione della logica,
Albanese Francescantonio, 79117
Pagina 12
quanto ad avere una modalità di accesso ai dati centralizzata, omogenea e
condivisa. In questo caso si ritiene che l‟integrazione a livello di logica
applicativa non sia necessaria: l‟obiettivo è avere applicazioni che agiscono
sugli stessi dati, che devono essere quindi accessibili in maniera omogenea.
3. Enterprise Application Integration (EAI) con questo termine si indicano
tutte quelle strategie focalizzate sull‟integrazione della logica applicativa; lo
scopo è la condivisione della business logic3 tra applicazioni diverse o la
composizione, in processi nuovi, di “pezzi” di logica già sviluppati. Al
contrario
della
PI,
dove
sia
i
dati
che
la
logica
possono
vivere
indipendentemente, in questo caso parte della logica di business è
necessariamente condivisa.
È importante notare che i tre approcci descritti, Portal Integration (PI),
Enterprise Application Integration (EAI) e Enterprise Information Integration
(EII), non sono in assoluta alternativa ma possono essere complementari:
l‟EII può ad esempio essere posta al servizio di soluzioni di portale fornendo
ad esse un accesso unificato a diverse sorgenti dati, con una semplificazione
nella costruzione delle soluzioni stesse.
Per lo scopo di questa tesi, ci soffermeremo in maniera più dettagliata
sull‟Enterprise Application Integration.
3
Business Logic è un termine che si riferisce a tutta quella logica applicativa che rende operativa
un'applicazione. Il business logic racchiude in sé regole cosiddette di "business", piuttosto che regole ed
elementi legati alla visualizzazione delle informazioni (vista o interfaccia grafica) o alla memorizzazione dei dati
(es. database, ecc.).
Albanese Francescantonio, 79117
Pagina 13
1.2 Enterprise Application Integration
Possiamo classificare le strategie di integrazione EAI secondo vari approcci. Il
primo approccio prevede la realizzazione di collegamenti peer-to-peer (P2P)4
che permettano di avere connessioni dirette tra le applicazioni da integrare,
ognuna delle quali può chiamare l'altra mediante specifiche Application
Programming Interfaces (APIs)5 e gestire singolarmente i problemi di
comunicazione e di mapping dei dati.
Il vantaggio principale dell‟approccio peer-to-peer è che in questo modo si
crea una connessione “stretta” e sincrona tra le due applicazioni, con la
possibilità di integrare all‟interno del codice non solo le necessarie
conversioni dei dati, ma anche le regole di business. Lo svantaggio principale
è che tale codice può essere complesso da sviluppare e va generato per ogni
coppia di applicazioni. All‟aumentare delle applicazioni da integrare crescono
anche le connessioni da implementare e l‟accoppiamento tra di esse, con
evidenti impatti sui costi di sviluppo e soprattutto di manutenzione.
Per evitare i problemi sopra descritti, è opportuno definire nell‟architettura
uno strato centrale di integrazione che permetta di isolare le applicazioni
gestendone le interconnessioni. Questo tipo di architettura può essere
4
Per peer-to-peer (o P2P) si intende una rete di computer o qualsiasi rete informatica che non possiede nodi
gerarchizzati come client o server fissi (clienti e serventi), ma un numero di nodi equivalenti (pari, in inglese
peer appunto) che fungono sia da cliente che da servente verso altri nodi della rete.
5 Le Application Programming Interface API (Interfaccia di Programmazione di un'Applicazione), sono ogni
insieme di procedure disponibili al programmatore, di solito raggruppate a formare un set di strumenti specifici
per un determinato compito.
Albanese Francescantonio, 79117
Pagina 14
realizzata tramite un approccio diretto (Server-Based), oppure tramite
l‟utilizzo di un middleware6 di appoggio.
L‟approccio diretto (Server-Based), prevede di utilizzare una qualche
tecnologia di connessione e comunicazione, demandando allo strato
applicativo le ulteriori problematiche di integrazione.
Con l‟approccio basato sull‟utilizzo di un middleware che agisce da
intermediario,
si
definisce
nell‟architettura
uno
specifico
strato
di
integrazione che permette di centralizzare la gestione delle interconnessioni,
evitando di affidare questo problema alle specifiche applicazioni.
1.3 Dall'Enterprise Integration alle architetture orientate ai
servizi
Con l‟avvento del Web, ambiente eterogeneo per eccellenza, i tradizionali
approcci all‟integrazione di applicazioni non sono più utilizzabili. Questo è
dovuto, oltre che all‟eterogeneità del campo di sviluppo, anche al fatto che il
controllo dell‟elaborazione non è più in mano ad una singola azienda, dato
che
l‟interazione
avviene
tra
applicazioni
appartenenti
a
differenti
compagnie. Vi è quindi la necessità di avere un modo “standard” per esporre
un software su una rete attraverso un‟interfaccia comprensibile da tutte
quelle aziende che, volendo far interagire le proprie applicazioni con quelle di
6
Con il termine middleware si intende un insieme di programmi informatici che fungono da intermediari tra
diverse applicazioni. Sono utilizzati come supporto per applicazioni distribuite complesse.
Albanese Francescantonio, 79117
Pagina 15
altre compagnie, riconoscono tale standard. Di conseguenza, per superare le
limitazioni di middleware e piattaforme EAI, sono state definite una serie di
best-practices che globalmente vengono indicate con il termine ServiceOriented Architecture (SOA, Architettura Orientata ai Servizi) e sono
stati introdotti i Web Services.
La Service-Oriented Architecture è un nuovo paradigma architetturale che
risolve
i
problemi
tradizionalmente
legati
all'integrazione,
poiché
nell'architettura che ne deriva, applicazioni software scritte in diversi
linguaggi di programmazione e implementate su diverse piattaforme
hardware possono interagire e scambiare informazioni e processi sotto forma
di servizi indipendentemente dalle singole logiche di business che li
generano. Essa pone delle specifiche condizioni che i componenti del sistema
devono rispettare e le caratteristiche che tale sistema deve necessariamente
avere.
I Web Services sono invece una nuova tecnologia, che si basa su standard
specifici, quali eXtensible Markup Language (XML), Simple Object Access
Protocol (SOAP), Web Services Description Language (WSDL), Universal
Description, Discovery and Integration (UDDI), di cui parleremo più avanti,
la quale fornisce un facile metodo di interfacciamento tra le applicazioni.
Questa tecnologia non è legata all‟architettura orientata ai servizi ma, ha
molti punti di contatto con essa e i sistemi che utilizzano i Web Services,
sfruttando
tutte
le
loro
potenzialità,
implementano
esattamente
un‟architettura di tale tipo. Web Services e SOA cercano di fornire una
Albanese Francescantonio, 79117
Pagina 16
soluzione al problema dell‟interoperabilità e le fondamenta per lo sviluppo di
applicazioni distribuite su larga scala.
Molti dei principi di SOA si sposano quindi alla perfezione con le
problematiche
di
integrazione
e
discendono
direttamente
dalla
consapevolezza che, se il sistema che si sviluppa ha successo, in futuro
occorrerà estenderlo/integrarlo, oppure dal fatto che si ritiene necessario
conservare gli asset7 dell'organizzazione a fronte di una evoluzione
tecnologica, in questo caso facendo esplicitamente integrazione.
Fare integrazione con SOA significa cercare di trasformare le funzionalità già
presenti in servizi. Questa evoluzione è indice di una maggiore maturità
architetturale delle organizzazioni che si rendono conto dei costi che
derivano da un‟errata applicazione dell'integrazione.
7
Gli Asset coincidono con il complesso di hardware, software conoscenze e abilità operative consolidate di
proprietà dell'impresa.
Albanese Francescantonio, 79117
Pagina 17
Capitolo 2
Service-Oriented Architecture e Web Services:
concetti base
2.1 Service-Oriented Architecture
Una Service-Oriented Architecture (SOA, Architettura Orientata ai
Servizi) è un modello architetturale per la progettazione di sistemi residenti
su una rete che focalizza l‟attenzione sul concetto di servizio. Il presupposto
che guida la SOA è la considerazione che conviene sviluppare sistemi già
pensando all'integrazione (il cambiamento è inevitabile) piuttosto che
adattarli volta per volta. Un sistema costruito seguendo la filosofia SOA è
costituito da applicazioni, chiamate servizi, ben definite ed indipendenti
l‟una dall‟altra, che risiedono su più computer all‟interno di una rete (ad
esempio la rete interna di una azienda o una rete di connessione fra più
aziende che collaborano). Ogni servizio mette a disposizione una certa
funzionalità e può utilizzare quelle che gli altri servizi hanno reso disponibili,
Albanese Francescantonio, 79117
Pagina 18
realizzando, in questo modo, applicazioni di maggiore complessità. Inoltre, in
una Service-Oriented Architecture è possibile modificare rapidamente questi
servizi, combinarli, aggiungerne di nuovi, modificare i processi per
rispondere alle specifiche esigenze di business e utilizzare i servizi in modo
illimitato e personalizzato: il processo di business, in questo modo, non è più
vincolato da una specifica piattaforma o da una applicazione ma può essere
considerato come un componente e quindi riutilizzato o modificato.
SOA è una forma particolare di Distributed System, la cui definizione è la
seguente:
Un Distributed System (Sistema distribuito) consiste di vari agenti
software distinti che devono lavorare insieme per svolgere alcuni
compiti, inoltre, gli agenti in un sistema distribuito non operano
nello stesso ambiente di calcolo, pertanto devono comunicare per
mezzo di stack di protocolli hardware/software su una rete. Questo
significa che le comunicazioni in un sistema distribuito sono meno
veloci e affidabili rispetto a quelle che utilizzano invocazione diretta
del codice e memoria condivisa e ha importanti implicazioni
architetturali, perché i sistemi distribuiti richiedono che gli
sviluppatori (di infrastruttura e applicazioni) considerino la latenza,
fattore imprevedibile dell‟accesso remoto, e tengano presente
questioni relative alla concorrenza e la possibilità di fallimenti
parziali.
Albanese Francescantonio, 79117
Pagina 19
2.2 Caratteristiche di una Service-Oriented Architecture
Con la Service-Oriented Architecture (SOA) sono definite alcune proprietà,
orientate al riutilizzo e all‟integrazione in un ambiente eterogeneo, che
devono essere rispettate dai servizi che compongono il sistema. In particolare
un servizio dovrà:
• essere ricercabile e recuperabile dinamicamente.
Un servizio deve poter essere ricercato in base alla sua interfaccia e
richiamato a tempo di esecuzione. La definizione del servizio in base alla sua
interfaccia rende quest‟ultima (e quindi l‟interazione con altri servizi)
indipendente dal modo in cui è stato realizzato il componente che lo
implementa.
• essere auto-contenuto e modulare.
Ogni servizio deve essere ben definito, completo ed indipendente dal contesto
o dallo stato di altri servizi.
• essere definito da un‟interfaccia ed indipendente dall‟implementazione.
Deve cioè essere definito in termini di ciò che fa. Questo determina
l‟indipendenza del servizio non solo dal linguaggio di programmazione
utilizzato per realizzare il componente che lo implementa ma anche dalla
piattaforma e dal sistema operativo su cui è in esecuzione: non è necessario
Albanese Francescantonio, 79117
Pagina 20
conoscere come un servizio è realizzato ma solo quali funzionalità rende
disponibili.
• essere debolmente accoppiato con altri servizi (loosely coupled).
Un‟architettura è debolmente accoppiata se le dipendenze fra le sue
componenti sono in numero limitato. Questo rende il sistema flessibile e
facilmente modificabile.
• essere reso disponibile sulla rete attraverso la pubblicazione della sua
interfaccia (in un Service Directory) ed accessibile in modo trasparente
rispetto alla sua allocazione. Essere disponibile sulla rete lo rende accessibile
da quei componenti che ne richiedono l‟utilizzo e l‟accesso deve avvenire in
maniera indipendente rispetto all‟allocazione del servizio. La pubblicazione
dell‟interfaccia deve rendere noto anche le modalità di accesso al servizio.
Deve mettere a disposizione un basso numero di operazioni, cioè poche
funzionalità, in modo tale da non dover avere un programma di controllo
complesso. Deve interagire con gli altri servizi attraverso lo scambio di
messaggi. Per questo motivo e per il fatto che i servizi possono trovarsi su
sistemi operativi e piattaforme diverse è necessario che i messaggi siano
composti utilizzando un formato standard largamente riconosciuto. I dati
che vengono trasmessi attraverso i messaggi possono essere costituiti sia dal
risultato dell‟elaborazione di un certo servizio sia da informazioni che più
servizi si scambiano per coordinarsi fra loro.
• essere realizzato in modo tale da permetterne la composizione con altri.
Albanese Francescantonio, 79117
Pagina 21
Nell‟architettura SOA le applicazioni sono il risultato della composizione di
più servizi. È per questo motivo che ogni servizio deve essere indipendente
da qualsiasi altro, in modo tale da ottenere il massimo della riusabilità. La
creazione
di
applicazioni
o
di
servizi
più
complessi
attraverso
la
composizione dei servizi di base viene definita Service Orchestration. La
composizione può essere definita con riferimento a linguaggi specializzati
come BPEL (BPEL4WS, Business Process Execution Language for Web
Services).
Queste sono le caratteristiche di un sistema di tipo SOA, di cui adesso
passiamo a descriverne il funzionamento.
2.3 Come funziona una Service-Oriented Architecture
Focalizzando l‟attenzione sul concetto di servizio, i principali attori in causa
sono il fornitore e il richiedente, come nella tipica interazione client server.
Attraverso la Service-Oriented Architecture (SOA) questa interazione viene
arricchita con un ulteriore attore il Service Directory o Service Broker che si
inserisce all‟interno della comunicazione tra fornitore e fruitore del servizio.
Di seguito è riportata una descrizione del ruolo di ognuno dei tre attori
coinvolti in un sistema SOA:
Albanese Francescantonio, 79117
Pagina 22
• Service Provider
Entità che realizza e mette a disposizione un qualche servizio. Tale servizio,
per poter essere trovato da altre entità che vogliono utilizzarlo, deve essere
reso visibile sulla rete, in termine tecnico Pubblicato. A tal fine il Service
Provider descrive il suo servizio usando Web Service Description Language
(WSDL) e successivamente lo comunica al Service Registry che la memorizza
nella directory dei servizi. Il Sevice Provider resta quindi, in attesa, che un
utente richieda i servizi pubblicati.
• Service Directory o Service Broker
Questo componente gestisce la directory dei servizi, permettendo a chi ha
necessità, di ricercare un servizio sulla base delle caratteristiche con le quali
è stato definito e memorizzato. Il Service Directory possiede quindi le
informazioni, come URL e modalità di accesso, di tutti i servizi disponibili.
• Service Consumer o Service Requester
Rappresenta un potenziale utente che richiede un servizio. A tale scopo il
Service Consumer interagisce con il Service Directory per ottenere il servizio
più adatto ai propri obbiettivi. Una volta individuato si collega al Service
Provider corrispondente per fruire del servizio.
In figura 2.1 sono riportate le interazioni fra le entità appena descritte.
Albanese Francescantonio, 79117
Pagina 23
Figura 2.1: Esempio di Architettura SOA.
Tutte queste interazioni passano attraverso quella che viene genericamente
definita Rete di Comunicazione, la quale in un‟implementazione reale di una
SOA può essere costituita sia da Internet sia da una Intranet. SOA definisce,
dunque, le caratteristiche che i componenti facenti parte di un sistema
devono avere al fine di poter definire quest‟ultimo un‟architettura orientata ai
servizi.
Ai tre ruoli si va ad aggiungere un‟altra entità: il Service Contract, che
definisce il formato per la richiesta di un servizio e per relativa risposta.
Poiché i servizi devono essere ricercati e recuperati dinamicamente, il Service
Contract deve essere pubblicato su un Service Broker dal Service Provider.
Albanese Francescantonio, 79117
Pagina 24
Va notato che quest‟entità coinvolte in un sistema SOA, possono essere
distribuite sul territorio e possono utilizzare piattaforme differenti, con
l‟unico vincolo di dover utilizzare tutte e tre un canale trasmissivo comune.
Rimanendo sul mezzo trasmissivo, questo risulta essere un parametro
dell‟architettura, quindi l‟approccio adottato dalle SOA ha il vantaggio di
potersi integrare con diversi ambienti quali il Web, la telefonia mobile e altri
permettendo di realizzare applicazioni multi canale, fruibili attraverso
dispositivi di natura molto diversa.
2.4 I Web Services
I Web Services sono un nuovo tipo di applicazioni web che cooperano fra
loro, indipendentemente dalla piattaforma sulla quale si trovano, attraverso
lo scambio di messaggi. Ognuna di queste applicazioni viene chiamato Web
Service (Servizio Web), o più semplicemente servizio, del quale il Web
Services Architecture Working Group (del W3C8) dà la seguente definizione:
Un Web Service è un‟applicazione software identificata da un
Uniform Resource Identifier (URI)9, le cui interfacce pubbliche e
8
Il World Wide Web Consortium (universalmente noto come W3C) è una organizzazione che sviluppa gli
standard ufficiali (specifiche, linee guida, software e strumenti) usati nell’ambito di Internet. Questo consorzio,
nato nel 1994 con l’obiettivo di sviluppare il potenziale del World Wide Web, è neutrale rispetto ai venditori.
9
Uniform Resource Identifier (URI, acronimo più generico rispetto ad "URL") è una stringa che identifica
univocamente una risorsa generica che può essere un indirizzo Web, un documento, un'immagine, un file, un
servizio, un indirizzo di posta elettronica, ecc. L'URL è un URI, o più comunemente chiamato indirizzo web.
Albanese Francescantonio, 79117
Pagina 25
collegamenti sono definiti e descritti come documenti eXtensible
Markup Language (XML), nello specifico WSDL. La sua definizione
può essere ricercata da altri agenti software situati su una rete, i
quali possono interagire direttamente con il Web Service, con le
modalità specificate nella sua definizione, utilizzando messaggi
basati su XML (SOAP), scambiati attraverso protocolli Internet
(tipicamente HTTP).
Gli standard utilizzati dai Web Services, alcuni citati nella definizione, si
basano tutti su XML, e sono:
• XML Schema (eXtensible Markup Language Schema), è un linguaggio di
descrizione del contenuto di un file XML. Il suo scopo è definire qual è la
costruzione legale di un documento XML, in particolare, gli elementi
permessi, quali tipi di dati sono ad essi associati e la loro relazione
gerarchica, permettendone la validazione, ovvero la verifica che i suoi
elementi siano in accordo con la descrizione in linguaggio XML Schema.
• SOAP (Simple Object Access Protocol), è un protocollo di trasmissione di
messaggi tra componenti software in formato XML. SOAP mette a
disposizione un meccanismo semplice, ma allo stesso tempo solido, che
permette ad una applicazione di mandare un messaggio XML ad un‟altra
applicazione. SOAP è un protocollo di alto livello ed è completamente
Albanese Francescantonio, 79117
Pagina 26
indipendente dal protocollo di trasmissione sottostante, che può essere
indifferentemente HTTP (Hypertext Transfer Protocol), JMS (Java Message
Service), SMTP (Simple Mail Transfer Protocol), MIME (Multipurpose Internet
Message Encapsulation) o altri. Tra questi il più usato è HTTP.
SOAP è diventato un nome, e non più un acronimo; tuttavia:
 Service Oriented Architecture Protocol: un messaggio SOAP
rappresenta l'informazione necessaria per invocare un servizio o
riflette il risultato dell'invocazione di un servizio e contiene l'
informazione specificata nella definizione dell'interfaccia del servizio.
 Simple Object Access Protocol: meccanismo per invocare
oggetti remoti, serializzando la lista degli argomenti che deve
essere trasportata dall'ambiente locale a quello remoto.
• WSDL (Web Services Description Language), è un linguaggio formale
basato XML, utilizzato per descrivere, in modo completo, un web
service.
Più
precisamente
un
documento
WSDL
fornisce
informazioni
riguardanti l‟interfaccia del Web Service in termini di:
servizi offerti dal Web Service
URL ad essi associato
modi per l‟invocazione
Albanese Francescantonio, 79117
Pagina 27
argomenti accettati in ingresso e modalità con cui debbono essere
passati
formato dei risultati restituiti
formato dei messaggi
In altre parole si può dire che un file WSDL fornisce la descrizione
relativa ad un Web Service in termini di:
cosa fa
come comunica
dove si trova
Attraverso tale file si può quindi conoscere tutti i dettagli per poter
invocare correttamente un servizio.
• UDDI (Universal Description, Discovery and Integration), è un
registry (ovvero una base dati ordinata ed indicizzata), basato su XML e
che utilizza SOAP per le comunicazioni da e verso l‟esterno. UDDI è
indipendente dalla piattaforma hardware e definisce un meccanismo
comune per pubblicare e trovare informazioni sui Web Services, in base
alle loro descrizioni WSDL. Ciò che UDDI mette a disposizione è un
registro nel quale si possa accedere, attraverso specifiche funzioni, per:
 pubblicare servizi che un‟azienda rende disponibili
 cercare aziende che mettono a disposizione un certo tipo di
servizio
Albanese Francescantonio, 79117
Pagina 28
 avere
informazioni
“Human
Readable”,
cioè
comprensibili
all‟utente, circa indirizzi, contatti o altro relativi ad una azienda
 avere
informazioni
tecniche
“Machine
Readable”,
cioè
interpretabili ed utilizzabili dalla macchina, relative ad un servizio
in modo tale da potersi connettere
Un registro UDDI è costituito, in realtà, da un database distribuito, cioè
da molti registri distribuiti sulla rete, ognuno dei quali si trova sul
server di una azienda che contribuisce allo sviluppo di questo archivio
pubblico, e connessi fra loro. Il sistema mantiene una centralizzazione
virtuale, cioè l‟informazione che viene registrata su uno dei nodi
(registri) del sistema viene propagata e resa disponibile su tutti gli altri
tramite una loro sincronizzazione. Questo, oltre che ad alleggerire il
carico di lavoro che un singolo nodo deve sopportare, contribuisce alla
protezione del sistema contro possibili situazioni di failure del database,
grazie alla ridondanza dei dati.
Attraverso l‟utilizzo di questi ed altri standard i Web Services rendono
possibile la comunicazione e la cooperazione, attraverso il web, di più
applicazioni (servizi) che mettono a disposizione alcune funzionalità e,
allo stesso tempo, utilizzano quelle rese disponibili da altre. Si può cioè
ricercare e invocare servizi che possono essere composti per formare
un‟applicazione per l‟utente finale, per abilitare transazioni di business
o per creare nuovi Web Services.
Albanese Francescantonio, 79117
Pagina 29
Di queste tecnologie, XML ha dato un contributo molto importante alla
nascita dei Web Services. Linguaggio a marcatori, tag, creato e gestito
dal World Wide Web Consortium (W3C) e derivato dallo Standard
Generalization Markup Language (SGML)10, l‟XML è utilizzato per la
memorizzazione di informazione in maniera strutturata.
XML è un formato indipendente dalle varie piattaforme; ciò è dovuto,
oltre che all‟essere universalmente riconosciuto come standard, anche
al fatto che tale tecnologia si basa sul formato testo e quindi un
documento XML può essere letto chiaramente su qualsiasi sistema
operativo. Questa indipendenza lo rende la soluzione ideale per lo
scambio di informazioni attraverso il Web.
I vantaggi offerti dai Web Services sono:
Indipendenza dalla piattaforma: i Web Services possono, infatti,
comunicare fra loro anche se si trovano su piattaforme differenti
Indipendenza dall‟implementazione del servizio: l‟interfaccia che
un Web Service presenta sulla rete è indipendente dal software
che implementa tale servizio. In futuro tale implementazione
potrà essere sostituita o migliorata senza che l‟interfaccia subisca
modifiche e quindi senza che dall‟esterno (da parte di altri utenti
o servizi sulla rete) si noti il cambiamento
10
Standard Generalized Markup Language (SGML), è uno standard per la descrizione logica dei documenti.
Albanese Francescantonio, 79117
Pagina 30
Riuso dell‟infrastruttura: per lo scambio di messaggi si utilizza
SOAP che fa uso di HTTP, grazie al quale si ottiene anche il
vantaggio di permettere ai messaggi SOAP di passare attraverso
sistemi di filtraggio del traffico sulla rete, quali “Firewall”
Riuso del software: è possibile riutilizzare software implementato
precedentemente e renderlo disponibile attraverso la rete
Il concetto di Web Services implica quindi un modello di architettura ad
oggetti distribuiti (oggetti intesi come applicazioni), che si trovano
localizzati in punti diversi della rete e su piattaforme di tipo differente.
Il legame con l‟architettura Service-Oriented Architecture (SOA) sta nel
fatto che, sfruttando al meglio tutte le caratteristiche della tecnologia
dei Web Services, il sistema che si ottiene implementa proprio
un‟architettura
orientata
ai
servizi.
Ad
oggi
i
Web
Services
rappresentano la soluzione migliore per la realizzazione di una SOA su
larga scala, ovvero su Internet.
2.5 Web Services e architettura di tipo non SOA
Bisogna
specificare,
che
parlare di Web
Services,
non implica
necessariamente parlare di Service-Oriented Architecture (SOA). Si può
ad esempio utilizzare i Web Services per aggiungere ad un‟architettura
esistente una funzionalità basata sui servizi al fine di ottenere un certo
Albanese Francescantonio, 79117
Pagina 31
requisito richiesto dal progetto che si sta realizzando. Oppure si può
realizzare un sistema privato, interno ad una azienda, basato sulle
tecnologie dei Web Services (fig. 2.3).
Figura 2.3: Utilizzo di Web Services in un’architettura di
tipo non SOA.
In questi casi, come in altri, non è detto che si possa definire il sistema
realizzato un‟architettura orientata ai servizi; questo perché, per il
Albanese Francescantonio, 79117
Pagina 32
particolare utilizzo che si fa dei Web Services all‟interno di un certo
sistema software, può non essere necessario soddisfare alcuni requisiti
richiesti dal modello di architettura SOA.
Poniamo, ad esempio, il caso di una rete interna ad una azienda in cui
sono state realizzate applicazioni che fanno uso della tecnologia dei Web
Services; se si prevede che le modifiche che verranno apportate nel
tempo al sistema non sono in misura elevata, si può ad esempio
pensare di memorizzare le informazioni riguardanti tutti i servizi nella
configurazione di ognuno di essi, escludendo perciò dal progetto la
presenza di un Service Registry, entità prevista invece dal modello di
architettura SOA.
Un altro possibile utilizzo, molto interessante, dei Web Services è il loro
impiego nel processo di integrazione di applicazioni fra più aziende o fra
più sedi della stessa azienda, attraverso il Web.
Ad esempio si possono avere due aziende partner interessate a mettere
a disposizione l‟una dell‟altra specifici servizi che si trovano sui propri
server, mantenendone però la gestione dell‟implementazione. I Web
Services rendono questo possibile senza doversi preoccupare della
compatibilità
fra
piattaforme,
sistemi
operativi
o
linguaggi
di
programmazione, grazie alla totale indipendenza che questa tecnologia
ha rispetto all‟implementazione del servizio.
Albanese Francescantonio, 79117
Pagina 33
Figura 2.4: Esempio di comunicazione fra Web Service
implementati su piattaforme diverse.
Un esempio è schematizzato in figura 2.4 dove si ha una cooperazione
fra Web Service realizzati su due piattaforme diverse, le due oggi più
importanti J2EE (Java 2 Platform, Enterprise Edition) e .NET (Microsoft
.NET).
Il vantaggio di una collaborazione di questo tipo fra più aziende non è
solo quello di poter avere accesso diretto attraverso la rete a servizi
Albanese Francescantonio, 79117
Pagina 34
implementati e gestiti da altri ma anche di poterli comporre fra loro,
siano essi in locale o in remoto, in modo tale da ottenerne di nuovi che
mettano a disposizione nuove funzionalità o che riescano a risolvere
problemi di complessità maggiore.
Abbiamo visto come possono essere utilizzati i Web Services per
interconnettere servizi situati in punti diversi della rete e con
caratteristiche differenti. L‟esempio che abbiamo descritto riferendoci
alla figura 2.3 fa uso di riferimenti agli altri servizi di tipo statico; il
Client (o Consumer) conosce già l‟indirizzo (URL) al quale poter trovare
un certo servizio (Provider).
Si può invece desiderare di non dover conoscere, al momento
dell‟implementazione di un servizio, gli URL di altri servizi di cui farà
uso, lasciando ad un‟ulteriore agente il compito di fornire, a tempo di
esecuzione, questa ed altre informazioni.
Stiamo parlando del Service Registry ed introduciamo così l‟utilizzo dei
Web Services nella realizzazione di un‟architettura Service-Oriented.
2.6 Web Services e architettura SOA
La presenza del Service Registry (o anche Service Directory o Service
Broker), di cui abbiamo già parlato nel capitolo 2.5, è ciò che rende il
sistema, nell‟esempio di utilizzo dei Web Services visto precedentemente
(in figura 2.3), un‟architettura Service-Oriented (SOA).
Albanese Francescantonio, 79117
Pagina 35
Per implementare il Service Registry i Web Services fanno uso di UDDI,
Universal Description, Discovery and Integration.
UDDI è un servizio di registro pubblico in cui le aziende possono
registrare (pubblicare) e ricercare Web Services. Esso mantiene
informazioni relative ai servizi come l‟URL e le modalità di accesso.
Anche UDDI è un Web Service, il quale mette a disposizione due
operazioni:
Publish, per la registrazione
Inquiry, per la ricerca
Si ottiene così quella che, allo stato attuale, è da molti considerata la
migliore soluzione per l‟implementazione di un sistema con architettura
Service Oriented.
In figura 2.5 è riportata la schematizzazione del funzionamento di un
sistema con architettura SOA, realizzato attraverso l‟uso dei Web
Services.
Albanese Francescantonio, 79117
Pagina 36
Figura 2.5: Sistema con architettura Service-Oriented
realizzato con la tecnologia dei Web Services.
Albanese Francescantonio, 79117
Pagina 37
Capitolo 3
Service Oriented Architecture e gli Enterpise
Service Bus
3.1
Enterprise
Service
Bus
come
infrastruttura
di
supporto ad architetture Service-Oriented
Con le architetture orientate ai servizi, il patrimonio informativo
aziendale non è più un insieme di applicazioni tra loro isolate e che
comunicano attraverso tecnologie d‟ integrazione di applicazioni, è,
invece, organizzato in una collezione di “servizi” intesi come funzionalità
di
business
realizzate
tramite
"componenti"
che
rispettano
un'interfaccia standard.
La
Service-Oriented
Architecture
promette
notevoli
miglioramenti
nell‟allineamento dell‟Information Technology (IT) con le esigenze
aziendali ma necessita di un‟infrastruttura in grado di connettere le
Albanese Francescantonio, 79117
Pagina 38
risorse
IT
indipendentemente
da
dove
siano
implementate,
in
particolare, necessita di un‟infrastruttura che offra flessibilità e
affidabilità, in grado di riassemblare facilmente i servizi senza
interruzioni. Quest‟infrastruttura è l’Enterprise Service Bus (ESB).
Un ESB è un‟infrastruttura software che opera tra le applicazioni ed il
sistema operativo (middleware) e che fornisce servizi di supporto ad
architetture Service-Oriented (SOA).
Il compito principale di un ESB è fornire un layer di comunicazione tra i
servizi, coerentemente con i principi architetturali SOA, e permettere
l‟invocazione dei servizi su sistemi eterogenei, risolvendo problematiche
legate all‟integrazione come per esempio il supporto a chiamate sincrone
e asincrone basate su messaggi, il routing intelligente dei messaggi,
trasformazione e validazione dei dati, integrazione con diversi protocolli,
gestione dell‟affidabilità e sicurezza. È facile, quindi, osservare che
queste funzionalità si sovrappongono parzialmente a quelle fornite
usualmente dai tradizionali middleware di integrazione da cui, in parte,
derivano.
Per comprendere pienamente i vantaggi forniti dagli ESB, occorre
partire dalle differenze che questi presentano rispetto ai tradizionali
sistemi di integrazione basati sull‟utilizzo di un middleware, di cui
rappresentano un‟evoluzione in senso SOA.
In tali architetture denominate Hub-and-Spoke (cosiddetto “a stella”), le
operazione di routing dei messaggi e trasformazione dei dati sono
Albanese Francescantonio, 79117
Pagina 39
centralizzate nell‟Hub e svolte dall‟Integration Broker, il componente
centrale del sistema di integrazione.
Da un punto di vista architetturale, l‟Integration Broker rappresenta
l‟interfaccia
unica
attraverso
cui
transita
ogni
richiesta
di
comunicazione tra sistemi applicativi disomogenei che devono interoperare.
In questo modo, tutte le problematiche e le operazioni di integrazione
risultano essere centralizzate, riusabili e facilmente amministrabili.
Gli svantaggi di un simile approccio nascono dal fatto che l‟hub
rappresenta un potenziale collo di bottiglia, un potenziale single point of
failure e presenta difficoltà di scalabilità. Inoltre, gran parte delle suite
di integrazione presenti sino ad oggi sul mercato sono state sviluppate
in tempi in cui o non esistevano “standard” per la definizione dei
processi operativi o dello scambio dati, oppure questi non erano
sufficientemente maturi e stabili.
I fornitori software hanno così sviluppato soluzione proprietarie per
risolvere le problematiche tipiche dell‟ integrazione.
Il risultato di tale investimento da parte dei fornitori dell‟Enterprise
Application Integration (EAI) erano software altamente funzionali ma
terribilmente costosi e non flessibili. Anche oggi, questo tipo di software
richiede un‟elevatissima tassa di licenza e un investimento in servizi di
consulenza cinque volte superiore rispetto alla tassa di licenza software,
per assicurarne il funzionamento. In molti casi, le competenze
Albanese Francescantonio, 79117
Pagina 40
necessarie per lo sviluppo e la gestione di tali soluzioni EAI sono quindi
garantite quasi unicamente dal fornitore del prodotto: vi è quindi un
chiaro svantaggio tecnico ed economico dovuto non solo al costo delle
licenze, ma soprattutto alle necessità per la manutenzione e la
consulenza sul prodotto. In passato, l‟adozione di tali suite ha
comportato
problemi
in
termini
di
costi,
manutenzione
e
interoperabilità.
Figura 3.1: Integration Middleware: architettura Hub-andSpoke
Albanese Francescantonio, 79117
Pagina 41
Figura 3.2: Integration broker: centralizzazione delle
funzionalità d’integrazione
Con l‟avvento degli Standard Internet vengono descritti come i sistemi
informatici debbano connettersi gli uni agli altri, la semantica delle
conversazioni tra questi e come i dati debbano essere rappresentati in
tali conversazioni ed è proprio tutto questo che ha cambiato il mondo
della EAI.
Il software EAI comincia ad essere progettato e sviluppato in modo da
utilizzare questi standard ad un costo minore rispetto alle soluzioni
Albanese Francescantonio, 79117
Pagina 42
proprietarie. Lavorare con questa nuova generazione di software
significa semplicemente ricercare gli standard opportuni e decidere la
migliore modalità di implementazione in ambito aziendale.
E, dato che le soluzioni sono conformi agli standard, le competenze
informatiche necessarie per sviluppare e gestire il software risultano
ampiamente disponibili.
3.2 Perché Enterprise Service Bus?
“Un ESB aiuta le aziende a sfruttare il valore dell’architettura
SOA incrementando la connettività, aggiungendo la flessibilità
che facilita il cambiamento e fornendo maggiore controllo
sull’utilizzo delle importanti risorse che unisce.”
Mike Gilpin, Vice President e Research Director
“What Is An Enterprise Service Bus?”
Forrester Research, Inc. , Agosto 2004
La nascita delle nuove tecnologie che tentano di migliorare i risultati del
processo di integrazione, come la Service Oriented Architecture (SOA),
l‟Enterprise Application Integration (EAI) e i servizi web, hanno
guadagnato l‟attenzione dei leader dell‟ Information Tecnology, dei
venditori e degli analisti. L‟Enterprise Service Bus (ESB) racchiude le
caratteristiche migliori di tutte queste tecnologie.
Un ESB è generalmente progettato per permettere che applicazioni di
diverso tipo si scambino messaggi con lo scopo di estendere le
funzionalità di ciascuna applicazione con quelle fornite dalle altre
Albanese Francescantonio, 79117
Pagina 43
applicazioni e di rendere virtuali le risorse aziendali, permettendo alla
logica
di
business
dell‟azienda
di
essere
sviluppata
e
gestita
indipendentemente dall‟infrastruttura della rete, e dalla fornitura di
questi servizi.
Un ESB è un prodotto per l‟integrazione basato su standard di mercato,
che raccoglie le novità introdotte dallo stile architetturale orientato ai
servizi e che fornisce le funzionalità tipiche dei tradizionali Integration
Broker di cui ne rappresenta l‟evoluzione, con due fondamentali
differenze.
La prima è tecnologica: gli ESB espongono tramite “standard” quelle
funzionalità che i tradizionali Integration Broker fornivano tramite
tecnologie proprietarie. Esempi di standard ampiamente utilizzati sono:
Java DataBase Connectivity (JDBC)11, Java Message Service (JMS) 12,
Web Services Description Language (WSDL)13 e altri.
11
JDBC (Java DataBase Connectivity), è un connettore per database che consente l'accesso alle basi di dati da
qualsiasi programma scritto con il linguaggio di programmazione Java, indipendentemente dal tipo di DBMS
utilizzato.
12
JMS (Java Message Service) è un insieme di API che consente alle applicazioni Java presenti in una rete di
scambiarsi messaggi tra loro e definisce lo standard di affidabilità per l'Enterprise Messaging (messaging per
imprese), il quale è universalmente riconosciuto come una parte essenziale del sistema di applicazioni delle
imprese.
13
Web Services Description Language (WSDL) è un linguaggio formale in formato XML utilizzato per la
creazione di "documenti" per la descrizione di Web Service.
Albanese Francescantonio, 79117
Pagina 44
Figura 3.3: Architettura Enterprise Service Bus
La seconda differenza è architetturale: un ESB non si basa su
un‟architettura “monolitica” di tipo Hub-and-Spoke, ma su di una
architettura distribuita a bus condiviso SOA oriented. In altre parole, in
un‟infrastruttura ESB, tutte le applicazioni sono integrate e operano
come “servizi”.
Albanese Francescantonio, 79117
Pagina 45
Figura 3.4: Enterprise Service Bus: scenario
d'integrazione
La logica d‟integrazione non è più centralizzata in un hub, ma è
distribuita lungo gli endpoint connessi al bus. Decentralizzando la
logica di integrazione lungo il bus si migliora la scalabilità ed è possibile
Albanese Francescantonio, 79117
Pagina 46
effettuare il deploy delle funzionalità d‟integrazione strettamente
necessarie (selective-deployment14).
L‟utilizzo degli standard permette di ridurre le soluzioni proprietarie
chiuse e costose tipiche dei tradizionali prodotti EAI riducendo
l‟acquisto di soluzioni proprietarie e i costi legati alle consulenze
specialistiche e alle licenze.
Risulta evidente che l‟aumento di interoperabilità dato dall‟uso di
protocolli e tecnologie standard, riduce i rischi aziendali dovuti
dall‟adozione di un middleware, rendendolo in teoria sostituibile. Ad
esempio, se ESB utilizza i Web Services, è possibile disaccoppiare
l‟interfaccia del servizio (Web Services Description Language (WSDL))
dall‟implementazione del servizio stesso.
L‟ESB permette, in linea con le best practices SOA, un'integrazione
"incrementale": è possibile infatti integrare in momenti differenti le varie
parti di un sistema attraverso un approccio cosiddetto Leave-and-layer:
si lascia inalterato l'insieme dei servizi Legacy e di applicazioni esistenti
riconciliando le loro differenze (logica e dati) in un nuovo layer (in
questo caso, appunto, l‟ESB). Gli ESB quindi, rispetto ai prodotti
tradizionali di integrazione, dovrebbero ridurre i costi di licenze e
manutenzione e permettere una maggiore garanzia di portabilità del
codice e di interoperabilità. Ad oggi, praticamente quasi tutti i principali
14
Con il termine inglese deployment indica la messa in campo o in atto (letteralmente, lo "spiegamento") di
una soluzione. In informatica, in particolare, l'espressione può avere diversi significati a seconda del contesto.
Albanese Francescantonio, 79117
Pagina 47
produttori di Software hanno realizzato o intendono realizzare un
proprio prodotto ESB da proporre sul mercato.
Da un lato società che proponevano broker di integrazione tradizionali
(es: IBM e SeeBeyond) hanno affiancato alla loro suite d'integrazione
anche dei prodotti ESB, dall'altro le società di dimensioni più limitate
(come Sonic o Fiorano) che proponevano sistemi di comunicazioni a
messaggi
hanno
migliorato
il
loro
prodotto
aggiungendo
nuove
caratteristiche. Altri venditori hanno riadattato le loro integration suite
effettuando di fatto una riproposizione del loro prodotto al fine di
ridurre i costi (licenze e manutenzione), altri ancora hanno fornito una
versione "light" del prodotto Integration Broker in veste di ESB.
3.3 Enterprise Service Bus: Funzionalità supportate
Generalmente gli Enterprise Service Bus (ESB) utilizzano come dorsale
infrastrutturale un sistema a scambio di messaggi come puro supporto
alla comunicazione, integrando poi nel suo stack le funzionalità e i
meccanismi che permettono integrazione a livello enterprise. Le
funzionalità che un ESB deve implementare e che lo rendono un
prodotto di successo, sono:

Trasformazione (sintattica e semantica), divisione, aggregazione e
arricchimento dei messaggi XML. Questo permette di riconciliare
rapidamente incompatibilità tra formati dati utilizzati da servizi
Albanese Francescantonio, 79117
Pagina 48
che interoperano, fondere dati provenienti da diverse fonti ed
estendere le funzionalità dei servizi.

Delivery dei messaggi con autenticazione, autorizzazione, non
ripudio; in generale deve essere garantito il supporto Middleware
alla comunicazione asincrona.

Mediazione del modello di trasporto, protocollo e interazione. È
possibile integrare facilmente servizi che rappresentano tecnologie
diverse, senza modificare le applicazioni sottostanti o introdurre
interdipendenze.

Supporto
a
diverse
modalità
conversazionali:
sincrona
e
asincrona.

Gestione avanzata del routing dei messaggi, per esempio sulla
base del contenuto del messaggio stesso che permette a un
servizio
di
mandare
un
messaggio
senza
conoscerne
la
destinazione.

Funzionalità
di
amministrazione
per
la
gestione
e
la
configurazione del bus.

Esposizione di servizi middleware di supporto alla logica di
business (per esempio la gestione delle transazioni).

Supporto di più protocolli di comunicazione (tramite appositi
Adapter15) per facilitare l‟integrazione.
15
Con il nome Adapter (in italiano adattatore) si denota un design pattern ovvero "una soluzione progettuale
generale a un problema ricorrente" utilizzato in informatica nella programmazione orientata agli oggetti.
Albanese Francescantonio, 79117
Pagina 49

Supporto
per
permettere
la
composizione
dei
servizi
(orchestration) in processi di business.

Gestione del monitoring del management per la gestione delle
configurazione, del ciclo di vita dei componenti, e per operazioni
di log, tracking e verifica dei servizi.

Gestione del Service registry e dei metadata per permettere la
catalogazione, la memorizzazione e la relativa ricerca.

Gestione della sicurezza nelle comunicazioni, per permettere
operazioni di autorizzazione, identificazione e di creazione regole e
policy.
Parte di queste funzionalità possono essere fornite da un middleware
che supporti la comunicazione asincrona a messaggi: rispetto a questo
un ESB è l'evoluzione da un puro supporto alla comunicazione ad un
sistema integrato di composizione di servizi. Si può affermare che gli
ESB realizzano la parte di middleware richiesta da architetture SOA
utilizzando sistemi a scambio di messaggi.
Albanese Francescantonio, 79117
Pagina 50
Capitolo 4
Una piattaforma di Integrazione Applicativa:
GreenVulcanoESB
"Oltre la metà delle grandi aziende disporranno di un enterprise service
bus entro la fine del 2006 (0.7 probabilità)"
Roy Schulte, Vice President
Presentazione: “The Future of Application Integration”
Gartner, Inc., Novembre 2004
Abbiamo visto che l‟integrazione rappresenta un imperativo aziendale, un
passaggio obbligato per generare maggiore efficienza operativa e che
l‟Enterprise Service Bus (ESB) rappresenta la pratica architetturale migliore
per implementare un‟architettura Service-Oriented (SOA). A tutt‟oggi diverse
compagnie di Information Tecnology hanno sviluppato un‟implementazione
dell‟ESB, lo scopo di questa tesi è quello di proporre l‟implementazione che è
stata sviluppata nell‟azienda presso la quale ho svolto il tirocinio “l‟E@I
Software”, azienda operante nel campo dell'integrazione applicativa in ambito
Enterprise, presentando poi un esempio di utilizzo dello strumento per
configurare la rete “UTRAN”.
Albanese Francescantonio, 79117
Pagina 51
4.1 Perché GreenVulcanoESB?
GreenVulcanoESB è una piattaforma di Integrazione Applicativa, in grado di
interfacciarsi a svariati sistemi di natura eterogenea. La sua architettura a
plug-in ne permette l'espansione e la personalizzazione, al fine di soddisfare
le esigenze più diverse. E' sviluppato interamente nel linguaggio Java, ed è
un sistema Enterprise Application Integration (EAI) molto flessibile, semplice
ed efficace. I punti di forza sono:
Si basa su standard aperti
Utilizza un qualsiasi Application Server J2EE16 compliant
Utilizza una architettura a plug-in
Ha un costo competitivo
Presenta un‟architettura “pluggable” con possibilità di realizzare altri adapter
a seconda delle esigenze del cliente.
16
J2EE (Java 2 Enterprise Edition) è la versione enterprise della piattaforma java. Essa è costituita da un
insieme di specifiche che definiscono le caratteristiche e le interfacce di un insieme di tecnologie pensate per la
realizzazione di applicazioni di tipo enterprise. Chiunque può realizzare una implementazione di tali specifiche e
produrre application server compatibili con le specifiche J2EE (chiamati , proprio per questo, “J2EE compliant”).
Albanese Francescantonio, 79117
Pagina 52
Figura 4.1: Componenti base e Architettura di
GreenVulcanoESB
4.2.1 Il Virtual Layer
Permette
l‟indipendenza
dall‟Application
Server
J2EE
adottato
non
utilizzando meccanismi proprietari dell‟Application Server, impiegando
invece concetti “virtuali” come operazioni di dequeue, enqueue, forward e
Albanese Francescantonio, 79117
Pagina 53
call, e meccanismi di code al suo interno (es: JMS) per permettere la
comunicazione tra i componenti, assicurando, così, un buon livello di
disaccoppiamento e di presa in carico dei messaggi.
4.2.2 Il Core
Costituisce la parte centrale del sistema e contiene i componenti ed i servizi
dei quali il cliente necessita.
Alcune
funzionalità
principali
sono
il
workflow,
dispatching,
data
transformation, data compression & decompression, data crypting etc.
Workflow
Supporta flussi sia short-time che long-time. La persistenza dei dati è
assicurata mediante l‟impiego di una base dati e l‟attivazione avviene
mediante “eventi” (esempio: arrivo di un file, invocazione Web Service,
evento schedulato). Interamente sviluppato con tecnologia J2EE. La
creazione e la modifica dei flussi avviene tramite console o plug-in di
Eclipse.
Dispatcher
E‟ il componente responsabile del dispatching dei messaggi. Tramite
delle
regole
configurabili
effettua
intelligent
routing.
Comunica
direttamente con il Data transformation. La configurazione delle regole
avviene tramite la console o plug-in di Eclipse.
Albanese Francescantonio, 79117
Pagina 54
Data crypting
Utilizzabile in presenza di dati “sensibili”, fa uso di una chiave
configurabile nel sistema e utilizza metodi di crypting standard. È
altamente performante.
Data transformation
Pensato come modulo generico di trasformazione dei dati. Adotta una
sua architettura di tipo “pluggable” ed ha la possibilità quindi di
estendere la capacità di trasformazione. Può eseguire molteplici
trasformazioni in “cascata” e assicura l‟integrazione tra contesti
applicativi tecnologicamente differenti.
Data compression & decompression
Modulo pensato per agevolare il transito di messaggi di grandi
dimensioni.
Esso è in grado di comprimere e decomprimere tutto il messaggio o
parti del dato (esempio: in caso di Web Service).
4.2.3 Integration Suite
L‟Integration Suite è l‟insieme delle funzionalità offerte dall‟Application
Server sottostante. Sono supportati tutti gli Application Server purché siano
J2EE compliant, come ad esempio:

BEA WebLogic Server
Albanese Francescantonio, 79117
Pagina 55

JBOSS

SeeBeyond

SAP NetWeaver
4.2.4 Connectivity Layer
Lo strato di connettività permette di integrare applicazioni via file, Database,
Web Services, oppure creare nuovi adapter a seconda delle esigenze del
cliente. Nello specifico, consente di far comunicare il Core e tutti componenti
contenuti con i sistemi esterni.
Al suo interno troviamo già una serie di adapter:

SIO (SAP Interface Object), connettore J2EE Connection Architecture
(JCA)
con
caratteristiche
sofisticate
che
permette
molteplici
configurazioni con sistemi SAP.

DB Adapter, plugin che da la possibilità di intergrarsi con database
remoti

File Adapter, strumento versatile per leggere, scrivere e trasferire file. È
in grado di:
Apprendere da un XML di configurazione la struttura di un
generico file da trattare
Albanese Francescantonio, 79117
Pagina 56
Leggere e scrivere il contenuto, partendo appunto dal suo XML
associato
Eventualmente trasferire su un sistema remoto, via FTP, il file
generato

WebService Adapter, ideato per integrare GreenVulcanoESB in un
contesto SOA del cliente.
In grado di:
Acquisire a run-time il WSDL del servizio da invocare
Invocare WebServices per interagire con servizi già presenti nella
realtà del cliente
Essere invocato in modalità WebService, e quindi offrire servizi
per gli altri sistemi

JARAD
(Java-ARS
Remedy
Adapter),
connettore
JCA
con
caratteristiche architetturali sofisticate, che comunica con l‟esterno
mediante messaggi XML.

FileNET Adapter, un connettore JCA con caratteristiche architetturali
sofisticate.
Permette
di
inserire,
modificare
e
cancellare
item
documentali ed attributi all‟interno di FileNET.
Albanese Francescantonio, 79117
Pagina 57
4.3 Amministrazione e controllo del sistema
Per quanto riguarda la parte di Amministrazione e Controllo, Il sistema da la
possibilità di monitorare sia le risorse del sistema che l‟esecuzione dei flussi
di integrazione. Dispone di Console di Amministrazione che consente di
visualizzare e ripristinare vecchie configurazioni, il controllo degli accessi,
creazione e design dei workflow, avviare e arrestare i servizi (singolarmente o
in gruppo), configurazione dei vari moduli (es: SIO, Dispatcher, Data
transformation etc).
4.4 VulCon (plug-in per Eclipse)
L‟Enterprise Service Bus di GreenVulcano mette anche a disposizione, nella
sua versione Enterprise, un plug-in per l‟ Integrated Development
Environment (IDE) Eclipse.
VulCon
(GreenVulcano
Console)
è
un
designer
sofisticato
per
la
progettazione e l‟implementazione di flussi di business, che permette di
realizzare flussi, sia semplici che complessi, in maniera semplice e intuitiva e
senza dover modificare “a mano” i file di configurazione.
Albanese Francescantonio, 79117
Pagina 58
4.5 DataHandler
Uno dei principali
plugin del ESB è il DataHandler: è un componente
altamente performante e configurabile, che si occupa di eseguire operazioni
di CRUD verso i principali RBMS17 che sono in commercio utilizzando le API
JDBC18. Questo componente è disponibile esclusivamente nella versione
Enterprise.
Il DataHandler attraverso mappe di trasformazione, elabora l'XML ricevuto in
input viene normalizzato in un altro XML, che definisce tipi di dati e valori,
necessari a eseguire l'operazione sul database. In seguito, il DataHandler
esegue le operazioni sul database configurate per il servizio. In base al tipo di
operazione configurata, il DataHandler restituisce un output composto di un
report che descrive il risultato dell'operazione, e un XML che, attraverso una
mappa di trasformazione, è convertito in un secondo XML definito da uno
XSD.
La configurazione di questo componente avviene in tre step:
1. Definizione degli XSD di input e output del servizio
17
Il Relational Database Management System (RDBMS) (sistema per la gestione di basi di dati relazionali) è
un database management system basato sul modello relazionale.
18
JDBC (Java DataBase Connectivity), è un connettore per database che consente l'accesso alle basi di dati da
qualsiasi programma scritto con il linguaggio di programmazione Java, indipendentemente dal tipo
di DBMS utilizzato. È costituita da una API, raggruppata nel package “java.sql”, che serve ai client per
connettersi a un database. Fornisce metodi per interrogare e modificare i dati. È orientata ai database
relazionali ed è Object Oriented.
Albanese Francescantonio, 79117
Pagina 59
2. Definizione delle mappe di conversione dal formato definito negli XSD
creati e viceversa
3. Composizione
delle select/update/calls in
linguaggio
SQL
per
il
ritrovamento/modifica dei dati sul database
Il linguaggio utilizzato per le mappe di trasformazione è XSLT 1.0.
4.6 UDDI
UDDI (Universal Description Discovery and Integration) costituisce
l‟elemento fondamentale in un‟architettura Enterprise Service Bus. E‟ un
registro XML-based che permette il discovery dei servizi da parte di un
utente o di una applicazione. E‟ interrogabile tramite invocazione Web
Service e restituisce un servizio.
Albanese Francescantonio, 79117
Pagina 60
4.7 I Vantaggi dell'utilizzo di GreenVulcanoESB
L‟ESB GreenVulcano offre molti vantaggi, tra i principali:
1. ESB configurabile e adattabile ad ogni esigenza del cliente
2. Possibilità di modificare i servizi configurati senza bloccare le attività
del cliente, grazie all‟hot deploy (lettura della configurazione a caldo)
che GreenVulcanoESB offre.
Albanese Francescantonio, 79117
Pagina 61
3. Grazie al plugin Vulcon è molto intuitiva la configurazione dei servizi,
ciò permette un notevole risparmio in termini di effort e costi.
4. Grazie al vasto numero di plugin e adapter si può integrare con sistemi
diversi anche per tecnologia di sviluppo.
Albanese Francescantonio, 79117
Pagina 62
Capitolo 5
Configurazione di GreenVulcanoESB per la
gestione della rete “UTRAN”
5.1 L’ambiente di lavoro
Il lavoro svolto per questa tesi riguarda lo sviluppo di un particolare caso
d‟utilizzo di GreenVulcanoESB per mostrare come è possibile, con questo
strumento, centralizzare la gestione delle interconnessioni tra applicazioni,
evitando di demandare questo problema alle applicazioni stesse, far
comunicare in modo sicuro rapido e affidabile i servizi web esposti da sistemi
disparati, creare una composizione di servizi, tenere sincronizzati fra di loro
diversi database e discriminare in base ad una particolare esigenza
l‟inserimento in un database piuttosto che in un altro. In particolare si è
sviluppato un sistema per la configurazione e la gestione della rete “UTRAN”.
Prima di illustrare il caso d‟utilizzo sviluppato ed analizzare la relativa
configurazione di GreenVulcanoESB, occorre fare una panoramica sulle
Albanese Francescantonio, 79117
Pagina 63
tecnologie e gli strumenti di sviluppo utilizzati, per comprendere meglio
l‟ambiente di lavoro.
Come base di dati è stata utilizzata Oracle19. Il sistema gestisce la
progettazione della rete “UTRAN”; per tale motivo sono stati creati due
schemi:
1. Uno schema di progetto con il requisito di memorizzare tutti i dati
creati durante la fase di progettazione
2. Uno schema che memorizza i dati che la rete possiede
Come application server20, sul quale far girare l‟ESB, è stato utilizzato Jboss.
Jboss è un application server open source basato sulla tecnologia Java di
Sun. Come IDE (Integrated Development Environment) di sviluppo è stato
utilizzato Eclipse con un plugin di GreenVulcano (VulCon) che permette di
configurare servizi di integrazione in modo rapido ed efficiente.
Eclipse è stato un valido strumento anche per sviluppare una piccola
applicazione web, la quale veniva utilizzata dall‟utente finale per configurare
la rete “UTRAN”. Tale applicazione web al suo interno contiene solo la logica
di MVC (Model View Controller), per la configurazione della rete, mentre
tutta la logica di Business è stata inserita nei servizi di GreenVulcanoESB.
19
Oracle è uno dei più famosi database management system (DBMS), cioè sistema di gestione di basi di dati,
ed è scritto in linguaggio C. Oracle fa parte di quei database detti RDBMS (Relational DataBase Management
System), ovvero di quei sistemi di database basati sul Modello Relazionale.
20
Un application server è un software che fornisce l'infrastruttura e le funzionalità di supporto, sviluppo ed
esecuzione di applicazioni e componenti server in un contesto distribuito. Si tratta di un complesso di servizi
orientati alla realizzazione di applicazioni per il web.
Albanese Francescantonio, 79117
Pagina 64
Come sistema operativo del server sul quale girerà l‟applicazione è stato
usato Sun Solaris 10. Solaris è un sistema operativo Unix, scritto in
linguaggio C, che è molto conosciuto e utilizzato per la sua scalabilità e per
l‟introduzione di molte caratteristiche innovative come DTrace, ZFS e Time
Slider21.
5.2 Che cos è la rete “UTRAN”?
Per capire a fondo le caratteristiche dell‟ambiente dove si va ad attestare il
sistema che è stato sviluppato, facciamo prima una panoramica sulla
tecnologia che sta alla base della rete “UTRAN”.
5.2.1 La tecnologia “UMTS”
Il sistema UTMS (Universal Mobile Telecommunication System), è un
sistema di telecomunicazione radiomobile di “terza generazione (3G)”.
Attualmente, il sistema UMTS, ormai caratterizzato da standard quasi
mondiali che definiscono le principali proprietà, è in una fase di sviluppo
tale, grazie al lancio commerciale in Europa di alcuni gestori, da permettere
21
DTrace è una funzione che offre capacità di osservazione pervasiva e sicura sui sistemi di produzione per
velocizzare lo sviluppo e l’ottimizzazione di applicazioni basate sullo stack AMP/MARS. ZFS è un file system
open source noto per la sua alta capacità e per l’integrazione di diversi concetti presi da vari file system in un
unico prodotto. Time Slider è una funzione che permette di effettuare il backup automatico dei dati sullo
stesso disco utilizzando le caratteristiche uniche del file system ZFS.
Albanese Francescantonio, 79117
Pagina 65
di poter usufruire dei servizi offerti dalla nuova tecnologia con un‟affidabilità
pari a sistemi globalmente diffusi, quali il GSM e il GPRS.
Un Sistema Radiomobile è un sistema che permette una connessione tra
due terminali, di cui almeno uno può essere in movimento. E‟ possibile, per
l‟utente, eseguire e ricevere chiamate in qualunque zona coperta dal sistema
stesso con un elevato grado di qualità. La copertura dell‟area da parte della
rete radiomobile è effettuata attraverso dei punti d‟accesso chiamati Stazioni
Radio Base (SRB). Ogni SRB fornisce l‟accesso alla stazione mobile, è
possibile instaurare un collegamento radio con il mobile stesso, se e solo se è
disponibile almeno un canale radio libero. I primi sistemi radiomobili (anni
„20 - ‟30) facevano uso delle frequenze più basse dello spettro radioelettrico,
trasmettendo nella gamma MF (Media Frequenza: 0.3 ÷ 3 MHz).
L‟incremento della conoscenza dei fenomeni elettromagnetici e l‟evoluzione
della tecnologia hanno permesso di utilizzare una sempre più ampia
porzione dello spettro, potendo così passare alle gamme di frequenza
superiori, giungendo oggi all‟uso della banda UHF (300 MHz ÷ 3 GHz) e
delle Microonde.
Negli Stati Uniti, in Giappone, e in Europa sono introdotti i primi sistemi
commerciali (come AMPS, TACS e NMT). Tutti questi sistemi sono basati su
tecniche d‟accesso e d‟accesso multiplo a divisione di frequenza (FDMA –
Frequency Division Multiple Access) (FDD – Frequency Division Duplex). Con
questa tecnica è assegnata una determinata frequenza per le trasmissioni
verso la SRB (Uplink), ed una frequenza diversa per le trasmissioni verso il
Albanese Francescantonio, 79117
Pagina 66
terminale mobile (Downlink). Trasportando esclusivamente servizi voce, la
modulazione utilizzata era di tipo analogico (FM) e la banda utilizzata per
ciascun canale era di circa 30 KHz.
I problemi che questi sistemi incontravano erano prevalentemente dovuti ad
effetti di fading (effetto di evanescenza del segnale) e d‟interferenza tra gli
altri utenti, i quali erano risolti con la trasmissione del segnale a potenze
relativamente alte, e con il riutilizzo delle stesse frequenze nelle celle non
adiacenti. Le difficoltà incontrate nei sistemi della prima generazione hanno
fatto crescere l'interesse per lo sviluppo dei sistemi di seconda generazione.
Con questi sistemi è introdotto l'uso delle tecniche digitali per la
trasmissione del segnale, abbinando alle tecniche di codifica della voce
anche sistemi per la correzione d‟errore e la sicurezza nelle comunicazioni.
Ecco quindi che intorno agli anni '90 si affaccia sul mercato la seconda
generazione (2G) dei sistemi per telefonia mobile: GSM, D-AMPS, PCS e PDC.
Utilizzando tecniche digitali di modulazione s‟introducono i vantaggi di una
maggiore efficienza spettrale e la possibilità di combinare le trasmissioni dati
insieme alle trasmissioni di tipo vocale. I primi sistemi sviluppati negli Stati
Uniti utilizzavano tecniche d‟accesso a divisione di tempo (TDMA- Time
Division Multiple Access), dove ciascuna portante di 30 KHz era divisa in tre
Time-Slot, e ciascuno di questi costituiva un canale d‟utente.
In
Europa
era
standardizzato
il GSM che,
utilizzando
tecniche
di
modulazione GMSK, consente di dividere una portante di 200 KHz in 8 Time
Slot, con conseguente aumento degli utenti che possono essere connessi
Albanese Francescantonio, 79117
Pagina 67
contemporaneamente con una sola cella. Per far fronte alle esigenze di
maggiori velocità nella trasmissione dati, in questi anni la seconda
generazione si è evoluta
verso la
generazione 2,5.
Un esempio
è
l'introduzione del GPRS sulle reti GSM, il quale consente una maggiore
velocità di trasmissione dati, e una più vasta gamma di servizi offerti (Packet
Data).
Con questo sistema è ora possibile realizzare delle trasmissioni dati fino
a 171 Kbit/s in modalità Always On (sempre connesso). Questo è reso
possibile dalla possibilità di adattare il traffico di tipo Packet Data
Switched sull‟attuale reteGSM, che per sua natura è di tipo Circuit Data
Switched. La differenza consiste nel fatto che, rispetto al sistema GSM
tradizionale, un collegamento dati GPRS utilizza le risorse di rete solamente
quando i dati sono effettivamente trasmessi, ed un utente potrà quindi avere
tariffe più orientate verso la quantità dei dati trasmessi indipendentemente
dal tempo effettivo della connessione.
Nel 1992 la WARC (World Administrative Radio Conference) ha individuato la
banda dei 2 GHz per l'utilizzo dei sistemi della terza generazione, e dal 1997
i sistemi che vi operano sono standardizzati da uno specifico gruppo di
lavoro in ambito ITU prendendo il nome di IMT-2000.
UMTS è il nome dei sistemi di terza generazione. Le bande utilizzate nei vari
paesi sono pressoché le stesse, ma l'idea originale di realizzare un‟unica
interfaccia radio standardizzata a livello mondiale non ha avuto seguito,
pertanto, anche se i sistemi di questa generazione presentano in ogni caso
Albanese Francescantonio, 79117
Pagina 68
molte similitudini, più che uno standard, l‟IMT-2000, è da considerarsi come
una famiglia di sistemi alla quale l‟UMTS appartiene.
Le bande individuate dal WARC verranno utilizzate in Europa e in Asia con
tecniche W-CDMA (Wideband
Code
Division
Multiple
Access) e TD-
CDMA (Time Division - Code Division Multiple Access), mentre negli USA
queste bande sono già utilizzate dal sistema PCS, pertanto gli operatori
dovranno condividere con questo sistema le risorse radio disponibili. L‟UMTS
inizialmente è standardizzato in Europa dall‟ETSI fino al 1998, poi nasce
il 3GPP (3rd Generation Partnership Project), associazione dei maggiori enti
di standardizzazione internazionali (europei, giapponesi, americani, coreani,
ecc.).
L'UMTS sarà allocato nelle bande di frequenza simmetriche (per il duplex) di
1920¸ 1980 MHz per l'Uplink, e 2110¸ 2170 MHz per il Downlink (modo FDD
– Frequency Division Duplex), nonché nelle bande asimmetriche da 1900 ÷
1920 MHz e 2010 ÷ 2025 MHz (modo TDD – Time Division Duplex). In
entrambi i casi, le bande sopra riportate sono suddivise in portanti da 5
MHz.
In particolare in Italia le frequenze assegnate ad H3G (3), primo gestore di
telefonia mobile ad aver lanciato in Europa la rete UMTS a livello
commerciale, sono le seguenti:
- 1900¸ 1905 per la banda asimmetrica (TDD)
- 1955¸ 1970 per la banda simmetrica in Uplink (FDD)
- 2145¸ 2160 per la banda simmetrica in Downlink (FDD)
Albanese Francescantonio, 79117
Pagina 69
La decisione di utilizzare modalità diverse per l'accesso radio comporta la
necessità per i terminali mobili di dover supportare i differenti standard. I
primi terminali UMTS supportano anche il sistema di seconda generazione
GSM e solo in futuro potranno supportare anche le altre reti 3G.
La possibilità per i terminali di potersi collegare anche alle reti della seconda
generazione consentirà una maggiore mobilità, specialmente nelle prime fasi
d‟implementazione della rete UMTS giacché non sarà coperta da subito la
totalità del territorio.
I servizi che un utente sottoscrive con un operatore saranno mantenuti
anche in condizione di mobilità verso altri operatori UMTS (servizio
chiamato roaming), sfruttandone le capacità di "Virtual Home Environment"
(VHE). È inoltre allo studio una modalità di trasmissione a più portanti che
consentirà di creare una compatibilità tra i sistemi UMTS e quelli CDMA2000.
L'introduzione della tecnica W-CDMA, combinata alle tecniche di codifica
variabile (OVSF) utilizzate per le canalizzazioni e all'utilizzo di opportuni
algoritmi per il controllo della potenza (Power Control), consentono di
realizzare delle connessioni a differenti velocità per ciascun utente, e sarà
possibile utilizzare servizi multipli in contemporanea, garantendo la qualità
del servizio in ogni momento della connessione pur utilizzando un‟unica
risorsa fisica (Bearer Channel).
L'obiettivo è in ogni modo quello di poter realizzare connessioni a 128
Kbit/s in condizioni di mobilità veicolare (fino a 500 Km/ora), connessioni
Albanese Francescantonio, 79117
Pagina 70
a 384 Kbit/s in condizioni di mobilità pedestre, per arrivare fino a 2
Mbit/s in condizioni di ridotta mobilità. Per rendere più flessibili i servizi
che una rete UMTS può offrire, le interconnessioni dei vari elementi di rete
saranno realizzate con la tecnica ATM (interfacce Iu e Iur). Questa soluzione
consente di interfacciare la rete ad accesso radio con la rete centrale in modo
molto dinamico, e darà la possibilità di introdurre futuri cambiamenti nella
struttura
della
rete
senza
dover
intervenire
direttamente
sull'UTRAN (UMTS Terrestrial Radio Access Network), permettendo così
uno sviluppo graduale ed in linea con le varie strategie adottate dai singoli
operatori.
5.2.2 Architettura di base del sistema “UMTS”
La rete UMTS utilizza la stessa architettura già impiegata da tutti i sistemi di
seconda generazione e da alcuni di prima generazione. Dal punto di vista
funzionale gli elementi di rete sono raggruppabili nell‟UTRAN, che gestisce
tutte le funzionalità radio, e nella Core Network (CN) responsabile della
commutazione e dell‟instradamento delle chiamate e delle connessioni con le
reti esterne.
Albanese Francescantonio, 79117
Pagina 71
Per completare la panoramica dei sistemi occorre considerare gli apparati
d‟utente (User Equipment– UE) che s‟interfacciano tra l‟utente e la rete
d‟accesso. Dal punto di vista delle specifiche e degli standard, sia gli apparati
d‟utente sia la rete UTRAN implementano protocolli assolutamente nuovi,
progettati sulla tecnologia d‟accesso radio UMTS; al contrario, la definizione
ed i protocolli della CN sono in gran parte mutuati dal GSM. Questa
caratteristica consente ai sistemi dotati delle nuove interfacce radio di poter
essere integrati con una tecnologia di CN già matura, conosciuta e
consolidata, favorendo la rapidità d‟introduzione delle nuove tecnologie e
il roaming globale. L‟UE si suddivide in due parti:
-
Il Mobile
Equipment (ME)
è
il
terminale
utilizzato
per
le
comunicazioni radio sull‟interfaccia Uu.
- L‟UMTS Subscriber Identity Module (USIM) è la smartcard che
immagazzina e gestisce l‟identità del sottoscrittore, esegue gli algoritmi
d‟autenticazione, memorizza le chiavi d‟autenticazione e crittografia ed altre
specifiche funzionalità necessarie al normale funzionamento del terminale.
L‟UTRAN è formata dai seguenti nodi di rete:
- Il Nodo B, che converte il flusso di dati tra le interfacce Iub e Uu e
coopera nella gestione delle risorse radio (il termine Nodo B ha significato
analogo al termine più generico Stazione Radio Base - SRB).
- Il Radio Network Controller (RNC), che gestisce e controlla le risorse
radio del proprio dominio (i Nodi B si connettono a quest‟elemento); il nodo
RNC costituisce il punto d‟accesso di tutti i servizi che l‟UTRAN fornisce alla
Albanese Francescantonio, 79117
Pagina 72
CN come, ad esempio, la connessione ai terminali d‟utente (UE). S‟interfaccia
con la CN (di solito con un MSC e un SGSN) e termina il protocollo RRC
(Radio Resource Control) che definisce i messaggi e le procedure tra il
terminale mobile e la rete UTRAN. Corrisponde, logicamente, al nodo BSC
del GSM. L‟insieme di un Radio Network Controller (RNC) e più Nodi B forma
il Radio Network Sub-System (RNS).
- HLR (Home Location Register): base dati installata presso la
rete home che memorizza i profili di servizio degli utenti. Il profilo d‟utente è
creato nel momento in cui il nuovo cliente sottoscrive il servizio e rimane
memorizzato finché la sottoscrizione è attiva. Per supportare l‟instradamento
verso il mobile dei servizi da esso terminati (chiamate entranti o
messaggi) l‟HLR memorizza anche la posizione dell‟UE a livello di MSC/VLR
e/o SGSN dal quale il terminale è servito.
- MSC/VLR (Mobile Services Switching Centre / Visitor Location
Register): sono, rispettivamente, la centrale di commutazione (MSC) e la base
dati (VLR) che supportano l‟UE, nella sua attuale posizione, per i servizi a
commutazione di circuito (Circuit Switched – CS). La funzionalità principale
dell‟MSC è di commutare le chiamate mentre il VLR memorizza i profili
d‟utente dei sottoscrittori ospiti (ovvero sotto la copertura radio servita dal
MSC/VLR) e informazioni più precise quali la posizione dell‟utente all‟interno
della copertura radio. La parte di rete alla quale si accede tramite MSC/VLR
è definita spesso come “Dominio a Commutazione di Circuito” o CS (Circuit
Switched).
Albanese Francescantonio, 79117
Pagina 73
- GMSC (Gateway MSC): è il nodo di commutazione che interfaccia la
PLMN (Public Land Mobile Network) UMTS con le altre reti esterne a
commutazione di circuito. Tutte le connessioni, entranti e uscenti, di tipo CS
passano attraverso il GMSC.
-
SGSN (Serving
GPRS
Support
Node): funzionalmente
simile
all‟MSC/VLR ma utilizzato per servizi a commutazione di pacchetto (Packet
Switched – PS).
- GGSN (Gateway GPRS Support Node): funzionalmente simile al
GMSC ma utilizzato per i servizi PS.
Si osservi, inoltre, che reti esterne di tipo CS possono essere la rete ISDN
(Integated Service Digital Network) o la rete PSTN (Public Switched Telephone
Network), mentre reti PS possono essere reti come Internet. Gli standard
UMTS sono strutturati in modo che le funzionalità interne degli elementi di
rete non siano specificate in dettaglio, mentre lo sono le interfacce tra gli
elementi logici di rete. Le interfacce aperte specificate dallo standard per la
rete d‟accesso sono le seguenti:
- Interfaccia Cu. Interfaccia elettrica tra la smartcard USIM ed il ME,
realizzato conformemente agli standard per smartcard.
- Interfaccia Uu. E‟ l‟interfaccia radio W-CDMA attraverso la quale il
terminale d‟utente accede alla parte fissa dell‟architettura di rete. Si tratta
dell‟interfaccia aperta più importante dell‟UMTS.
- Interfaccia Iu. Connette l‟UTRAN alla CN. Questa interfaccia aperta
permette agli operatori di acquistare UTRAN e CN da manifatturiere diverse.
Albanese Francescantonio, 79117
Pagina 74
E‟ basata su trasporto ATM (Asynchronous Transfer Mode). Il livello fisico di
questa interfaccia è realizzato in fibra ottica, collegamento radio o cavo in
rame.
-
Interfaccia
Iur.
Questa
interfaccia
aperta
consente
il soft
handover tra gli RNC di diverse manifatturiere ed è, quindi, complementare
rispetto all‟interfaccia Iu. Anche questa interfaccia è basata su un livello di
trasporto ATM.
- Interfaccia Iub. Connette i Nodi B all‟RNC. L‟UMTS è il primo sistema
radiomobile commerciale dotato d‟interfaccia completamente aperta tra il
nodo di controllo e le stazioni radio base. Questo per permettere maggiore
competizione tra le diverse manifatturiere impegnate nella realizzazione di
Nodi B. Come l‟interfaccia Iur anche la Iub implementa un livello di trasporto
su ATM.
Particolare caratteristica della rete UTRAN è quella relativa alle funzionalità
logiche del nodo RNC. L‟RNC che controlla il Nodo B (ovvero che termina
l‟interfaccia Iub proveniente dal Nodo B) è detto Controlling RNC (CRNC) del
Nodo B. Il CRNC è responsabile della gestione del traffico e delle situazioni di
congestione delle proprie celle. Nel caso in cui una connessione mobile UTRAN utilizzi le risorse appartenenti a più di un RNC (condizione di Soft
Handover Inter RNC) gli RNC coinvolti hanno due ruoli distinti:
1. Serving RNC. L‟SRNC di un terminale mobile è l‟RNC che termina il
collegamento Iu per il trasporto dei dati utente e la corrispondente
segnalazione verso la CN. Un UE può avere sempre un solo SRNC.
Albanese Francescantonio, 79117
Pagina 75
2. Drift RNC. Il DRNC è un qualunque RNC, diverso e distinto dall‟SRNC,
che controlla le celle utilizzate dal terminale mobile. Il DRNC non
esegue le elaborazioni del livello 2 (trasporto) ma instrada in maniera
trasparente i dati tra le interfacce Iub e Iur. Un UE può avere nessuno,
uno o più DRNC.
5.3 Scenario del sistema
Il sistema creato tramite l‟ESB GreenVulcano per configurare e gestire la rete
“UTRAN” è un sistema molto complesso ed è stato sviluppato in un team di
progetto diviso in tre sezioni. Una sezione si è dedicata allo sviluppo della
parte database e store procedures; un‟altra sezione si è dedicata allo
sviluppo della web application e della console di interfaccia; infine un'altra
sezione, cui il sottoscritto ha fatto parte, si è dedicata alla configurazione dei
servizi sull‟ESB.
Per il sistema sono stati previsti due database, uno che gestisce le
informazioni riguardanti la rete nel suo complesso e uno che gestisce i
progetti dei vari utenti e gli elementi di rete da essi manipolati.
La console web messa a disposizione dell‟utente espone varie funzionalità di
gestione della rete “UTRAN”; tra le principali ci sono tutte le operazioni
Albanese Francescantonio, 79117
Pagina 76
riguardanti la configurazione della rete eseguibili da un‟ area di “progetto”
che è divisa in varie “action”. Le action sono le funzionalità principali e sono
a loro volta divise in “task”. I task sono le operazioni effettive che un utente
può fare all‟interno del suo progetto.
Esempi di task sono:
Creazione e cancellazione di nuovi elementi di rete come Node B,
Celle e Configurazione Trasmissiva
Creazione e cancellazione di Servizi, Coverage e Adiacenze tra Celle
Cambio di parametri di ogni elemento di rete e servizio
Rehoming
Al fine di sfruttare al meglio le potenzialità dell‟ESB si è scelto di non
aggiungere alcuna logica di Business sulla web application, sviluppandola
tutta all‟interno di GreenVulcanoESB.
L'ESB, avendo anche capacità di orchestrazione dei servizi (e quindi
funzionalità di Business Process Management22 (BPM)), può esporre un
servizio
composto
che
effettua
operazioni
(inserimenti,
cancellazioni,
chiamata a store procedure, etc.) sulle tabelle di tutti i database dei sistemi
coinvolti, rendendoli sincronizzati. Grazie alla sua capacità di orchestrazione
22
Il Business Process Management è l’insieme di attività necessarie per definire, ottimizzare, monitorare e
integrare i processi aziendali, al fine di creare un processo orientato a rendere efficiente ed efficace il business
dell’azienda.
Albanese Francescantonio, 79117
Pagina 77
(attraverso il workflow engine di cui ogni ESB è dotato) l'ESB riesce anche a
discriminare su quale sistema operare.
Le interazioni tra sistemi avviene tramite delle ws-call, che sono un tipo di
Virtual Middleware Operation23 che l‟ESB mette a disposizione.
Tutta la configurazione dei servizi di GreenVulcanoESB è scritta in file XML;
tra i più importanti ci sono:
1. GVCore: contiene tutte le operazioni e l‟ordine con cui devono essere
eseguite. In particolare contiene le configurazioni dei servizi, dei
sistemi che invocano i servizi, dei plugin e delle trasformazioni XSL
utilizzate.
2. GVAdapters: contiene le configurazioni dei vari DataProvider, dei
WebServices e dei driver JDBC con i relativi DataSource.
3. GVSupport: contiene le configurazioni dei file di log con i relativi livelli
di logging (“info”, “debug”, “error”) per ogni componente, plugin o
adapters.
23
Le Virtual Middlware Operation sono le chiamate in uscita dal bus, rappresentano il dialogo verso l’esterno
e possono essere sia chiamate a DB_call (per esempio una insert direttamente dal bus senza un servlet
container per far girare i web services e quindi senza passaggi intermedi con ws_call), operazioni sul file system
o semplici ws call (chiamate a servizio Web).
Albanese Francescantonio, 79117
Pagina 78
5.4 Configurazione di GreenVulcanoESB
La figura 5.2 mostra la configuration console di GreenVulcanoESB
accessibile
all‟indirizzo
http://localhost:8080/gvconsole24,
ovvero,
la
schermata principale del BUS. Questa console rappresenta l‟interfaccia di
configurazione del bus. Da qui, è possibile eseguire le seguenti operazioni:
1. Esportare tutta la configurazione di GreenVulcano
2. Cambiare la configurazione di qualsiasi servizio deployato sull‟ESB
3. Fare operazioni di monitoraggio di servizi, log, RAM busy, etc.
4. Eseguire test di qualsiasi servizio deployato
5. Ricaricare nuove configurazioni
Figura 5.2: Schermata principale della console di
GreenVulcanaESB
24
http://localhost:8080/gvconsole corrisponde a http://<server>:<port>/gvconsole dove <server> è l’indirizzo
IP del server o il nome del server che ospita l’applicazione, in questo caso localhost si riferisce al sistema in uso
e <port> è la porta di ascolto del server.
Albanese Francescantonio, 79117
Pagina 79
Oltre a poter configurare l‟ESB da console di amministrazione è possibile,
come già detto in precedenza, farlo in maniera molto più semplice e intuitiva
tramite il plug-in VulCon di Eclipse.
La figura 5.3 mostra la schermata generale di VulCon con le sezioni dedicate
alla configurazione dei tre file principali dell‟ESB: Core, Adapters e
Variables.
Figura 5.3: Schermata generale di VulCon
Albanese Francescantonio, 79117
Pagina 80
I servizi creati e configurati sull‟ESB per il sistema realizzato, sia tramite
plug-in VulCon che tramite console, sono moltissimi. Le operazioni effettuate
dai servizi chiamano la loro relativa configurazione che avviene nell‟area dei
sistemi (per “sistema” si intende un sistema esterno con il bus comunica per
invocare servizi web o operazioni sul database), come si può vedere dalla
figura 5.3. In GreenVulcanoESB bisogna dichiarare i sistemi coinvolti
nell'espletamento dei vari servizi. Ogni sistema avrà uno o più canali di
comunicazione
all'interno
del
quale
vengono
raggruppate
le
Virtual
Middleware Operation (VMO). Per questo progetto è stato configurato un solo
sistema, “DAMA” con due canali di comunicazione, “CHANNEL_LOADER” e
“CHANNEL_WEBGUI”.
Ora verrà mostrato, come esempio, uno dei workflow più complessi e
andremo ad analizzarlo nel dettaglio.
Export Project:
input: Identificativo del progetto
output: OSS file
Albanese Francescantonio, 79117
Pagina 81
Figura 5.4: Activity Diagram per il servizio
EXPORT_PROJECT
La figura 5.4 mostra l‟Activity Diagram UML dal quale si è partiti per la
realizzazione del servizio che andremo ora a descrivere.
Albanese Francescantonio, 79117
Pagina 82
Figura 5.5: Workflow per il servizio EXPORT_PROJECT
Servizio EXPORT_PROJECT:
La figura 5.5 mostra la configurazione del servizio EXPORT_PROJECT.
Questo servizio è stato realizzato per rendere effettive e permanenti le
modifiche effettuate alla rete che l‟utente ha realizzato nella sua area di
progetto. In pratica l‟utilizzatore configura le modifiche in “locale”, nel senso
che sono visibili solo nella sua area di progetto; poi una volta terminate,
grazie a questo servizio, le rende effettive nella rete. Questo perché il servizio
genera tutti i file xml che leggerà l‟ “OSS”, creando, cancellando o
modificando realmente elementi della rete “UTRAN”. Naturalmente i servizi
Albanese Francescantonio, 79117
Pagina 83
dell‟ESB GreenVulcano, unitamente alla configurazione dei database,
forniscono ampia garanzia di gestione sicura dei dati condivisi, nel senso che
due
utenti
non
possono
agire
sugli
stessi
elementi
di
rete
contemporaneamente.
Andando più in dettaglio nel workflow vediamo che i nodi rappresentano
operazioni diverse effettuate dall‟ESB e ognuna di esse riceve un input
rappresentato da un buffer che viaggia all‟interno del bus. Dopo aver
elaborato il suo processo, in base al tipo di operazione, ogni nodo restituisce
un output, rappresentato sempre da un buffer che può essere anche lo
stesso dell‟input, che sarà l‟input dell‟operazione successiva e così via fino
alla fine del servizio. Inoltre ci sono alcuni nodi di “check” che servono a
controllare il risultato dell‟elaborazione precedente e nel caso effettuare
operazioni diverse se si è verificata un‟eccezione.
Il servizio EXPORT_PROJECT riceve in input, dalla web gui, l‟identificativo,
inteso come chiave primaria del database, del progetto che si vuole
esportare. Il primo nodo del flusso, “select_actions”, effettua un‟operazione di
“select” sul database tramite il DataHandler; in pratica seleziona tutte le
azioni effettuate in quel progetto. Il passo successivo è quello di andare a
controllare il risultato dell‟operazione effettuata dal DataHandler tramite il
nodo di check, che in caso di eccezione la cattura e ritorna alla WebGui così
che l‟utente possa essere a conoscenza di ciò che accade e perché.
Come si può vedere dalla figura 5.4 tutti i nodi di check del workflow
convergono in un unico nodo, “set_exception_property”; questo nodo è un
Albanese Francescantonio, 79117
Pagina 84
nodo del tipo “ChangeGVBuffer” sul quale viene agganciato uno script ognl25
che cattura l‟eccezione e la setta come property del buffer dell‟ESB.
Script OGNL:
#exc=#environment.get('LAST_GV_EXCEPTION'),
#sw=new java.io.StringWriter(),
#pw=new java.io.PrintWriter(#sw),
#exc.printStackTrace(#pw),
#pw.close(),
property['EXCEPTION_STACK']=#sw.toString(),
object='<root/>'
Se il check va a buon fine si passa al nodo “export_for_single_action”. Questo
è un nodo particolare, perché è un “IteratorCoreCall”, cioè appunto un nodo
che itera in base a un Collection Data Provider e per ogni iterazione effettua
una chiamata a un altro servizio, il quale riceverà nel buffer di input una
property settata tramite un Object Data Provider. Inoltre è stata settata una
“condition” per uscire dall‟iterazione in caso di eccezione.
Per comprendere la funzionalità del Collection Data Provider va spiegato che
il DataHandler, per effettuare le sue operazioni, riceve i parametri in ingresso
e restituisce l‟output in file XML che sono nel seguente formato:
25
L’ Object-Graph Navigation Language (OGNL) è un linguaggio open-source per Java, che, anche utilizzando
semplici espressioni, permette di impostare e ottenere property ed eseguire metodi di classi Java.
Albanese Francescantonio, 79117
Pagina 85
<RowSet>
<data>
<row>
<col>VALORE</col>
…
…
</row>
…
…
</data>
</RowSet>
I Data Provider si settano sul file XML di configurazione “GVAdapters” o
nella sezione “Adapters” di VulCon come si può vedere dalla figura 5.3.
Quindi
il
nostro
Collection
Data
Provider
è
stato
configurato
con
l‟applicazione di una espressione xpath26 che naviga nei nodi del file XML di
output del DataHandler e seleziona le singole azioni restituite dalla select
effettuata.
26
XPath (XML Path Language ) è un linguaggio parte della famiglia XML che permette di individuare i nodi
all'interno di un documento XML. Le espressioni XPath, a differenza delle espressioni XML, non servono a
identificare la struttura di un documento, bensì a localizzarne con precisione i nodi.
Albanese Francescantonio, 79117
Pagina 86
Collection Data Provider XPATH Expression:
/RowSet/data/row/col/text()
L‟Object Data Provider che setta la property del buffer è stato, invece,
configurato con un‟espressione ognl.
Object Data Provider OGNL Expression:
property['ACTION_ID']=object.nodeValue
Una volta che finiscono le iterazioni e le elaborazioni dei servizi chiamati (che
vedremo più avanti), viene controllato il tutto da un altro nodo di check e, se
tutto è andato a buon fine, viene elaborato il nodo “create_zip_file”. Questo
nodo è sempre un nodo del tipo ChangeGVBuffer al quale viene applicata
un‟espressione ognl che crea un file ZIP contenente tutti i file ZIP restituiti
dal servizio EXPORT_ACTION.
Script OGNL:
#[email protected]@createTempFile('DAMA_PRJ','.zip'),
property['ZIP_PRJ_FILE_NAME']=#tempFile.getCanonicalPath(),
#outStream=new java.io.FileOutputStream(#tempFile,true),
#zos=new java.util.zip.ZipOutputStream(#outStream),
object.{
(#this instanceof java.lang.String) && (
Albanese Francescantonio, 79117
Pagina 87
#fileName=#this,
#inStream=new java.io.FileInputStream(#fileName),
#byteArray=new byte[2048],
#zipEntry= new
java.util.zip.ZipEntry(#fileName.substring(#fileName.lastIndexOf('/'))),
#zos.putNextEntry(#zipEntry),
#loop = :[#this>-1 && (#zos.write(#byteArray,0,#this),
#loop(#inStream.read(#byteArray)))], #loop(#inStream.read(#byteArray)),
#zos.closeEntry(),
new java.io.File(#fileName).delete()
)
},
#zos.close(),
#outStream.close()
Dopo aver creato il file ZIP e controllato che tutto sia andato a buon fine,
viene invocata l‟operazione di lettura del file nel nodo “read_zip_file”, che
utilizza
l‟operazione
“filereader”
sempre
definita
nel
canale
CHANNEL_WEBGUI del sistema DAMA. Dopodiché, se tutto è andato bene,
si passa al nodo “prepare_for_dh”, che è un nodo ChangeGVBuffer che,
tramite espressione ognl, costruisce il file XML da dare in input al
DataHandler.
Albanese Francescantonio, 79117
Pagina 88
Script OGNL:
property['ZIP_PRJ_FILE_DELETED']=new
java.io.File(property['ZIP_PRJ_FILE_NAME']).delete(),
property['DH_SERVICE_NAME']='DAMA::EXPORT_PROJECT_SAVE_ZIP',
#prjID=property['PRJ_ID'],
#[email protected]@encodeBase64S
tring(object),
#xmlString = "<RowSet><data><row id='1'></row><row id='2'/><row
id='3'/></data></RowSet>",
#[email protected]@parseDOM_S(#xmlString),
#docEl=#root.documentElement,
#data=#docEl.getFirstChild(),
#row=#data.getFirstChild(),
#col=#root.createElement('col'),
#col.appendChild(#root.createTextNode(#prjID)),
#row.appendChild(#col),
#col=#root.createElement('col'),
#col.setAttribute('type', 'base64'),
#col.appendChild(#root.createTextNode(#stringEncode)),
#row.appendChild(#col),
#col=#root.createElement('col'),
Albanese Francescantonio, 79117
Pagina 89
#col.appendChild(#root.createTextNode('export_' + #prjID + '.zip')),
#row.appendChild(#col),
object=#root
Se tutto è andato a buon fine si passa al nodo “save_attachment”, che
effettua il salvataggio del file ZIP sul database tramite il DataHandler. Infatti
il DataHandler può effettuare qualsiasi tipo di operazione sul database e nel
caso in questione effettua una chiamata a una “store procedure” passandogli
i parmetri in ingresso che abbiamo definito nell‟XML di input.
Alla fine, se anche l‟operazione di salvataggio è andata a buon fine, si passa
al nodo “call_check_result”, che è un nodo del tipo “CoreCall”, cioè che
effettua una chiamata singola a un altro servizio.
Vediamo ora questo servizio che è un servizio generico richiamato anche dal
nodo che setta la property di eccezione e da altri servizi del sistema
realizzato.
Albanese Francescantonio, 79117
Pagina 90
Servizio CHECK_RESULT:
Figura 5.5: Workflow per il servizio CHECK_RESULT
Questo servizio è stato implementato per generare un XML che verrà
restituito alla WebGui, la quale ne legge alcune property e, a seconda del
loro valore, all‟utente verrà mostrato un messaggio di esito positivo o
negativo dell‟export. In caso di esito negativo, poiché tutto il flusso EXPORT
PROJECTS è in un‟unica transazione, avverrà una “RollBack” totale che
permetterà all‟utente di mantenere l‟integrità dei dati sul DataBase, come
erano prima dell‟invocazione del servizio.
Andiamo ad analizzarlo nel dettaglio:
Albanese Francescantonio, 79117
Pagina 91
il primo nodo è un nodo di check come abbiamo già visto nel servizio
precedente, solo che in questo caso, oltre a gestire i due casi di default ed
eccezione, gestisce anche un ulteriore caso di routing. Per effettuare ciò è
stata settata una condition, agganciata alla freccia di connessione del nodo
di check, che verifica se la property del buffer “EXCEPTION_STACK” è
valorizzata con l‟eccezione o meno.
In caso di verifica positiva della condition si passa al nodo “operation_error”
che è un nodo ChangeGVBuffer sul quale è agganciata una Trasformazione
XSL27 che crea l‟XML di output nel caso si sia verifica un‟eccezione.
In caso che la condition non si verifichi il nodo di check intraprende l‟opzione
di default e passa al nodo ChangeGVBuffer “operation_correct”, che sempre
grazie a una Trasformazione XSL crea l‟XML di output di successo
dell‟operazione.
Torniamo ora al servizio EXPORT_PROJECT e andiamo ad analizzare il
servizio chiamato da quest‟ultimo, cioè EXPORT_ACTION.
Servizio EXPORT_ACTION:
input: Identificativo dell‟action
27
L'XSLT (eXtensible Stylesheet Language Transformations) è il linguaggio di trasformazione dell’XML; deriva
direttamente dal linguaggio XSL, infatti i file di questo formato sono essenzialmente file di testo, contengono
elementi ed attributi ed hanno l'estensione ".xsl". L'XSLT è diventato uno standard web con una direttiva
(Recommendation) W3C del 16 Novembre 1999. L'obiettivo principale per cui l'XSLT è stato creato è rendere
possibile la trasformazione di un documento XML in un altro documento anche XML.
Albanese Francescantonio, 79117
Pagina 92
output: File .ZIP
Figura 5.6: Activity Diagram per il servizio EXPORT_ACTION
La figura 5.6 mostra l‟Activity Diagram dal quale si è partiti per la
realizzazione del servizio Export Action che ora vedremo.
Albanese Francescantonio, 79117
Pagina 93
Figura 5.7: Workflow per il servizio EXPORT_ACTION
Questo servizio riceve in input l‟identificativo della action, passatogli dal
servizio chiamante tramite property del buffer. Il primo nodo “select_tasks”
effettua una select sul database tramite DataHandler e recupera tutti i task
con i relativi task_type effettuati da quella action. Una volta fatto ciò e
controllato che l‟operazione è andata a buon fine si passa a un altro nodo del
tipo IteratorCoreCall come visto per il servizio EXPORT_PROJECT, il quale è
sempre configurato con un Collection Data Provider e un Object Data
Provider.
Albanese Francescantonio, 79117
Pagina 94
Collection Data Provider XPATH Expression:
/RowSet/data/row
Object Data Provider OGNL Expression:
property['TASK_ID'][email protected]@get_S(object,
'col[1]/text()'),
property['TASK_TYPE_ID'][email protected]@get_S(object,
'col[2]/text()')
Il risultato dell‟elaborazione del servizio chiamato viene controllato da un
nodo di check e passato al nodo ChangeGVBuffer “array_to_xml”, il quale
trasforma ciò che gli arriva nel buffer in input che è un array in un file XML
e setta una property booleana in base a se ci sono o meno dati da esportare,
il tutto tramite uno script ognl.
Script OGNL:
#[email protected]@parseDOM_S("<root/>"),
#docEl=#root.documentElement,
#exportDataExists = 'false',
object.{
#this.{
#this.{
Albanese Francescantonio, 79117
Pagina 95
#currentNode = (#this instanceof
org.w3c.dom.Document ? #this.documentElement : #this),
#newNode = #root.importNode(#currentNode, true),
#docEl.appendChild(#newNode),
#exportDataExists = 'true'
}
}
},
property['EXPORT_DATA_EXISTS'] = #exportDataExists,
[email protected]@serializeDOMToByteArray_S(#roo
t)
In seguito si passa a un nodo di check che effettua routing su tre diverse
possibilità; infatti, oltre al solito discorso sull‟eccezione, il nodo prevede una
condition in base alla property booleana settata nel nodo precedente. Se
questa property è „false‟ il flusso termina, altrimenti continua e si passa al
nodo “map”. Questo nodo è un ChangeGVBuffer al quale è agganciata una
Trasformazione XSL che realizza una fusione di tutti i frammenti di EXPORT
XML. Infine si passa al nodo “create_zip_file” che realizza un file ZIP dei file
XML creati tramite script ognl.
Script OGNL:
#[email protected]@createTempFile('DAMA','.zip'),
Albanese Francescantonio, 79117
Pagina 96
property['ZIP_FILE_NAME']=#tempFile.getCanonicalPath(),
#outStream=new java.io.FileOutputStream(#tempFile,true),
#zos=new java.util.zip.ZipOutputStream(#outStream),
#[email protected]@getParserInstance(),
#index=1,
#nlDEL=#xml.selectNodeList(object, "/root/lock[modifier='delete']"),
#nlDEL==null || (
#loop = :[ #this<#nlDEL.length && (
#byteArray=#xml.serializeDOMToByteArray(#nlDEL.item(#this)),
#zipEntry= new java.util.zip.ZipEntry(#index + '_' +
'DELETECONFIG' + '.xml'),
#zos.putNextEntry(#zipEntry),
#zos.write(#byteArray,0,#byteArray.length),
#zos.closeEntry(),
#index=#index +1,
#loop(#this+1)
)], #loop(0)
),
#nlRNC=#xml.selectNodeList(object, '/root/cnf:bulkCmConfigDataFile'),
#loop = :[ #this<#nlRNC.length && (
#byteArray=#xml.serializeDOMToByteArray(#nlRNC.item(#this)),
#RNCName=#xml.get(#nlRNC.item(#this),'*/*/*/*/@id'),
Albanese Francescantonio, 79117
Pagina 97
#zipEntry= new java.util.zip.ZipEntry(#index + '_' + #RNCName + '_' +
@java.lang.System@currentTimeMillis() + '.xml'),
#zos.putNextEntry(#zipEntry),
#zos.write(#byteArray,0,#byteArray.length),
#zos.closeEntry(),
#index=#index +1,
#loop(#this+1)
)], #loop(0),
#nlCREATE=#xml.selectNodeList(object, "/root/lock[modifier='create']"),
#nlCREATE==null || (
#loop = :[ #this<#nlCREATE.length && (
#byteArray=#xml.serializeDOMToByteArray(#nlCREATE.item(#this)),
#zipEntry= new java.util.zip.ZipEntry(#index + '_' +
'CREATECONFIG' + '.xml'),
#zos.putNextEntry(#zipEntry),
#zos.write(#byteArray,0,#byteArray.length),
#zos.closeEntry(),
#index=#index +1,
#loop(#this+1)
)], #loop(0)
),
#zos.close(),
#outStream.close(),
Albanese Francescantonio, 79117
Pagina 98
@it.greenvulcano.util.xml.XMLUtils@releaseParserInstance(#xml),
object=property['ZIP_FILE_NAME']
Passiamo ora a descrivere il servizio chiamato da EXPORT_ACTION e cioè
EXPORT_SINGLE_TASK.
Servizio EXPORT_SINGLE_TASK:
Figura 5.7: Activity Diagram per il servizio
EXPORT_SINGLE_TASK
Albanese Francescantonio, 79117
Pagina 99
La figura 5.7 mostra il semplice Activity Diagram dal quale si è partiti per la
realizzazione del servizio.
Figura 5.8: Workflow per il servizio EXPORT_SINGLE_TASK
Questo semplice servizio riceve in input le property settate nel buffer dal
servizio chiamante e nel primo nodo realizza una select sul database per
recuperare
alcune
informazioni
utili.
In
seguito
si
passa
al
nodo
“export_for_single_entity” che è un altro nodo del tipo IteratorCoreCall che
Albanese Francescantonio, 79117
Pagina 100
chiama un altro servizio sempre utilizzando un Collection Data Provider e un
Object Data Provider.
Collection Data Provider XPATH Expression:
/RowSet/data
Object Data Provider OGNL Expression:
property['DB_ENTITY_TYPE_ID'][email protected]@get_S(o
bject, '@key_1'),
property['EXTRA_PARAM_ID'][email protected]@get_S(obj
ect, '@key_2'),
#extraParam=property['EXTRA_PARAM_ID'],
property['DH_SERVICE_NAME']='DAMA::EXPORT_'+property['TASK_TYPE_ID'
]+'_'+property['DB_ENTITY_TYPE_ID']+(#extraParam=='' ? '' : '_' +
#extraParam),
object
In particolare l‟Object Data Provider setta una property molto interessante,
che
è
“DH_SERVICE_NAME”.
Infatti
il
DataHandler
decide
quale
configurazione applicare in base a questa property se è settata, altrimenti in
base a uno standard: NOME_SERVIZIO::NOME_SISTEMA.
Albanese Francescantonio, 79117
Pagina 101
Vediamo ora il servizio chiamato dal servizio appena descritto.
Servizio EXPORT_SINGLE_ENTITY:
input: Elementi coinvolti nell‟action
output: Frammento XML
Figura 5.9: Activity Diagram per il servizio
EXPORT_SINGLE_ENTITY
Albanese Francescantonio, 79117
Pagina 102
Figura 5.10: Workflow del servizio EXPORT_SINGLE_ENTITY
Questo servizio viene chiamato per ogni entità coinvolta nell‟action. Per ogni
elemento coinvolto esso crea un frammento di XML; tale frammento farà
parte dell‟export dei file di output. EXPORT_SINGLE_ENTITY riceve in input
gli elementi selezionati nel servizio chiamante e, in base a questi, e alla
property “DH_SERVICE_NAME” realizza una query sul database differente
tramite il DataHandler. In seguito, dopo aver controllato che l‟operazione è
andata a buon fine, si passa al nodo ChangeGVBuffer “choose_export_map”,
il quale applica una Trasformazione XSL al file XML restituito dalla chiamata
Albanese Francescantonio, 79117
Pagina 103
al DataHandler. Questa trasformazione realizza un altro file XML che
contiene il nome o i nomi delle trasformazioni successive da chiamare e i dati
estrapolati dal database.
Infine,
se
tutto
è
andato
a
buon
fine,
si
passa
al
nodo
“create_export_fragment”, un altro nodo di tipo IteratorCoreCall che però
questa volta è configurato solo con il Collection Data Provider.
Collection Data Provider XPATH Expression:
/OssMaps/map
Andiamo ora ad analizzare l‟ultimo servizio della serie chiamato.
Servizio EXPORT_SINGLE_OSS:
Figura 5.9: Workflow del servizio EXPORT_SINGLE_OSS
Albanese Francescantonio, 79117
Pagina 104
Questo semplice servizio riceve in input il file XML generato dal servizio
chiamante e il nodo ChangeGVBuffer “create_export_fragment” applica la
Trasformazione XSL corretta. Infatti essendo tutto molto dinamico la
trasformazione corretta da applicare viene definita dal nome che abbiamo
settato nel servizio chiamante, il quale viene letto tramite uno script ognl.
Script OGNL:
ognl{{@it.greenvulcano.util.xml.XMLUtils@get_S(object, '@call-map')}}
dove “@call-map” è l‟attributo del tag “map” che contiene il nome della
trasformazione.
Albanese Francescantonio, 79117
Pagina 105
Testing
Terminata la fase di analisi, e sviluppo si è passati ai test di unità (Unit
Test). Lo “unit testing” è una procedura usata per verificare singole parti di
un codice sorgente. Lo scopo dello unit testing è quello di verificare il
corretto funzionamento di parti di programma permettendo così una precoce
individuazione dei bug e degli errori. Uno unit testing accurato può dare una
prova certa se un pezzo di codice funziona correttamente, con importanti
vantaggi:
Semplifica le modifiche
Lo unit testing facilita la modifica del codice del modulo in momenti
successivi (“refactoring”) con la sicurezza che il modulo continuerà a
funzionare correttamente. Il procedimento consiste nello scrivere test
case per tutte le funzioni e i metodi, in modo che se una modifica
produce un fallimento del test, si possa facilmente individuare la
modifica responsabile.
Albanese Francescantonio, 79117
Pagina 106
Unit test già predisposti semplificano la vita al programmatore nel
controllare che una porzione di codice stia ancora funzionando
correttamente. Un buon unit testing produce test case che coprono
tutti i percorsi del codice dell'unità, con particolare attenzione alle
condizioni nei cicli (test sugli “if”, “while”, “for”).
In sistemi con unit testing continuo, tali test sono in grado di garantire
l'automatica integrità del codice ad ogni modifica.
Semplifica l'integrazione
Lo unit testing semplifica l'integrazione di moduli diversi perché limita
i malfunzionamenti dovuti a problemi nell'interazione tra i moduli e
non nei moduli stessi, rendendo i test di integrazione più semplici.
Un argomento molto dibattuto è quello della non necessità di test di
integrazione manuali, in caso si sia organizzata una procedura di unit
testing sufficientemente completa. In realtà spesso un elaborato
sistema di unit testing fornisce una falsa sicurezza e un test di
integrazione gestito da esseri umani
è in genere ugualmente
necessario. Probabilmente la reale necessità del fattore umano nella
procedura di test dipende dalle caratteristiche del sistema nel quale si
sviluppa e soprattutto dalla disponibilità di risorse.
Albanese Francescantonio, 79117
Pagina 107
Supporta la documentazione
Lo unit testing fornisce una documentazione "viva" del codice, perché è
intrinsecamente un esempio di utilizzo dell'API del modulo.
I test case incorporano le caratteristiche critiche per il successo di
un'unità di codice. Tali caratteristiche indicano l'uso appropriato
dell'unità e i comportamenti errati che devono essere identificati nel
suo
funzionamento.
Pertanto
lo
unit
testing
documenta
tali
caratteristiche, sebbene in molti ambienti questi non possono
costituire la sola documentazione necessaria. In compenso, la
tradizionale documentazione diventa spesso obsoleta a causa di
successive modifiche del codice non documentate.
Separazione dell'interfaccia dall'implementazione
Poiché alcune classi possono far riferimento ad altre, il test di una
classe spesso si propaga alle altre. Un esempio è una classe che
interagisce con un database: testare la classe spesso implica la
scrittura del codice che interagisce con il database. Questo è un
problema perché lo unit test non dovrebbe mai varcare i confini della
classe. La conseguenza è che il programmatore, nel progettare lo unit
testing, impara ad isolare la classe da analizzare, individuando
l'interfaccia con il database ed implementandola con un “mock object”,
Albanese Francescantonio, 79117
Pagina 108
una simulazione dell'oggetto reale che può essere effettuata in
condizioni controllate. L'effetto è un test più approfondito e quindi uno
unit testing di qualità più elevata.
Limitazioni dello unit testing
In generale il testing non riesce ad identificare tutti gli errori in un
programma e lo stesso vale per lo unit testing che, analizzando per
definizione le singole unità, non può identificare gli errori di
integrazione, problemi legati alla performance e altri problemi legati al
sistema in generale. Lo unit testing è più efficace se utilizzato in
congiunzione con altre tecniche di testing del software.
Come ogni forma di testing, anche lo unit testing non può individuare
l'assenza di errori ma può solo evidenziarne la presenza.
Il testing del software è un problema di matematica combinatoria. Per
esempio, ogni test booleano richiede almeno due test, uno per la
condizione di "true" e uno per quella di "false". Si può dimostrare che,
per ogni linea di codice funzionale, siano necessarie dalla 3 alle 5 linee
di codice per il test. È quindi irrealistico testare tutte le possibili
combinazioni di input di qualsiasi codice non banale senza un tool
apposito di generazione di casi di test.
Albanese Francescantonio, 79117
Pagina 109
Per ottenere gli sperati benefici dallo unit test, è richiesto un rigoroso
senso di disciplina durante tutto il processo di sviluppo. È essenziale
mantenere traccia non solo dei test che sono stati sviluppati ed
eseguiti, ma anche di tutte le modifiche effettuate al codice funzionale
dell'unità in esame e di tutte le altre. L'uso di un sistema di controllo
di versione è essenziale. Se una versione successiva di una unità
fallisce un test che aveva passato in precedenza, il sistema di controllo
di versione permette di evidenziare le modifiche al codice intervenute
nel frattempo.
Per eseguire lo unit test si è utilizzato il framework JUnit28.
Di seguito la configurazione junit del servizio Export_Project
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
package it.greenvulcano.dama.tests;
import static org.junit.Assert.fail;
import it.greenvulcano.gvesb.buffer.GVBuffer;
import it.greenvulcano.gvesb.core.ejb.J2EEGreenVulcano;
import it.greenvulcano.gvesb.core.ejb.J2EEGreenVulcanoHome;
import it.greenvulcano.util.xml.XMLUtils;
import java.io.File;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import org.w3c.dom.Document;
import org.w3c.dom.Node;
public class Test {
private static J2EEGreenVulcano greenVulcano;
28
JUnit è un unit test framework per il linguaggio di programmazione Java, che ha segnato l’inizio
dell’evoluzione dell’idea di sviluppo guidato da test (test-driven development).
Albanese Francescantonio, 79117
Pagina 110
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
@test
public static startExportProject(String args[]){ try{
GVBuffer input = new GVBuffer("DAMA", "EXPORT_PROJECT");
File file = new File("..\\..\\TestApply.xml");
DocumentBuilderFactory dbf =
DocumentBuilderFactory.newInstance();
DocumentBuilder db = dbf.newDocumentBuilder();
Document doc = db.parse(file);
input.setObject(XMLUtils.serializeDOMToByteArray_S(doc));
GVBuffer result = executeService(input);
if(result.getRetCode()!= 1)
fail("APPLY_PROJECT execute with error");
}catch(Exception e){
e.printStackTrace();
}
}
/* ExecuteService chiama il servizio EXPORT_PROJECT /*
protected static GVBuffer executeService(GVBuffer input) throws
Exception{
GVBuffer response = getGreenVulcano().requestReply(input);
XMLUtils xml = XMLUtils.getParserInstance();
String retCode = "-1";
try {
Object object = response.getObject();
if (object instanceof Node) {
Node node = (Node) object;
retCode = xml.get(node, "/response/retCode", "-1");
}
else {
retCode = "1";
}
}
finally {
XMLUtils.releaseParserInstance(xml);
}
boolean ret = "1".equals(retCode);
response.setRetCode(Integer.parseInt(retCode));
return response;
}
Albanese Francescantonio, 79117
Pagina 111
75.
/* Questo metodo, che serve per prendersi il riferimento
dell’EJB
dall’albero JNDI dell’application server, è stato creato
come un Singleton in modo di avere un’unica istanza della classe
J2EEGreenVulcano /*
76.
77.
private static synchronized J2EEGreenVulcano getGreenVulcano()
throws Exception{
78.
79.
if (greenVulcano == null) {
80.
Context initialContext = new InitialContext();
81.
J2EEGreenVulcanoHome home = (J2EEGreenVulcanoHome)
initialContext.lookup("gvesb/core/GreenVulcano");
82.
greenVulcano = home.create();
83.
}
84.
return greenVulcano;
85.
}
86.
87.
}
88.
Il metodo Junit startExportProject legge il file TestApply.xml dal file
system, lo parsa, e lo setta nel buffer di GreenVulcanoESB.
La riga “GVBuffer result = executeService(input);” invoca il servizio
sull‟ESB. Se L‟ESB ritorna con “retCode” uguale a 1 l‟esecuzione del servizio
è in “success” altrimenti va in “failure”.
L‟esempio riportato non rispetta del tutto lo standard Unit test, infatti lo
standard richiederebbe di scrivere singoli unit test per tutte le singole
procedure che compongono il servizio. Per ragioni di tempo si è scelto di fare
un singolo Unit Test per l‟intero Servizio di Export.
Albanese Francescantonio, 79117
Pagina 112
File TestApply.xml
<response>
<actions>
<id>975</id>
<configRBS>false</configRBS>
<rnc>
<numberFile>0</numberFile>
<rncId>53246</rncId>
<rncName>111</rncName>
</rnc>
<ran>false</ran>
<cn>false</cn>
<TN>false</TN>
<actionname>Add node</actionname>
</actions>
</response>
Albanese Francescantonio, 79117
Pagina 113
Conclusioni
Nello svolgimento di questa tesi è stata presentata una possibile applicazione
dell‟Enterprise Service Bus e sono state messe in risalto solo alcune delle
funzionalità di questo strumento quali la composizione di servizi, il routing
intelligente dei messaggi e la trasformazione dei dati, ma ce ne sono tante
altre e tutte molto utili nel campo dell‟integrazione applicativa. L‟ESB è un
concetto di tecnologia aperta basata su standard che stanno rivoluzionando
l‟informatica. L‟ESB emergerà come backbone dell‟infrastruttura distribuita
all‟interno
dell‟azienda
informatica,
poiché,
oltre
a
consentire
il
mantenimento e l‟implementazione dei sistemi business-critical in uso,
permetterà all‟utente di introdurre nuove applicazioni in funzione delle
proprie necessità. Credo che l‟integrazione applicativa sia uno dei principali
fattori di innovazione dell‟industria software e che l‟ESB abbia trasformato il
mondo dell‟integrazione con una soluzione basata su standard che riduce i
costi, impedisce qualsiasi vincolo nei confronti di un singolo fornitore,
assicura flessibilità e scalabilità.
Albanese Francescantonio, 79117
Pagina 114
Bibliografia
1. David A. Chappel, “Enterprise Service Bus”, O'Reilly, 2004
2. Mike Gilpin, Vice President e Research Director, “What Is An
Enterprise Service Bus?”, 2004
3. Roy Schulte, Presentazione: “The Future of Application Integration”,
Gartner, 2004
4. Nicolai M. Josuttis, “SOA in Practice – The Art of Distributed System
Design”, O'Reilly, 2007
5. MokaByte: Articoli. On line at: http://www.mokabyte.it/
6. MokaByte: Service-Oriented Architecture. On line at:
http://www.mokabyte.it/2004/09/soa.htm
7. W3C: Web Services Architecture. On line at: http://www.w3.org/TR/wsarch
8. W3C: Web Services Architecture Requirements. On line at:
http://www.w3.org/TR/wsa-reqs
9. Web Services e Service-Oriented Architecture: Documentazione. On
line at: http://www.service-architecture.com
10.
Web Service Description Language: Documentazione. On line at:
http://www.w3.org/TR/wsdl
Albanese Francescantonio, 79117
Pagina 115
11.
eXtensible Markup Language: Documentazione. On line at:
http://www.xml.com
12.
UDDI: Documentazione. On line at: http://www.uddi.org
13.
SUN: Java. On line at: http://java.sun.com
14.
Apache Axis: Sito ufficiale. On line at: http://ws.apache.org/axis/
15.
Simple Object Access Protocol: Documentazione. On line at:
http://www.w3.org/TR/soap
16.
S. Davis, T. Marrs, “JBoss at work: A Pratical Guide”, O‟Reilly,
2005
17.
JBoss: Sito ufficiale. On line at: http://www.jboss.org
18.
Eclipse: Sito ufficiale. On line at: http://www.eclipse.org
19.
The Java Web Services Tutorial. Sun Microsystems, 2003
20.
Italian Wikipedia. On line at:
http://it.wikipedia.org/wiki/Pagina_principale
Albanese Francescantonio, 79117
Pagina 116