Università della Calabriaweb.mclink.it/MN3298/gv-site-docs/TesiAlbaneseFrancesc...(presentation), a...

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 Francescantonio ALBANESE

Dott. Ciro ROMANO

Albanese Francescantonio, 79117 Pagina 1

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


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


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


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


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


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


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.


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”.


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.


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.


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.


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 customer-

care) 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,


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.).


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.


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.


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 Service-

Oriented 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


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.


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,


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.


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


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.


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:


• 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.


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.


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.


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


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


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


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.


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.


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


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


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.


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


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).


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.


Figura 2.5: Sistema con architettura Service-Oriented

realizzato con la tecnologia dei Web Services.


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


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


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 inter-

operare.

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


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-and-

Spoke


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


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


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.


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”.


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


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.


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


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.


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.


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”.


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”).


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


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.


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


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


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.


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.


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.


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.


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.


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.


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


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.


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.


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


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


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


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)


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 CDMA-

2000.

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


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.


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


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).


- 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.


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.


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


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.


(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).


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.


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


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


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.


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


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


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.


<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.


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) && (


#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.


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.setAttribute('type', 'base64'),

#col.appendChild(#root.createTextNode(#stringEncode)),




#col.appendChild(#root.createTextNode('export_' + #prjID + '.zip')),


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.


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:


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.


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.


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.



/RowSet/data/row


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.{


#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'),


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.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'),


#zipEntry= new java.util.zip.ZipEntry(#index + '_' + #RNCName + '_' +

@java.lang.System@currentTimeMillis() + '.xml'),



#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.closeEntry(),

#index=#index +1,

#loop(#this+1)

)], #loop(0)

),

#zos.close(),

#outStream.close(),


@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:


EXPORT_SINGLE_TASK


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


chiama un altro servizio sempre utilizzando un Collection Data Provider e un

Object Data Provider.


/RowSet/data


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.


Vediamo ora il servizio chiamato dal servizio appena descritto.

Servizio EXPORT_SINGLE_ENTITY:

input: Elementi coinvolti nell‟action

output: Frammento XML


EXPORT_SINGLE_ENTITY


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


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.


/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


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.


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.


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.


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”,


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.


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. package it.greenvulcano.dama.tests;

5. import static org.junit.Assert.fail;

6. import it.greenvulcano.gvesb.buffer.GVBuffer;

7. import it.greenvulcano.gvesb.core.ejb.J2EEGreenVulcano;

8. import it.greenvulcano.gvesb.core.ejb.J2EEGreenVulcanoHome;

9. import it.greenvulcano.util.xml.XMLUtils;

10. import java.io.File;

11. import javax.naming.Context;

12. import javax.naming.InitialContext;

13. import javax.xml.parsers.DocumentBuilder;

14. import javax.xml.parsers.DocumentBuilderFactory;

15. import org.w3c.dom.Document;

16. import org.w3c.dom.Node;

17.

18. public class Test {

19. private static J2EEGreenVulcano greenVulcano;

20.

21.

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).


22. @test

23. public static startExportProject(String args[]){ try{

24.

25. GVBuffer input = new GVBuffer("DAMA", "EXPORT_PROJECT");

26. File file = new File("..\\..\\TestApply.xml");

27. DocumentBuilderFactory dbf =

DocumentBuilderFactory.newInstance();

28. DocumentBuilder db = dbf.newDocumentBuilder();

29. Document doc = db.parse(file);

30. input.setObject(XMLUtils.serializeDOMToByteArray_S(doc));

31.

32. GVBuffer result = executeService(input);

33.

34. if(result.getRetCode()!= 1)

35. fail("APPLY_PROJECT execute with error");

36.

37. }catch(Exception e){

38.

39. e.printStackTrace();

40.

41. }

42.

43. }

44.

45. /* ExecuteService chiama il servizio EXPORT_PROJECT /*

46.

47. protected static GVBuffer executeService(GVBuffer input) throws

Exception{

48.

49. GVBuffer response = getGreenVulcano().requestReply(input);

50. XMLUtils xml = XMLUtils.getParserInstance();

51. String retCode = "-1";

52. try {

53. Object object = response.getObject();

54. if (object instanceof Node) {

55. Node node = (Node) object;

56. retCode = xml.get(node, "/response/retCode", "-1");

57. }

58. else {

59. retCode = "1";

60. }

61. }

62. finally {

63. XMLUtils.releaseParserInstance(xml);

64. }

65. boolean ret = "1".equals(retCode);

66. response.setRetCode(Integer.parseInt(retCode));

67. return response;

68. }

69.

70.

71.

72.

73.

74.


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.


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>


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à.


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/ws-

arch

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

http://www.mokabyte.it/

http://www.mokabyte.it/2004/09/soa.htm

http://www.w3.org/TR/ws-arch

http://www.w3.org/TR/ws-arch

http://www.w3.org/TR/wsa-reqs

http://www.service-architecture.com/

http://www.w3.org/TR/wsdl


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

http://www.xml.com/

http://www.uddi.org/

http://java.sun.com/

http://ws.apache.org/axis/

http://www.w3.org/TR/soap

http://www.jboss.org/

http://www.eclipse.org/

http://it.wikipedia.org/wiki/Pagina_principale

Università della Calabriaweb.mclink.it/MN3298/gv-site-docs/TesiAlbaneseFrancesc...(presentation), a...

Documents

Transcript of Università della Calabriaweb.mclink.it/MN3298/gv-site-docs/TesiAlbaneseFrancesc...(presentation), a...